Phần 1: Giới thiệu tổng quan về Gitlab Runner

Gitlab Runner là gì, có thể làm được gì và tại sao phải sử dụng đến nó? Bài viết này sẽ giúp bạn có một cái nhìn tổng quan nhất về “công cụ” CI/CD đến từ Gitlab

Có lẽ cụm từ CI/CD đã không còn quá xa lạ với trong thời điểm hiện tại. Khi DevOps đã trở thành một cụm từ khá phổ biến ở năm 2022. Người người, nhà nhà đều tìm hiểu DevOps, giúp công việc của mình vận hành một cách trơn tru hơn và tự động hóa hơn.

• Phần 2: Các loại Runner Executor trong Gitlab CI
• Phần 3: Hướng dẫn cài đặt Gitlab Runner trên Ubuntu
• Phần 3: Hướng dẫn cài đặt Gitlab Runner trên Centos
• Phần 3: Hướng dẫn cài đặt Gitlab Runner trên macOS
• Phần 3: Hướng dẫn cài đặt Gitlab Runner trên Windows
• Phần 4: Các thành phần cơ bản trong file “.gitlab-ci.yml”
• Phần 5: Tạo Docker image với Gitlab Runner
• Phần 6: Deploy AWS Lambda với Gitlab-CI và Serverless Framework

Gitlab Runner là gì? #

Đây là một phần mềm / công cụ mã nguồn mở, được viết bằng ngôn ngữ Go và do chính Gitlab tạo ra để phục vụ cho việc CI/CD cho các dự án / repository được tạo trên Gitlab. Người dùng có thể tự cài đặt cho mình một runner trên server của mình hoặc sử dụng những runner do Gitlab cung cấp. Người dùng chỉ cần tạo 1 file .gitlab-ci.yml ở thư mục gốc của dự án / repository, để khởi tạo CI/CD pipeline và chỉ định Gitlab runner nào sẽ được sử dụng.

Gitlab sẽ cung cấp 2 gói hỗ trợ, bao gồm:

• Miễn phí:
  • Giới hạn: 400 phút/tháng đối với “private repository” và 5000 phút/tháng đối với “public repository”.
  • Không giới hạn: người dùng tự cài đặt và quản lý runner của riêng mình.
• Trả phí: từ $19 – $99/user/tháng tùy theo các gói đăng ký Lưu ý: chỉ áp dụng đối với “shared runner” do Gitlab cung cấp.

Các loại Gitlab runner #

Runner sẽ bao gồm 2 loại:

Shared runner – do Gitlab quản lý #

Nếu bạn theo xu hướng “serverless”, đây là một giải pháp hợp lý và nhanh chóng. Bạn không phải cấu hình, quản trị, lo lắng về hiệu năng, tính sẵn sàng của runner. Các công việc này sẽ do Gitlab chịu trách nhiệm xử lý. Việc của bạn là sử dụng, trả thêm tiền nếu đã sử dụng hết định mức và muốn tiếp tục sử dụng.

Các runner này được cài đặt trên hệ thống máy chủ thuộc Google Cloud Platform – GCP. Bao gồm 3 loại runner chạy 3 hệ điều hành phổ biến hiện nay:

• Linux: cấu hình thuộc dòng n1-standard-1 (thuộc khu vực South Carolina – us-east1): 1 vCPU, 3.75GB RAM, 25GB HDD, chạy hệ điều hành của Google – Google COS, và được cài đặt Docker Engine phiên bản mới nhất.
• Windows (Beta): cấu hình thuộc dòng n1-standard-2: 2 vCPU, 7.5GB RAM
• macOS (Beta): chỉ áp dụng đối với các dự án mã nguồn mở hoặc người dùng đăng ký gói Premium / Ultimate

Shared runner sẽ xử lý các “job” thông qua một hàng đợi đặc biệt – “fair usage queue”. Hàng đợi này sẽ ngăn chặn việc các dự án / repository chiếm dụng toàn bộ runner bằng cách tạo ra hàng trăm “job” cần được xử lý cùng lúc. Thay vào đó, hàng đợi này sẽ ưu tiên phân phối các “job” cho các dự án / repository có số lượng “job” đã sử dụng shared runner thấp nhất trước.

