რატომ გავუშვა საკუთარი runner GitHub-ჰოსტინგის ნაცვლად?

სამი ნამდვილი მიზეზი: თქვენი საკუთარი dependency-ები და toolchain ჩაშენებული (მათი ხელახლა ინსტალაციის გარეშე ყოველ გაშვებაზე), წვდომა პირად რესურსებზე, როგორიცაა შიდა registry ან მონაცემთა ბაზა, და კონტროლი მანქანაზე — მისი ზომა, cache-ები, ქსელი. თუ GitHub-ჰოსტინგ წუთები და სუფთა გარემო გერგებათ, დარჩით მათზე. თვით-ჰოსტინგი, როცა კონკრეტულად ერთ-ერთი ამ სამიდან გჭირდებათ.

რამდენი CPU და RAM სჭირდება runner-ს?

მთლიანად თქვენს build-ზეა დამოკიდებული. ტიპური compile-and-test job კომფორტულია 2 ბირთვითა და 4-8 GB-ით — Small ან Medium აქ. მძიმე build-ები (დიდი native compile-ები, დიდი Docker image-ები, მეხსიერების-მშიერი test suite-ები) მეტს ითხოვენ, და ზომა უნდა განსაზღვროთ თქვენი ნამდვილი job-ისთვის, არა გამოცნობით. უყურეთ ერთ ნამდვილ გაშვებას და გეცოდინებათ.

შეუძლია ერთ runner-ს რამდენიმე repo-ს მართვა?

runner შეიძლება დარეგისტრირდეს ორგანიზაციაზე და აიღოს რამდენიმე repo-მ, ნაგულისხმევად ერთი job ერთ დროს. მეტი პარალელიზმისთვის გაუშვით მეტი runner — თითოეული საკუთარი systemd სერვისია. უბრალოდ შეინახეთ ისინი ყველა პირად repo-ებზე.

მჭირდება თქვენთვის ID-ის მიცემა?

არა. ელფოსტა რეგისტრაციისთვის, USDC ან USDT გადასახდელად. არავითარი დოკუმენტი, root დაახლოებით წუთში.

თვით-ჰოსტინგ GitHub Actions runner-ის გაშვება VPS-ზე

Q: უსაფრთხოა თვით-ჰოსტინგ runner-ის გამოყენება?

პირად repo-ზე, დიახ. საჯარო repo-ზე, არა — არასოდეს. workflow უშვებს თვითნებურ კოდს, ვინც მას აჩენს, და საჯარო repo-ზე უცხოს pull request-ს შეუძლია მისი კოდის გაშვება თქვენს runner-ზე. GitHub-ის საკუთარი docs იმავეს ამბობს. შეინახეთ თვით-ჰოსტინგ runner-ები პირად repo-ებზე, ან მიიღეთ, რომ box-ს ინტერნეტს გადასცემთ.

GitHub-ჰოსტინგ runner-ები კარგი ნაგულისხმევია. მათი საჭიროება წყდება იმ მომენტში, როცა build-ს რაღაც უნდა, რაც მათ არ აქვთ — თქვენი პირადი პაკეტების registry, კონკრეტული toolchain ვერსია, რომლის ხელახლა ინსტალაცია ყოველ გაშვებაზე მოგბეზრდათ, მონაცემთა ბაზა თქვენს ქსელში, ან უბრალოდ მეტი კონტროლი მანქანაზე. სწორედ მაშინ იმსახურებს თვით-ჰოსტინგ runner VPS-ზე თავის ღირებულებას.

ეს გზამკვლევი აყენებს ერთს სათანადოდ: დაინსტალებული, დარეგისტრირებული, ცოცხალი systemd-ის ქვეშ და — ნაწილი, რომელსაც ხალხი არასწორად აკეთებს — უსაფრთხო. დავიწყოთ ამ ბოლოთი, რადგან ეს ის ნაწილია, რომელიც კბენს.

ერთი უსაფრთხოების წესი

GitHub Actions workflow უშვებს თვითნებურ კოდს — რაც workflow ფაილშია და რასაც ის კოდი ჩამოიტანს. თქვენს საკუთარ repo-ზე ეს თქვენი კოდია და ეს კარგია. საჯარო repo-ზე უცხოსგან pull request-ს შეუძლია მისი კოდის გაშვება თქვენს runner-ზე. ეს არ არის bug; ასე მუშაობს CI. GitHub-ის საკუთარი დოკუმენტაცია პირდაპირ ამბობს: ნუ გამოიყენებთ თვით-ჰოსტინგ runner-ებს საჯარო რეპოზიტორიებთან.

ასე რომ წესი მარტივი და შეურყევადია: თვით-ჰოსტინგ runner-ები პირადი repo-ებისთვისაა. თუ თქვენი repo საჯაროა, გამოიყენეთ GitHub-ჰოსტინგ runner-ები და გააგრძელეთ. ყველაფერი ქვემოთ ვარაუდობს პირად repo-ს.

