Gitlab runner connect gke như thế nào
|
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.
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:
Trong đó:
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:
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ý:
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 Để 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 |
