GitLab: CI/CD

Wie Sie GitLab CI/CD nutzen

👋 Willkommen in der Stackhero-Dokumentation!

Stackhero bietet eine einsatzbereite GitLab Cloud Lösung, die speziell für Teams entwickelt wurde, die eine schnelle, sichere und skalierbare Umgebung benötigen:

Unbegrenzte Nutzer, Repositories, Datentransfers und CI/CD-Verarbeitungszeit für maximale Flexibilität.

Mühelose Updates per Klick, damit Ihre Umgebung immer aktuell bleibt – ganz ohne Ausfallzeiten.

Eigene Domain mit HTTPS-Verschlüsselung (zum Beispiel https://git.ihre-firma.com) für professionelles Auftreten und höchste Sicherheit.

Stetige Performance und starke Sicherheit auf Ihrer eigenen privaten, dedizierten Infrastruktur. Keine störenden Nachbarn, vollständige Isolation garantiert.

Wahl des Hosting-Standorts: 🇪🇺 Europa oder 🇺🇸 USA – passend zu Ihren Compliance- oder Latenzanforderungen.

Starten Sie in wenigen Minuten und konzentrieren Sie sich ganz auf Ihren Code. Die GitLab Cloud Hosting Lösung von Stackhero ist in etwa 5 Minuten einsatzbereit.

Einführung

GitLab CI/CD ist eine leistungsstarke und integrierte Funktion von GitLab, einer weit verbreiteten Open-Source-Plattform für Versionskontrolle und Zusammenarbeit. Mit diesem Tool können Sie die entscheidenden Phasen des Build-, Test- und Deployment-Prozesses automatisieren und optimieren, um eine schnellere und zuverlässigere Auslieferung hochwertiger Software zu gewährleisten.

Beispielsweise können Sie mit GitLab CI/CD automatisierte Unit-Tests einrichten, die bei jedem neuen Commit in ein GitLab-Repository ausgelöst werden. Nach erfolgreichem Bestehen dieser Tests kann Ihr Code gebaut und in eine Staging-Umgebung für weitere Prüfungen bereitgestellt werden. Sobald alle Staging-Tests bestanden sind, kann das System den Code in die Produktionsumgebung übernehmen und so für Endnutzer verfügbar machen.

Ein herausragendes Merkmal von GitLab CI/CD ist die enge Integration direkt in GitLab. Dadurch können Sie Ihre CI/CD-Pipelines direkt innerhalb Ihrer Projekt-Repositories definieren und verwalten, was die Orchestrierung und Nachverfolgung Ihres gesamten Workflows erheblich vereinfacht.

GitLab CI/CD unterstützt eine breite Palette an Programmiersprachen, Frameworks und Tools und ist somit vielseitig genug, um unterschiedlichste Projekte abzudecken. Das anpassbare Pipeline-System ermöglicht es Ihnen, jede Phase des CI/CD-Prozesses individuell auf Ihre Anforderungen zuzuschneiden – egal ob Build, Test oder Deployment in verschiedene Umgebungen.

Zusammengefasst ist GitLab CI/CD eine umfassende Lösung zur Automatisierung und Optimierung von Software-Lieferprozessen. Entwickler können sich auf das Schreiben und Verbessern von Code konzentrieren, während die Plattform die operativen Aufgaben effizient übernimmt.

Wie Sie Docker-Images in Ihrer GitLab CI bauen

Wenn Ihr Projekt-Repository Dockerfile-Dateien enthält, können Sie den Prozess des Bauens, Ausführens und – falls erforderlich – Veröffentlichens von Docker-Images in ein Registry automatisieren.

Schritt 1: Docker in Docker (DinD) Support aktivieren

Aktivieren Sie zunächst den "Docker in Docker" (DinD) Support in Ihrem Stackhero-Dashboard.

Die Aktivierung von DinD-Support stellt ein Sicherheitsrisiko dar, insbesondere wenn Sie Ihre Nutzer voneinander isolieren und verhindern möchten, dass sie auf die Projekte anderer zugreifen können.

Schritt 2: GitLab CI Pipeline konfigurieren

Anschließend passen Sie Ihre gitlab-ci.yml-Datei an, um eine Pipeline-Konfiguration einzubinden, die Ihr Dockerfile mit DinD baut. Nachfolgend ein Beispiel für eine solche Konfiguration:

image: docker:29

build:
  stage: build
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    # Weist das Docker CLI an, den Docker-in-Docker-Service über dessen
    # unverschlüsselte (non-TLS) Port zu nutzen. Siehe Hinweis unten, warum DOCKER_HOST wichtig ist.
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Ersetzen Sie "my-docker-image" durch den gewünschten Image-Namen:
    - docker build -t my-docker-image .
    # Optional: Testen Sie das Docker-Image:
    # - docker run my-docker-image /script/to/run/tests

Der Service docker:29-dind startet einen Docker-Daemon neben Ihrem Job, und DOCKER_HOST weist das docker CLI an, diesen zu verwenden. Setzen Sie immer DOCKER_HOST, wenn Sie einen docker:dind-Service deklarieren: Wenn Sie dies weglassen, verbindet sich das CLI stillschweigend mit einem anderen Daemon, und Ihr Build kann auch dann erfolgreich sein, wenn der Service falsch konfiguriert ist – was echte Probleme verschleiert. DOCKER_TLS_CERTDIR: "" sorgt dafür, dass der unverschlüsselte Port 2375 im internen Job-Netzwerk genutzt wird.

Als einfachere Alternative können Sie den gesamten services-Block und beide Variablen weglassen: Der Stackhero-Runner stellt bereits einen einsatzbereiten Docker-Daemon über einen gemounteten Socket zur Verfügung, sodass ein einfaches docker build direkt funktioniert.

Weitere Informationen zum Bauen von Docker-Images mit GitLab CI finden Sie in der offiziellen GitLab-Dokumentation.

Tests mit Testcontainers ausführen

Wenn Ihre Testsuite Testcontainers verwendet – eine Bibliothek, die reale Services (wie Datenbanken, Message Broker und mehr) als temporäre Docker-Container während der Testausführung startet –, ist die obige Konfiguration bereits ausreichend. Belassen Sie den Service docker:29-dind und beide Variablen: Testcontainers nutzt DOCKER_HOST, um den Docker-Daemon zu erreichen und sich mit den gestarteten Containern zu verbinden. Weitere Anpassungen sind nicht erforderlich.

Das Weglassen von DOCKER_HOST ist die häufigste Ursache für Testcontainers-Fehler in CI-Umgebungen. Die Bibliothek greift dann auf den vom Runner gemounteten Docker-Socket zurück und kann ihre eigenen Testcontainer nicht erreichen, was sich meist durch ein Timeout des Ryuk-Hilfscontainers äußert.