Γιατί να τρέξω τον δικό μου runner αντί για GitHub-hosted;

Τρεις πραγματικοί λόγοι: οι δικές σας εξαρτήσεις και toolchain ενσωματωμένα (χωρίς επανεγκατάστασή τους σε κάθε εκτέλεση), πρόσβαση σε ιδιωτικούς πόρους όπως ένα εσωτερικό registry ή βάση δεδομένων, και έλεγχος της μηχανής — του μεγέθους της, των caches της, του δικτύου της. Αν τα GitHub-hosted λεπτά και ένα καθαρό περιβάλλον σας ταιριάζουν, μείνετε σε αυτά. Self-host όταν χρειάζεστε συγκεκριμένα έναν από αυτούς τους τρεις.

Είναι ασφαλές να χρησιμοποιώ έναν self-hosted runner;

Σε ένα ιδιωτικό repo, ναι. Σε ένα δημόσιο repo, όχι — ποτέ. Ένα workflow τρέχει αυθαίρετο κώδικα από όποιον το ενεργοποιεί, και σε ένα δημόσιο repo ένα pull request ενός αγνώστου μπορεί να τρέξει τον κώδικά του στον runner σας. Η ίδια η τεκμηρίωση του GitHub λέει το ίδιο. Κρατήστε τους self-hosted runners σε ιδιωτικά repos, ή αποδεχτείτε ότι παραδίδετε το box σας στο διαδίκτυο.

Πόση CPU και RAM χρειάζεται ένας runner;

Εξαρτάται εντελώς από το build σας. Ένα τυπικό job compile-and-test είναι άνετο με 2 πυρήνες και 4-8 GB — Small ή Medium εδώ. Βαριά builds (μεγάλα native compiles, μεγάλες Docker images, memory-hungry σουίτες tests) θέλουν περισσότερα, και θα πρέπει να ορίσετε το μέγεθος στο πραγματικό σας job, όχι σε μια μαντεψιά. Παρακολουθήστε μία πραγματική εκτέλεση και θα ξέρετε.

Μπορεί ένας runner να χειριστεί πολλά repos;

Ένας runner μπορεί να καταχωρηθεί σε έναν οργανισμό και να τον αναλάβουν αρκετά repos, ένα job τη φορά εξ ορισμού. Για περισσότερο parallelism, τρέξτε περισσότερους runners — καθένας είναι το δικό του systemd service. Απλώς κρατήστε τους όλους σε ιδιωτικά repos.

Χρειάζεται να σας δώσω ID;

Όχι. Email για εγγραφή, USDC ή USDT για πληρωμή. Χωρίς έγγραφα, root σε περίπου ένα λεπτό.

Τρέχοντας έναν Self-Hosted GitHub Actions Runner σε VPS

Οι GitHub-hosted runners είναι μια καλή προεπιλογή. Παύετε να τους χρειάζεστε τη στιγμή που ένα build θέλει κάτι που δεν έχουν — το ιδιωτικό σας package registry, μια συγκεκριμένη έκδοση toolchain που βαρεθήκατε να επανεγκαθιστάτε σε κάθε εκτέλεση, μια βάση δεδομένων στο δικό σας δίκτυο, ή απλώς περισσότερο έλεγχο της μηχανής. Τότε ένας self-hosted runner σε VPS αξίζει τη θέση του.

Αυτός ο οδηγός βάζει έναν να τρέχει σωστά: εγκατεστημένο, καταχωρημένο, ζωντανό κάτω από systemd, και — το μέρος που οι άνθρωποι κάνουν λάθος — ασφαλή. Ας ξεκινήσουμε με αυτό το τελευταίο, γιατί είναι το μέρος που δαγκώνει.

Ο ένας κανόνας ασφαλείας

Ένα workflow GitHub Actions τρέχει αυθαίρετο κώδικα — ό,τι είναι στο αρχείο workflow, και ό,τι τραβά αυτός ο κώδικας. Στο δικό σας repo αυτό είναι ο κώδικάς σας, και είναι εντάξει. Σε ένα δημόσιο repo, ένα pull request από έναν άγνωστο μπορεί να τρέξει τον δικό του κώδικα στον runner σας. Αυτό δεν είναι bug· είναι πώς λειτουργεί το CI. Η ίδια η τεκμηρίωση του GitHub λέει ξεκάθαρα: μη χρησιμοποιείτε self-hosted runners με δημόσια repositories.

Οπότε ο κανόνας είναι απλός και μη διαπραγματεύσιμος: οι self-hosted runners είναι για ιδιωτικά repos. Αν το repo σας είναι δημόσιο, χρησιμοποιήστε GitHub-hosted runners και προχωρήστε. Όλα τα παρακάτω υποθέτουν ένα ιδιωτικό repo.

