Tự host GitLab trên Cloud Server: quản lý code riêng cho team 20 người

Code là tài sản cốt lõi của công ty phần mềm — nhưng bao nhiêu team Việt Nam đang đặt toàn bộ "gia tài" đó trên tài khoản SaaS nước ngoài, phụ thuộc vào thẻ Visa công ty và chính sách giá thay đổi mỗi năm? Khi team vượt qua 10–15 người, câu hỏi tự host GitLab trên hạ tầng riêng bắt đầu trở nên nghiêm túc: chủ động hoàn toàn về dữ liệu, không giới hạn CI/CD minutes, chi phí cố định dễ dự toán.

Bài viết này hướng dẫn chi tiết cách tự host GitLab trên Cloud Server cho team khoảng 20 người: từ chọn cấu hình, cài đặt, đến tổ chức workflow và vận hành lâu dài — đúc kết từ các deployment thực tế cho team outsource và product tại Việt Nam.

Tự host gitlab: vì sao team 20 người nên nghĩ đến GitLab self-hosted?

1. Chi phí SaaS tăng theo đầu người. GitLab.com gói Premium khoảng 29 USD/user/tháng — team 20 người là ~7.000 USD/năm (gần 180 triệu đồng), chưa kể CI/CD minutes vượt quota. Trong khi một Cloud Server 8 vCPU/16 GB RAM chạy GitLab CE thoải mái cho team 20 người, chi phí chỉ khoảng 2–4 triệu đồng/tháng.

2. Chủ động về dữ liệu và pháp lý. Code, lịch sử commit, tài liệu nội bộ nằm trên server do bạn kiểm soát — đặt tại datacenter trong nước nếu cần tuân thủ yêu cầu lưu trữ dữ liệu nội địa của khách hàng (đặc biệt khách hàng chính phủ, ngân hàng).

3. CI/CD không giới hạn. Runner tự quản chạy bao nhiêu pipeline tùy thích — team làm mobile build 30 phút/lần hay chạy test suite nặng đều không lo hết quota minutes.

4. Tùy biến sâu. Tích hợp LDAP/AD nội bộ, custom hook kiểm duyệt code, kết nối Jira/Slack self-hosted — những thứ bản SaaS hạn chế hoặc tính phí cao.

Khi nào KHÔNG nên tự host? Team dưới 5 người, không có người quản trị hệ thống, hoặc nhu cầu chỉ là lưu code đơn giản — lúc đó GitHub/GitLab SaaS gói miễn phí vẫn là lựa chọn hợp lý hơn. Self-hosted đòi hỏi có người chăm sóc server.

Tự host gitlab: gitLab CE hay EE? Chọn bản nào cho team 20 người?

Khuyến nghị: 90% team 20 người dùng GitLab CE là đủ. Các tính năng thiếu của CE (epic, portfolio) thường không phải nhu cầu thiết yếu ở quy mô này. Hãy bắt đầu với CE, chỉ nâng cấp khi thực sự "đau" vì thiếu tính năng.

Tự host gitlab: chọn cấu hình Cloud Server cho GitLab team 20 người

GitLab là ứng dụng "ngốn" RAM (do chạy nhiều tiến trình Ruby/Sidekiq). Cấu hình tối thiểu và đề xuất:

Lưu ý quan trọng:

• Disk SSD là bắt buộc, không dùng HDD — GitLab thao tác git rất nhiều IOPS, HDD sẽ khiến giao diện chậm chạp khó chịu.
• Runner CI/CD nên tách riêng: 1 Cloud Server chạy GitLab (8vCPU/16GB) + 1–2 VPS/Cloud Server nhỏ (4vCPU/8GB) làm runner. Tách runner giúp build nặng không làm treo giao diện GitLab.
• Swap: cấu hình thêm 4 GB swap để chống OOM khi GitLab rebuild index.
• Backup storage: chuẩn bị thêm không gian (local hoặc S3-compatible) cho backup hàng ngày — dung lượng backup khoảng 1,5–2 lần dung lượng repo.

Cài đặt GitLab Omnibus từng bước

Cách đơn giản và ổn định nhất là gói Omnibus (tất cả trong một) trên Ubuntu 22.04/24.04.

Bước 1: Chuẩn bị server.

sudo apt update && sudo apt upgrade -y
sudo hostnamectl set-hostname gitlab.tencongty.vn

Trỏ bản ghi DNS A gitlab.tencongty.vn về IP Cloud Server trước khi cài để Let's Encrypt cấp chứng chỉ được ngay.

Bước 2: Cài đặt gói GitLab CE.

curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo EXTERNAL_URL="https://gitlab.tencongty.vn" apt install -y gitlab-ce

Bước 3: Cấu hình cơ bản. Sửa /etc/gitlab/gitlab.rb:

external_url 'https://gitlab.tencongty.vn'
gitlab_rails['time_zone'] = 'Asia/Ho_Chi_Minh'
gitlab_rails['gitlab_default_projects_features_builds'] = true
# Giới hạn dung lượng repo để tránh 1 project chiếm hết disk
gitlab_rails['max_attachment_size'] = 200_000_000

