Gitlab

flowchart LR
 subgraph External["External"]
        U["Users"]
  end
 subgraph Gitlab["GITLAB"]
        GITLAB["gitlab-ce"]
        GITLAB_COM["gitlab.com"]
  end
 subgraph RUNNER["GITLAB RUNNERS"]
        R1["Gitlab runner s1"]
        R2["Gitlab runner s2"]
        R3["Gitlab runner s3"]
  end
 subgraph STORAGE["NFS Storage"]
        NFSProd[("NFS Gitlab-Runner<br> Cache")]
        NFSProv["NFS Provisioner"]
  end
    GITLAB == <br> ==> R1
    U ==> GITLAB
    GITLAB ==> R2 & R3
    GITLAB_COM ==> R1 & R2 & R3
    R1 == /cache ==> NFSProv
    R2 == /cache ==> NFSProv
    R3 == /cache ==> NFSProv
    NFSProv == /volume1/gitlab-runner ==> NFSProd

    style RUNNER fill:#FFF9C4,color:#000000
    style STORAGE fill:#FFCDD2,color:#000000
    linkStyle 0 stroke:#D50000,fill:none
    linkStyle 1 stroke:#00C853,fill:none
    linkStyle 2 stroke:#D50000,fill:none
    linkStyle 3 stroke:#D50000,fill:none
    linkStyle 4 stroke:#AA00FF,fill:none
    linkStyle 5 stroke:#AA00FF,fill:none
    linkStyle 6 stroke:#AA00FF,fill:none
    linkStyle 7 stroke:#FF6D00,fill:none
    linkStyle 8 stroke:#FF6D00,fill:none
    linkStyle 9 stroke:#FF6D00
    linkStyle 10 stroke:#FF6D00

1. Architektura logiczna

Architektura składa się z czterech warstw:

1. Warstwa kliencka (External)
2. Warstwa GitLab (GitLab CE + gitlab.com)
3. Warstwa wykonawcza CI/CD (GitLab Runners)
4. Warstwa storage cache (NFS)

2. Warstwa kliencka (External)

2.1. Opis

Warstwa kliencka obejmuje:

• użytkowników (developerów, adminów),
• automaty (np. integracje, webhooki, narzędzia deploymentowe),
• procesy CI/CD inicjowane przez system GitLab.

2.2. Punkt wejścia

Użytkownicy komunikują się z:

• GitLab CE (instancja self-hosted) – interfejs www, API, repozytoria,
• gitlab.com – analogicznie, w zależności od repozytoriów/projektów.

3. Warstwa GitLab

3.1. GitLab CE (self-hosted)

Rola:

• zarządzanie repozytoriami, merge requestami, issue tracking,
• orkiestracja pipeline’ów i kolejkowanie jobów,
• dostarczanie konfiguracji .gitlab-ci.yml do runnerów,
• dystrybucja zadań do zarejestrowanych wykonawców (runnerów).

Interakcje:

• GitLab CE przydziela zadania do runnerów R1, R2, R3.

3.2. gitlab.com

Rola:

• publiczna lub osobna instancja GitLab wykorzystywana równolegle,
• możliwość wykorzystywania tej samej puli runnerów (model „shared runners” w ujęciu infrastruktury użytkownika).

Interakcje:

• gitlab.com deleguje zadania do runnerów R1, R2, R3 (o ile są zarejestrowane do tej instancji).

4. Warstwa wykonawcza CI/CD – GitLab Runners

4.1. Skład

Warstwa CI/CD obejmuje trzy instancje wykonawcze:

• GitLab runner s1 (R1)
• GitLab runner s2 (R2)
• GitLab runner s3 (R3)

4.2. Rola

Runner odpowiada za:

• pobranie joba z GitLab (CE lub gitlab.com),
• wykonanie joba w wybranym executorze (np. Docker/Shell),
• zarządzanie cache buildów oraz pobieraniem/zapisywaniem cache,
• publikację wyników (logi, statusy, artefakty) do GitLab.

4.3. Skalowanie i dostępność

• Architektura umożliwia skalowanie horyzontalne poprzez dodawanie kolejnych runnerów.
• Awaria pojedynczego runnera zmniejsza przepustowość, ale nie zatrzymuje działania całego CI/CD.

5. Warstwa storage – NFS dla cache

5.1. Cel cache

Cache CI/CD jest wykorzystywany do przechowywania danych pośrednich (np. zależności, paczek, warstw buildów), aby:

• skrócić czas pipeline’ów,
• ograniczyć transfer i liczbę pobrań z Internetu,
• ujednolicić środowisko pracy runnerów.

5.2. Komponenty

5.3. Mapowanie montowań

6. Przepływy (workflow)

6.1. Uruchomienie pipeline (GitLab CE)

1. Użytkownik wykonuje push/merge request do GitLab CE.
2. GitLab CE tworzy pipeline i planuje joby.
3. Jeden z runnerów (R1/R2/R3) pobiera joba.
4. Runner wykonuje job i używa /cache do odczytu/zapisu danych cache.
5. Wyniki joba są raportowane do GitLab CE.

6.2. Uruchomienie pipeline (gitlab.com)

Analogicznie, z tą różnicą, że orkiestracja pipeline zachodzi po stronie gitlab.com, natomiast wykonanie joba nadal jest realizowane przez runner’y użytkownika.

7. Wysoka dostępność i odporność na awarie

7.1. Założenia

7.2. Krytyczne zależności

• NFS jako cache: awaria NFS nie zatrzymuje całego CI/CD, ale może:

  • wydłużyć pipeline’y,
  • spowodować błędy jobów, jeśli pipeline zakłada istnienie cache lub brak tolerancji na brak mountu.

8. Wymagania bezpieczeństwa i separacji (zalecenia)

Jeżeli te same runnery obsługują jednocześnie GitLab CE i gitlab.com, należy przyjąć minimalny zestaw zasad:

• separacja runnerów tagami (tags) i restrykcyjne rules/only po stronie projektów,
• rozdzielenie executorów i środowisk uruchomieniowych (np. różne Docker daemony, izolacja hostów),
• kontrola, co trafia do cache (ryzyko „cache poisoning” między projektami),
• ograniczenie uprawnień runnerów (np. unikanie privileged, ograniczenie mountów hosta),
• rozważenie dedykowanych runnerów dla gitlab.com vs GitLab CE, jeśli wymagania compliance są wysokie.