Nyílt forráskódú DevOps nagyban: a GitLab saját üzemeltetésben

laptop screen showing code in a busy room

A forráskód az az egyetlen vagyontárgy, amelyet szinte minden technológiai cég kritikusnak tart, és egyben az, amelyet a legtöbben olyan infrastruktúrán tartanak, amely nem az övék, olyan joghatóság alatt, amelyet nem ők választottak, olyan szerződés alapján, amelyet nem olvastak el figyelmesen. Ez az elrendezés általában rendben van. Mégis érdemes tudni, mibe kerül az alternatíva, mert a GitLab több mint egy évtizede teszi valóban kivitelezhetővé, hogy a teljes fejlesztési életciklust magad üzemeltesd.

Ez ráadásul olyan termék, amelynek ingyenes szintje bőkezűbb, üzemeltetési terhe viszont nehezebb, mint a legtöbben várnák. Mindkettőt érdemes megérteni az elköteleződés előtt, úgyhogy ez az útmutató arról szól, mi is valójában a saját üzemeltetésű GitLab, mit ad ténylegesen az ingyenes szint, és melyik három üzemeltetési probléma okozza a fájdalom nagy részét.

Mi a GitLab

Nem egy Git-tárhely, amire extrákat csavaroztak. Egy Rails alkalmazás, PostgreSQL, Redis, Gitaly a tárolók tárolásához, Sidekiq a háttérfeladatokhoz és egy konténerregiszter, egyetlen rendszerré csomagolva, amely lefedi a verziókezelést, a kódellenőrzést, a hibakövetést, a CI/CD-t, a csomag- és konténerregisztereket, a biztonsági vizsgálatot és a telepítést.

Ez a szélesség az egész érv. A GitHub plusz Actions plusz Dependabot plusz egy csomagregiszter plusz egy projektkövető hasonló funkciókészletet ad, darabokból összerakva. A GitLab egyetlen alkalmazás egyetlen jogosultsági modellel és egyetlen adatbázissal. Ez vagy pontosan az, amit akarsz, vagy több, mint amennyire szükséged van, és hogy melyik, azon múlik, az életciklus mekkora részét szándékozol tényleg egy helyen futtatni.

Az építészetileg fontos tény ugyanaz, mint az analitika saját üzemeltetésénél Matomóval, a marketingautomatizálásnál Mautickal vagy a csapatchatnél Mattermosttal: ott fut, ahová teszed. A te tárolóid, a te CI-naplóid, a te műtermékeid, a te adatbázisod.

A licenchelyzet, kertelés nélkül

Ez valóban zavarba ejtő és pontosságot érdemel, mert a félreértés az elvárttal ellentétes irányba mutat.

Két forrásdisztribúció létezik. A Community Edition MIT licenc alatt áll. Az Enterprise Edition saját, korlátozóbb licenccel rendelkezik, amely a tároló ee/ könyvtárára vonatkozik. Idáig a szokásos nyílt mag modellnek hangzik.

Ami meglepi az embereket: a Linux csomag, amelyet szinte mindenki telepít, az Enterprise Edition build, és licenckulcs nélkül Free szintként fut, a Community Edition módjára viselkedve. Vagyis nem a MIT licencű disztribúciót futtatod, hacsak nem választottad tudatosan a CE csomagot. A gyakorlatban ez ritkán számít, de ha a saját üzemeltetés oka szigorú nyílt forráskódú irányelv, nem pedig az adatok feletti kontroll, akkor nagyon is számít, és szinte senki nem ellenőrzi.

A kereskedelmi szintek a Free, a Premium havi 29 dollár felhasználónként éves számlázással, és az Ultimate egyedi árazással. A Premium fejlett CI/CD-t, jobb projektkezelést és elsőbbségi támogatást ad hozzá. Az Ultimate a biztonsági és megfelelőségi csomagot: alkalmazásbiztonsági tesztelést, ellátási lánc biztonságot, függőségvizsgálatot. Mindkét fizetős szint tartalmaz már GitLab Creditet az MI-funkciókhoz, havi 12 dollárt felhasználónként Premiumon és 24-et Ultimate-en.

