Tới nội dung
Cloudj

Ứng dụng VPS

Tự host GitHub Actions runner trên VPS CPU dedicated

Hướng dẫn tự host GitHub Actions runner trên VPS: cài thành service, bảo mật khi dùng với repo public, và thêm runner tính giờ khi cần chạy CI dồn dập.

Cập nhật · 5 phút đọc

Tự host GitHub Actions runner nghĩa là bạn dùng một máy chủ của mình để nhận và chạy job từ workflow GitHub thay cho runner do GitHub cung cấp. Các team thường chuyển sang cách này vì ba lý do: build cần nhiều CPU hoặc RAM hơn runner mặc định, job cần phần mềm hay quyền truy cập mạng mà dựng lại mỗi lần chạy rất phiền, hoặc phút CI đã thành một khoản chi đáng quản lý. Bài này hướng dẫn từng bước cài runner trên VPS Linux, giải thích các nguyên tắc bảo mật quan trọng (nhất là với repo public), và cách dùng VPS tính giờ để thêm năng lực chạy CI theo đợt mà không phải trả tiền cho máy rảnh cả tháng.

Chọn máy chủ cho runner

Job CI chạy theo từng đợt và ngốn CPU. Một lần compile hay chạy test suite đẩy mọi core lên tối đa vài phút, rồi máy ngồi không. Vì vậy loại CPU là quyết định chính:

  • CPU dedicated cho bạn core riêng, thời gian build ổn định giữa các lần chạy. Công việc nặng CPU và đều đặn chính là thứ core dedicated sinh ra để phục vụ, cũng là lý do nhiều người chạy bot giao dịch crypto trên VPS Singapore hay VPS forex tại London trên loại CPU này.
  • General purpose là lựa chọn mặc định hợp lý cho job hỗn hợp: lint, unit test, build Docker nhỏ.
  • Shared ("Availability") đủ cho job nhẹ như script deploy hay tác vụ định kỳ.

Trên Cloudj, mỗi vị trí có 30 gói dựng sẵn hoặc bạn tự phối vCPU, RAM, ổ đĩa, từ 1 vCPU, 1 GB RAM đến 104 vCPU và 512 GB RAM. Với build, ổ đĩa quan trọng hơn bạn nghĩ: layer Docker, cache thư viện và artifact lấp đầy 20 GB rất nhanh, nên hãy chọn ổ lớn ngay từ đầu. Giá chính xác hiện trong console trước khi triển khai, còn trang bảng giá có giá trực tiếp.

Vị trí máy chủ ít quan trọng với CI hơn so với ứng dụng phục vụ người dùng, nhưng vẫn có ảnh hưởng. Hãy đặt runner gần thứ nó làm việc nhiều nhất: container registry, nơi lưu artifact hoặc máy chủ mà nó deploy tới. Bài hướng dẫn chọn vị trí VPS điểm qua 14 quốc gia có trên trang cloud server.

Các bước tự host GitHub Actions runner

Các bước dưới đây dùng Ubuntu hoặc Debian. Hãy bắt đầu từ một máy chủ đã cài SSH key và firewall theo checklist bảo mật VPS mới. Runner chỉ kết nối ra ngoài tới GitHub qua HTTPS, nên bạn không cần mở cổng inbound nào cho nó.

1. Tạo user riêng

Đừng bao giờ chạy runner bằng root. Tạo một user riêng:

sudo adduser --disabled-password --gecos "" runner
sudo su - runner

2. Tải runner

Trong repo (hoặc organization), vào Settings, chọn Actions, rồi Runners, bấm New self-hosted runner và chọn Linux, x64. GitHub hiển thị đúng lệnh tải với phiên bản hiện tại kèm một registration token có hạn ngắn. Lệnh có dạng:

mkdir actions-runner && cd actions-runner
curl -o actions-runner.tar.gz -L https://github.com/actions/runner/releases/download/v<version>/actions-runner-linux-x64-<version>.tar.gz
tar xzf ./actions-runner.tar.gz

Hãy lấy số phiên bản từ trang của GitHub thay vì từ bài này, vì runner được cập nhật thường xuyên.

3. Cài thư viện phụ thuộc và đăng ký

Quay lại user có quyền sudo để cài thư viện hệ thống cho runner, rồi đăng ký bằng user runner:

sudo /home/runner/actions-runner/bin/installdependencies.sh
sudo su - runner
cd actions-runner
./config.sh --url https://github.com/OWNER/REPO --token <TOKEN> --name build-01 --labels linux,dedicated --unattended

Label là cách workflow chọn đúng máy này.

4. Chạy runner như một service

Runner có sẵn script cài service systemd:

cd /home/runner/actions-runner
sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

Giờ runner tự chạy lại sau khi khởi động máy và hiện trạng thái Idle trong danh sách Runners.

5. Trỏ workflow vào runner

jobs:
  build:
    runs-on: [self-hosted, linux, dedicated]
    steps:
      - uses: actions/checkout@v4
      - run: make test

