GitLab: Wie Sie Docker-Images in Ihrer GitLab CI bauen

Diese Dokumentation ist Teil des CI/CD-Leitfadens. Den vollständigen Leitfaden finden Sie hier: 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.

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.