DevOps open source na dużą skalę: GitLab we własnej infrastrukturze

laptop screen showing code in a busy room

Kod źródłowy to jedyne dobro, co do którego niemal każda firma technologiczna zgadza się, że jest krytyczne, a zarazem to, które większość trzyma na infrastrukturze, której nie posiada, w jurysdykcji, której nie wybrała, na podstawie umowy, której nie przeczytała uważnie. Zwykle taki układ jest w porządku. Warto jednak wiedzieć, ile kosztuje alternatywa, bo GitLab od ponad dekady sprawia, że hostowanie całego cyklu wytwarzania u siebie jest naprawdę wykonalne.

To także produkt, którego darmowy poziom jest hojniejszy, a obciążenie eksploatacyjne cięższe, niż większość ludzi się spodziewa. Jedno i drugie warto zrozumieć przed decyzją, więc ten przewodnik mówi, czym GitLab we własnym hostingu naprawdę jest, co faktycznie daje darmowy poziom i jakie trzy problemy eksploatacyjne odpowiadają za większość bólu.

Czym jest GitLab

Nie hostingiem Gita z doczepionymi dodatkami. Aplikacją w Railsach, PostgreSQL, Redisem, Gitaly do przechowywania repozytoriów, Sidekiqiem do zadań w tle i rejestrem kontenerów, spakowanymi razem jako jeden system obejmujący kontrolę wersji, przegląd kodu, śledzenie zgłoszeń, CI/CD, rejestry pakietów i kontenerów, skanowanie bezpieczeństwa oraz wdrożenia.

Ta rozpiętość jest całym argumentem. GitHub plus Actions plus Dependabot plus rejestr pakietów plus narzędzie do śledzenia projektu dają porównywalny zestaw funkcji, złożony z części. GitLab to jedna aplikacja z jednym modelem uprawnień i jedną bazą danych. To albo dokładnie to, czego chcesz, albo więcej, niż potrzebujesz, a które z tych dwóch, zależy od tego, jak dużą część cyklu rzeczywiście zamierzasz prowadzić w jednym miejscu.

Kluczowy fakt architektoniczny jest ten sam co przy samodzielnym hostowaniu analityki z Matomo, automatyzacji marketingu z Mautic czy komunikatorze zespołowym z Mattermost: działa tam, gdzie je postawisz. Twoje repozytoria, twoje logi CI, twoje artefakty, twoja baza.

Sytuacja licencyjna, powiedziana wprost

To naprawdę myli i zasługuje na precyzję, bo zamieszanie idzie w stronę odwrotną do oczekiwań.

Istnieją dwie dystrybucje źródeł. Community Edition jest na licencji MIT. Enterprise Edition ma własną, bardziej restrykcyjną licencję obejmującą katalog ee/ repozytorium. Na razie brzmi to jak zwykły model open core.

Zaskakuje co innego: pakiet linuksowy, który instaluje niemal każdy, to build Enterprise Edition, a bez wgranego klucza licencyjnego działa jako poziom Free i zachowuje się jak Community Edition. Nie uruchamiasz więc dystrybucji na licencji MIT, chyba że świadomie wybrałeś pakiet CE. W praktyce rzadko to ma znaczenie, ale jeśli powodem samodzielnego hostowania jest ścisła polityka open source, a nie kontrola nad danymi, to ma znaczenie ogromne, a prawie nikt tego nie sprawdza.

Poziomy komercyjne to Free, Premium za 29 dolarów za użytkownika miesięcznie przy rozliczeniu rocznym oraz Ultimate z wyceną indywidualną. Premium dokłada zaawansowane CI/CD, lepsze zarządzanie projektem i wsparcie priorytetowe. Ultimate dokłada pakiet bezpieczeństwa i zgodności: testy bezpieczeństwa aplikacji, bezpieczeństwo łańcucha dostaw, skanowanie zależności. Oba płatne poziomy zawierają już GitLab Credits na funkcje AI, 12 dolarów na użytkownika miesięcznie w Premium i 24 w Ultimate.

