1. Giới thiệu

Trong bài viết trước, Làm quen với github action, chúng ta đã cùng khám phá các định nghĩa, cách hoạt động, cách tạo và sử dụng GitHub Actions. Qua đó, hẳn bạn đã quen thuộc với khái niệm Runner - môi trường thực thi các job trong workflow của chúng ta, mặc định là các GitHub-Hosted runners do chính GitHub cung cấp.

Sự tiện lợi của GitHub-Hosted runners là không thể phủ nhận, ví dụ như: nhanh chóng, dễ thiết lập, không cần quản lý hạ tầng. Tuy nhiên, khi dự án mà bạn thi triển trở nên phức tạp, khi yêu cầu về build, test, deploy trở nên phức tạp, đòi hỏi các yếu tố bảo mật, truy cập nội bộ, ... thì bạn sẽ dần cảm nhận được những sự giới hạn của GitHub-Hosted runners.

Chính từ những nhu cầu cao hơn về dự án, bài viết này sẽ tập trung phân tích sâu hơn về những hạn chế của GitHub-Hosted runners, và giới thiệu một giải pháp khác, có độ tùy chỉnh cao hơn để đáp ứng mọi kịch bản build, test, deploy của dự án.

2. Runner trong GitHub Actions

Runners

Runners đơn giản là các máy (vật lý hoặc ảo) thực thi các jobs trong workflow.

Hai loại runners chính

1. GitHub-Hosted runners: Là các máy chủ ảo được GitHub cung cấp và quản lý. Hỗ trợ nhiều hệ điều hành khác nhau với các cấu hình phần cứng tiêu chuẩn. Giúp người dùng dễ dàng để bắt đầu, không cần quan tâm đến vấn đề bảo trì, thiết lập.

2. Self-Hosted runners: Ngược lại, đây là các máy chủ (vật lý, ảo, container) do người dùng tự thiết lập, quản lý, duy trì trên cơ sở hạ tầng của riêng họ và kết nối chúng với GitHub Actions.

Như vậy với Self-Hosted runner, bạn có thể dần cảm nhận được sự tùy chỉnh cao, nắm quyền chủ động hoàn toàn, giúp biến môi trường CI/CD phù hợp với từng dự án của bạn.

3. Hạn chế của GitHub-Hosted Runners

Sự tiện lợi của GitHub-Hosted runners là không cần bãn, đặc biệt là dùng cho các dự án nhỏ, mới, cho các bạn mới làm quen với GitHub Actions. Tuy nhiên khi nhu cầu vượt qua khởi những điều mà nó có thể cung cấp, những hạn chế bắt đầu lộ ra.

1. Chi phí leo thang

Đối với các private repository hoặc các tổ chức sử dụng GitHub Actions ở quy mô lớn, chi phí tính theo phút sử dụng của GitHub-hosted runners có thể nhanh chóng trở thành một khoản đáng kể. Số phút miễn phí có hạn, và vượt quá đó, bạn sẽ phải trả tiền. Với các build chạy thường xuyên và kéo dài, con số này không hề nhỏ.

2. Giới hạn về cấu hình phần cứng

Bạn sẽ bị ràng buộc vào các cấu hình CPU, RAM, và dung lượng ổ đĩa mà GitHub cung cấp. Các tác vụ nặng như biên dịch dự án lớn, training model AI/ML, hay xử lý đồ họa thường đòi hỏi tài nguyên vượt trội hơn, hoặc các loại phần cứng chuyên dụng (như GPU) mà GitHub-hosted runners không (hoặc có với chi phí rất cao và hạn chế) cung cấp.

3. Tùy biến môi trường hạn hẹp

GitHub cung cấp các images với nhiều công cụ cài sẵn, tuy nhiên việc cài đặt các phần mềm rất đặc thù, các phiên bản thư viện cũ, hoặc các dependencies phức tạp có thể trở nên khó khăn và tốn thời gian. Mỗi lần job chạy, môi trường có thể cần được thiết lập lại từ đầu, làm chậm đáng kể workflow của bạn.

4. Khó khăn truy cập tài nguyên nội bộ

Đây là một rào cản lớn. Đơn giản vì GitHub-hosted runners hoạt động trên hạ tầng của GitHub, hoàn toàn tách biệt với mạng nội bộ của bạn, của tổ chức. Do đó, chúng không thể trực tiếp truy cập vào các database, staging server, artifact repositories, hay bất kỳ dịch vụ nào nằm trong private network của tổ chức bạn.

5. Ràng buộc về thời gian chạy và số lượng job đồng thời

Mỗi job trên GitHub-hosted runner có một giới hạn thời gian chạy tối đa. Đồng thời, số lượng jobs có thể chạy song song (concurrency) cũng bị giới hạn, đặc biệt với các tài khoản miễn phí hoặc các gói thấp, gây ra tình trạng "thắt cổ chai" khi có nhiều workflow cần thực thi.

6. Vấn đề bảo mật và chính sách của tổ chức

Với một số tổ chức, đặc biệt là trong các ngành có quy định nghiêm ngặt (tài chính, y tế), việc mã nguồn và dữ liệu nhạy cảm được xử lý trên hạ tầng của bên thứ ba (là GitHub) có thể vi phạm các chính sách bảo mật hoặc yêu cầu tuân thủ nội bộ. Họ cần mọi thứ phải diễn ra trong kiểm soát của họ.

