🚀 Wprowadzenie

Automatyzacja procesów budowania, testowania i wdrażania aplikacji – czyli CI/CD (Continuous Integration/Continuous Delivery) – stała się fundamentem nowoczesnego podejścia DevOps. GitLab CI/CD oferuje kompleksowe narzędzia do stworzenia niezawodnego pipeline’u na serwerach Linux. W tym zaawansowanym artykule przeanalizujemy każdy aspekt instalacji, optymalizacji i utrzymania pipeline’ów, z naciskiem na skalowalność, bezpieczeństwo, monitoring i szybkie reagowanie na błędy.

🧩 1. Architektura GitLab CI/CD

• GitLab Server: hostowany na Linuxie – może działać samodzielnie lub w klastrze z bazą PostgreSQL, Redis, Gitaly, Sidekiq.
• GitLab Runner: agenci wykonujący zadania. Tryby: Shell, Docker, Docker Machine, Kubernetes.
• Pipeline definiowany w .gitlab-ci.yml.
• Rejestr kontenerowy: GitLab Container Registry lub zewnętrzne (Harbor, Docker Hub).
• Artifacty/pipeline cache: przechowywanie wyników budowania/testów.

Graf: pipeline → runner → środowiska testowe → produkcja.

🛠️ 2. Instalacja GitLab na Linuxie

📌 Wymagania sprzętowe:

• CPU: min. 2‑4 rdzenie
• RAM: 8‑16 GB
• Dysk: 100 GB+ (dla rejestru i backupów)

🔧 Instalacja Omnibus GitLab:

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ee

Konfiguracja gitlab.rb, uruchomienie per:

gitlab-ctl reconfigure

🧠 3. Konfiguracja runnerów: skalowalność i bezpieczeństwo

🔁 GitLab Runner Shell

Prosty wybór – runner działa bezpośrednio na serwerze. Zalety: prosta konfiguracja, szybki start. Wady: brak izolacji między zadaniami.

📦 GitLab Runner Docker

Rekomendowane dla CI z kontenerami:

sudo apt install docker.io gitlab-runner
sudo gitlab-runner register

Warto użyć docker-compose do izolacji i limitowania zasobów.

☸️ GitLab Runner Kubernetes

Najbardziej skalowalna opcja dla dużych firm:

• Kubernetes jako orkiestrowanie runnerów.
• Dynamiczne zwiększanie liczby podów.
• W pełni izolowane środowiska budowania.

🔐 4. Zabezpieczenie CI/CD i sejfów

• Sekrety (CI/CD Variables): utajnianie kluczy API, tokenów, certyfikatów.
• Protected Branches / Tags – ograniczenie uruchamiania pipeline’ów z uprawnieniami.
• Runner tags – separacja środowisk testowych i produkcyjnych.
• Zapobieganie leakowi secretów – analiza logs i aliasowanie zmiennych w .gitlab-ci.yml.
• Podpisy pipeline – zabezpieczenie commitów.

📦 5. Definicja pliku .gitlab-ci.yml

Przykładowy pipeline:

stages:
  - build
  - test
  - deploy

variables:
  IMAGE: registry.example.com/$CI_PROJECT_PATH:$CI_COMMIT_REF_SLUG

build:
  stage: build
  script:
    - docker build -t $IMAGE .
    - docker push $IMAGE

test:
  stage: test
  script:
    - docker run --rm $IMAGE pytest

deploy_prod:
  stage: deploy
  when: manual
  script:
    - ssh deploy@server "docker pull $IMAGE && docker stop app || true && docker rm app || true && docker run -d --name app $IMAGE"
  only:
    - main

• only: main – ogranicza wdrożenie do głównej gałęzi.
• when: manual – wymaga ręcznego uruchomienia.

🧪 6. Testowanie automatyczne i CI best practices

• Testy jednostkowe (pytest, go test, npm test).
• Testy integracyjne w kontenerach.
• Lintery (eslint, flake8, gometalinter).
• Analiza bezpieczeństwa (bandit, trivy, dependency scan, SAST).
• Code coverage raporty wysyłane do Codecov lub GitLab Code Quality.

Przykład z linterem:

lint:
  stage: test
  script:
    - eslint src/

🔁 7. Continuous Deployment i rollback

• Wdrażanie Blue-Green: utrzymanie dwóch środowisk, router zmienia ruch.
• Canary deployment: nowa wersja obsługuje część ruchu.
• Rollback przy błędach – definiujemy rollback stage w pipeline.

📈 8. Monitorowanie pipeline’ów i jakości pracy

• GitLab Dashboard: czasy pipeline, flakowanie testów.
• Prometheus + Grafana: metryki runnera, zużycie GPU, błędy pipeline.
• Alerty: email, Slack, MS Teams przy nieudanych pipeline’ach.

🔄 9. Migracja i skalowanie infrastruktury

• Backup GitLab: gitlab-rake gitlab:backup:create.
• Migracja runnerów: jego retriggering i migracja certyfikatów.
• Horizontal scaling GitLab (stawianie drugiego instancji z load balancerem).
• High Availability z Patroni (PostgreSQL) i Redis Cluster.

⚙️ 10. Integracja GitLab CI/CD z Ceph, Docker Registry, Kubernetes

• Ceph jako storage dla artifactów: RBD lub S3.
• GitLab Container Registry – wbudowany rejestr.
• Kubernetes Integration – autodeploy za pomocą chartów Helm.

✅ Podsumowanie

GitLab CI/CD to potężny system umożliwiający pełną automatyzację budowania, testowania i wdrażania aplikacji. Wymaga przemyślanej architektury infrastrukturalnej:

1. Wybór i konfiguracja runnerów.
2. Ochrona sekretów i ograniczenie dostępu.
3. Konsolidacja pipeline’y z testami i skanowaniem.
4. Strategia wdrożeniowa i rollback.
5. Skalowalny monitoring i backup.

Dzięki dobrze przygotowanemu podejściu CI/CD firmy mogą osiągnąć krótszy czas wdrożeń, mniejsze ryzyko błędów oraz wyższą jakość procesów deweloperskich.

Polecane wpisy

Jak zainstalować i skonfigurować Linuksa na swoim komputerze? – Kompletny przewodnik

Jak zainstalować i skonfigurować Linuksa na swoim komputerze? – Kompletny przewodnik Wstęp Linux to jeden z najpopularniejszych systemów operacyjnych na Czytaj dalej

Virtualization w Linuxie (KVM, Xen): Czy wirtualizacja to tylko iluzja bezpieczeństwa?

🧠 Virtualization w Linuxie (KVM, Xen): Czy wirtualizacja to tylko iluzja bezpieczeństwa? 🔓 Luki w hiperwizorach – fakty, których nie Czytaj dalej