GitLab — alapok, lehetőségek és CI/CD

Mi az a GitLab?

GitLab — egy teljes értékű, nyílt forráskódú DevOps platform MIT licenc alatt. Ellentétben a GitHub-bal, amely különböző szolgáltatásokat integrációkon keresztül kapcsol össze, a GitLab egyetlen eszközt kínál a fejlesztés teljes életciklusához: a kódkezeléstől és kódellenőrzéstől a CI/CD-n, monitorozáson, biztonságon és telepítésen keresztül. A platform nem igényel külső szolgáltatásokat a legtöbb DevOps feladathoz.

A GitLab története 2011-ben kezdődött, mint ukrán fejlesztők belső projektje. Az első nyilvános verzió 2011 szeptemberében jelent meg, és 2015-ben a GitLab lett az első projekt a GitLab.com-on, elindítva a felhőalapú tárhelyszolgáltatást. 2017-ben a GitLab egy fájdalmas, de tanulságos migrációs folyamatot hajtott végre — a teljes infrastruktúra áthelyezését Azure-ból Google Cloud-ba, amelyet élőben közvetítettek és egy sorozat bejegyzésben dokumentáltak.

A GitLab architektúra három fő összetevőből áll: GitLab Rails (Ruby on Rails alapú webalkalmazás), GitLab Shell (Git műveletek feldolgozása SSH-n keresztül) és Gitaly (gRPC szerver Git adatokhoz való hozzáféréshez). A CI/CD-t a GitLab Runner biztosítja — egy külön álló alkalmazás, amely az építő szerverekre települ, és feladatokat (job-okat) hajt végre elkülönített környezetekben (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipeline-ok és runner-ek

GitLab CI/CD — egy beépített folyamatos integrációs és szállítási rendszer, amely a platform egyik legfőbb előnye. Ellentétben a GitHub Actions-szal, a GitLab CI/CD a kezdetektől fogva része volt az architektúrának, és nem igényel külön konfigurációt: minden projekt automatikusan megkapja a CI/CD-t, miután a .gitlab-ci.yml fájlt hozzáadták a tár gyökeréhez.

A pipeline (pipeline) szakaszokból (stages) áll, amelyek sorrendben vagy párhuzamosan hajthatók végre: build → test → deploy. Minden szakasz egy vagy több job-ot tartalmaz, amelyeket runner-ek hajtanak végre. Ha egy job a szakaszban hibával ér véget, a teljes szakasz failed-ként lesz megjelölve, és a következő szakaszok alapértelmezés szerint nem indulnak el. Az alábbiakban egy példa látható pipeline-ra egy mobil projekthez:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

A GitLab Runner több executor-t (végrehajtót) támogat: Docker (ajánlott), Kubernetes, SSH, VirtualBox és Parallels. A legnépszerűbb megoldás a Docker executor, amely minden job-ot egy külön konténerben futtat. A runner regisztrálható egy adott projektre specifikusnak vagy megosztottnak (shared) az egész csoport számára. A GitLab.com ingyenes megosztott runner-eket biztosít 2000 perc korlátozással havonta.

CI/CD haladó lehetőségei

GitLab CI/CD támogatja a kézi indítást (when: manual), késleltetett indítást (when: delayed), párhuzamos végrehajtást (parallel: 5), mátrixot (matrix), dinamikus pipeline-okat (child pipelines) és többszintű pipeline-okat (parent-child). Ez lehetővé teszi összetett forgatókönyvek építését: például dinamikusan pipeline generálását minden modulhoz egy monorepository-ban, vagy párhuzamos építések futtatását különböző Android architektúrákhoz (arm64, x86_64).

GitLab kontra GitHub: fő különbségek

GitLab és GitHub — a két fő versenytárs a Git platformok piacán, de filozófiájuk és architektúrájuk alapvetően különbözik. A GitHub a nyílt közösségre, az integrációs ökoszisztémára és a szociális funkciókra (fork-ok, csillagok) összpontosít. A GitLab az átfogó DevOps ciklusra koncentrál, és minden eszközt a dobozból kínál: a tervezéstől a monitorozásig.

A fő architektúrabeli különbség: GitLab — egyetlen monolitikus alkalmazás, amelyet a fejlesztő teljes egészében telepít. Minden funkció (CI/CD, Container Registry, Security Scanning, Pages) beépített és a telepítés után azonnal működik. GitHub — egy API-val rendelkező platform, ahol a funkciók többsége külső szolgáltatásokkal való integráción keresztül valósul meg: Travis CI, CircleCI, Jenkins, SonarQube. Az alábbi táblázat összehasonlítja a fő jellemzőket:

A választás GitLab és GitHub között a csapat igényeitől függ. Ha a prioritás a gyors telepítés nulla konfigurációval és a nyílt közösség — válassza a GitHub-ot. Ha teljes infrastruktúra-kezelésre, saját tárhelyre és beépített biztonságra van szükség — a GitLab az előnyösebb. A Stack Overflow felmérése (2024) szerint a fejlesztők 90%-a használja a GitHub-ot, 33%-a a GitLab-ot (gyakran mindkét platformot egyszerre).

Self-Managed GitLab: telepítés saját szerverre

Self-Managed GitLab (korábban On-Premises) lehetővé teszi a platform saját szerverre telepítését és a teljes ellenőrzést az adatok, infrastruktúra és rendelkezésre állás felett. Ez különösen fontos a megfelelési követelményekkel rendelkező szervezetek számára: pénzügyi szektor, állami intézmények, egészségügyi szervezetek, ahol az adatok nem tárolhatók külső szervereken.

A GitLab telepítése Ubuntu, Debian, CentOS rendszerekre és Dockeren keresztül támogatott. A hivatalos Omnibus csomag tartalmazza az összes összetevőt: webszerver (NGINX), adatbázis (PostgreSQL), gyorsítótár (Redis), Git feldolgozó (Gitaly) és háttérfolyamatok. Minimális követelmények: 4 GB RAM és 2 CPU egy legfeljebb 100 fős csapat számára. Nagy terhelésű nagyméretű telepítések esetén az összetevők különválasztása ajánlott külön szerverekre.

# GitLab CE telepítése Ubuntu-ra Omnibus segítségével
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Csomag telepítése
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Állapot megtekintése
sudo gitlab-ctl status
sudo gitlab-ctl tail

A Self-Managed GitLab-nak nincs CI/CD perc korlátozása — az összes runner a szervezet tulajdona, és teljesítményüket csak a saját hardver korlátozza. Továbbá elérhető a Geo-replikáció régiók számára, audit naplók, IP-blokkolás és vállalati LDAP/SAML szolgáltatókkal való integráció. A GitLab havonta (22-én) ad ki frissítéseket új funkciókkal és biztonsági javításokkal.

Beépített biztonsági eszközök a GitLab-ban

Biztonság a GitLab-ban platform szinten beépített, és több vizsgálót tartalmaz, amelyek a pipeline minden szakaszában működnek. A SAST (Static Application Security Testing) elemzi a forráskódot sérülékenységekre az alkalmazás futtatása nélkül, támogatva több mint 15 nyelvet, köztük Java, Kotlin, Swift, Python és JavaScript. A DAST (Dynamic Application Security Testing) a futó webalkalmazást vizsgálja sérülékenységekre belülről.

Kiegészítő eszközök: Container Scanning ellenőrzi a Docker képeket az alap rétegek sérülékenységeire; Dependency Scanning elemzi a projekt függőségeit és figyelmeztet az ismert CVE-kre; Secret Detection megtalálja a véletlenül commit-olt API kulcsokat, jelszavakat és tokeneket; Fuzz Testing automatikus tesztelést végez hibás adatokkal a nem nyilvánvaló hibák megtalálására. Az összes vizsgálati eredmény egyetlen Security Dashboard-ban jelenik meg.

A GitLab Compliance eszközöket is kínál a szabályozói követelmények betartásához. A Compliance Dashboard megmutatja az összes projekt megfelelési állapotát, az Audit Events naplózza a rendszergazda és a fejlesztő minden műveletét, a Compliance Frameworks pedig lehetővé teszi a konfigurációs házirendek kötelező érvényesítését bizonyos projektcsoportokra. Ez teszi a GitLab-ot népszerű választássá a szigorú biztonsági követelményekkel rendelkező vállalati környezetekben.

Container Registry és Dependency Proxy

GitLab Container Registry — egy beépített Docker regiszter, amely integrálódik a CI/CD-vel. Miután a pipeline-ban elkészült egy Docker kép, az azonnal publikálható a Registry-ben a CI_REGISTRY és CI_REGISTRY_USER környezeti változók segítségével. A Registry támogatja a pull-through gyorsítótárat, címkézést, tisztítási szabályokat és sérülékenység-vizsgálatot közvetlenül a regiszterben.

Dependency Proxy — a konténerek és képek gyorsítótárazásának mechanizmusa külső regiszterekből (Docker Hub, Quay, GCR). Amikor a pipeline kér egy ubuntu:latest képet, a GitLab előszőr ellenőrzi a saját gyorsítótárát — ha a kép már betöltődött, nem tölti le újra. Ez csökkenti a külső regiszterek terhelését, gyorsítja a pipeline-okat és véd a Docker Hub sebességkorlátai ellen.

Mobil fejlesztők számára a GitLab GitLab Pages-t kínál dokumentáció és tesztjelentések tárhelyéhez. A tesztek futtatása után a műtermékek (HTML jelentések, képernyőképek, naplók) Pages-ként publikálhatók, és egy link kapható a QA csapatnak való elküldéshez. Ez kényelmesebb, mint a jelentések felhőalapú tárhelyre töltése, mivel minden elhelyezésre kerül ugyanazon GitLab projekten belül.

GitLab API és Webhook-ok

GitLab API (REST és GraphQL) hozzáférést biztosít a platform összes erőforrásához: projektek, felhasználók, pipeline-ok, Merge Request-ek, regiszter. Az API automatizálásra használható: projekt létrehozása sablonból, reviever kijelölése, pipeline állapotának lekérdezése. A Webhook-ok lehetővé teszik HTTP értesítések küldését külső rendszerekbe események esetén: push, merge, Issue létrehozása. A Webhook-ok integrálódnak Mattermost, Slack, Telegram és belső monitorozó rendszerekkel.

GitLab Pages mobil dokumentációhoz

GitLab Pages automatikusan publikál statikus weboldalakat a tárból. Mobil projektekhez a Pages hasznos API dokumentáció, tesztlefedettségi jelentések és lint elemzési eredmények elhelyezésére. A publikálás automatikusan történik sikeres pipeline után — elég megadni a .gitlab-ci.yml-ben a deploy lépést a Pages-be publikálással. Az eredmény a https://namespace.gitlab.io/projekt-neve címen érhető el.