Specific runner / Own runner – do người dùng tự cài đặt và quản lý #

Đây là một giải pháp sử dụng CI/CD của Gitlab hoàn toàn miễn phí. Bạn có server của mình, bạn muốn tự mình cài đặt, quản lý các runner. Người dùng sẽ cấu hình và chỉ định mỗi runner được sử dụng cho một hoặc nhiều dự án / repository. Nếu sử dụng giải pháp này, bạn có thể đảm bảo yếu tố bảo mật, kiểm soát dữ liệu của mình. Bù lại là bạn sẽ trả thêm một khoản về chi phí đường truyền mạng nếu sử dụng cách này.

Người dùng có thể tự cài đặt runner trên hầu hết các hệ điều hành phổ biến trên thị trường hiện nay: Linux, macOS, Windows,… mà không cần phải cài thêm bất kỳ phần mềm nào kèm theo. Ngoài ra, bạn hoàn toàn có thể thiết lập một Gitlab runner cho riêng mình bằng cách sử dụng Docker container hoặc bên trong Kubenetes cluster.

Group runner – các runner thuộc “group” trên Gitlab #

Khi người dùng tạo 1 runner thuộc loại “Group runner”, toàn bộ các dự án / repository thuộc group sẽ có thể sử dụng các runner này. Các runner này sẽ sử dụng cơ chế hàng đợi (queue  – FIFO – First In First Out) để nhận và xử lý các “job”.

Tính năng của Gitlab Runner #

• Có thể chạy nhiều “job” CI/CD cùng một lúc miễn là bạn có đủ runner
• Cho phép tùy chọn môi trường chạy các “job” (khi bạn chạy Gitlab runner bằng Docker)
• “Job” có thể chạy ở local / docker container / kết nối đến server thông qua SSH
• Hỗ trợ  Bash, PowerShell Core và Windows PowerShell
• Hỗ trợ “caching” Docker container
• Tích hợp Prometheus metrics HTTP server
• Dễ dàng cài đặt như một dịch vụ / service trên GNU/Linux, macOS và Windows
• …

Bạn có thể xem chi tiết các tính năng của Gitlab runner ở thời điểm hiện tại thông qua website chính thức của Gitlab

Cơ chế hoạt động của Gitlab Runner #

Về cơ chế, bạn có thể hiểu đơn giản Gitlab runner sẽ giống như một anh shipper. Anh shipper này sẽ chuyên đi giao nhận các “job” từ Gitlab server đến “executor”. Gitlab server sẽ đóng vai trò như là một đơn vị vận chuyển. Chi tiết như sau:

• Runner đăng ký làm “shipper” cho Gitlab server:
  • Sử dụng “registration_token” của dự án / repository để đăng ký lên Gitlab server thông qua API
  • Nhận kết quả đăng ký từ API

• Runner nhận các “job” từ Gitlab server và chuyển tiếp đến “executor” để xử lý:
  • Gọi API để kiểm tra có “job phù hợp” cần được xử lý hay không, nếu có “job phù hợp” thì nhận về để giao cho “exector”
  • Sau khi có được “job phù hợp”, runner sẽ nhận “job token” và “job payload” từ Gitlab server và chuyển nó đến “executor”
  • “Executor” sau khi nhận được thông tin từ runner thì tiến hành lấy các tài nguyên / thông tin cần thiết từ Gitlab server để xử lý “job” bằng “job token”.
  • Xử lý xong “job”, “executor” sẽ đưa kết quả cho runner để gửi về Gitlab server.
  • Sau khi nhận được kết quả xử lý từ runner, Gitlab server hiển thị kết quả lên giao diện

Nếu vẫn cảm thấy chưa hiểu, bạn có thể xem thêm ảnh minh họa bên dưới

Nguồn tham khảo: Gitlab