Bước 4: Áp dụng và kiểm tra.

sudo gitlab-ctl reconfigure
sudo gitlab-ctl status

Truy cập https://gitlab.tencongty.vn — lần đầu đăng nhập bằng tài khoản root, mật khẩu lấy từ file /etc/gitlab/initial_root_password (file này tự xóa sau 24 giờ, hãy đổi mật khẩu ngay).

Bước 5: Cấu hình SMTP để gửi mail mời thành viên, thông báo merge request: dùng dịch vụ mail server riêng hoặc SMTP của nhà cung cấp, khai báo trong gitlab.rb mục gitlab_rails['smtp_*'].

Tổ chức group, project và workflow cho team 20 người

Cài xong chỉ là 20% công việc — 80% còn lại là tổ chức sao cho team dùng hiệu quả.

Cấu trúc group đề xuất:

ten-cong-ty/              (top-level group)
├── product-a/            (subgroup theo sản phẩm/dự án)
│   ├── frontend
│   ├── backend
│   └── mobile
├── product-b/
└── internal/             (tool nội bộ, tài liệu)

Phân quyền theo vai trò: Owner (1–2 người: CTO/tech lead), Maintainer (team lead các nhóm), Developer (dev thường — chỉ được push lên branch, merge qua MR), Reporter (intern, khách hàng xem tiến độ).

Workflow nhánh chuẩn cho team 20 người:

1. main là nhánh production — protected, chỉ Maintainer được merge, yêu cầu ít nhất 1 approval.
2. Mỗi tính năng tạo branch từ main: feature/ten-tinh-nang, xong tạo Merge Request.
3. CI chạy tự động trên mỗi MR: lint + unit test + build — đỏ thì không được merge.
4. Release theo tag v1.2.3, deploy từ tag.

Quy tắc này nghe nghiêm ngặt nhưng với 20 người cùng push code, không có kỷ luật nhánh thì main sẽ "cháy" hàng tuần.

Dựng CI/CD Runner riêng cho team

Runner là nơi chạy pipeline — tách khỏi server GitLab chính.

Cài GitLab Runner trên server riêng (Docker executor là phổ biến nhất):

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt install gitlab-runner
sudo gitlab-runner register

Khi register, lấy token tại Admin → Runners (shared runner) hoặc Project → Settings → CI/CD (specific runner). Chọn executor docker, image mặc định docker:24.

Chiến lược runner cho team 20 người:

Gán tag cho job nặng (tags: [mobile]) để nó chỉ chạy trên runner khỏe. Đừng để một job build mobile 40 phút chiếm hết runner chung khiến cả team chờ.

Bảo mật GitLab self-hosted: 6 việc bắt buộc

Server chứa toàn bộ code công ty mà bị hack thì thảm họa. 6 việc không được bỏ qua:

1. Bật 2FA bắt buộc cho mọi tài khoản (Admin → Settings → General → Require 2FA). Đây là biện pháp hiệu quả nhất chống lộ mật khẩu.

2. HTTPS everywhere. Let's Encrypt tự động qua Omnibus (letsencrypt['enable'] = true). Không bao giờ để GitLab chạy HTTP trần trên internet.

3. Giới hạn truy cập mạng. Nếu team làm remote, đặt GitLab sau VPN/WireGuard thay vì mở public. Nếu phải public, dùng firewall chỉ cho phép IP Việt Nam + IP văn phòng.

4. Cập nhật định kỳ. GitLab ra bản vá bảo mật hàng tháng — lên lịch update vào cuối tuần đầu tiên mỗi tháng. Đăng ký nhận thông báo bảo mật của GitLab.

5. Audit và log. Bật Audit Events, định kỳ rà soát ai tạo token, ai đổi quyền. Thu hồi personal access token không dùng quá 90 ngày.

6. Backup mã hóa và test restore. Backup GitLab chứa toàn bộ code — mã hóa file backup, lưu offsite (server khác hoặc S3), và test restore mỗi quý. Backup chưa từng restore thành công thì coi như chưa có backup.

Backup và disaster recovery cho GitLab

Cấu hình backup tự động trong /etc/gitlab/gitlab.rb:

gitlab_rails['manage_backup_path'] = true
gitlab_rails['backup_path'] = '/var/opt/gitlab/backups'
gitlab_rails['backup_keep_time'] = 604800  # giữ 7 ngày

Thêm cron chạy 2h sáng hàng ngày: 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1. Đừng quên backup cả file cấu hình (/etc/gitlab/gitlab.rb, /etc/gitlab/gitlab-secrets.json) — mất file secrets thì backup data cũng không restore được!

Kịch bản DR: chuẩn bị sẵn một Cloud Server dự phòng (tắt, chỉ bật khi cần hoặc dùng snapshot). Quy trình restore: cài GitLab cùng phiên bản → copy file backup + secrets → gitlab-backup restore → reconfigure. RTO mục tiêu cho team 20 người: dưới 4 giờ — hãy diễn tập restore ít nhất 1 lần trước khi coi hệ thống là "production-ready".

