Trong phần cơ chế hoạt động của Gitlab Runner ở bài trước có nhắc đến “executor”, vậy “executor” là gì? Có bao nhiêu loại “executor”? Bài viết này sẽ giải đáp những câu hỏi trên một cách đơn giản nhất.
- Phần 1: Giới thiệu tổng quan về Gitlab Runner
- 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
- Phần 7: Lưu trữ Terraform state trên Gitlab
Runner executor (executor) là gì? #
Có thể hiểu đơn giản thì đây là các phần mềm / dịch vụ được sử dụng để xử lý các “job” được nhận từ Gitlab runner. Như đã đề cập tới ở bài trước, Gitlab runner chỉ đóng vai như là một chàng shipper chuyên đi giao nhận các “job” từ người dùng đến các executor. Các phần mềm / dịch vụ này sẽ xử lý yêu cầu được giao và gửi kết quả đến người dùng thông qua Gitlab runner.
Thư mục lưu mã nguồn của executor #
Mặc định mã nguồn (source code) của dự án / repository sẽ được lưu vào đường dẫn sau:
~/builds/<short-token>/<concurrent-id>/<namespace>/<tên dự án / repository>
Trong đó:
- <short-token>: 8 ký tự đầu tiên của ID runner
- <concurrent-id>: Job ID tương ứng với runner thực thi “job”
- <namespace>: tên group user
Người dùng hoàn toàn có thể tự định nghĩa thư mục dùng để lưu mã nguồn khi bằng cách thêm trường build_dir bên dưới phần [[runners]] trong file config.toml, chỉ định vị trí sẽ lưu mã nguồn của mình.
Các loại executor #
Gitlab hỗ trợ khá nhiều loại executor để người dùng có thể cân nhắc sử dụng, tuy nhiên con số này đang dừng lại ở 8 loại. Bao gồm:
SSH #
Đầu tiên, đây là executor mà ngay cả chính Gitlab khuyến cáo không nên dùng. Executor này giúp người dùng có thể kết nối SSH đến một máy chủ chỉ định với các thông tin do người dùng cung cấp. Sau đó thực thi các câu lệnh mà người dùng đã quy định cho “job”. Một lưu ý khi sử dụng executor dạng này đó là chỉ thực thi được Bash script và không hỗ trợ “caching” ở thời điểm hiện tại.
Đặc điểm nhận dạng của executor này là trong file config.toml, phần executor sẽ có giá trị là “ssh”. Bên dưới là cấu hình đơn giản cho SSH executor
Thông tin cấu hình từ ảnh bên trên bao gồm:
- executor: loại executor được sử dụng
- runners.ssh: khu vực khai báo thông tin kết nối SSH
- host: thông tin máy chủ sẽ kết nối đến (IP / Hostname)
- port: port kết nối (mặc định port của SSH là 22)
- user: user dùng để kết nối
- password: mật khẩu để đăng nhập vào máy chủ (có thể khai báo thông tin này hoặc là thông tin identity_file bên dưới, không bắt buộc phải khai báo cả hai)
- identity_file: Gitlab runner sẽ không tự đọc file chứa thông tin định danh của bạn từ thư mục /home/user/.ssh/id_(rsa|dsa|ecdsa), thay vào đó, người dùng cần phải khai báo đường dẫn cụ thể để Gitlab runner có thể sử dụng khi tạo kết nối SSH.
Shell #
Đây là loại loại executor đơn giản nhất vì “job” sẽ được xử lý ngay tại máy chủ mà Gitlab runner đang hoạt động. Runner được cài đặt ở đâu, executor sẽ hoạt động ở đó. Người dùng có thể chạy các script được viết bằng Bash, PowerShell Core, Windows PowerShell (tùy thuộc vào hệ điều hành của máy chủ).
Khi cài đặt Gitlab runner từ nguồn chính thức do Gitlab cung cấp trên hệ điều hành Linux, quá trình cài đặt sẽ ưu tiên sử dụng “user” có tên là “gitlab_ci_multi_runner”. Nếu không tìm thấy user này tồn tại trên server, quá trình cài đặt sẽ tự tạo thêm một “user” mới có tên là “gitlab-runner”. Vì vậy, khi quá trình xử lý “job” diễn ra, Runner sẽ sử dụng một trong 2 user này để xử lý “job”.
Nếu như “job” cần được xử lý phải gọi các tài nguyên có quyền đặc biệt, người dùng cần phải thêm các user của Runner vào group được quyền truy cập các tài nguyên này. Ví dụ, “job” cần thao tác đến Docker Engine và VirtualBox, Gitlab runner đang sử dụng là “gitlab-runner”. Việc của bạn cần làm là thả 2 câu lệnh bên dưới vào máy chủ để tránh gặp lỗi phân quyền khi “job” được xử lý:
usermod -aG docker gitlab-runner
usermod -aG vboxusers gitlab-runner
VirtualBox #
Loại executor này cho phép người dùng sử dụng một máy ảo đã được tạo trước đó để xử lý các “job” được yêu cầu. Executor này sẽ phù hợp với những ai muốn xử lý “job” hoặc “build” trên nhiều hệ điều hành khác nhau, giúp giảm chi phí về server / máy chủ. Việc của Gitlab runner lúc này là kết nối đến các máy ảo được chỉ định để xử lý các “job” được yêu cầu từ phía Gitlab server.
Lưu ý: Thư mục chứa mã nguồn lúc này sẽ không có phần <concurrent-id>
Để sử dụng loại executor này, Gitlab runner sẽ được cài đặt trên máy chủ đã vài đặt VirtualBox. Máy ảo cần phải được thiết lập sẵn SSH (OpenSSH server), các thư viện, phần mềm cần có để xử lý “job”. Đối với cấu hình của máy ảo cần được cấu hình NAT đối với “Network Adapter” để Gitlab runner có thể kết nối đến máy ảo.
Cơ chế hoạt động cũng như cách thiết lập bạn có thể xem chi tiết tại đây: link
Parallels #
Cách cài đặt và quy trình xử lý tương tự như VirtualBox
Docker #
Executor sẽ xử lý các “job” dựa trên các Docker image do người dùng chỉ định. Thông qua việc kết nối với Docker Engine, executor sẽ xử lý từng “job” với từng container riêng biệt với các Docker image được chỉ định trong file .gitlab-ci.yml, hoặc dựa theo cấu hình trong file config.toml.
Người dùng có thể tạo ra 1 Docker image đã được cài đặt toàn bộ các thư viện, phần mềm cần thiết để xử lý các “job”, lưu chúng ở registry. Sau đó executor chỉ việc sử dụng image này và xử lý job, không còn phải tốn thời gian cho việc cài đặt thư viện, phần mềm bổ sung để xử lý các “job”.
Riêng đối với Docker executor chạy trên Windows sẽ có một số hạn chế nhất định, bạn có thể xem chi tiết ở bài viết này: link
Docker Machine (auto-scaling) #
Đây là một phiên bản đặc biệt của Docker executor với tính năng “auto-scaling”. Tuy Docker đã “khai tử” Docker Machine, Gitlab đã tạo ra 1 phiên bản cho riêng mình. Điều này giúp đảm bảo người dùng đang sử dụng executor này vẫn được hỗ trợ.
Sơ lược về Docker Machine: service này cho phép người dùng tạo ra Docker hosts trên chính máy chủ của mình, trên các nhà cung cấp dịch vụ điện toán đám mây và bên trong trung tâm dữ liệu (data center). Công cụ này tạo ra các máy chủ, cài đặt Docker trên chúng, sau đó cấu Docker client để kiểm soát chúng.
Chi tiết về executor này bạn có thể tham khảo tại đây: link
Kubernetes #
Đã nhắc đến Docker thì không thể nào thiếu Kubernetes (k8s). Người dùng sẽ sử dụng các k8s cluster hiện có để xử lý các “job”. Các executor sẽ gọi API của k8s cluster và tạo ra các pod mới để xử lý từng “job”. Chi tiết bạn có thể tham khảo ảnh minh họa bên dưới
Custom #
Nếu những executor kể trên chưa phù hợp với nhu cầu của bạn, đây sẽ là giải pháp cuối cùng. Với “Custom” executor, người dùng sẽ tự tạo ra một executor mới cho riêng mình.
Người dùng sẽ tùy biến Gitlab runner để chỉ định service / script nào được gọi để xử lý “job”. Các service / script thực thi này được gọi chung là Driver. Chi tiết bạn có thể tham khảo ở bài viết sau: link
Nguồn tham khảo: Gitlab
|
Trung tâm đào tạo Viễn thông và Công nghệ thông tin TEL4VN (TEL4VN) chuyên đào tạo các khóa học về DevOps như: Docker, Kubernetes, Ansible, Jenkins, Linux…….Ngoài ra, TEL4VN còn là Trung tâm đào tạo duy nhất về VoIP mã nguồn mở. 🌐Website: https://tel4vn.edu.vn/ |