A oto fakt, który zmienia rachunek większości zespołów i jest dokładnym odwróceniem sytuacji z Mattermostem: poziom Free we własnym hostingu nie ma limitu użytkowników. Limit pięciu użytkowników, o którym ludzie słyszeli, dotyczy wyłącznie prywatnych grup na GitLab.com. Samodzielnie hostowany Free daje nieograniczoną liczbę użytkowników, kontrolę wersji, CI/CD i rejestry, a magazyn i runnery przynosisz sam. Organizacja stu inżynierów może działać na nim w całości.

Rezygnujesz ze skanowania bezpieczeństwa, raportowania zgodności, zaawansowanych reguł zatwierdzania i wsparcia. Jeśli podlegasz aktowi o cyberodporności i chcesz skanowanie zależności oraz generowanie SBOM wbudowane w pipeline'y zamiast składane z osobnych narzędzi, to rozmowa o Ultimate. Dla większości pozostałych zespołów Free nie jest okresem próbnym. To trwała, sensowna odpowiedź.

Instalacja

Małe wdrożenie

GitLab waży więcej, niż wygląda. Udokumentowana podstawa dla pojedynczego węzła to 8 vCPU i 16 GB RAM, i w odróżnieniu od większości minimów producentów ta liczba jest uczciwa, a nie optymistyczna. Da się to wcisnąć w 8 GB, ale to czuć, a swap lepiej wyłączyć, bo swapowanie tej aplikacji jest gorsze niż brak pamięci.

PostgreSQL to jedyna wspierana baza. Która wersja, zależy od wersji GitLaba: 17.x chce PostgreSQL od 14.14 do 16.x, 18.x chce od 16.5 do 17.x, a 19.x chce 17.x. Zalecany jest Redis 7.2, minimum to 7.0, a Valkey 7.2 sprawdza się jako zamiennik. Tylko instancje samodzielne, bo warianty klastrowe i serverless Redisa nie są wspierane.

Instaluj pakietem linuksowym. Są charty Helma, Operator, obrazy Dockera i droga ze źródeł, ale pakiet linuksowy jest opcją najdojrzalszą i to na nim działa sam GitLab.com. Zawiera PostgreSQL, Redisa i Sidekiqa, więc jedna maszyna i jeden plik konfiguracyjny dają działającą instancję.

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

Jedno gitlab-ctl reconfigure później masz instancję. Ustaw external_url dobrze za pierwszym razem, bo ta wartość zapiecze się w adresach klonowania, webhookach i adresach rejestru.

Wdrożenie produkcyjne

GitLab publikuje architektury referencyjne od 1000 do 50 000 użytkowników i warto je przeczytać, nawet jeśli żadnej nie wdrożysz, bo pokazują, który komponent staje się wąskim gardłem jako pierwszy.

Rada, która oszczędza najwięcej pieniędzy, pochodzi od samego GitLaba i przemawia przeciw złożoności: poniżej 3000 użytkowników zalecają solidną strategię kopii zapasowych zamiast wysokiej dostępności. Dokumentacja jest w tym nietypowo szczera, zauważając, że podejście oparte na kopiach ma wolniejszy czas odtworzenia, ale oznacza znacznie mniejszą architekturę i niższe koszty utrzymania. Powyżej 3000 użytkowników albo tam, gdzie awaria naprawdę zatrzymuje firmę, wysoka dostępność staje się zaleceniem.

Potraktuj to poważnie. Pojedynczy dobrze zabezpieczony węzeł z przetestowanym odtworzeniem jest w praktyce pewniejszy niż w połowie zrozumiany klaster HA i znacznie tańszy.

Artefakty, przesyłane pliki, obiekty LFS i obrazy rejestru przenieś do magazynu obiektowego od początku. To samo rozumowanie co wszędzie: trzyma węzeł bezstanowym, kopie w rozsądnym rozmiarze, a migrację w zasięgu.

Trzy rzeczy, które idą nie tak

Wszystko powyżej jest w dokumentacji. To poniżej rodzi incydenty.

Twoja kopia zapasowa nie zawiera tego, co ją odszyfrowuje

To najważniejszy akapit w tym tekście.

gitlab-backup create obejmuje sporo: bazę danych, repozytoria, obiekty LFS, artefakty CI i logi zadań, obrazy rejestru, wiki, przesłane pliki, zawartość Pages, stan Terraforma, snippety. Czego nie obejmuje, to katalog konfiguracyjny, a konkretnie /etc/gitlab/gitlab-secrets.json.

