ทำไมรัน runner ของฉันเองแทน GitHub-hosted?

สามเหตุผลจริง: dependency และ toolchain ของคุณเองอบไว้ (ไม่ต้องติดตั้งใหม่ทุกการรัน) การเข้าถึงทรัพยากรส่วนตัวอย่าง registry หรือฐานข้อมูลภายใน และการควบคุมเครื่อง — ขนาด แคช เครือข่าย หากนาที GitHub-hosted และสภาพแวดล้อมสะอาดเหมาะกับคุณ อยู่กับมัน โฮสต์เองเมื่อคุณต้องการหนึ่งในสามนั้นโดยเฉพาะ

ปลอดภัยไหมที่จะใช้ self-hosted runner?

บน repo ส่วนตัว ใช่ บน repo สาธารณะ ไม่ — ไม่เคย เวิร์กโฟลว์รันโค้ดตามใจจากใครที่ trigger มัน และบน repo สาธารณะ pull request ของคนแปลกหน้ารันโค้ดของพวกเขาบน runner ของคุณได้ เอกสารของ GitHub เองบอกเหมือนกัน เก็บ self-hosted runner ไว้กับ repo ส่วนตัว หรือยอมรับว่าคุณมอบเครื่องให้อินเทอร์เน็ต

runner ต้องการ CPU และ RAM เท่าไร?

ขึ้นอยู่ทั้งหมดกับ build ของคุณ งาน compile-and-test ทั่วไปสบายกับ 2 คอร์และ 4-8 GB — Small หรือ Medium ที่นี่ build หนัก (compile native ใหญ่ อิมเมจ Docker ใหญ่ ชุดเทสต์หิวหน่วยความจำ) ต้องการมากกว่า และคุณควรกำหนดขนาดตามงานจริงของคุณ ไม่ใช่การเดา ดูการรันจริงหนึ่งครั้งแล้วคุณจะรู้

runner หนึ่งจัดการหลาย repo ได้ไหม?

runner ลงทะเบียนกับองค์กรและถูก repo หลายตัวรับได้ หนึ่งงานในแต่ละครั้งโดยค่าเริ่มต้น สำหรับ parallelism มากขึ้น รัน runner มากขึ้น — แต่ละตัวเป็นบริการ systemd ของตัวเอง แค่เก็บพวกมันทั้งหมดบน repo ส่วนตัว

ฉันต้องให้ ID ไหม?

ไม่ อีเมลเพื่อสมัคร USDC หรือ USDT เพื่อจ่าย ไม่มีเอกสาร root ในเวลาประมาณหนึ่งนาที

การรัน Self-Hosted GitHub Actions Runner บน VPS

runner ที่ GitHub โฮสต์เป็นค่าเริ่มต้นที่ดี คุณหยุดต้องการมันทันทีที่ build ต้องการอะไรที่มันไม่มี — registry แพ็กเกจส่วนตัว เวอร์ชัน toolchain เจาะจงที่คุณเบื่อติดตั้งใหม่ทุกการรัน ฐานข้อมูลบนเครือข่ายของคุณเอง หรือแค่การควบคุมเครื่องมากขึ้น นั่นคือเมื่อ self-hosted runner บน VPS ได้ที่ยืน

คู่มือนี้ทำให้หนึ่งรันอย่างถูกต้อง: ติดตั้ง ลงทะเบียน มีชีวิตใต้ systemd และ — ส่วนที่คนทำผิด — ปลอดภัย มาเริ่มด้วยส่วนสุดท้าย เพราะเป็นส่วนที่กัด

กฎความปลอดภัยหนึ่ง

เวิร์กโฟลว์ GitHub Actions รันโค้ดตามใจ — อะไรที่อยู่ในไฟล์เวิร์กโฟลว์ และอะไรที่โค้ดนั้นดึงเข้ามา บน repo ของคุณเองนั่นคือโค้ดของคุณ และมันโอเค บน repo สาธารณะ pull request จากคนแปลกหน้ารันโค้ดของพวกเขาบน runner ของคุณได้ นั่นไม่ใช่บั๊ก มันคือวิธีที่ CI ทำงาน เอกสารของ GitHub เองบอกตรง ๆ: อย่าใช้ self-hosted runner กับ repository สาธารณะ

ดังนั้นกฎง่ายและต่อรองไม่ได้: self-hosted runner สำหรับ repo ส่วนตัว หาก repo ของคุณเป็นสาธารณะ ใช้ runner ที่ GitHub โฮสต์และเดินหน้า ทุกอย่างด้านล่างสันนิษฐาน repo ส่วนตัว

runner ต้องการอะไรจากเครื่อง

ขึ้นอยู่กับ build และคุณควรกำหนดขนาดตามของคุณแทนตัวเลขจากหน้า:

งาน compile-and-test ทั่วไป — 2 คอร์และ 4-8 GB สบาย Small ($8, 4 vCPU / 4 GB) หรือ Medium ($12, 6 vCPU / 6 GB) ครอบคลุมเหล่านี้ส่วนใหญ่
build หนักกว่า — compile native ใหญ่ การ build อิมเมจ Docker ใหญ่ ชุดเทสต์หิวหน่วยความจำ — ต้องการพื้นที่เหลือมากกว่า ดูการรันจริงหนึ่งครั้ง (htop ขณะมัน build) และกำหนดขนาดตามที่คุณเห็นจริง ไม่ใช่ตามความหวัง

ดิสก์สำคัญด้วย: build cache, Docker layer และ repo ที่ clone สะสม เฝ้าดูมันและ prune

1. เตรียมเครื่อง

สร้างผู้ใช้ที่ไม่ใช่ root สำหรับ runner — ตัวติดตั้งของ GitHub ปฏิเสธการรันในฐานะ root อยู่แล้ว และคุณอยากให้เป็นแบบนั้น:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # เฉพาะหาก build ของคุณต้องการ sudo จริง

ติดตั้งอะไรที่ build ของคุณต้องการ — toolchain ภาษา Docker เครื่องมือ build ตัวอย่าง หากงานของคุณ build คอนเทนเนอร์:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner

2. ดาวน์โหลดและลงทะเบียน runner

ใน repo (หรือ org) ของคุณบน GitHub ไป Settings → Actions → Runners → New self-hosted runner GitHub ให้คำสั่งดาวน์โหลดที่แน่นอนและโทเคนลงทะเบียน (มันอายุสั้น — คว้าใหม่) ในฐานะผู้ใช้ runner:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# ใช้ URL ที่แน่นอนที่ GitHub แสดงสำหรับ OS/arch ของคุณ:
curl -o actions-runner-linux-x64.tar.gz -L "URL_FROM_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

config.sh ถามชื่อ runner, label และโฟลเดอร์ work — ค่าเริ่มต้นโอเคที่จะเริ่ม label คือวิธีที่เวิร์กโฟลว์ของคุณมุ่งเป้า runner นี้ (runs-on: self-hosted)

3. รันมันเป็นบริการ systemd

runner มาพร้อมตัวช่วยที่ติดตั้งบริการ systemd ให้คุณ — ใช้มัน เพื่อให้ runner รอดรีบูตและรีสตาร์ทเมื่อล้มเหลว ยังในฐานะการติดตั้งของผู้ใช้ runner แต่คำสั่งบริการต้องการ root:

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

นั่นลงทะเบียน actions.runner.* เป็น systemd unit ที่รันในฐานะผู้ใช้ runner เริ่มตอนบูต log ไป journald:

sudo journalctl -u 'actions.runner.*' -f

กลับที่หน้า Runners ของ GitHub runner ของคุณตอนนี้แสดง Idle — จุดเขียว ชี้เวิร์กโฟลว์ไปที่มัน:

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: make test

push และงานรันบนเครื่องของคุณ

4. เก็บมันให้สะอาด

self-hosted runner ใช้ filesystem ซ้ำระหว่างงาน — นั่นคือชัยชนะความเร็ว (แคช warm) และ footgun (สถานะค้าง) สองนิสัยเก็บมันให้แข็งแรง:

prune สม่ำเสมอ Docker โดยเฉพาะ — docker system prune บน cron หรือดิสก์เต็มเงียบ ๆ ด้วย layer ตาย
อย่าเก็บความลับบนเครื่อง ใช้ secret ของ GitHub Actions ฉีดต่อการรัน ไม่ใช่ไฟล์นั่งในบ้านของ runner หาก runner ถูกบุกรุก อะไรบนดิสก์ไปกับมัน

หากคุณต้องการสภาพแวดล้อมสะอาดจริงต่องาน รันแต่ละงานในขั้นคอนเทนเนอร์ — runner อยู่ ความรกของงานไม่

เมื่อไรโฮสต์เอง อย่างตรงไปตรงมา

โฮสต์เองเมื่อคุณต้องการ toolchain ของคุณเองอบไว้ การเข้าถึงทรัพยากรเครือข่ายส่วนตัว หรือการควบคุมเครื่อง อยู่กับ runner ที่ GitHub โฮสต์เมื่อสภาพแวดล้อมใช้แล้วทิ้งสะอาดและนาทีของพวกเขาเหมาะกับคุณ — นั่นง่ายกว่าจริง และง่ายกว่าคุ้มค่า และไม่เคย บน repo สาธารณะ โฮสต์เอง อันนั้นไม่ใช่ความชอบ

หาก runner บน repo ส่วนตัวคือสิ่งที่คุณต้องการ: เลือกแพ็กเกจ — Small ($8) สำหรับ build เบา Medium ($12) เมื่อมันหนักกว่า — จ่ายด้วย USDC หรือ USDT (ไม่ต้อง KYC ไม่มีเอกสาร) และคุณจะมี root ในเวลาประมาณ 60 วินาที จากนั้นทำตามหน้านี้แล้วคุณจะมี runner รับงานสองสามนาทีถัดมา

ดูแพ็กเกจ & สั่งซื้อ VPS →