A GitLab OpenStack integrációja egyre elterjedtebb azok körében, akiknek elsődleges szempont az adatfüggetlenség és a privát felhőben való működés. Sokan választják az OpenStack-et szuverenitási okokból, de gyakran előfordul, hogy a CI/CD folyamatokat továbbra is külső szolgáltatók, például a GitLab.com kezeli, ami új kihívásokat vet fel a valódi adatkontroll szempontjából.
Ebben a cikkben részletesen bemutatom, hogyan lehet a GitLab teljesen saját OpenStack környezetben futtatni, hogy ne csak a futtatási, hanem az irányítási sík (control plane) is a te kezedben legyen. Szó lesz a platform engineering gyakorlati lépéseiről, a CI/CD biztonságáról, valamint a privát felhőben való működés szuverenitásának valódi jelentőségéről.
Miért nem elég önmagában a szuverén CI/CD Runner?
Gyakori tévhit, hogy ha a GitLab Runner már saját OpenStack tenantban fut, akkor a rendszer teljesen szuverén. Valójában a helyzet ennél árnyaltabb. A szuverenitás két külön síkon értelmezhető:
- Végrehajtási sík (Execution plane): Itt fut a build, a teszt, a deploy, tehát a kód tényleges feldolgozása. Ha saját Runnered van, ezek a folyamatok már a te OpenStack környezeteden belül zajlanak.
- Irányítási sík (Control plane): Itt tárolódnak a repók, CI/CD változók (jelszavak, tokenek), artifactok, infrastruktúra leírások, naplók. Ha ezek GitLab.com-on vagy más külső SaaS-on maradnak, nem rendelkezel felettük teljes kontrollal.
A fenti kettő közül az irányítási sík az, ahol az igazán érzékeny adatok (például cloud hozzáférési kulcsok, Terraform state fájlok) laknak. Egy külső szolgáltató kiesése, jogi változása vagy biztonsági incidense az egész rendszeredet veszélyeztetheti, hiába futnak a Runnerjeid privát felhőben. Ezért ha valódi adatfüggetlenséget szeretnél, a GitLab teljes működését – a webes felületet, repókat, pipeline-okat – is OpenStack-on kell tartanod.
OpenStack környezet előkészítése GitLab-hoz
Az első lépés egy stabil, jól menedzselt OpenStack infrastruktúra kiépítése, amely képes ellátni egy GitLab szerver igényeit. Gyakorlati példán keresztül egy Ubuntu 22.04-es virtuális gépet hoztam létre a következő minimum erőforrásokkal:
| Erőforrás | Ajánlott minimum | Megjegyzés |
|---|---|---|
| CPU | 4 vCPU | Pipeline és webes terheléshez |
| RAM | 8 GB | Stabil működéshez elengedhetetlen |
| Tárhely | 100 GB SSD | Repositoryk, artefaktok, logok |
| Hálózat | Floating IP | Publikus eléréshez |
Fontos, hogy a VM rendelkezzen Floating IP-vel, így biztosítható a kifelé és befelé irányuló hálózati forgalom. Az Ubuntu telepítés után ellenőriztem a hálózatot (ping, apt update), majd előkészítettem a csomagkezelőt a GitLab telepítéséhez.
GitLab telepítése és beállítása OpenStack környezetben
A GitLab OpenStack környezetben az Omnibus csomag használata a legpraktikusabb, mivel egyetlen installációval megkapjuk a szükséges összetevőket: Nginx, PostgreSQL, Redis és Sidekiq. A telepítés során érdemes privát IP-t beállítani external_url-nek, majd a végén HTTPS-re váltani.
Alapvető biztonsági beállítások:
- Nyílt regisztráció tiltása – csak admin által engedélyezett felhasználók léphetnek be
- Alapértelmezett projekt láthatóság privátra állítása
- Automatikus backup beállítása (pl. heti mentés Object Storage-ra)
Az első bejelentkezés után célszerű minden hozzáférést naplózni, és a root jelszót biztonságosan megváltoztatni. Ezen a ponton már elmondhatod, hogy a forráskódod, pipeline-jaid és minden kulcsadatod az OpenStack privát felhőben él – a saját szabályaid szerint.
Barbican: titkosítás és tanúsítványkezelés OpenStack módra
A privát felhős adatfüggetlenség szempontjából kulcskérdés a titkok, tanúsítványok szuverén kezelése. Az OpenStack Barbican komponense pontosan erre szolgál: titkos kulcsokat, TLS tanúsítványokat kezel, és csak a Keystone által engedélyezett entitások férhetnek hozzá.
Példa a tanúsítvány Barbicanben való tárolására:
- Külön tárolóban helyeztem el a gitlab.crt és gitlab.key fájlokat.
- Az Nginx konfigurációban ezekre a titkosított kulcsokra hivatkoztam, így semmilyen érzékeny adat nem marad laza fájlként a VM-en.
- Keystone alapú jogosultságkezeléssel csak a GitLab, illetve CI folyamat férhet hozzá ezekhez.
Az eredmény: a teljes TLS titokkezelés az OpenStack ökoszisztémán belül történik, még egy admin kompromittáció sem veszélyezteti a privát kulcsokat.
Teljesen szuverén Runner – pipeline végrehajtás OpenStack-on belül
Most már a control plane is a te kezedben van, de a CI/CD pipeline-ok tényleges végrehajtása is szuverén kell legyen. Azaz a Runnernek is OpenStack VM-en kell futnia, nem egy külső gépen vagy Docker hoston.
Runner regisztráció lépései, saját példán keresztül:
- Lépj be a GitLab webes felületére: Beállítások > CI/CD > Runnerek
- Új projekt runner létrehozása: válassz Linuxot, és címkézd pl. sovereign taggel
- Jegyezd fel a generált regisztrációs tokent
- Runner VM-en következő parancs:
gitlab-runner register, majd add meg az URL-t, tokent, executor típust (shell/docker/kubernetes) - Ha HTTPS-t használsz, ügyelj a CA tanúsítványok helyes beállítására a Runner VM-en
Ezután minden pipeline futás, minden build, minden artefakt csak az OpenStack-odon belül születik és marad – nem függsz többé semmilyen külső SaaS-tól.
Az adatfüggetlenség OpenStack-on: előnyök és kihívások
A GitLab OpenStack architektúra mellett dönteni komoly elköteleződés, de cserébe teljes adatfüggetlenséget és jogi szuverenitást kapsz. Lássuk a legfontosabb előnyöket és a gyakorlatban felmerülő kihívásokat:
- Előnyök:
- Az összes forráskód, pipeline, artefakt, titok a te OpenStack-odon marad
- Jogilag és fizikailag te rendelkezel minden adattal
- Helyi biztonsági szabályzatok és audit igények könnyen teljesíthetők
- Nincs függés harmadik fél ToS-ától vagy szolgáltatásminőségétől
- Kihívások:
- Több üzemeltetési feladat: frissítések, biztonsági mentések, monitoring
- Nagyobb kezdeti IT beruházás (erőforrás, szakértelem)
- Integráció külső szolgáltatásokkal (például e-mail, registry) saját magadnak kell megoldani
Sokan félnek a plusz karbantartási munkától, de megfelelő automatizálással (pl. Ansible playbookok, Terraform OpenStack modulok) a napi üzemeltetés pár óra alatt kézben tartható – miközben a szuverenitásod valóban 100%-os.
Gyakran ismételt kérdések
Miben különbözik a GitLab OpenStack-on való futtatása a GitLab.com használatától?
A GitLab OpenStack környezetben a teljes rendszer – repók, pipeline-ok, titkok – a saját privát felhőben helyezkedik el, így minden adat felett te rendelkezel. Ezzel szemben a GitLab.com SaaS szolgáltatás, ahol az adataid, titkaid egy külső szolgáltató szerverein laknak, és azokhoz harmadik fél is hozzáférhet, akár jogi, akár technikai okokból.
Mekkora gépet érdemes dedikálni a GitLab OpenStack szerverhez?
Kisebb (5-10 fős) fejlesztőcsapatoknak minimum 4 vCPU, 8 GB RAM és legalább 100 GB SSD tárhely javasolt. Nagyobb csapatok, több projekt vagy sok CI feladat esetén duplázd meg az erőforrásokat. Fontos a gyors tárhely, mert a pipeline artefaktok és repók gyorsasága döntő lehet.
Mennyire biztonságos titkokat (pl. pipeline kulcsokat) OpenStack Barbicanben tárolni?
Az OpenStack Barbican titkosítási szintje nagyvállalati szintű, a kulcsokat csak a megfelelő Keystone jogosultságok birtokában lehet kiolvasni. A gyakorlatban sokkal biztonságosabb, mint egy sima fájlrendszeren vagy GitLab változóként (plaintext-ben) tárolni titkokat.
Hogyan oldható meg a GitLab frissítése privát OpenStack környezetben?
Az Omnibus csomagot ugyanúgy lehet frissíteni, mint bárhol máshol: apt-get update && apt-get upgrade gitlab-ee. Ajánlott előtte snapshotot vagy backupot készíteni a VM-ről, illetve a PostgreSQL adatbázisról és tárhelyről. Ha Barbicanben vannak a kulcsok, azokat nem érinti a frissítés.
Lehet-e teljesen elkülöníteni a fejlesztői és éles környezetet OpenStack-on belül?
Igen, az OpenStack tenant szintű elkülönítése teljesen szeparált infrastruktúrát ad: külön hálózat, külön GitLab példány, külön Barbican titkok – semmilyen adat vagy jogosultság nem keveredik, ha jól van beállítva a felhő.
Összegzés
A GitLab OpenStack kombinációval – ha jól csinálod – valódi adatfüggetlenséget, szuverenitást és privát CI/CD élményt kapsz, minden kompromisszum nélkül. Ez az út nem mindig a legegyszerűbb, de hosszú távon megtérül: nincs külső függés, a titkaid a te kezedben maradnak, és a megfelelőségi követelmények is könnyebben teljesíthetők.
Ha komolyan gondolod a szuverén platform engineering-et vagy kritikus CI/CD biztonságot, a GitLab OpenStack környezetben történő teljes bevezetése az egyik legjobb befektetés lehet. Ha kérdésed van, vagy szeretnéd elkezdeni a saját privát felhős GitLab setupod kialakítását, keress bátran – tanácsadással, üzemeltetéssel és automatizált bevezetési csomagokkal is segítek!