Nếu job cần build container, hãy cài Docker theo bài cài Docker trên VPS. Lưu ý rằng thêm user runner vào nhóm docker gần như trao quyền root trên máy, và đó là lúc phải nói tới bảo mật.

Bảo mật: phần hay bị bỏ qua

Runner chạy bất cứ đoạn code nào workflow yêu cầu. Đó là mục đích của nó, và cũng là rủi ro.

Không gắn runner tự host chạy lâu dài vào repo public. Chính tài liệu của GitHub cảnh báo điều này: ai cũng có thể mở pull request từ fork, và workflow chạy theo pull request đó có thể thực thi code của họ trên máy bạn, đọc mọi thứ user runner đọc được, rồi để lại thứ gì đó cho job sau. Nếu buộc phải dùng runner tự host với repo public, hãy bật yêu cầu duyệt workflow từ người đóng góp bên ngoài và dùng runner ephemeral.

Vài nguyên tắc thực tế khác:

  • Dùng runner ephemeral cho job không tin cậy hoặc hỗn hợp. Đăng ký với --ephemeral khiến runner nhận đúng một job rồi tự hủy đăng ký, không còn gì sót lại giữa các job. Kết hợp với máy chủ mới hoặc container sạch cho mỗi job.
  • Giới hạn phạm vi secret. Dùng secret cấp environment có người duyệt cho job deploy, để job test không đọc được thông tin đăng nhập production.
  • Tách build và deploy. Runner có quyền SSH vào production không nên build pull request.
  • Hạn chế kết nối ra ngoài nếu được. Firewall chỉ cho phép đúng những gì job cần sẽ giới hạn thứ mà một job bị chiếm quyền có thể chạm tới.
  • Cập nhật hệ điều hành. Runner tự cập nhật, còn hệ điều hành thì không. Hãy bật cập nhật bảo mật tự động.

Hướng dẫn đầy đủ của GitHub có trong tài liệu về self-hosted runner.

Thêm runner theo đợt với VPS tính giờ

Phần lớn thời gian team chỉ cần một hai runner, nhưng tuần phát hành có thể cần năm đến mười. VPS tính giờ khớp với nhu cầu đó. Cloudj trừ tiền máy chủ tính giờ từ số dư tài khoản trong suốt thời gian máy tồn tại, và khi tính giờ thì băng thông được tính theo GB sử dụng.

Có một chi tiết cần nhớ: máy chủ tính giờ vẫn bị tính phí khi còn tồn tại, dù đang chạy hay đã tắt, vì ổ đĩa và IP vẫn được giữ cho bạn. Tắt runner không làm dừng hóa đơn. Phát hành xong, hãy hủy đăng ký runner (./config.sh remove --token <TOKEN>) rồi xóa máy chủ.

Để dựng nhanh, hãy chuẩn bị một runner đã cài sẵn toolchain, image Docker và cache, gỡ đăng ký, rồi lưu thành custom image. Runner bổ sung triển khai từ image đó chỉ cần chạy bước config.sh. So sánh hai cách tính phí có trong bài VPS theo giờ hay theo tháng, còn môi trường dựng lên rồi xóa nói chung có trong bài VPS tính giờ cho staging.

Runner chạy thường trực nên dùng kỳ trả trước theo tháng có sẵn băng thông, giống như bất kỳ máy nào phải chạy suốt tháng, chẳng hạn VPS forex tại New York.

Câu hỏi thường gặp

Có cần mở cổng nào cho runner không?

Không. Runner kết nối ra ngoài tới GitHub qua HTTPS và chờ job. Chỉ cần để inbound cho SSH.

Một VPS chạy được nhiều runner không?

Được. Cài mỗi runner vào một thư mục riêng, đặt tên và service riêng. Hãy đảm bảo CPU và RAM đủ cho các job chạy cùng lúc, nếu không chúng sẽ làm chậm nhau.

Có build trên Windows được không?

Cloudj có máy chủ Windows, đăng nhập bằng mật khẩu và có phí bản quyền hằng tháng hiển thị trong console trước khi triển khai. GitHub có gói runner riêng cho Windows.

Runner có tự chạy lại sau khi máy khởi động lại không?

Có. Vì runner được cài như service systemd, nó tự khởi động sau khi máy reboot hoặc sau khi đổi cấu hình, rồi trở về trạng thái Idle.

Bước tiếp theo

Triển khai một máy chủ CPU dedicated trong console Cloudj, đăng ký làm runner và theo dõi vài lần build trước khi thêm máy. Khi tuần bận rộn tới, dựng thêm runner tính giờ từ custom image rồi xóa khi xong việc. Nếu thanh toán từ Việt Nam, bạn có thể nạp số dư bằng chuyển khoản ngân hàng bằng VND.

Triển khai máy chủ hoặc mua proxy

Chọn vị trí trong console, xem giá trực tiếp và thanh toán từ số dư tài khoản.