És itt van a tény, amely a legtöbb csapat számításait megváltoztatja, és a Mattermost-helyzet pontos fordítottja: a Free szintnek saját üzemeltetésben nincs felhasználószám-korlátja. Az ötfelhasználós plafon, amelyről az emberek hallottak, csak a GitLab.com privát csoportjaira vonatkozik. Saját üzemeltetésben a Free korlátlan felhasználót, verziókezelést, CI/CD-t és regisztereket ad, a tárhelyet és a futtatókat pedig te hozod. Egy száz mérnökös szervezet teljes egészében elfér rajta.

Amiről lemondasz: biztonsági vizsgálat, megfelelőségi jelentések, fejlett jóváhagyási szabályok és támogatás. Ha a kiberreziliencia-rendelet hatálya alá esel, és a függőségvizsgálatot meg az SBOM-előállítást a pipeline-jaidba építve akarod, nem pedig külön eszközökből összerakva, az egy Ultimate-beszélgetés. A legtöbb más csapatnak a Free nem próbaidőszak. Életképes végleges válasz.

A telepítés

Kis telepítés

A GitLab nehezebb, mint amilyennek látszik. A dokumentált alap egyetlen csomópontra 8 vCPU és 16 GB RAM, és a legtöbb gyártói minimummal ellentétben ez a szám őszinte, nem optimista. Be lehet préselni 8 GB-ba, de érezni fogod, és a swapet érdemes kikapcsolni, mert ezt az alkalmazást swapelni rosszabb, mint ha nem lenne meg a memória.

A PostgreSQL az egyetlen támogatott adatbázis. Hogy melyik verzió, az a GitLab verziójától függ: a 17.x PostgreSQL 14.14-től 16.x-ig kér, a 18.x 16.5-től 17.x-ig, a 19.x pedig 17.x-et. Redis 7.2 ajánlott, 7.0 a minimum, és a Valkey 7.2 helyettesítőként megfelel. Csak önálló példányok, mert a Redis fürtözött és serverless változatai nem támogatottak.

Telepíts a Linux csomaggal. Van Helm chart, Operator, Docker image és forrásból építés is, de a Linux csomag a legérettebb megoldás, és maga a GitLab.com is ezen fut. Hozza a PostgreSQL-t, a Redist és a Sidekiqet, tehát egy gép és egy konfigurációs fájl működő példányt ad.

# /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'
}

Egy gitlab-ctl reconfigure után van egy példányod. Az external_url-t elsőre állítsd be helyesen, mert az az érték beleég a klónozási URL-ekbe, a webhookokba és a regiszter címeibe.

Éles telepítés

A GitLab 1 000-től 50 000 felhasználóig publikál referenciaarchitektúrákat, és érdemes elolvasni őket akkor is, ha egyiket sem valósítod meg, mert megmutatják, melyik komponens válik először szűk keresztmetszetté.

A legtöbb pénzt megtakarító tanács magától a GitLabtól jön, és a bonyolultság ellen érvel: 3 000 felhasználó alatt szilárd mentési stratégiát ajánlanak a magas rendelkezésre állás helyett. A dokumentáció szokatlanul őszinte ebben, megjegyezve, hogy a mentésre épülő megközelítés visszaállítási ideje ugyan lassabb, de sokkal kisebb architektúrát és alacsonyabb karbantartási költséget jelent. 3 000 felhasználó fölött, vagy ahol egy kiesés tényleg megállítja a céget, a magas rendelkezésre állás lesz az ajánlás.

Vedd komolyan. Egyetlen jól mentett csomópont tesztelt visszaállítással a gyakorlatban megbízhatóbb, mint egy félig értett HA-fürt, és jóval olcsóbb is.

A műtermékeket, feltöltéseket, LFS-objektumokat és regiszterképeket az elejétől tedd objektumtárolóba. Ugyanaz az érvelés, mint máshol: a csomópont állapotmentes marad, a mentések kezelhetők, a költözés pedig lehetséges.

A három dolog, ami félremegy

A fentiek mind benne vannak a dokumentációban. Ezek viszont incidenseket okoznak.

A mentésed nem tartalmazza azt, ami visszafejti

Ez a cikk legfontosabb bekezdése.

A gitlab-backup create sok mindent rögzít: adatbázist, tárolókat, LFS-objektumokat, CI-műtermékeket és feladatnaplókat, regiszterképeket, wikiket, feltöltéseket, Pages-tartalmat, Terraform-állapotot, kódrészleteket. Amit nem rögzít, az a konfigurációs könyvtár, és név szerint az /etc/gitlab/gitlab-secrets.json.