Bạn có thể tham khảo một số thông số cấu hình của GitHub-Hosted runner và một số giới hạn về storage và minutes

4. Vị cứu tinh: Self-Hosted Runners

Trước những giới hạn mà GitHub-Hosted runners mang lại như đã nói ở trên, thì Self-Hosted runners xuất hiện như một "đấng cứu thế", mang đến sự linh hoạt về quyền kiểm soát, tùy chỉnh, đáp ứng được nhu cầu của những dự án phức tạp hơn. Nó cho phép bạn sử dụng chính hạ tầng của riêng mình để chạy các jobs trong GitHub Actions.

1. Toàn quyền kiểm soát môi trường

Bạn có thể cài đặt bất kỳ hệ điều hành nào (Linux, Windows, macOS, ...), bất kỳ phiên bản phần mềm, thư viện, hay dependencies nào mà dự án của bạn yêu cầu. Môi trường được chuẩn bị một lần và sẵn sàng cho mọi lần chạy job, không tốn thời gian cài đặt lại từ đầu. Còn với GitHub-Hosted runners thì mỗi lần workflow chạy thì môi trường sẽ bị setup lại từ đầu.

2. Tối ưu hóa hiệu suất

Kiến trúc hạ tầng đa dạng, tùy chỉnh cao, mọi thứ tùy ý của bạn. Các dự án IoT thì dùng kiến trúc CPU đặc thù như ARM64 mà GitHub-Hosted runners không có. Với các dự án về AI/ML, hoặc build game thì đòi hỏi CPU, RAM, DISK, GPU "xịn xò" hơn, mạnh mẽ hơn đối với những gì mà GitHub có thể cung cấp.

3. Kiếm soát chi phí hiệu quả

Bạn có thể sử dụng các hạ tầng sẵn có. Ví dụ có sẵn máy chủ on-premise hoặc virtual machine trên các nền tảng cloud (AWS, Azure,...), thì bạn có thể biến chúng thành self-hosted runner để chạy CI/CD, không tốn thêm chi phí vận hành nào khác.

4. Truy cập tài nguyên nội bộ an toàn

Khi runner được cài đặt trong mạng nội bộ của bạn, nó hoàn toàn có thể tương tác trực tiếp với các dịch vụ nội bộ như: database, staging server, ... Từ self-hosted runner có thẻ kết nối vào một cách an toàn mà không cần các giải pháp phức tạp hay kém bảo mật.

5. Phá bỏ giới hạn thời gian và concurrency

Có thể thấy thời gian chạy của một job bây giờ phụ thuộc vào cấu hình của bạn chứ không phải cấu hình của GitHub cung cấp. Số lượng job chạy đồng thời phụ thuộc vào sức mạnh hạ tầng của bạn. Tuy nhiên vẫn có một số giới hạn với self-hosted runner, bạn có thể tham khảo tại đây. Tuy nhiên nhìn chung, bạn vẫn sẽ có một giới hạn ở cấp độ cao hơn, quan trọng là khả năng xử lý thực tế của hạ tầng do bạn quản lý.

6. Bảo mật và tuân thủ chính sách trong tầm tay

Toàn bộ mã nguồn và quá trình build/test/deploy diễn ra trên hạ tầng của bạn khi dùng Self-Hosted runners. Điều này giúp đáp ứng các yêu cầu bảo mật nghiêm ngặt và các quy định tuân thủ (compliance) mà nhiều tổ chức đặt ra, vì không có dữ liệu nhạy cảm nào rời khỏi kiểm soát của tổ chức.

5. Hướng dẫn cơ bản thiết lập Self-Hosted Runners

Tiếp theo, chúng ta sẽ tìm hiểu cách cài đặt cơ bản Self-Hosted Runners trên hạ tầng của bạn.

Bước 1: Chuẩn bị cấu hình

• Tại repository trên github, Settings -> Actions -> Runners -> New self-hosted runners
• Chọn nền tảng: macOS, Linux, Windows
• Chọn kiến trúc: x64, ARM, ... Bước 2: Tải và chạy cơ bản
• Mở terminal/cmd trên host machine
• Chạy command mà GitHub hiển thị cho bạn

Bước 3: Áp dụng

• Trong file định nghĩa workflow của bạn, sửa runs-on thành self-hosted | x64 | Linux, tham khảo ảnh dưới

Việc cài đặt self-hosted runner trực tiếp lên một máy chủ như hướng dẫn ở trên là bước đệm quan trọng. Nhưng thế giới của self-hosted runner không chỉ dừng lại ở đó. Làm thế nào để chúng hoạt động hiệu quả trên các máy ảo đám mây? Hay làm sao để đóng gói chúng vào container và điều phối bằng Kubernetes một cách chuyên nghiệp? Do tính chất và những yêu cầu đặc thù của từng môi trường này, mình sẽ chia sẻ chi tiết hơn trong các bài viết chuyên đề sẽ sớm được ra mắt.

Tài liệu tham khảo

1. Step-by-Step Guide to Configuring a Self-Hosted Runner in GitHub Actions [2024]

2. When to choose GitHub-Hosted runners or self-hosted runners with GitHub Actions