Lộ trình nâng cấp GitLab an toàn

GitLab ra bản mới vào ngày 22 hàng tháng — nhưng đừng bao giờ bấm upgrade ngay. Quy trình nâng cấp an toàn cho production:

1. Đọc release notes kỹ. Xác định bản hiện tại → bản đích có phải "upgrade path" hợp lệ không. GitLab yêu cầu nâng cấp tuần tự: không được nhảy từ 16.x lên 17.x mà bỏ qua các bản trung gian — phải đi 16.11 → 17.0 → 17.x mới nhất. Bỏ qua bước trung gian là nguyên nhân phổ biến nhất gây lỗi migration database.

2. Backup trước mọi lần nâng cấp. Chạy backup đầy đủ (data + /etc/gitlab) ngay trước khi upgrade. Với team 20 người, lên lịch upgrade vào tối thứ 7, thông báo trước 3 ngày.

3. Nâng cấp từng bước:

sudo apt update
sudo apt install gitlab-ce=17.5.2-ce.0  # ghim đúng phiên bản đích
sudo gitlab-ctl reconfigure

Sau mỗi bước, kiểm tra gitlab-ctl status, đăng nhập giao diện, chạy thử một pipeline. Chỉ sang bước tiếp theo khi mọi thứ xanh.

4. Có kế hoạch rollback. Nếu upgrade lỗi nghiêm trọng: restore từ backup (đây là lúc backup phát huy tác dụng). Đừng cố "sửa tiếp" một bản upgrade hỏng quá 2 giờ — rollback rồi tìm hiểu nguyên nhân sau.

Tần suất khuyến nghị: upgrade bản vá bảo mật (patch) hàng tháng, upgrade bản lớn (minor) mỗi quý. Đừng để tụt quá 3 bản minor — càng để lâu, upgrade càng đau.

So sánh chi phí: tự host vs GitLab.com

Tự host rẻ hơn khoảng 2/3 — nhưng đừng quên chi phí ẩn là thời gian quản trị (update, backup, xử lý sự cố). Nếu công ty không có người làm sysadmin, hãy cộng thêm chi phí thuê ngoài hoặc dùng dịch vụ quản trị.

Kết luận

Tự host GitLab trên Cloud Server là lựa chọn kinh tế và chủ động cho team khoảng 20 người: chi phí cố định thấp, CI/CD không giới hạn, dữ liệu nằm trong tầm kiểm soát. Công thức thành công gồm 3 yếu tố: cấu hình server đủ mạnh (8vCPU/16GB + SSD), runner tách riêng, và kỷ luật vận hành (backup, update, 2FA).

Nếu bạn cần hạ tầng để bắt đầu ngay, SunCloud cung cấp Cloud Server SSD hiệu năng cao với chính sách dùng thử 10 ngày miễn phí — đủ để dựng GitLab lab, chạy thử với team 1–2 tuần trước khi quyết định production. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để được tư vấn cấu hình phù hợp.

Câu hỏi thường gặp

Team bao nhiêu người thì nên tự host GitLab?

Từ khoảng 10–15 người trở lên, khi chi phí SaaS theo đầu người bắt đầu đáng kể và team có nhu cầu CI/CD nhiều. Dưới 10 người mà không có sysadmin thì SaaS vẫn tiện hơn.

GitLab CE có đủ dùng cho team 20 người không?

Đủ cho 90% nhu cầu: quản lý repo, merge request, CI/CD, code review, protected branch. Chỉ thiếu các tính năng quản trị dự án nâng cao (epic, roadmap) của bản trả phí.

Cần bao nhiêu server để chạy GitLab cho team 20 người?

Tối thiểu 2: một Cloud Server 8vCPU/16GB chạy GitLab, một server 4vCPU/8GB làm CI runner. Không nên chạy runner nặng trên cùng server GitLab vì sẽ làm chậm giao diện khi build.

Tự host GitLab có an toàn không?

An toàn nếu làm đúng: HTTPS, 2FA bắt buộc, update định kỳ, firewall giới hạn IP, backup mã hóa offsite. Nguy hiểm nhất là cài xong rồi "bỏ quên" không update — lỗ hổng GitLab bị khai thác rất nhanh sau khi công bố.

Có nên đặt GitLab public internet hay sau VPN?

Nếu team làm việc tập trung tại văn phòng hoặc remote cố định, đặt sau VPN/WireGuard an toàn hơn nhiều. Chỉ mở public khi thực sự cần (ví dụ webhook từ dịch vụ ngoài), và khi đó phải bật 2FA + giới hạn IP.

Migrate từ GitLab.com về self-hosted có khó không?

Không khó: GitLab hỗ trợ export/import project trực tiếp (kèm repo, issue, MR). Với team 20 người (~30–50 project), toàn bộ quá trình thường hoàn thành trong 1–2 ngày, gồm cả thời gian kiểm tra.