რა სჭირდება runner-ს box-იდან

დამოკიდებულია build-ზე, და ზომა უნდა განსაზღვროთ თქვენისთვის, არა გვერდიდან რიცხვისთვის:

ტიპური compile-and-test job — 2 ბირთვი და 4-8 GB კომფორტულია. Small ($8, 4 vCPU / 4 GB) ან Medium ($12, 6 vCPU / 6 GB) ფარავს ამათ უმეტესს.
უფრო მძიმე build-ები — დიდი native compile-ები, დიდი Docker image build-ები, მეხსიერების-მშიერი test suite-ები — მეტ სივრცეს ითხოვენ. უყურეთ ერთ ნამდვილ გაშვებას (htop, სანამ ის build-ს აკეთებს) და ზომა განსაზღვრეთ იმით, რასაც რეალურად ხედავთ, არა იმედით.

დისკსაც აქვს მნიშვნელობა: build cache-ები, Docker layer-ები და clone-ული repo-ები იზრდება. თვალი ადევნეთ და მოაცილეთ.

1. მოამზადეთ box

შექმენით non-root მომხმარებელი runner-ისთვის — GitHub-ის installer ისედაც უარს ამბობს root-ად გაშვებაზე, და ასეც გინდათ:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # only if your builds genuinely need sudo

დააინსტალეთ, რაც თქვენს build-ებს სჭირდებათ — ენის toolchain, Docker, build ხელსაწყოები. მაგალითად, თუ თქვენი job-ები კონტეინერებს აშენებენ:

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 გაძლევთ ზუსტ გადმოწერის ბრძანებებსა და რეგისტრაციის token-ს (ის მალევადიანია — აიღეთ ის ახალი). runner მომხმარებლად:

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-ის სახელს, label-ებსა და work საქაღალდეს — ნაგულისხმევები კარგია დასაწყებად. label-ები ის არის, როგორ მიმართავს თქვენი workflow ამ runner-ს (runs-on: self-hosted).

3. გაუშვით ის systemd სერვისად

runner მოყვება helper-ს, რომელიც აყენებს 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

GitHub-ის Runners გვერდზე დაბრუნებული, თქვენი runner ახლა აჩვენებს Idle-ს — მწვანე წერტილი. მიმართეთ workflow მასზე:

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

Push, და job მუშაობს თქვენს box-ზე.

4. შეინახეთ ის სუფთად

თვით-ჰოსტინგ runner ხელახლა იყენებს თავის ფაილურ სისტემას job-ებს შორის — ეს არის სიჩქარის მოგება (თბილი cache-ები) და footgun (დარჩენილი მდგომარეობა). ორი ჩვევა ინახავს მას ჯანმრთელად:

მოაცილეთ რეგულარულად. განსაკუთრებით Docker — docker system prune cron-ზე, თორემ დისკი ჩუმად ივსება მკვდარი layer-ებით.
ნუ ინახავთ საიდუმლოებს box-ზე. გამოიყენეთ GitHub Actions secrets, injected per-run, არა ფაილები, box-ის home-ში მჯდარი. თუ runner კომპრომეტირდება, ყველაფერი დისკზე მასთან ერთად მიდის.

თუ გჭირდებათ ჭეშმარიტად სუფთა გარემო ყოველ job-ზე, გაუშვით ყოველი job კონტეინერის step-ის შიგნით — runner რჩება, job-ის არეულობა არა.

როდის თვით-ჰოსტინგოთ, გულწრფელად

თვით-ჰოსტინგი, როცა გჭირდებათ თქვენი საკუთარი toolchain ჩაშენებული, წვდომა პირად ქსელის რესურსებზე ან კონტროლი მანქანაზე. დარჩით GitHub-ჰოსტინგ runner-ებზე, როცა სუფთა, ერთჯერადი გარემო და მათი წუთები გერგებათ — ეს ჭეშმარიტად უფრო მარტივია, და მარტივი რაღაცას ღირს. და არასოდეს, საჯარო repo-ზე, თვით-ჰოსტინგოთ. ის უპირატესობა არ არის.

თუ პირად-repo runner არის ის, რაც გჭირდებათ: აირჩიეთ ტარიფი — Small ($8) მსუბუქი build-ებისთვის, Medium ($12), როცა ისინი უფრო მძიმე ხდება — გადაიხადეთ USDC-ით ან USDT-ით (no KYC, დოკუმენტების გარეშე) და გექნებათ root დაახლოებით 60 წამში. შემდეგ იმუშავეთ ამ გვერდზე და გექნებათ runner, რომელიც job-ებს იღებს რამდენიმე წუთის შემდეგ.

იხილეთ ტარიფი და შეუკვეთეთ VPS →