GitHub-hosted runners ጥሩ default ናቸው። build እነሱ የሌላቸውን ነገር በሚፈልግበት ቅጽበት እነሱን መፈለግ ያቆማሉ — የprivate package-registryዎ፣ እያንዳንዱን run እንደገና ከመጫን የሰለቹት የተወሰነ toolchain version፣ በራስዎ network ላይ database፣ ወይም በmachine ላይ ተጨማሪ ቁጥጥር ብቻ። ያ በVPS ላይ self-hosted runner ገንዘቡን የሚያገኝበት ነው።
ይህ መመሪያ አንዱን በትክክል ያሄዳል: የተጫነ፣ የተመዘገበ፣ በsystemd ስር ሕያው፣ እና — ሰዎች የሚሳሳቱበት ክፍል — ደኅንነቱ የተጠበቀ። በዚያ የመጨረሻው እንጀምር፣ ምክንያቱም የሚነክሰው ክፍል ስለሆነ።
አንዱ security rule
GitHub Actions workflow arbitrary code ያሄዳል — በworkflow file ውስጥ ያለው ማንኛውም፣ እና ያ code የሚያመጣው ማንኛውም። በራስዎ repo ላይ ያ codeዎ ነው፣ እና ጥሩ ነው። በpublic repo ላይ የእንግዳ pull request codeቸውን በrunnerዎ ላይ ማሄድ ይችላል። ያ bug አይደለም፤ CI እንዲህ ነው የሚሠራው። የGitHub የራሱ documentation በግልጽ ይላል: self-hosted runners ከpublic repositories ጋር አይጠቀሙ።
ስለዚህ ደንቡ ቀላል እና የማይደራደር ነው: self-hosted runners ለprivate repos ናቸው። repoዎ public ከሆነ፣ GitHub-hosted runners ይጠቀሙ እና ይቀጥሉ። ከታች ያለው ሁሉ private repo ይገምታል።
runner ከbox ምን እንደሚፈልግ
በbuild ላይ ይወሰናል፣ እና ከገጽ ላይ ካለ ቁጥር ይልቅ ለእርስዎ መመዘን አለብዎ:
- የተለመደ compile-and-test job — 2 cores እና 4-8 GB ምቹ ነው። Small ($8, 4 vCPU / 4 GB) ወይም Medium ($12, 6 vCPU / 6 GB) አብዛኞቹን ይሸፍናል።
- ከባድ builds — ትላልቅ native compiles፣ ትላልቅ Docker image builds፣ memory-የተራቡ test suites — ተጨማሪ ቦታ ይፈልጋሉ። አንድ እውነተኛ run ይመልከቱ (
htopሲገነባ) እና ለሚያዩት መመዘን፣ ለተስፋ አይደለም።
Disk ደግሞ ያስፈልጋል: build caches፣ Docker layers፣ እና cloned repos ይደራረባሉ። ዓይን ይጣሉበት እና ያprune ያድርጉ።
1. boxን ያዘጋጁ
ለrunner non-root user ይፍጠሩ — የGitHub installer ለማንኛውም እንደ root ማሄድ ይከለክላል፣ እና እንዲህ ይፈልጋሉ:
sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner # only if your builds genuinely need sudo
buildsዎ የሚፈልጉትን ይጫኑ — language toolchain፣ Docker፣ build tools። ለምሳሌ፣ jobsዎ containers የሚገነቡ ከሆኑ:
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 ትክክለኛዎቹን download commands እና registration token ይሰጥዎታል (አጭር-የሚኖር ነው — ትኩስ ይያዙት)። እንደ runner user:
sudo -iu runner
mkdir actions-runner && cd actions-runner
# use the exact URL GitHub shows you for your 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 name፣ labels፣ እና work folder ይጠይቃል — defaults ለመጀመር ጥሩ ናቸው። Labels workflowዎ ይህን runner እንዴት እንደሚtarget ያደርግ ናቸው (runs-on: self-hosted)።
3. እንደ systemd service ያሂዱት
runner systemd service ለእርስዎ የሚጭን helper ጋር ይመጣል — ይጠቀሙት፣ runner reboots እንዲተርፍ እና በfailure እንዲrestart። አሁንም እንደ runner user install፣ ግን service commands root ይፈልጋሉ:
sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status
ያ actions.runner.*ን እንደ runner user የሚሮጥ systemd unit ይመዘግባል፣ በboot ይጀምራል። Logs ወደ journald ይሄዳሉ:
sudo journalctl -u 'actions.runner.*' -f
ወደ GitHub Runners page ተመልሰው፣ runnerዎ አሁን Idle ያሳያል — አረንጓዴ ነጥብ። workflow ወደ እሱ ይምሩ:
jobs:
build:
runs-on: self-hosted
steps:
- uses: actions/checkout@v4
- run: make test
ይpush ያድርጉ፣ እና job በboxዎ ላይ ይሮጣል።
4. ንፁህ ያድርጉት
self-hosted runner በjobs መካከል filesystemውን እንደገና ይጠቀማል — ያ የፍጥነት ትርፉ (ሞቅ ያሉ caches) እና footgunው (የቀረ state) ነው። ሁለት ልማዶች ጤናማ ያደርጉታል:
- በመደበኛ ያprune ያድርጉ። Docker በተለይ —
docker system pruneበcron ላይ፣ አለበለዚያ disk በሞቱ layers ጸጥ ብሎ ይሞላል። - secrets በbox ላይ አያከማቹ። GitHub Actions secrets ይጠቀሙ፣ በእያንዳንዱ run የተስገባ፣ በrunner home ውስጥ ያሉ files አይደለም። runner ከተበላሸ፣ በdisk ላይ ያለው ሁሉ ከእሱ ጋር ይሄዳል።
በእያንዳንዱ job በእውነት ንፁህ environment ከፈለጉ፣ እያንዳንዱን job በcontainer step ውስጥ ያሂዱ — runner ይቆያል፣ የjob ብጥብጥ አይቀርም።
መቼ self-host ማድረግ፣ በሐቀኝነት
የራስዎ toolchain የተጋገረ ሲፈልጉ፣ private network resources መዳረሻ፣ ወይም በmachine ላይ ቁጥጥር ሲፈልጉ self-host ያድርጉ። ንፁህ፣ throwaway environment እና minutesቸው ሲስማሙዎ በGitHub-hosted runners ይቆዩ — ያ በእውነት ቀላል ነው፣ እና ቀላል ዋጋ አለው። እና ፈጽሞ፣ በpublic repo ላይ፣ self-host አያድርጉ። ያ ምርጫ አይደለም።
private-repo runner የሚፈልጉት ከሆነ: plan ይምረጡ — Small ($8) ለቀላል builds፣ Medium ($12) ሲከብዱ — በUSDC ወይም USDT ይክፈሉ (KYC የለም፣ documents የለም)፣ እና በ60 ሰከንድ አካባቢ root ይኖርዎታል። ከዚያ ይህን ገጽ ወደታች ይሥሩ እና ከጥቂት ደቂቃዎች በኋላ jobs የሚይዝ runner ይኖርዎታል።
አስተያየቶች
እስካሁን አስተያየቶች የሉም። መጀመሪያ ይሁኑ።