Τι χρειάζεται ένας runner από το box

Εξαρτάται από το build, και θα πρέπει να ορίσετε το μέγεθος στο δικό σας παρά σε ένα νούμερο από μια σελίδα:

Ένα τυπικό job compile-and-test — 2 πυρήνες και 4-8 GB είναι άνετα. Το Small ($8, 4 vCPU / 4 GB) ή το Medium ($12, 6 vCPU / 6 GB) καλύπτει τα περισσότερα από αυτά.
Βαρύτερα builds — μεγάλα native compiles, μεγάλα Docker image builds, memory-hungry σουίτες tests — θέλουν περισσότερο περιθώριο. Παρακολουθήστε μία πραγματική εκτέλεση (htop όσο χτίζει) και ορίστε το μέγεθος σε αυτό που πραγματικά βλέπετε, όχι στην ελπίδα.

Ο δίσκος μετρά επίσης: τα build caches, τα Docker layers, και τα cloned repos αθροίζονται. Κρατήστε ένα μάτι σε αυτόν και κάντε prune.

1. Προετοιμάστε το box

Δημιουργήστε έναν non-root χρήστη για τον runner — ο installer του GitHub αρνείται να τρέξει ως 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 και ένα registration 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, labels, και έναν φάκελο work — οι προεπιλογές είναι εντάξει για αρχή. Τα labels είναι πώς το workflow σας στοχεύει αυτόν τον runner (runs-on: self-hosted).

3. Τρέξτε τον ως systemd service

Ο runner έρχεται με έναν βοηθό που εγκαθιστά ένα systemd service για εσάς — χρησιμοποιήστε τον, ώστε ο runner να επιβιώνει επανεκκινήσεων και να επανεκκινεί σε αποτυχία. Ακόμη στην εγκατάσταση του χρήστη runner, αλλά οι εντολές service χρειάζονται root:

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

Αυτό καταχωρεί το actions.runner.* ως ένα systemd unit που τρέχει ως ο χρήστης runner, ξεκινώντας στο boot. Τα logs πάνε στο journald:

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

Πίσω στη σελίδα Runners του GitHub, ο runner σας τώρα δείχνει Idle — πράσινη κουκκίδα. Στρέψτε ένα workflow σε αυτόν:

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

Κάντε push, και το job τρέχει στο box σας.

4. Κρατήστε τον καθαρό

Ένας self-hosted runner επαναχρησιμοποιεί το filesystem του μεταξύ jobs — αυτό είναι το κέρδος ταχύτητας (ζεστά caches) και το footgun (leftover state). Δύο συνήθειες τον κρατούν υγιή:

Κάντε prune τακτικά. Το Docker ειδικά — docker system prune σε ένα cron, αλλιώς ο δίσκος γεμίζει σιωπηλά με νεκρά layers.
Μην αποθηκεύετε secrets στο box. Χρησιμοποιήστε GitHub Actions secrets, injected ανά εκτέλεση, όχι αρχεία που κάθονται στο home του runner. Αν ο runner παραβιαστεί, οτιδήποτε στον δίσκο πάει μαζί του.

Αν χρειάζεστε ένα πραγματικά καθαρό περιβάλλον ανά job, τρέξτε κάθε job μέσα σε ένα container step — ο runner μένει, το χάος του job όχι.

Πότε να κάνετε self-host, έντιμα

Self-host όταν χρειάζεστε το δικό σας toolchain ενσωματωμένο, πρόσβαση σε ιδιωτικούς πόρους δικτύου, ή έλεγχο της μηχανής. Μείνετε σε GitHub-hosted runners όταν ένα καθαρό, αναλώσιμο περιβάλλον και τα λεπτά τους σας ταιριάζουν — αυτό είναι γνήσια απλούστερο, και το απλούστερο αξίζει κάτι. Και ποτέ, σε δημόσιο repo, μην κάνετε self-host. Αυτό δεν είναι προτίμηση.

Αν ένας runner ιδιωτικού-repo είναι αυτό που χρειάζεστε: επιλέξτε πακέτο — Small ($8) για ελαφρύτερα builds, Medium ($12) όταν γίνονται βαρύτερα — πληρώστε σε USDC ή USDT (χωρίς KYC, χωρίς έγγραφα), και θα έχετε root σε περίπου 60 δευτερόλεπτα. Μετά δουλέψτε προς τα κάτω αυτή τη σελίδα και θα έχετε έναν runner να αναλαμβάνει jobs μερικά λεπτά αργότερα.

Δείτε το πακέτο & παραγγείλτε VPS →