Mô Hình GitLab CI/CD: Chọn Kiểu Nào Cho “Chuẩn”?
Giải thích dễ hiểu cho newbie, kèm case study thực tế và lời khuyên từ ‘tiền bối’.
Chào các bạn, nếu bạn đang bắt đầu tìm hiểu về DevOps, chắc chắn bạn đã nghe tới CI/CD. GitLab CI/CD là một công cụ cực kỳ xịn sò, nhưng câu hỏi đầu tiên mà team nào cũng phải trả lời là: “Nên cài đặt nó theo kiểu nào?”.
Nghe thì có vẻ “xoắn não”, nhưng thực ra chỉ có 2 kiểu chính thôi. Việc chọn đúng kiểu ngay từ đầu sẽ giúp team bạn chạy nhanh hơn, an toàn hơn và đỡ phải “đập đi xây lại” sau này. Trong bài này, chúng ta sẽ cùng mổ xẻ hai kiểu này theo cách dễ hiểu nhất nhé!
1. Kiểu “Tất cả trong một” (All-in-One)
Cứ tưởng tượng bạn có một cái máy tính duy nhất. Bạn vừa dùng nó để chứa code (GitLab), vừa bắt nó phải làm luôn công việc build, test code (GitLab Runner). Mọi thứ dồn hết vào một chỗ, nên gọi là “Tất cả trong một”.
GitLab Instance (Sếp)
Chứa code, quản lý…
Giao việc ngay tại chỗ
GitLab Runner (Nhân viên)
Build, test code…
Ưu và Nhược điểm nói thẳng là…
Cái hay
- Dễ như ăn kẹo: Cài đặt siêu nhanh, quản lý chỉ một thứ.
- Tiết kiệm “lúa”: Chỉ tốn tiền cho một cái server, quá hợp lý!
- Tuyệt vời cho người mới: Dùng để học, làm dự án cá nhân, hay cho team siêu nhỏ là “hết sảy”.
Cái dở
- Rất nguy hiểm: Lỡ script có virus thì “toang” cả server chứa code.
- Máy chủ dễ bị “đuối”: GitLab và Runner tranh giành nhau tài nguyên, làm cả hai cùng chậm.
- Khó “gánh” team: Khi dự án lớn lên, một mình nó không thể xử lý nổi.
Case Study: Startup “TechUp”
Câu chuyện: Một startup 3 người cần làm CI/CD cho nhanh mà không có nhiều tiền. Họ chọn kiểu “Tất cả trong một”. Ban đầu mọi thứ rất ổn, nhưng vài tháng sau, mỗi lần code được build là trang GitLab lại ì ạch, cả team phải ngồi chờ.
2. Kiểu “Teamwork” (Distributed)
Kiểu này giống như một công ty thực thụ. Có một “Sếp Tổng” (GitLab Instance) chỉ ngồi phòng riêng để giao việc. Còn công việc build, test thì giao cho một đội “nhân viên” (Runners) chuyên trách, mỗi nhân viên ngồi ở một “phòng ban” (máy chủ) khác nhau.
GitLab Instance (Sếp Tổng)
Chỉ giao việc, không làm gì khác
“Alo, có việc cho các chú đây!”
Nhân viên 1
(Máy chủ Linux)
Nhân viên 2
(Máy chủ Windows)
Nhân viên 3
(Trên Cloud/K8s)
Ưu và Nhược điểm nói thẳng là…
Cái hay
- An toàn tuyệt đối: “Nhân viên” có gặp sự cố cũng không ảnh hưởng đến “Sếp”.
- Hiệu suất “khủng”: Mỗi người một việc, không ai tranh giành của ai, chạy vèo vèo.
- Mở rộng “tẹt ga”: Cần thêm người làm? Chỉ cần “tuyển” thêm nhân viên Runner mới là xong.
- Làm được đủ thứ việc: “Tuyển” nhân viên chuyên Linux, Windows, macOS… đều được.
Cái dở
- Setup ban đầu hơi “khoai”: Phải biết chút ít về mạng, quản trị server.
- Tốn kém hơn lúc đầu: Phải trả tiền cho nhiều “phòng ban” (máy chủ) hơn.
Case Study: Công ty “MegaMart”
Câu chuyện: Một công ty thương mại điện tử lớn cần build code cho cả web, app Android, app iOS. Họ chọn kiểu “Teamwork”, “tuyển” một đội nhân viên Runner: team chuyên build Docker, team chuyên build app iOS… Kết quả là thời gian chờ build giảm từ 30 phút xuống còn 5 phút, ai cũng vui vẻ.
Hướng dẫn thực tế: “Tuyển” một nhân viên Runner riêng
Ok, giờ tới phần hay nhất. Việc “tuyển” một nhân viên Runner riêng để nó làm việc thay cho con server GitLab chính là bước đi cực kỳ thông minh. Dưới đây là 3 bước chính.
Chuẩn bị “chỗ làm việc” cho Runner
Đầu tiên, bạn cần một cái máy chủ mới (cứ coi như một “chỗ ngồi” mới cho nhân viên). Trên đó, bạn cài phần mềm GitLab Runner. Việc cài đặt này rất dễ, GitLab có hướng dẫn tận răng cho mọi hệ điều hành.
Bạn có thể xem hướng dẫn cài đặt chính thức từ GitLab tại đây. Đây là nguồn chuẩn nhất rồi nhé.
Xin “giấy thông hành” từ Sếp Tổng
Để nhân viên mới có thể vào công ty làm việc, nó cần được “Sếp Tổng” (GitLab) cấp phép. Bạn cần lấy 2 thứ từ GitLab:
- Địa chỉ công ty: Chính là URL của trang GitLab của bạn.
- Mã token: Giống như cái mật khẩu để nhân viên mới đăng ký.
Bạn vào dự án của mình, tìm đến mục: Settings -> CI/CD -> Runners là sẽ thấy ngay.
“Khai báo” và giao “chuyên môn” (Tags)
Đây là bước cuối cùng để “kết nối” nhân viên Runner với Sếp Tổng GitLab. Bạn sẽ chạy một lệnh duy nhất trên máy chủ Runner:
sudo gitlab-runner registerLệnh này sẽ khởi động một quy trình hỏi-đáp ngay trên terminal. Nó sẽ yêu cầu bạn nhập URL và token đã lấy ở bước 2, cùng một vài thông tin khác.
Quan trọng nhất là mục tags. Tags giống như bạn gán “chuyên môn” cho nhân viên vậy. Ví dụ: `chuyen-build-docker`, `chuyen-deploy-production`. Sau này, trong file .gitlab-ci.yml, bạn chỉ cần ghi:
deploy_job:
# ... script ...
tags:
- chuyen-deploy-production… là GitLab sẽ tự động biết phải giao việc này cho đúng nhân viên có chuyên môn đó. Quá xịn!
*Để xem chi tiết tất cả các tùy chọn khi đăng ký, bạn có thể tham khảo tài liệu chính thức về lệnh register từ GitLab.
Lời khuyên chân thành từ “tiền bối”
Tóm lại, nếu bạn làm dự án cho công ty, đi làm thực tế, thì auto chọn kiểu “Teamwork” (Distributed) nhé. Đừng lăn tăn. Nó an toàn, chạy nhanh và có thể ‘gánh’ team bạn đi rất xa.
Kiểu “Tất cả trong một” chỉ nên dùng để vọc vạch, học hỏi hoặc làm dự án cá nhân cho vui thôi. Hãy đầu tư đúng đắn ngay từ đầu để xây dựng một nền tảng DevOps vững chắc!