Hosting GitLab Runner na maszynie, która należy do Ciebie
Samodzielnie zarządzany runner w Pradze lub Covilhã z całym dyskiem tylko dla siebie, dzięki czemu pamięć podręczna warstw Dockera jest wciąż na miejscu przy drugim potoku danego dnia, a rachunek nie rośnie, kiedy rośnie kompilacja.
Dla kogo to jest
Zespół, który kupuje minuty obliczeniowe
Zestaw testów urósł, więc potok się wydłużył, więc rachunek poszedł w górę - a jedyna dźwignia, jaką oferuje plan, to kupno jeszcze większej liczby dokładnie tych samych minut.
Potok, który chce tej samej maszyny dwa razy
Każde zadanie startuje z pustym dyskiem. Obraz bazowy jest pobierany od nowa, zależności ściągane od nowa, a wysyłanie pamięci podręcznej trwa dłużej niż krok, który miała oszczędzić.
Repozytorium objęte wymogiem lokalizacji danych
Kod, artefakty i klucze wdrożeniowe przechodzą przez runner, a "współdzielona flota, gdzieś tam" to odpowiedź, którą audytor wciąż zakreśla na czerwono.
Co oddaje Ci samodzielnie zarządzany runner
- Ciepła pamięć podręczna warstw Dockera na lokalnym NVMe, dzięki czemu drugi potok dnia zaczyna tam, gdzie skończył pierwszy, a nie od pustego dysku.
- Dowolny executor - docker, shell, docker-autoscaler, instance albo kubernetes - wybierany per runner, a nie przydzielany przez plan.
- Własna równoległość, ustawiona jako liczba w config.toml zamiast kupiona jako wyższy próg.
- Tryb uprzywilejowany, kiedy naprawdę potrzebujesz Docker-in-Docker, czego żadna współdzielona flota Ci nie da.
- Statyczny wychodzący IPv4 z AS204057, dzięki czemu cel wdrożenia, lustro pakietów albo zapora bazy danych może dopuścić runner po adresie.
- To, czego kompilacja naprawdę potrzebuje na hoście: stary łańcuch narzędzi, licencjonowany SDK albo zestaw danych testowych, którego nikt nie chce pobierać raz na zadanie.
Dobrane do tego, co potok naprawdę robi
GitLab nie publikuje wymagań sprzętowych dla samego runnera i nie jest to przeoczenie: proces runnera jest mały, a kompilacja nie. Liczbą, która ma znaczenie, jest zadanie. Wyjdź od najcięższego zadania, jakie dziś uruchamiasz, pomnóż przez pożądaną równoległość i nie żałuj dysku - to pamięć podręczna warstw i katalog roboczy go zapełniają, a pełny dysk psuje potok w sposób wyglądający jak zepsuty test. Jednej rzeczy stały miesięczny host nie zrobi: nie zniknie w spokojnym tygodniu. Minuty u dostawcy nic nie kosztują, gdy nikt nie wypycha zmian, a to kosztuje tyle samo. Opłaca się od momentu, w którym potok działa niemal codziennie.
Jak zainstalować GitLab Runner na świeżym hoście
Debian albo Ubuntu, na czystym serwerze, w kolejności, którą dokumentuje GitLab. Wszystko poniżej to ich sekwencja, nie nasza.
-
Dodaj oficjalne repozytorium pakietów
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh less script.deb.sh sudo bash script.deb.shGitLab dostarcza repozytorium jako skrypt instalacyjny i prosi, żeby go przeczytać przed uruchomieniem - dlatego ich własna instrukcja najpierw go pobiera, zamiast przepuszczać go prosto do powłoki.
-
Zainstaluj runner
sudo apt install gitlab-runnerPakiet tworzy użytkownika systemowego gitlab-runner, którego katalog domowy powstaje pusty, bez plików szkieletowych. Aby przypiąć wersję, zainstaluj gitlab-runner i gitlab-runner-helper-images razem w tej samej wersji - od 17.7.1 chodzą w parze, a podanie tylko jednego kończy się błędem zależności.
-
Zainstaluj Dockera, jeśli zadania działają w kontenerach
sudo apt install docker.io sudo systemctl enable --now dockerExecutor docker rozmawia z lokalnym Docker Engine przez API v1.25, więc demon musi być na samym hoście runnera. Pakiet z dystrybucji wystarczy na start; własne repozytorium Dockera niesie nowsze wydania, jeśli któraś kompilacja ich potrzebuje.
-
Zarejestruj runner
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ --token "$RUNNER_TOKEN" \ --executor "docker" \ --docker-image alpine:latest \ --docker-pull-policy "if-not-present" \ --description "docker-runner"Najpierw utwórz runner w GitLabie, w Settings, potem CI/CD, potem Runners - odda token uwierzytelniający zaczynający się od glrt-, który trafia do --token. Etykiety zadań i opcję zadań bez etykiet ustaw w tym samym formularzu: przy tokenach uwierzytelniających należą one do runnera, a nie do polecenia register. Starsza ścieżka z --registration-token jest przestarzała i przewidziana do usunięcia w GitLabie 20.0.
-
Ustaw równoległość i uruchom
sudo sed -i "s/^concurrent = .*/concurrent = 4/" /etc/gitlab-runner/config.toml sudo gitlab-runner restart sudo gitlab-runner statusconfig.toml leży w /etc/gitlab-runner, kiedy runner działa jako root. concurrent to pułap obejmujący wszystkie runnery zarejestrowane na tym hoście, a nie ustawienie per runner, i każdy runner może mieć pod spodem własny, niższy limit.
-
Sprawdź to jednym zadaniem
stages: [test] smoke: stage: test tags: [docker-runner] script: - cat /etc/os-release - echo "built on $CI_RUNNER_DESCRIPTION"Zatwierdź to jako .gitlab-ci.yml, wypchnij zmiany, a zadanie powinno wylądować na Twoim hoście w kilka sekund. Jeśli zostaje w kolejce, etykiety nie zgadzają się z tymi ustawionymi w interfejsie albo runner jest przypięty do innego projektu.
Sprawdzone z oficjalną dokumentacją dnia 2026-08-15 — przeczytaj źródło
Czym nie jesteśmy
- Nie jesteśmy GitLabem. GitLab, GitLab CI/CD i GitLab Runner należą do nich i nic na tej stronie nie jest przez nich firmowane. Sprzedajemy maszynę, na której runner działa.
- Ta strona nie dotyczy hostowania samego GitLaba. Samodzielnie zarządzana instancja GitLaba to większa maszyna i inna rozmowa - zapytaj, a ją dobierzemy, ale nie ona jest tutaj wyceniona.
- Nie piszemy Twojego .gitlab-ci.yml. Potok jest Twój; host, sieć i adres są nasze.
- Runner nie jest zarządzany za Ciebie, 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ą.
- Twoja subskrypcja GitLaba pozostaje u GitLaba. Samodzielnie zarządzany runner nie zużywa ich minut obliczeniowych, o to właśnie chodzi, ale nie zastępuje też licencji użytkowników.
Elementy, które zespoły odkrywają za późno
- Ścieżka z tokenem rejestracyjnym odchodzi. Runner utworzony w interfejsie oddaje token uwierzytelniający glrt-, który gitlab-runner register przyjmuje jako --token, a --registration-token jest przewidziany do usunięcia w GitLabie 20.0.
- Etykiety poszły razem z nim. Przy tokenie uwierzytelniającym etykiety zadań, opcja bez etykiet i przypięcie należą do obiektu runnera utworzonego w interfejsie, więc flagi, które kiedyś ustawiały je w wierszu poleceń, o niczym już nie decydują.
- Przypięcie wersji oznacza przypięcie dwóch pakietów. Od 17.7.1 jawna wersja gitlab-runner wymaga także gitlab-runner-helper-images w tej samej wersji, inaczej apt odmawia instalacji.
- check_interval domyślnie wynosi 3 sekundy. Na hoście z wieloma zarejestrowanymi runnerami to mnóstwo odpytywania; podnieś tę wartość, zanim zaczniesz obwiniać sieć.
- Docker-in-Docker wymaga trybu uprzywilejowanego, co faktycznie daje zadaniu roota na hoście. Jeśli potok tylko buduje obrazy, bezrootowy builder w rodzaju Kaniko albo Buildah jest tańszym wyborem.
- Artefakty i pamięci podręczne wciąż wędrują do GitLaba, dopóki nie skierujesz pamięci podręcznej do własnego kubełka zgodnego z S3. Na runnerze, który świadomie przeniosłeś do UE, to zwykle ostatni skok, jaki został do przeniesienia.
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
- Czym różni się runner współdzielony od samodzielnie zarządzanego?
Runner współdzielony to maszyna GitLaba i płacisz za minuty, które spędza nad Twoim zadaniem. Runner samodzielnie zarządzany to Twoja maszyna: instalujesz na niej gitlab-runner, rejestrujesz ją przy swoim projekcie, grupie albo instancji, i nie zużywa ona żadnych minut obliczeniowych. Przestrzenie nazw na darmowym planie GitLaba dostają 400 minut obliczeniowych miesięcznie, a ruchliwy potok przerabia je w kilka dni
- Jak zainstalować i zarejestrować GitLab Runner?
Dodaj ich repozytorium apt ze skryptu instalacyjnego na packages.gitlab.com, zainstaluj pakiet gitlab-runner, a potem uruchom gitlab-runner register w trybie nieinteraktywnym z tokenem uwierzytelniającym, który GitLab wydaje przy tworzeniu runnera w interfejsie. Pełna sekwencja z dokładnymi poleceniami jest na tej stronie, wzięta z ich dokumentacji, a nie z wpisu na blogu
- Czy runner nadal rejestruje się tokenem rejestracyjnym?
Nie, i to właśnie ta zmiana psuje większość starszych poradników. Najpierw utwórz runner w interfejsie GitLaba, a odda token uwierzytelniający zaczynający się od glrt-, który gitlab-runner register przyjmuje jako --token. Stara ścieżka z --registration-token jest przestarzała i przewidziana do usunięcia w GitLabie 20.0. Etykiety zadań, opcja bez etykiet i przypięcie należą teraz do obiektu runnera utworzonego w interfejsie, a nie do polecenia register
- Jakiego rozmiaru serwera potrzebuje GitLab Runner?
GitLab nie publikuje wymagań sprzętowych dla samego runnera, bo proces runnera jest mały, a Twoja kompilacja nie. Dobieraj według najcięższego zadania pomnożonego przez pożądaną równoległość. W praktyce 4 vCPU, 8 GB i 120 GB NVMe unosi dwa albo trzy zadania naraz; 8 vCPU, 16 GB i 240 GB unosi od sześciu do ośmiu. Nie żałuj dysku - zapełniają go pamięć podręczna warstw Dockera i katalog roboczy
- Czy potrzebuję Dockera na hoście runnera?
Tylko jeśli używasz executora docker, co robi większość. Rozmawia on z lokalnym Docker Engine przez API v1.25, więc demon musi być zainstalowany na samym hoście runnera. Executor shell nie potrzebuje Dockera wcale, a executory instance i docker-autoscaler tworzą maszyny gdzie indziej
- Czy kilka runnerów może dzielić jeden host?
Tak, i to jest normalny układ. Zarejestruj ich tyle, ile chcesz, przy tej samej instalacji; ustawienie concurrent w /etc/gitlab-runner/config.toml jest pułapem dla nich wszystkich, a każdy runner może mieć pod spodem własny, niższy limit. Uważaj na check_interval, domyślnie 3 sekundy, które zamienia się w mnóstwo odpytywania, gdy host niesie tuzin runnerów
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