Ten plik zawiera klucz szyfrowania bazy danych. Dokumentacja mówi o konsekwencji bez ogródek: jeśli go stracisz, aplikacja GitLab nie będzie w stanie odszyfrować żadnych zaszyfrowanych wartości w bazie. Czyli zmiennych CI/CD, tokenów, sekretów dwuskładnikowych i poświadczeń integracji. Miałbyś kopię, która odtwarza się do instancji niezdolnej odczytać własnych sekretów.

Wyłączone są też /etc/gitlab/gitlab.rb, klucze i certyfikaty TLS, klucze hosta SSH oraz zawartość magazynu obiektowego, gdy jest skonfigurowany. To ostatnie dopada właśnie tych, którzy zrobili architektonicznie słuszną rzecz, a potem założyli, że kopia to obejmuje.

Rób więc kopię /etc/gitlab osobno, trzymaj ją gdzie indziej niż samo archiwum, bo jest do niego kluczem, a potem odtwórz całość na maszynę jednorazową i sprawdź, czy możesz się zalogować i odczytać zmienną CI. Nieprzetestowana kopia nie jest kopią, a w przypadku GitLaba nieprzetestowane odtworzenie zwykle jest zepsute.

Nie zaktualizujesz jednym skokiem

GitLab ma obowiązkowe przystanki przy aktualizacji i to nie jest sugestia. Nie da się ich pominąć. Od 17.5 przystanki są przewidywalne i wypadają na x.2, x.5, x.8 i x.11, więc przejście z 18.0 do 19.2 oznacza drogę przez 18.2, 18.5, 18.8, 18.11 i 19.0.

Każdy przystanek wiąże się z migracjami w tle, które muszą się w pełni zakończyć, zanim ruszysz dalej. Uruchomienie kolejnej aktualizacji, gdy migracje jeszcze trwają, to sposób, w jaki instancje trafiają w stany rozplątywane tylko przez wsparcie. Na dużej instancji te migracje potrafią trwać godzinami.

Dwa praktyczne wnioski. Aktualizuj regularnie, bo rok odkładanych aktualizacji to weekend aktualizacji po kolei. I zawsze bierz najnowsze wydanie łatki docelowej wersji pomocniczej zamiast pierwszego, co dokumentacja mówi wprost. GitLab utrzymuje narzędzie wyliczające ścieżkę aktualizacji za ciebie i lepiej z niego skorzystać, niż rozumować samodzielnie.

Prawdziwy koszt siedzi w runnerach

Serwer GitLaba nie wykonuje twojego CI. GitLab Runner to osobny komponent, który instalujesz, konfigurujesz i opłacasz, na infrastrukturze, którą dostarczasz. Free we własnym hostingu nie zawiera żadnych minut obliczeniowych, bo nie ma dołączonej mocy do dania: przynosisz własne maszyny.

Zwykle to dobry interes, bo dedykowany runner kosztuje mniej za minutę niż hostowane CI przy poważnym wolumenie, a każdemu buildowi możesz dać sprzęt, jakiego potrzebuje. Ale to prawdziwa praca infrastrukturalna. Podejmiesz decyzje o executorach, czy shell, Docker, czy Kubernetes; o autoskalowaniu, żeby runnery nie mieliły na jałowym biegu o trzeciej w nocy; i o cache'owaniu, które jest różnicą między pipeline'em czterominutowym a czternastominutowym.

Wpisz flotę runnerów jako osobną pozycję budżetową. Zespoły modelujące koszt własnego hostingu wyłącznie po węźle GitLaba mocno się nie doszacowują, a potem odkrywają lukę jako kolejkę oczekujących zadań.

Wyjście z GitHuba

Importer GitHuba jest dobry, znacznie lepszy niż większość narzędzi migracyjnych dostawców, i przenosi dane repozytorium, gałęzie, obiekty LFS, zgłoszenia i pull requesty wraz z komentarzami, przeglądami i odpowiedziami w dyskusjach, strony wiki, wydania i załączniki, etykiety, kamienie milowe, reguły ochrony gałęzi oraz współpracowników z mapowaniem ról.