Ez a fájl tartalmazza az adatbázis titkosítási kulcsát. A dokumentáció nyers a következményről: ha elveszíted, a GitLab alkalmazás semmilyen titkosított értéket nem tud majd visszafejteni az adatbázisban. Vagyis CI/CD-változókat, tokeneket, kétfaktoros titkokat és integrációs hitelesítő adatokat. Olyan mentésed lenne, amely egy saját titkait olvasni képtelen példányba áll vissza.

Szintén kimarad: az /etc/gitlab/gitlab.rb, a TLS-kulcsok és tanúsítványok, az SSH gazdakulcsok, és az objektumtároló tartalma, ha objektumtárolót állítottál be. Ez utóbbi épp azokat kapja el, akik architektúrában jól döntöttek, aztán feltételezték, hogy a mentés lefedi.

Mentsd tehát az /etc/gitlab-ot külön, tárold máshol, mint az archívumot, hiszen az archívum kulcsa, majd állítsd vissza az egészet egy eldobható gépre, és ellenőrizd, hogy be tudsz-e lépni és el tudsz-e olvasni egy CI-változót. A nem tesztelt mentés nem mentés, GitLab esetén pedig a nem tesztelt visszaállítás rendszerint hibás.

Nem lehet egy ugrással frissíteni

A GitLabnak kötelező frissítési megállói vannak, és ez nem javaslat. Nem hagyhatod ki őket. 17.5 óta a megállók kiszámíthatók, x.2, x.5, x.8 és x.11 verziókra esnek, tehát 18.0-ról 19.2-re jutni azt jelenti, hogy áthaladsz a 18.2, 18.5, 18.8, 18.11 és 19.0 verziókon.

Minden megálló háttérmigrációkkal jár, amelyeknek teljesen le kell futniuk, mielőtt továbblépsz. A következő frissítés elindítása még futó migrációk mellett az a mód, ahogy a példányok olyan állapotba kerülnek, amit csak a támogatás bogoz ki. Nagy példányon ezek a migrációk órákig tarthatnak.

Két gyakorlati következmény. Frissíts rendszeresen, mert egy év halasztott frissítés egy hétvégényi egymás utáni frissítés. És mindig a célként kitűzött minor verzió legutolsó javítókiadását vedd, ne az elsőt, amit a dokumentáció kifejezetten ki is mond. A GitLab fenntart egy eszközt, amely kiszámolja neked a frissítési útvonalat, és érdemesebb azt használni, mint magad kikövetkeztetni.

A valódi költség a futtatókban van

A GitLab szerver nem futtatja a CI-det. A GitLab Runner külön komponens, amelyet te telepítesz, konfigurálsz és fizetsz, az általad biztosított infrastruktúrán. A saját üzemeltetésű Free egyetlen számítási percet sem tartalmaz, mert nincs mellékelt számítási kapacitás: a saját gépeidet hozod.

Ez általában jó üzlet, mert egy dedikált futtató percenként olcsóbb, mint bármelyik hosztolt CI, amint a volumen komollyá válik, és minden buildnek adhatod azt a hardvert, amire szüksége van. De ez valódi infrastruktúramunka. Döntesz majd a végrehajtókról, hogy shell, Docker vagy Kubernetes; az automatikus skálázásról, hogy a futtatók ne járjanak üresen hajnali háromkor; és a gyorsítótárazásról, ami a négyperces és a tizennégy perces pipeline közti különbség.

A futtatóflottát külön költségsorként tervezd. Azok a csapatok, amelyek a saját üzemeltetés költségét csak a GitLab csomópontot nézve modellezik, jócskán alábecsülik, aztán a hiányt függőben lévő feladatok sorának formájában fedezik fel.

Kilépés a GitHubról

A GitHub importáló jó, jóval jobb a legtöbb gyártói migrációs eszköznél, és áthozza a tároló adatait, az ágakat, az LFS-objektumokat, a hibajegyeket és pull requesteket a hozzászólásokkal, véleményezésekkel és vitaválaszokkal, a wikioldalakat, a kiadásokat és mellékleteket, a címkéket, mérföldköveket, ágvédelmi szabályokat és a közreműködőket szerepleképezéssel.

