GitHub Actions chính thức ra mắt tính năng Custom Runner Images

08 tháng 4, 2026·5 phút đọc

GitHub vừa công bố tính năng hình ảnh tùy chỉnh cho các runner được lưu trữ đã chính thức khả dụng. Tính năng này cho phép các đội ngũ tạo hình ảnh máy ảo có sẵn các công cụ cần thiết, giúp tối ưu hóa quy trình CI/CD và giảm thiểu thời gian thiết lập.

GitHub Actions chính thức ra mắt tính năng Custom Runner Images

GitHub Actions chính thức ra mắt tính năng Custom Runner Images

GitHub vừa thông báo rằng tính năng hình ảnh tùy chỉnh (custom images) cho các runner được lưu trữ (hosted runners) đã chính thức khả dụng, đánh dấu sự kết thúc giai đoạn xem trước công khai bắt đầu từ tháng 10 năm ngoái. Tính năng mới này cho phép các nhóm phát triển sử dụng hình ảnh cơ bản được GitHub phê duyệt để xây dựng hình ảnh máy ảo đáp ứng chính xác các yêu cầu của quy trình làm việc (workflow).

Giải quyết bài toán cài đặt công cụ lặp lại

Vấn đề mà tính năng này giải quyết rất quen thuộc với bất kỳ ai từng quản lý CI (Tích hợp liên tục) ở quy mô lớn. Mỗi khi một workflow chạy trên runner tiêu chuẩn của GitHub, hệ thống sẽ phải cài đặt các công cụ từ đầu. Node, Python runtime, các SDK dành riêng cho ngôn ngữ, chứng chỉ nội bộ, các tệp nhị phân tùy chỉnh... tất cả đều được tải xuống lại trong mỗi lần chạy, mỗi công việc.

Custom Images đảo ngược mô hình này: bạn "nướng" (bake) mọi thứ vào hình ảnh một lần, và các công việc sau đó sẽ bỏ qua hoàn toàn bước thiết lập này.

Quy trình tạo và quản lý phiên bản

Quy trình triển khai bao gồm ba bước chính: thiết lập một runner tạo hình ảnh, chạy một workflow với từ khóa snapshot, sau đó tạo một runner sử dụng hình ảnh đó.

Từ khóa snapshot là cơ chế cốt lõi. Mỗi công việc có từ khóa này sẽ tạo ra một hình ảnh riêng biệt. Mỗi lần chạy thành công sẽ tạo ra một phiên bản mới; GitHub sẽ tự động tăng số phiên bản phụ (minor version number). Các nhóm muốn kiểm soát chặt chẽ hơn có thể "ghim" (pin) vào một phiên bản chính cụ thể bằng cách sử dụng cú pháp ánh xạ. Runner có thể được cấu hình để sử dụng phiên bản mới nhất hoặc bị khóa ở một số phiên bản cụ thể.

Một runner được ghim vào phiên bản mới nhất sẽ tự động nhận hình ảnh mới vào lần tiếp theo khi phiên bản mới được tạo ra; trong khi đó, runner bị khóa ở phiên bản cụ thể sẽ giữ nguyên cho đến khi ai đó cập nhật thủ công.

GitHub đề xuất thiết lập việc tạo hình ảnh như một nhiệm vụ hàng tuần. Điều này giúp giữ cho các phần phụ thuộc được cập nhật và đảm bảo các bản vá bảo mật được áp dụng thường xuyên. Tuy nhiên, điều này cũng có nghĩa là custom images là một tạo phẩm (artifact) khác cần quản lý; chúng cần được tạo, phiên bản hóa và có thể được kiểm toán.

Về mặt quản trị, chủ sở hữu doanh nghiệp có thể quản lý quyền truy cập vào các hình ảnh tùy chỉnh và đặt chính sách lưu giữ trong cài đặt chính sách Actions.

Tính sẵn có và giới hạn

Hiện tại, tính năng này chỉ dành riêng cho các runner lớn hơn (larger runners), nghĩa là nó gắn liền với các gói GitHub Team hoặc GitHub Enterprise Cloud. Các tổ chức sử dụng gói miễn phí không thể sử dụng tính năng này.

Nền tảng của runner tạo hình ảnh phải khớp với nền tảng của hình ảnh đang được xây dựng: Linux x64, Linux ARM64 hoặc Windows x64.

Cần làm rõ rằng tính năng này không phải là một đường ống hình ảnh máy ảo (VM image pipeline) đa năng. Bạn không thể đưa vào bất kỳ AMI hoặc hình ảnh máy GCP nào từ bên ngoài. Nền tảng phải là hình ảnh cơ bản do GitHub quản lý hoặc một hệ điều hành sạch từ GitHub. Hình ảnh vẫn nằm trong hệ sinh thái của GitHub và bạn có thể tìm thấy nó trong cài đặt Actions của tổ chức dưới mục "Custom images" thay vì trong sổ đăng ký container của riêng bạn.

So sánh với các nền tảng CI khác

Vấn đề về môi trường thực hành có thể tùy chỉnh và được làm nóng trước (pre-warmed) không phải là mới mẻ. Các nền tảng CI khác đã giải quyết vấn đề này theo nhiều cách khác nhau.

GitLab CI cho phép các nhóm chỉ định bất kỳ hình ảnh container nào trong tệp .gitlab-ci.yml. Điều này có nghĩa là họ có thể dễ dàng trỏ một công việc đến hình ảnh trong sổ đăng ký của họ, dù là của GitLab hay bên ngoài. Không cần thêm bước cung cấp nào cả. Hình ảnh được kéo khi bắt đầu công việc.

CircleCI tiếp cận theo hai hướng. Các nhóm có thể chạy trên các thực thi máy (machine executors) với quyền truy cập hệ thống đầy đủ hoặc đưa hình ảnh Docker của riêng họ để đáp ứng các yêu cầu cụ thể. Câu trả lời của CircleCI cho các nhóm cần kiểm soát cấp độ hệ điều hành đầy đủ chủ yếu là các runner tự lưu trữ.

Cách tiếp cận của GitHub đối với custom images tương tự như việc sử dụng nhóm runner tự lưu trữ với các AMI đã được chuẩn bị sẵn trên AWS hoặc thư viện hình ảnh do Packer quản lý. Tuy nhiên, nó được quản lý hoàn toàn và tích hợp vào nền tảng. Sự đánh đổi là giống như bất kỳ giải pháp được quản lý nào: giảm tính linh hoạt để đổi lấy chi phí vận hành thấp hơn.

Giá trị của sự đánh đổi này phụ thuộc vào độ phức tạp của môi trường xây dựng của bạn và liệu tổ chức của bạn có sẵn sàng coi hình ảnh runner là các tạo phẩm quan trọng cần phiên bản hóa và lịch trình cập nhật riêng hay không.

Bài viết được tổng hợp và biên soạn bằng AI từ các nguồn tin tức công nghệ. Nội dung mang tính tham khảo. Xem bài gốc ↗