GitLab Runner: Docker-Images erstellen

Erstellen und pushen Sie Docker-Images effizient aus Ihren GitLab CI/CD-Pipelines mit Stackhero Runnern und Docker-in-Docker

👋 Willkommen in der Stackhero-Dokumentation!

Stackhero bietet Ihnen eine benutzerfreundliche GitLab Runner Cloud-Lösung, die speziell dafür entwickelt wurde, Ihre GitLab CI/CD-Jobs effizient auszuführen. Das erwartet Sie:

Unbegrenzte CI/CD-Minuten: Es gibt keine Abrechnung pro Minute, sodass Ihre Pipelines jederzeit ausgeführt werden können.

Mehrere gleichzeitige Jobs: Führen Sie mehrere Jobs parallel aus, um Ihre gesamte Pipeline zu beschleunigen.

Der Docker Executor mit Docker-in-Docker-Unterstützung: Optimieren Sie das Erstellen und Pushen Ihrer Container-Images.

Kompatibel mit GitLab.com sowie jeder selbst gehosteten GitLab-Instanz.

Eine private, dedizierte VM mit schnellen NVMe/SSD-Festplatten für konsistente und zuverlässige Builds.

Verfügbar in den Regionen 🇪🇺 Europa und 🇺🇸 USA.

Sparen Sie Zeit: Sie können Ihren ersten GitLab Runner verbinden und Ihre Pipelines in nur wenigen Minuten starten!

Einführung

Mit einem Stackhero GitLab Runner wird jeder Job in einem frischen Container mithilfe des Docker Executors ausgeführt. Sie können Ihre eigenen Docker-Images direkt in Ihrer Pipeline bauen, indem Sie Docker-in-Docker (DinD) aktivieren. Diese Konfiguration startet einen Docker-Daemon parallel zu Ihrem Job, sodass Sie docker build- und docker push-Befehle als Teil Ihres CI/CD-Prozesses ausführen können.

Jeder Lauf profitiert von unbegrenzten CI/CD-Minuten: Sie können beliebig oft Builds durchführen, ohne sich um Nutzungslimits sorgen zu müssen. Ihr Build-Cache wird auf der dedizierten Festplatte des Runners gespeichert, sodass wiederholte Builds auf vorherige Layer zurückgreifen können. Das verkürzt die Build-Zeiten erheblich und beschleunigt Ihre Pipelines.

Docker-Image mit Docker-in-Docker bauen

Sie können die folgende Beispiel-.gitlab-ci.yml-Datei zu Ihrem Repository hinzufügen. Diese Konfiguration baut das Dockerfile im Root-Verzeichnis Ihres Projekts:

build-image:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker info
  script:
    # Ersetzen Sie "my-image" durch den gewünschten Namen:
    - docker build -t my-image .
    # Optional: Führen Sie einen schnellen Test mit dem gebauten Image aus:
    # - docker run --rm my-image /path/to/tests

In diesem Beispiel verwenden wir die Docker-Image-Version 29. Sie können auch eine neuere Version verwenden, sobald diese verfügbar ist. Die aktuellsten Tags finden Sie auf der offiziellen Docker-Image-Seite.

In dieser Konfiguration startet der Service docker:29-dind den Docker-Daemon. Mit der Einstellung DOCKER_TLS_CERTDIR: "/certs" wird eine sichere TLS-Verbindung zwischen Ihrem Job und dem Docker-Daemon aktiviert.

Push in die GitLab Container Registry

GitLab stellt vordefinierte Variablen (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_REGISTRY_IMAGE) bereit, damit Ihre Pipeline sich authentifizieren und Images sicher in die Container Registry Ihres Projekts pushen kann. Zusätzliche Secrets sind nicht erforderlich.

Hier ein Beispiel-Job, der Ihr Image baut und pusht:

build-and-push:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
    # Wenn Sie sich auf dem Default-Branch befinden, können Sie zusätzlich "latest" taggen und pushen:
    - |
      if [ "$CI_COMMIT_BRANCH" = "$CI_DEFAULT_BRANCH" ]; then
        docker tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" "$CI_REGISTRY_IMAGE:latest"
        docker push "$CI_REGISTRY_IMAGE:latest"
      fi

Um Ihre Images in ein anderes Registry (wie Docker Hub oder ein privates Registry) zu pushen, können Sie Zugangsdaten als CI/CD-Variablen speichern und diese wie oben mit docker login verwenden.

Wiederholte Builds beschleunigen

Die Festplatte Ihres Runners bleibt zwischen den Pipelines bestehen, sodass Sie Image-Layer als Build-Cache wiederverwenden können. Das macht wiederholte Builds deutlich schneller. Hier ein Beispiel für eine entsprechende Konfiguration:

build-cached:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    # Die neueste Image-Version ziehen, um den Cache zu initialisieren (falls vorhanden):
    - docker pull "$CI_REGISTRY_IMAGE:latest" || true
    - docker build --cache-from "$CI_REGISTRY_IMAGE:latest" -t "$CI_REGISTRY_IMAGE:latest" .
    - docker push "$CI_REGISTRY_IMAGE:latest"

Mit diesem Ansatz nutzen Ihre Builds das Layer-Caching von Docker, sodass nur neue oder geänderte Layer neu gebaut werden.

Jobs parallel ausführen

Ihr Tarif bestimmt, wie viele Jobs gleichzeitig ausgeführt werden können. Jobs innerhalb derselben Stage starten parallel, bis zur maximalen Parallelitätsgrenze. Das bedeutet, mehrere unabhängige Jobs können gleichzeitig laufen und beenden, sobald der langsamste Job abgeschlossen ist – ohne aufeinander warten zu müssen.

Beispiel:

stages:
  - test

unit:
  stage: test
  image: node:22
  script: npm run test:unit

integration:
  stage: test
  image: node:22
  script: npm run test:integration

e2e:
  stage: test
  image: node:22
  script: npm run test:e2e

Wenn Sie Ihre Parallelität auf 1 oder höher setzen, werden die Jobs unit, integration und e2e gleichzeitig ausgeführt.

Weitere Informationen zum Erstellen von Docker-Images in GitLab CI/CD-Pipelines finden Sie in der offiziellen GitLab-Dokumentation zur Verwendung von Docker-Builds.