A dokumentált hiányosságokat érdemes betervezni. A szervezetek és csoportok nem jönnek át, tehát a csoportstruktúrát te tervezed meg ahelyett, hogy örökölnéd, ami rendszerint javulás. A GitHub Actions munkafolyamatok nem konvertálódnak GitLab CI-re. A 2017 előtti pull request hozzászólások külön szálakként érkeznek a GitHub API korlátai miatt, és a nagyjából 30 000 hozzászólásnál nagyobb tárolókhoz be kell kapcsolni az alternatív hozzászólás-importálási módot.

Mivel a GitHub a # jelet hibajegyekre és pull requestekre is használja, a GitLab viszont megkülönbözteti őket, néhány kereszthivatkozás nem fog feloldódni. Semmi nem vész el, de a régi vitákban lévő linkek rossz helyre mutathatnak.

A CI újraírását tervezd magaként a projektként, mert az. Minden más egy importfeladat, amit lefuttatsz és ellenőrzöl.

Az európai szempont

Az Európában működő cégeknél a költség mellé megfelelőségi dimenzió társul. A forráskód, a build pipeline-ok és a műtermékek a legérzékenyebb dolgok közé tartoznak, amivel egy technológiai cég rendelkezik, és hogy hol élnek, egyre inkább olyan kérdés, amit feltesznek neked, nem pedig olyan, amire önként válaszolsz.

A saját üzemeltetés egy általad ellenőrzött határon belülre helyezi őket, ami egy mozdulattal egyszerűsíti a GDPR szerinti adattovábbítási elemzést és a NIS2 ellátási lánccal kapcsolatos kérdéseit, és ez ugyanaz a szuverenitási érv, amely köré a Cloud and AI Development Act épül.

Az élesebb kapcsolat a kiberreziliencia-rendelet. Ha szoftvert hozol az uniós piacra, függőségi leltárakra, sérülékenységkezelésre és koordinált közzétételi folyamatra lesz szükséged. Ezek a kötelezettségek a build pipeline-ban teljesülnek, nem egy dokumentumban, és ha a pipeline, a regiszter és a vizsgálat egyetlen általad üzemeltetett rendszerben van, a bizonyítékok előállítása jóval kevésbé fájdalmas, mint négy szállítótól összeszedni.

Mikor ne bajlódj vele

Ha húsz mérnök alatt vagytok, nincs szabályozói nyomás, és senkinek nincs erős véleménye arról, hol éljen a kód, vegyétek a SaaS-t. A GitLab.com és a GitHub is kiváló, és az üzemeltetési munka többe kerül majd, mint az előfizetés.

Ha a szervezeted mélyen benne ül a GitHub ökoszisztémájában, számold össze őszintén, mit veszítenél. Az Actions, a marketplace és a platform puszta ismertsége minden jelöltnél, akit felveszel, valódi érték, és a válasz nem automatikusan az, hogy a GitLab nyer.

És ha senki nem veszi a nyakába a példányt, ne is kezdj bele. A GitLab azt jutalmazza, aki foltozza, figyeli a futtatóflottát és teszteli a visszaállítást. Az az ember nélkül egy foltozatlan dobozzá züllik, amelyben a legértékesebb vagyontárgyad van, és ez rosszabb, mint az a SaaS, amit el akartál hagyni.

Hogyan segíthetünk

Saját üzemeltetésű fejlesztői infrastruktúrát telepítünk és futtatunk Európában működő cégeknek, beleértve azokat a részeket, amelyeket senki nem szeret: frissítési sorozatokat a kötelező megállókon át, rendesen automatikusan skálázódó futtatóflottákat, objektumtárolóra való migrációkat és mentési sémákat, amelyeket ténylegesen vissza is állítottak.

Ha őszintén méretezett GitLab példányt szeretnél, olyan GitHub migrációt, amelyet valaki tervez, aki a CI újraírását már megcsinálta, vagy egy átvilágítást arról, hogy a jelenlegi mentésed túlélne-e egy valódi hibát, írj a office@c9group.dev címre. Az infrastruktúrás munkánkról bővebben az AWS költségoptimalizálás oldalon.

Ha teljes saját üzemeltetésű stacket állítasz össze, ugyanez a gondolatmenet érvényes az analitikára, a marketingautomatizálásra és a csapatkommunikációra is.

Közzétéve: 2026. augusztus 8. Kategóriák: DevOps, Nyílt forráskód, Adatvédelem