Udokumentowane luki warto zaplanować. Organizacje i grupy nie przechodzą, więc strukturę grup projektujesz sam, zamiast ją dziedziczyć, co zwykle jest ulepszeniem. Przepływy GitHub Actions nie konwertują się na GitLab CI. Komentarze do pull requestów sprzed 2017 trafiają jako osobne wątki z powodu ograniczeń API GitHuba, a repozytoria z ponad mniej więcej 30 000 komentarzy wymagają włączenia alternatywnej metody importu komentarzy.

Ponieważ GitHub używa # zarówno dla zgłoszeń, jak i pull requestów, a GitLab je rozróżnia, część odwołań krzyżowych się nie rozwiąże. Nic nie ginie, ale linki w starych dyskusjach mogą wskazywać nie to, co trzeba.

Zaplanuj przepisanie CI jako właściwy projekt, bo nim jest. Cała reszta to zadanie importu, które uruchamiasz i sprawdzasz.

Perspektywa europejska

Dla firm działających w Europie do kosztu dochodzi wymiar zgodności. Kod źródłowy, pipeline'y budowania i artefakty należą do najbardziej wrażliwych rzeczy, jakie ma firma technologiczna, a to, gdzie żyją, coraz częściej jest pytaniem, które ci zadają, a nie takim, na które sam chcesz odpowiedzieć.

Własny hosting umieszcza je w granicy, którą kontrolujesz, co za jednym zamachem upraszcza analizę transferów wedle RODO i pytania o łańcuch dostaw z NIS2, i jest to ten sam argument o suwerenności, wokół którego zbudowano Cloud and AI Development Act.

Ostrzejszy związek to akt o cyberodporności. Kto wprowadza oprogramowanie na rynek UE, będzie potrzebował inwentarzy zależności, obsługi podatności i skoordynowanego procesu ujawniania. Te obowiązki spełnia się w pipelinie budowania, a nie w dokumencie, a posiadanie pipeline'u, rejestru i skanowania w jednym systemie, który sam prowadzisz, czyni wytworzenie dowodów znacznie mniej bolesnym niż zbieranie ich od czterech dostawców.

Kiedy sobie odpuścić

Jeśli jest was mniej niż dwudziestu inżynierów, nie ma presji regulacyjnej ani mocnych przekonań co do tego, gdzie mieszka kod, weźcie SaaS. GitLab.com i GitHub są oba znakomite, a praca eksploatacyjna będzie kosztować więcej niż abonament.

Jeśli twoja organizacja siedzi głęboko w ekosystemie GitHuba, policz uczciwie, co byś stracił. Actions, marketplace i zwykła znajomość platformy u każdego kandydata, którego zatrudniasz, to realne aktywa, a odpowiedź nie brzmi automatycznie, że wygrywa GitLab.

A jeśli nikt nie przejmie instancji, nie zaczynaj. GitLab nagradza kogoś, kto go łata, pilnuje floty runnerów i testuje odtworzenie. Bez tej osoby degeneruje się do niezałatanej skrzynki trzymającej twoje najcenniejsze dobro, a to gorsze niż SaaS, z którego chciałeś odejść.

Jak możemy pomóc

Wdrażamy i utrzymujemy samodzielnie hostowaną infrastrukturę wytwórczą dla firm działających w Europie, łącznie z częściami, których nikt nie lubi: sekwencjami aktualizacji przez obowiązkowe przystanki, flotami runnerów, które porządnie się autoskalują, migracjami do magazynu obiektowego i schematami kopii, które faktycznie zostały odtworzone.

Jeśli chcesz instancję GitLaba dobraną uczciwie, migrację z GitHuba zaplanowaną przez kogoś, kto przepisywanie CI ma już za sobą, albo przegląd tego, czy twoja obecna kopia przetrwałaby zderzenie z prawdziwą awarią, napisz na office@c9group.dev. Więcej o naszej pracy infrastrukturalnej na stronie o optymalizacji kosztów AWS.

Jeśli składasz pełny stos we własnym hostingu, to samo rozumowanie dotyczy analityki, automatyzacji marketingu i komunikacji zespołowej.

Opublikowano: 8 sierpnia 2026 Kategorie: DevOps, Open Source, Prywatność