Hướng dẫn nâng cấp GitLab EE 19.2.4 lên 19.3.2 an toàn trên Ubuntu 24.04
Ngày thực hiện: 12/09/2026
Môi trường: Ubuntu 24.04 LTS, GitLab Enterprise Edition cài bằng Linux Package/Omnibus
Lộ trình thực tế: 19.2.4-ee → 19.2.6-ee → 19.3.2-ee
GitLab ngày 10/09/2026 đã phát hành bản vá bảo mật quan trọng gồm 19.3.2, 19.2.6 và 19.1.8, đồng thời khuyến nghị các hệ thống GitLab Self-Managed nâng cấp sớm.
Trong bài này, CloudX chia sẻ toàn bộ quy trình nâng cấp thực tế một máy chủ GitLab EE đang chạy production từ 19.2.4-ee lên 19.3.2-ee, bao gồm kiểm tra hệ thống, backup, kiểm tra database migration, background migration và xác nhận hệ thống sau khi nâng cấp.
1. Môi trường GitLab trước khi nâng cấp
Máy chủ được sử dụng trong quá trình nâng cấp có cấu hình phần mềm:
OS: Ubuntu 24.04
GitLab: 19.2.4-ee
PostgreSQL: 17.10
Redis: 7.2.14
Ruby: 3.3.11
GitLab EE package: 19.2.4-ee.0
GitLab được cài theo dạng Linux Package:
dpkg -l | grep -E 'gitlab-(ee|ce)'
Kết quả:
ii gitlab-ee 19.2.4-ee.0 amd64
Dung lượng ổ đĩa lúc thực hiện còn hơn 170 GB nên không có vấn đề về không gian lưu trữ trong lúc upgrade.
2. Tại sao không nên chạy apt upgrade trực tiếp?
Khi nâng GitLab production, chúng tôi không dùng:
sudo apt upgrade
và cũng không dùng:
sudo apt install gitlab-ee
nếu đang cần kiểm soát chính xác lộ trình phiên bản.
GitLab khuyến nghị khi upgrade qua nhiều phiên bản nên chỉ định chính xác package muốn cài, ví dụ:
sudo apt install gitlab-ee=
Cách này giúp tránh việc hệ thống tự nhảy lên phiên bản ngoài dự kiến.
Trong case CloudX, chúng tôi chủ động đi:
19.2.4
↓
19.2.6
↓
19.3.2
Việc đi qua 19.2.6 không phải là một required stop riêng, mà là lựa chọn thận trọng để trước tiên đưa hệ thống lên bản vá mới nhất của nhánh 19.2 rồi mới chuyển sang 19.3.
3. Kiểm tra trạng thái GitLab trước khi nâng cấp
Trước khi thực hiện bất kỳ thay đổi nào, chạy:
sudo gitlab-ctl status
Các thành phần quan trọng phải ở trạng thái run, ví dụ:
gitaly
gitlab-workhorse
nginx
postgresql
puma
redis
sidekiq
Tiếp tục chạy health check:
sudo gitlab-rake gitlab:check SANITIZE=true
Cần đặc biệt chú ý các dòng:
Internal API available: OK
Redis available via internal API: OK
Gitaly: ... OK
Sidekiq: ... Running? ... yes
All migrations up? ... yes
GitLab chính thức khuyến nghị thực hiện health check trước và sau mỗi bước upgrade.
4. Backup GitLab trước khi upgrade
Dù máy chủ đã có snapshot VM, CloudX vẫn thực hiện thêm backup native của GitLab.
Backup database, repositories, uploads và dữ liệu GitLab:
sudo gitlab-backup create
Backup cấu hình GitLab:
sudo gitlab-ctl backup-etc
Có thể kiểm tra:
sudo ls -lh /var/opt/gitlab/backups/
sudo ls -lh /etc/gitlab/config_backup/
Ngoài GitLab backup, nếu GitLab chạy trên VMware, Proxmox, Hyper-V hoặc nền tảng ảo hóa khác, nên tạo một snapshot VM trước mỗi mốc upgrade quan trọng.
Ví dụ:
gitlab-19.2.4-before-upgrade
và sau khi 19.2.6 ổn định:
gitlab-19.2.6-before-19.3.2
Điều này tạo thêm một phương án rollback nhanh trong trường hợp package upgrade hoặc database migration gặp sự cố.
5. Kiểm tra package GitLab 19.2.6
Cập nhật danh sách package:
sudo apt update
Kiểm tra repository:
apt-cache madison gitlab-ee | grep '19.2.6'
Trong trường hợp của CloudX:
gitlab-ee | 19.2.6-ee.0
Khi đúng package đã xuất hiện, tiến hành nâng cấp:
sudo apt install gitlab-ee=19.2.6-ee.0
Khi apt hỏi:
Do you want to continue? [Y/n]
chọn:
Y
Không nên Ctrl+C, reboot hoặc ngắt quá trình trong lúc package đang chạy migrations hoặc gitlab-ctl reconfigure.
GitLab 19.2.6 là một trong các bản critical patch được phát hành ngày 10/09/2026.
6. Kiểm tra GitLab 19.2.6 sau upgrade
Sau khi package hoàn thành:
sudo gitlab-ctl status
Kiểm tra version:
sudo gitlab-rake gitlab:env:info | grep -E 'Version:|DB Version'
Kết quả phải thể hiện:
Version: 19.2.6-ee
Tiếp tục kiểm tra database migrations:
sudo gitlab-rake db:migrate:status | awk '$1=="down"'
Nếu không có kết quả trả về thì không có migration nào còn ở trạng thái down.
Không nên dùng:
grep down
vì lệnh này có thể bắt nhầm các migration chứa chữ như:
Markdown
do từ Markdown cũng chứa chuỗi down.
7. Kiểm tra Background Migration trước khi nâng tiếp
Đây là bước rất quan trọng và không nên bỏ qua.
Chạy:
sudo gitlab-rake gitlab:background_migrations:list
GitLab yêu cầu các background migrations phải hoàn tất trước khi tiếp tục lên phiên bản kế tiếp. Các migration này được Sidekiq xử lý trong nền và GitLab vẫn có thể hoạt động trong thời gian đó.
Có thể kiểm tra nhanh migration chưa hoàn thành bằng:
sudo gitlab-rake gitlab:background_migrations:list | grep -E 'active|failed|paused'
Nếu không có output, có thể tiếp tục.
Một cách kiểm tra trực tiếp database mà GitLab cũng hướng dẫn là:
sudo gitlab-psql -c "
SELECT
job_class_name,
table_name,
column_name,
job_arguments
FROM batched_background_migrations
WHERE status NOT IN (3,6);
"
Nếu query trả về:
0 rows
thì các batched background migrations đã hoàn tất.
8. Kiểm tra khả năng giải mã secrets
Trước khi tiếp tục upgrade, chạy:
sudo gitlab-rake gitlab:doctor:secrets
Trong hệ thống CloudX, toàn bộ các đối tượng kiểm tra đều:
failures: 0
và kết thúc:
Total: 0 row(s) affected
Done!
GitLab cũng đưa việc kiểm tra encrypted database values vào quy trình kiểm tra trước upgrade.
9. Nâng GitLab EE 19.2.6 lên 19.3.2
Trước tiên kiểm tra package:
sudo apt update
apt-cache madison gitlab-ee | grep '19.3.2'
Khi repository có:
19.3.2-ee.0
tiến hành:
sudo apt install gitlab-ee=19.3.2-ee.0
GitLab 19.3.2 cũng nằm trong đợt critical patch ngày 10/09/2026. GitLab khuyến nghị các hệ thống Self-Managed nâng lên một trong những phiên bản đã được vá.
10. Kết quả thực tế sau khi lên GitLab 19.3.2
Sau upgrade, máy chủ CloudX ghi nhận:
Ruby Version: 3.3.12
Redis Version: 7.2.16
GitLab Version: 19.3.2-ee
DB Version: 17.10
Gitaly Version: 19.3.2
Đây là kết quả thực tế trên máy chủ sau quá trình nâng cấp.
Tiếp tục chạy:
sudo gitlab-rake gitlab:check SANITIZE=true
Hệ thống CloudX sau nâng cấp có:
Internal API available: OK
Redis available via internal API: OK
Gitaly: ... OK
Sidekiq: ... Running? ... yes
All migrations up? ... yes
GitLab config up to date? ... yes
11. Một điểm quan trọng: web chạy được chưa có nghĩa upgrade đã hoàn toàn kết thúc
Ngay sau khi lên 19.3.2, website GitLab của CloudX đã hoạt động bình thường nhưng khi chạy:
sudo gitlab-rake gitlab:background_migrations:list
vẫn còn hai migration:
CleanupRepositoryLanguagesLanguageId | active
UpdateStepUrlToWelcomePath | active
Đây là lý do không nên lập tức tiếp tục nâng GitLab chỉ vì giao diện web đã truy cập được.
GitLab quy định tất cả background migrations phải hoàn thành trước mỗi bước nâng cấp tiếp theo.
Chúng tôi để Sidekiq tiếp tục xử lý và kiểm tra lại:
sudo gitlab-rake gitlab:background_migrations:list | grep -E 'active|failed|paused'
Sau khi lệnh không trả về kết quả, có thể xác nhận không còn migration thuộc các trạng thái trên.
12. Nếu bấm Ctrl+C khi chạy gitlab-rake và thấy stack trace thì sao?
Trong quá trình kiểm tra, nếu chạy:
sudo gitlab-rake gitlab:background_migrations:list
và nhấn:
Ctrl+C
khi Ruby/Rake còn đang khởi động, có thể xuất hiện stack trace dài và dòng:
Interrupt
Ví dụ stack trace có thể bắt đầu từ RubyGems, Bundler hoặc rake.
Điều này không có nghĩa GitLab bị lỗi. Nó chỉ thể hiện tiến trình gitlab-rake bị người dùng gửi tín hiệu interrupt.
Chỉ cần chạy lại command và chờ nó hoàn thành.
13. Kiểm tra Git thực tế sau nâng cấp
Ngoài giao diện web, nên kiểm tra cả SSH và Git operation.
Kiểm tra SSH:
ssh -T [email protected]
Nếu thành công thường sẽ thấy:
Welcome to GitLab, @username!
Sau đó thử trên một repository test:
git pull
và:
git push
Việc này giúp xác nhận đồng thời GitLab Shell, Gitaly, SSH và repository access đều hoạt động.
14. Required Upgrade Stops của GitLab 19
Đối với GitLab 19, GitLab công bố các required upgrade stop tại:
19.2
19.5
19.8
19.11
Có nghĩa là nếu sau này nâng lên các version cao hơn, không nên tùy ý nhảy qua các mốc này.
Ví dụ một lộ trình trong tương lai có thể là:
19.3.x
↓
19.4.x
↓
19.5.x ← required stop
↓
...
19.8.x ← required stop
↓
...
19.11.x ← required stop
Tại thời điểm thực hiện bài viết, GitLab 19.4 vẫn đang được GitLab ghi nhận là Upcoming release, trong khi GitLab 19.3 đã được phát hành ngày 20/08/2026.
15. Bộ lệnh kiểm tra nhanh trước và sau mỗi lần upgrade
Đây là bộ lệnh CloudX sử dụng để kiểm tra một GitLab Linux Package trước khi chuyển sang phiên bản tiếp theo:
# Kiểm tra service
sudo gitlab-ctl status
# Kiểm tra tổng thể GitLab
sudo gitlab-rake gitlab:check SANITIZE=true
# Kiểm tra version
sudo gitlab-rake gitlab:env:info | grep -E 'Version:|DB Version'
# Kiểm tra regular migrations còn down
sudo gitlab-rake db:migrate:status | awk '$1=="down"'
# Kiểm tra background migrations chưa hoàn tất
sudo gitlab-rake gitlab:background_migrations:list | grep -E 'active|failed|paused'
# Kiểm tra encrypted secrets
sudo gitlab-rake gitlab:doctor:secrets
# Kiểm tra dung lượng
df -h
Nếu tất cả đều sạch thì mới chuyển sang bước nâng tiếp theo.
16. Một số lỗi thường gặp cần tránh
Không nên upgrade nhiều component của Ubuntu cùng lúc với GitLab nếu không cần thiết. Việc tách riêng GitLab upgrade giúp dễ xác định nguyên nhân nếu hệ thống có lỗi.
Không nên chạy:
sudo apt upgrade
chỉ với mục đích nâng GitLab.
Không nên nhảy nhiều minor version mà chưa xem required upgrade stops.
Không nên bỏ qua:
gitlab:background_migrations:list
vì regular migration có thể đã hoàn tất nhưng background migration vẫn đang chạy.
Không nên downgrade package GitLab ngay khi migration gặp lỗi. Nếu cần rollback, nên thực hiện theo đúng backup/snapshot tương ứng với phiên bản trước đó.
Đặc biệt, GitLab truy cập web bình thường không đồng nghĩa toàn bộ upgrade process đã kết thúc.
Kết luận
Quá trình nâng cấp GitLab EE tại CloudX đã hoàn thành thành công theo lộ trình:
Ubuntu 24.04
GitLab EE 19.2.4
↓
GitLab EE 19.2.6
↓
GitLab EE 19.3.2
Sau upgrade:
GitLab: 19.3.2-ee
Gitaly: 19.3.2
Ruby: 3.3.12
Redis: 7.2.16
PostgreSQL: 17.10
GitLab check: OK
Database migrations: OK
Background migrations: OK
Secrets check: 0 failures
GitLab Web: OK
Quy tắc quan trọng nhất khi nâng cấp GitLab production là:
Backup
↓
Health Check
↓
Kiểm tra Upgrade Path
↓
Cài đúng package version
↓
Kiểm tra Service
↓
Kiểm tra Database Migration
↓
Chờ Background Migration hoàn tất
↓
Mới nâng phiên bản tiếp theo
Với GitLab Self-Managed, cách làm này an toàn hơn nhiều so với việc chỉ chạy một lệnh apt upgrade rồi chờ kết quả.
Thông tin SEO gợi ý cho CloudX
SEO Title:
Hướng dẫn nâng cấp GitLab EE 19.2.4 lên 19.3.2 an toàn trên Ubuntu 24.04
Slug:
huong-dan-nang-cap-gitlab-19-2-4-len-19-3-2-ubuntu-24-04
Meta Description:
Hướng dẫn chi tiết nâng cấp GitLab Enterprise Edition từ 19.2.4 lên 19.2.6 và 19.3.2 trên Ubuntu 24.04, bao gồm backup, database migration, background migration, health check và kiểm tra sau upgrade.
Focus Keyword:
nâng cấp GitLab
Các từ khóa phụ phù hợp:
upgrade GitLab Ubuntu 24.04
GitLab 19.3.2
GitLab EE upgrade
GitLab background migration
GitLab Omnibus upgrade
GitLab Self-Managed
Tôi khuyên khi đăng trên cloudx.com.vn, dùng tiêu đề:
Hướng dẫn nâng cấp GitLab EE 19.2.4 lên 19.3.2 an toàn trên Ubuntu 24.04 – Case thực tế CloudX
Cách đặt này vừa có từ khóa tìm kiếm, vừa thể hiện đây là quy trình đã triển khai thực tế, thay vì bài dịch tài liệu GitLab.
