Samodzielnie hostowane runnery GitHub Actions w UE
Te same workflow, na maszynie w Pradze lub Covilhã, która jest Twoja na miesiąc, a nie na minutę - z wciąż ciepłą pamięcią podręczną kompilacji i jednym adresem, który zapora naprawdę może dopuścić.
Dla kogo to jest
Zespół obserwujący licznik minut
Minuta Linuksa na 2 rdzeniach kosztuje 0,006 USD, a na 16 rdzeniach 0,042 USD, więc kompilacja macierzowa, która przyspieszyła zestaw testów, jest dokładnie tym, co uczyniło rachunek interesującym.
Workflow, który musi sięgnąć do czegoś prywatnego
Krok wdrożenia musi rozmawiać z bazą danych, rejestrem albo urządzeniem, które przyjmuje tylko znane adresy, a hostowane runnery GitHuba przychodzą z zakresu zbyt wielkiego, żeby go dopuścić.
Kompilacja, której trzeba więcej, niż niesie obraz
Licencjonowany kompilator, emulator, 30 GB danych testowych albo po prostu więcej dysku, niż ma hostowany runner - a instalowanie tego od nowa w każdym zadaniu to większość potoku.
Co się zmienia, gdy runner jest Twój
- Katalog roboczy i pamięci podręczne przetrwają między zadaniami, więc odtwarzanie zależności przestaje być najdłuższym krokiem workflow.
- Statyczny IPv4 z AS204057, który Twoja baza danych, rejestr albo VPN mogą dopuścić po adresie.
- To, co zainstalujesz, zostaje zainstalowane - łańcuchy narzędzi, licencjonowane SDK, emulatory, wielkie zestawy danych testowych, wszystko, czego hostowany obraz nie niesie.
- Runnery zarejestrowane na poziomie repozytorium, organizacji albo przedsiębiorstwa, z etykietami, które sam wybierasz, i workflow, który wskazuje je przez runs-on.
- Dysk i pamięć według Twojego wyboru, zamiast sztywnego kształtu hostowanego runnera.
- Maszyna w Pradze lub Covilhã na umowie cypryjskiej, co jest odpowiedzią o lokalizację danych, a nie ustawieniem regionu.
Dobrane do tego, co potok naprawdę robi
Jedna usługa runnera to jedno zadanie naraz, więc równoległość jest tu liczbą procesów runnera, a nie progiem planu - kilka na jednym hoście, każdy we własnym katalogu, to normalny układ. Dobieraj według najcięższego zadania, nie średniej, i zostaw zapas dysku: katalog roboczy, pamięć podręczna narzędzi i warstwy kontenerów mieszkają tam wszystkie, a właśnie ta trwałość jest powodem, żeby hostować u siebie. Uczciwa połowa transakcji: stały miesięczny host kosztuje tyle samo w tygodniu bez wypchnięć, gdzie minuty u dostawcy nie kosztują nic. Opłaca się, gdy tylko potok działa niemal codziennie.
Jak zainstalować runner GitHub Actions na świeżym hoście
Linux x64, w kolejności, którą dokumentuje GitHub. Token rejestracyjny jest generowany per runner i wygasa godzinę po otwarciu strony, więc weź go na końcu.
-
Utwórz dla niego nieuprzywilejowanego użytkownika
sudo adduser --disabled-password --gecos "" runner sudo -iu runnerRunner wykonuje to, co każe mu workflow, więc nie powinien być rootem ani dzielić katalogu domowego z czymkolwiek innym. Wszystko poniżej działa jako ten użytkownik.
-
Pobierz i rozpakuj runner
mkdir actions-runner && cd actions-runner curl -O -L https://github.com/actions/runner/releases/download/v2.336.0/actions-runner-linux-x64-2.336.0.tar.gz echo "04cf0be1aff4c3ec3554466c39124ca250e3effd8873bb7e8d68535aa9505d5d actions-runner-linux-x64-2.336.0.tar.gz" | shasum -a 256 -c tar xzf ./actions-runner-linux-x64-2.336.0.tar.gzTa wersja i ta suma kontrolna to te opublikowane wraz z wydaniem v2.336.0. Zanim to skopiujesz, sprawdź na stronie wydań, czy nie ma nowszej: runner potem sam się aktualizuje, ale pierwsze pobranie należy do Ciebie i to Ty je weryfikujesz.
-
Skonfiguruj go pod repozytorium albo organizację
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token AXXXXXXXXXXXXXXXXXXXXXXXXX --labels self-hosted,linux,x64,euToken weź z Settings, potem Actions, potem Runners, potem New self-hosted runner - jest ograniczony czasowo i wygasa godzinę po wydaniu. Wskaż adres organizacji zamiast repozytorium, żeby dzielić jeden runner między repozytoria.
-
Uruchom go jako usługę
sudo ./svc.sh install runner sudo ./svc.sh start sudo ./svc.sh statussvc.sh przyjmuje użytkownika, na którym usługa ma działać - dlatego użytkownik runner powstał najpierw. Użyj zamiast tego ./run.sh, jeśli chcesz tylko zobaczyć, jak ląduje jedno zadanie, zanim zdecydujesz się na usługę.
-
Powstrzymaj needrestart przed ubijaniem zadań w trakcie
echo '$nrconf{override_rc}{qr(^actions\.runner\..+\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/actions_runner_services.confW Debianie i Ubuntu needrestart restartuje usługi, których biblioteki zostały zaktualizowane - także runner w środku zadania. GitHub dokumentuje dokładnie ten plik jako sposób na wyłączenie go z tego mechanizmu.
-
Skieruj na niego workflow
name: smoke on: [push] jobs: build: runs-on: [self-hosted, linux, x64, eu] steps: - uses: actions/checkout@v6 - run: cat /etc/os-releaseruns-on dopasowuje każdą etykietę z listy, więc zadanie proszące o cztery etykiety wyląduje tylko na runnerze, który ma wszystkie cztery. Jeśli zostaje w kolejce, brakuje jednej etykiety - a zadanie czekające dłużej niż 24 godziny kończy się niepowodzeniem.
Sprawdzone z oficjalną dokumentacją dnia 2026-08-15 — przeczytaj źródło
Czym nie jesteśmy
- Nie jesteśmy GitHubem. GitHub, GitHub Actions i runner należą do nich i nic na tej stronie nie jest przez nich firmowane. Sprzedajemy maszynę, na której runner działa.
- To nie zastępuje Twojego planu GitHuba. Samodzielnie hostowane runnery nie kosztują minut Actions, o to właśnie chodzi, ale licencje, przestrzeń i cała reszta zostają na ich fakturze.
- Nie zarządzamy runnerem, o ile o to nie poprosisz. Instalujesz go sam albo dokładasz naszą usługę administracji, a my trzymamy go załatanego, zarejestrowanego i pod obserwacją.
- Samodzielnie hostowane runnery są udokumentowane jako słabo pasujące do publicznych repozytoriów: fork może zaproponować zmianę w pliku workflow, a ta zmieniona wersja uruchomiłaby się na Twojej maszynie. Trzymaj je przy prywatnych repozytoriach, chyba że dokładnie to przemyślałeś.
- Nie ma tu warstwy sterowania z autoskalowaniem. Jeśli chcesz runnerów tworzonych i niszczonych per zadanie, to Actions Runner Controller na klastrze Kubernetes - który chętnie hostujemy, na innej stronie.
Elementy, które zespoły odkrywają za późno
- Jedna usługa runnera wykonuje jedno zadanie naraz. Równoległość bierze się z zainstalowania kilku, każdej we własnym katalogu i z własną usługą, a nie z ustawienia.
- Token rejestracyjny wygasa godzinę po wydaniu, więc generuj go wtedy, gdy jesteś gotowy uruchomić config.sh, a nie na początku popołudnia.
- Etykiety to cały mechanizm kierowania ruchem. runs-on dopasowuje każdą etykietę z listy, więc literówka nie daje błędu - zadanie po prostu czeka i kończy się niepowodzeniem po 24 godzinach w kolejce.
- Runner potrzebuje lttng-ust, OpenSSL, Kerberosa, zlib i libicu. Debian i Ubuntu je niosą; minimalny obraz kontenera często nie.
- x64 i ARM64 są wspierane na Linuksie, a ARM32 wyłącznie na Linuksie. Debian 10 i nowszy oraz Ubuntu 20.04 i nowsze to udokumentowane podstawy.
- Wszystko, co workflow po sobie zostawia, zostaje na dysku - to jest ta zaleta, i to jest zarazem powód, dla którego samodzielnie hostowany runner potrzebuje zaplanowanego sprzątania i migawki.
Minuty CI u dostawcy kontra własny runner
| Minuty CI hostowane przez dostawcę | Runner w DCXV | |
|---|---|---|
| Za co płacisz | Za każdą minutę każdego zadania, tak długo jak projekt istnieje | Za stały miesięczny host, cokolwiek potok robi w danym miesiącu |
| Kompilacja, która zwalnia | Kosztuje więcej w każdym miesiącu, w którym pozostaje wolna | Nie kosztuje nic więcej - maszyna jest już opłacona |
| Pamięć podręczna warstw Dockera | Zimna przy każdym zadaniu, o ile sam jej nie wyślesz i nie pobierzesz | Ciepła na lokalnym NVMe, między zadaniami i między dniami |
| Równoległość | Próg planu, który się podnosi | Liczba, którą ustawiasz we własnym pliku konfiguracyjnym |
| Gdzie ląduje checkout | Na współdzielonej flocie, często w regionie, którego nie da się wskazać | Na jednej maszynie w Pradze lub Covilhã, na umowie cypryjskiej |
| Adres wychodzący | Wielki współdzielony zakres, którego nic nie dopuści | Jeden statyczny IPv4 z AS204057, Twój do dopuszczenia |
| Co maszyna może pomieścić | To, co akurat niesie obraz runnera | Dowolny łańcuch narzędzi, licencję albo zestaw danych zainstalowany raz |
Jak to rusza na Twoim hoście
Powiedz, co robi potok
Najcięższe zadanie, jakie dziś uruchamiasz, ile ich ma iść naraz i czy buduje obrazy kontenerów. To wystarczy, żeby dobrać host bez zgadywania.
Przekazujemy maszynę
Praga albo Covilhã, dostęp root i statyczny IPv4, w niecałe dziesięć minut. Przynieś własny obraz, jeśli runner już w nim siedzi.
Wykonaj instrukcję z tej strony
To sekwencja producenta, wzięta z jego aktualnej dokumentacji, a nie z wpisu na blogu, i na czystym hoście zajmuje kilka minut.
Zrób migawkę, potem dołóż drugi
Zrób migawkę, gdy pierwszy potok świeci na zielono, żeby kolejna maszyna była odtworzeniem, a nie budową od zera. Pula rośnie przez dokładanie hostów, a nie przez rozdymanie jednego.
Dlaczego nas wybrać
- Obiekty certyfikowane Tier III, SLA obiektu 99,982 %
- Własna sieć, AS204057, IPv4 i IPv6
- Wsparcie 24/7/365 ze średnim czasem odpowiedzi około 10 minut
- Spółka cypryjska, jurysdykcja UE, zgodność z RODO od 2007 roku
FAQ
- Ile kosztują hostowane runnery GitHuba w porównaniu z hostowaniem u siebie?
GitHub rozlicza hostowane runnery Linux za minutę: 0,006 USD za 2 rdzenie, 0,012 za 4, 0,022 za 8 i 0,042 za 16, Windows 0,010 za 2 rdzenie, a macOS 0,062 za maszynę 3- lub 4-rdzeniową. Samodzielnie hostowane runnery nie zużywają minut Actions. Host u nas zaczyna się od 16,49 EUR miesięcznie, czyli mniej więcej tyle, ile kosztuje 2700 minut na hostowanym runnerze 2-rdzeniowym - punkt przecięcia wypada więc przy około 45 godzinach kompilacji miesięcznie
- Jak skonfigurować samodzielnie hostowany runner GitHub Actions?
Utwórz nieuprzywilejowanego użytkownika, pobierz archiwum runnera dla linux-x64 z wydań actions/runner i zweryfikuj sumę kontrolną, uruchom ./config.sh z adresem swojego repozytorium albo organizacji i tokenem rejestracyjnym z Settings, Actions, Runners, a potem zainstaluj go jako usługę poleceniem sudo ./svc.sh install i uruchom. Dokładne polecenia są na tej stronie. Token rejestracyjny wygasa godzinę po wydaniu
- Ile zadań runner może wykonywać naraz?
Jedno. Usługa runnera bierze pojedyncze zadanie naraz, więc równoległość oznacza zainstalowanie kilku usług runnera na hoście, każdej we własnym katalogu. Dlatego dobór rozmiaru na tej stronie liczy usługi runnera, a nie zadania, i dlatego maszyna z 8 vCPU z zapasem unosi małą kompilację macierzową
- Jakie systemy operacyjne i architektury są wspierane?
Na Linuksie Debian 10 i nowszy, Ubuntu 20.04 i nowsze, RHEL 8 i nowszy, CentOS 8 i nowszy, Fedora 29 i nowsza, openSUSE 15.2 i nowsze oraz ich krewni, na x64, ARM64 i ARM32. Runner potrzebuje ponadto lttng-ust, OpenSSL, Kerberosa, zlib i libicu, które Debian i Ubuntu niosą standardowo
- Czy samodzielnie hostowany runner jest bezpieczny w publicznym repozytorium?
GitHub to odradza, a powód jest konkretny: każdy może otworzyć pull request zmieniający plik workflow, a ten zmieniony workflow uruchomiłby się na Twojej maszynie. Trzymaj samodzielnie hostowane runnery przy prywatnych repozytoriach, chyba że dokładnie to przeczytałeś i wprowadziłeś realną izolację. Wszystko, co zadanie zostawia po sobie, dodatkowo trwa na dysku, co jest zaletą dla pamięci podręcznej i ryzykiem dla sekretów
- Czy jeden runner może obsługiwać kilka repozytoriów?
Tak. Zarejestruj go na poziomie organizacji zamiast repozytorium, a każde repozytorium w organizacji będzie mogło go wybrać, kierując pracę etykietami w runs-on. Zadanie proszące o etykietę, której żaden runner nie ma, po prostu czeka i kończy się niepowodzeniem po 24 godzinach w kolejce - tak właśnie wygląda literówka w runs-on
Jeśli potrzebujesz pomocy lub masz dodatkowe pytania, skontaktuj się z menedżerami lub napisz do zespołu wsparcia pod adresem support@dcxv.com
Gotowy na rozpoczęcie?
Rozliczenie miesięczne, bez opłaty aktywacyjnej, bez umowy na czas określony