GitLab: CI/CD

Jak korzystać z GitLab CI/CD

👋 Witamy w dokumentacji Stackhero!

Stackhero oferuje gotowe do użycia rozwiązanie GitLab cloud, stworzone z myślą o zespołach potrzebujących szybkiego, bezpiecznego i skalowalnego środowiska:

Nieograniczona liczba użytkowników, repozytoriów, transferów danych oraz czasu przetwarzania CI/CD – pełna elastyczność.

Bezproblemowe aktualizacje jednym kliknięciem – Twoje środowisko zawsze aktualne, bez przestojów.

Własna nazwa domeny zabezpieczona HTTPS (np. https://git.twoja-firma.com) – profesjonalny wizerunek i bezpieczeństwo.

Stała wydajność i wysoki poziom bezpieczeństwa na Twojej prywatnej, dedykowanej infrastrukturze. Brak "głośnych sąsiadów" i pełna izolacja.

Wybór lokalizacji hostingu: 🇪🇺 Europa lub 🇺🇸 USA – zgodnie z wymaganiami dotyczącymi zgodności lub opóźnień.

Zacznij szybko i skup się na swoim kodzie. Rozwiązanie GitLab cloud hosting od Stackhero jest gotowe do użycia w około 5 minut.

Wprowadzenie

GitLab CI/CD to zaawansowana i zintegrowana funkcjonalność platformy GitLab, popularnego, otwartego oprogramowania do kontroli wersji i współpracy zespołowej. Narzędzie to umożliwia automatyzację i usprawnienie kluczowych etapów budowania, testowania oraz wdrażania oprogramowania, zapewniając szybszą i bardziej niezawodną dostawę wysokiej jakości aplikacji.

Na przykład, dzięki GitLab CI/CD można skonfigurować automatyczne testy jednostkowe, które uruchamiają się przy każdym nowym commicie wypchniętym do repozytorium GitLab. Po pomyślnym przejściu tych testów kod może zostać zbudowany i wdrożony na środowisko stagingowe w celu dalszej weryfikacji. Po zaliczeniu wszystkich testów na środowisku staging, system może promować kod na środowisko produkcyjne, udostępniając go użytkownikom końcowym.

Jedną z kluczowych zalet GitLab CI/CD jest jego ścisła integracja z samym GitLabem. Pozwala to definiować i zarządzać pipeline'ami CI/CD bezpośrednio w repozytoriach projektowych, co upraszcza orkiestrację i monitorowanie całego procesu pracy.

GitLab CI/CD obsługuje szeroką gamę języków programowania, frameworków i narzędzi, dzięki czemu jest na tyle uniwersalny, by sprostać wymaganiom różnych projektów. System konfigurowalnych pipeline'ów pozwala dostosować każdy etap procesu CI/CD do własnych potrzeb — niezależnie czy chodzi o budowanie, testowanie, czy wdrażanie na wiele środowisk.

Podsumowując, GitLab CI/CD to kompleksowe rozwiązanie zaprojektowane do automatyzacji i usprawniania procesów dostarczania oprogramowania. Pozwala deweloperom skupić się na pisaniu i ulepszaniu kodu, podczas gdy platforma efektywnie zarządza zadaniami operacyjnymi.

Jak budować obrazy Docker w GitLab CI

Jeśli repozytorium projektu zawiera pliki Dockerfile, można zautomatyzować proces budowania, uruchamiania oraz – w razie potrzeby – publikowania obrazów Docker do rejestru.

Krok 1: Włącz obsługę Docker in Docker (DinD)

Na początek należy włączyć obsługę "Docker in Docker" (DinD) w panelu Stackhero.

Włączenie obsługi DinD wiąże się z ryzykiem bezpieczeństwa, zwłaszcza jeśli zależy Państwu na izolacji użytkowników i uniemożliwieniu im dostępu do projektów innych osób.

Krok 2: Skonfiguruj pipeline GitLab CI

Następnie należy zaktualizować plik gitlab-ci.yml, aby dodać konfigurację pipeline'u budującego Dockerfile z wykorzystaniem DinD. Przykładowa konfiguracja poniżej:

image: docker:29

build:
  stage: build
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    # Ustawia CLI dockera na usługę Docker-in-Docker przez jej zwykły
    # (nie-TLS) port. Zobacz poniższą uwagę, dlaczego DOCKER_HOST jest istotny.
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Zamień "my-docker-image" na nazwę wybranego obrazu:
    - docker build -t my-docker-image .
    # Opcjonalnie, przetestuj obraz Docker:
    # - docker run my-docker-image /script/to/run/tests

Usługa docker:29-dind uruchamia demona Docker obok zadania, a DOCKER_HOST wskazuje CLI dockera, aby z niego korzystał. Zawsze ustawiaj DOCKER_HOST, gdy deklarujesz usługę docker:dind: jeśli tego nie zrobisz, CLI po cichu połączy się z innym demonem, a build może się powieść nawet przy błędnej konfiguracji usługi, co ukrywa rzeczywiste problemy. DOCKER_TLS_CERTDIR: "" pozwala korzystać ze zwykłego portu 2375 (bez TLS) w wewnętrznej sieci zadania.

Jako prostszą alternatywę można całkowicie pominąć blok services i obie zmienne: runner Stackhero udostępnia już gotowego demona Docker przez zamontowany socket, więc zwykłe docker build działa od razu.

Dodatkowe informacje na temat budowania obrazów Docker z GitLab CI można znaleźć w oficjalnej dokumentacji GitLab.

Uruchamianie testów z Testcontainers

Jeśli Państwa zestaw testów korzysta z Testcontainers, biblioteki uruchamiającej rzeczywiste usługi (bazy danych, message brokers i inne) jako tymczasowe kontenery Docker podczas testów, powyższa konfiguracja jest już odpowiednia. Należy pozostawić usługę docker:29-dind oraz obie zmienne: Testcontainers używa DOCKER_HOST do połączenia z demonem Docker i kontenerami, które uruchamia, więc nie są wymagane żadne dodatkowe ustawienia.

Brak ustawienia DOCKER_HOST to najczęstsza przyczyna niepowodzeń Testcontainers w CI. Biblioteka wtedy korzysta z socketa Docker zamontowanego przez runnera i nie może połączyć się z własnymi kontenerami testowymi, co zwykle objawia się timeoutem kontenera pomocniczego Ryuk.