Docker in der CI/CD-Pipeline

Die Kombination aus Containern und CI/CD hat die Softwareentwicklung der letzten zehn Jahre geprägt. Was Container an Reproduzierbarkeit und Portabilität bringen, passt perfekt zu dem, was CI/CD an Automatisierung verlangt: jeder Git-Commit soll automatisch gebaut, getestet und deployt werden – und am Ende soll genau das Artefakt in Produktion landen, das vorher getestet wurde. Docker-Images sind das ideale Auslieferungsartefakt: einmal gebaut, läuft das Image identisch in Test, Staging und Produktion. Diese Lektion zeigt, wie Docker in CI/CD-Pipelines eingesetzt wird – mit konkreten Beispielen für GitHub Actions und GitLab CI.

Die Analogie passt zur Industrie-Fertigung. Ohne CI/CD ist Software-Auslieferung wie Manufaktur-Arbeit: Jemand schraubt manuell ein Produkt zusammen, prüft es, packt es ein, schickt es los. Aufwändig, fehleranfällig, nicht skalierbar. Mit Docker-basiertem CI/CD wird daraus eine moderne Produktionsstraße: Rohstoff (Code) kommt rein, automatische Stationen bauen das Image, testen es, scannen es, packen es ein (Tag) und schicken es ins Lager (Registry).

1) Die typische Docker-CI/CD-Pipeline

Eine Pipeline hat klare Stufen, durch die jeder Code-Push läuft. Klick „Pipeline durchlaufen", um zu sehen, wie die Stages nacheinander aktiv werden:

Docker-Pipeline – die typischen Stages

1.Source – Code-Trigger Git-Push, Pull Request, Tag oder Scheduled Trigger startet die Pipeline.

2.Build – Image bauen docker build aus dem Dockerfile, mit Layer-Cache aus vorherigen Builds.

3.Test – Unit + Integration Tests laufen IM Container (gleiche Umgebung wie später Produktion). Compose für Integration mit DB/Cache.

4.Scan – Sicherheits-Scan Image-Scan (Trivy, Snyk, Grype) auf bekannte CVEs in Layern und Dependencies.

5.Tag – Versionierung Mehrere Tags: sha-abc1234, v2.3.0, main – klare Identifikation.

6.Push – Registry Image in die Registry pushen (Docker Hub, GHCR, Harbor, AWS ECR).

7.Deploy – Staging In Test-/Staging-Umgebung deployen, ggf. Smoke-Tests gegen die Live-Instanz.

8.Deploy – Production Nach manueller Freigabe oder bei Git-Tag: Rolling Update in Kubernetes / Compose / Cloud.

Die Reihenfolge ist klar: Was schiefgehen könnte, kommt zuerst. Build vor Test (sonst gibt's nichts zu testen), Test vor Scan (Scan dauert lange), Scan vor Push (sonst hast du kaputte Images in der Registry), Push vor Deploy. Bei einem Fehler in irgendeiner Stage bricht die Pipeline ab – „Fail Fast"-Prinzip. Mehr in CI/CD-Pipeline-Aufbau.

2) Image-Tagging – die wichtigste Disziplin

Eines der wichtigsten Themen in Docker-CI/CD ist das richtige Image-Tagging. Ein Tag ist mehr als ein Name – er kommuniziert, woher das Image kommt, in welcher Version es ist und ob es stabil ist. Eine gute Tag-Strategie spart später viele Diskussionen und Fehler bei Rollbacks:

Tag-Strategien – gut, ok, schlecht

✓ Git-SHA

Immutable, eindeutig, traceable zu Commit.

myapp:sha-a3f8b2c

✓ Semver-Version

Klare Releases, perfekt für Tags/Releases.

myapp:1.2.3

✓ Datum + Build

Chronologisch sortierbar, gut für nächtliche Builds.

myapp:2026.05.16-42

~ Branch-Name

Praktisch für Feature-Builds, nicht versionsstabil.

myapp:feature-login

~ Environment

Convenience-Tag, sollte auf konkrete Version zeigen.

myapp:staging

✗ latest

NICHT für Produktion. Bewegt sich, nicht reproduzierbar.

myapp:latest

Best Practice: jedes Image bekommt MEHRERE Tags. Der Build setzt z. B. drei Tags: myapp:sha-abc1234 (eindeutig), myapp:v2.3.0 (semantisch), myapp:main (Branch). Damit kann man später nach Bedarf den passenden Tag verwenden. Für Produktion gilt: nie auf bewegliche Tags wie main oder latest deployen – immer den unveränderlichen SHA-Tag. So ist garantiert, dass nach einem Rollback exakt die gleiche Version läuft wie vor dem Update.

3) GitHub Actions – konkretes Beispiel

GitHub Actions ist eine der verbreitetsten CI/CD-Plattformen. Hier ein vollständiger Workflow, der ein Image baut, scannt und in die GitHub Container Registry (ghcr.io) pusht – kommentiert, sodass du jeden Schritt nachvollziehst:

.github/workflows/docker.yml – komplettes Beispiel

name: Build & Push Docker Image on: push: branches: [main] tags: ['v*'] pull_request: branches: [main] env: REGISTRY: ghcr.io IMAGE_NAME: ${{ github.repository }} jobs: build: runs-on: ubuntu-latest permissions: contents: read packages: write steps: # 1. Code auschecken - uses: actions/checkout@v4 # 2. Docker Buildx setup (Layer-Cache + multi-platform) - uses: docker/setup-buildx-action@v3 # 3. Bei der Registry anmelden - name: Login to GHCR uses: docker/login-action@v3 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} # 4. Tags automatisch aus Branch/SHA/Version generieren - id: meta uses: docker/metadata-action@v5 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} tags: | type=ref,event=branch # main, develop type=sha,prefix=sha- # sha-abc1234 type=semver,pattern={{version}} # 1.2.3 bei Tag v1.2.3 # 5. Build + Push (mit GHA-Cache) - name: Build and push uses: docker/build-push-action@v5 with: context: . push: ${{ github.event_name != 'pull_request' }} tags: ${{ steps.meta.outputs.tags }} cache-from: type=gha cache-to: type=gha,mode=max # 6. Sicherheits-Scan mit Trivy - name: Trivy scan uses: aquasecurity/trivy-action@master with: image-ref: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:sha-${{ github.sha }} severity: CRITICAL,HIGH exit-code: '1' # Pipeline fail bei CVEs

Wichtige Details: secrets.GITHUB_TOKEN ist auto-generiert pro Workflow-Run (keine eigene Konfiguration nötig). type=gha nutzt den eingebauten GitHub-Cache für schnelle Wiederholungen. Trivy scannt das fertige Image auf bekannte CVEs in OS-Paketen UND Anwendungs-Dependencies – findet er CRITICAL/HIGH-Schwachstellen, bricht die Pipeline. Mehr in Docker-Sicherheit.

4) GitLab CI – das Gegenstück

GitLab hat seine eigene CI/CD-Engine mit eingebauter Container Registry. Der Workflow folgt dem gleichen Muster, mit etwas anderer Syntax:

.gitlab-ci.yml – Equivalent für GitLab

stages: - build - test - scan - deploy variables: IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA build: stage: build image: docker:24 services: - docker:24-dind # docker-in-docker für Build script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build -t $IMAGE_TAG -t $CI_REGISTRY_IMAGE:latest . - docker push $IMAGE_TAG - docker push $CI_REGISTRY_IMAGE:latest test: stage: test image: $IMAGE_TAG # Tests IM gerade gebauten Image script: - npm test - npm run lint scan: stage: scan image: aquasec/trivy:latest script: - trivy image --severity HIGH,CRITICAL --exit-code 1 $IMAGE_TAG deploy_staging: stage: deploy script: - ssh deploy@staging.firma.de "docker compose pull && docker compose up -d" only: - main deploy_prod: stage: deploy script: - kubectl set image deployment/myapp myapp=$IMAGE_TAG only: - tags when: manual # manuelle Freigabe vor Production-Deploy

GitLab-spezifisch: Predefined Variables wie $CI_REGISTRY, $CI_REGISTRY_IMAGE, $CI_COMMIT_SHORT_SHA sind automatisch verfügbar. Docker-in-Docker (dind) startet einen Docker-Daemon im CI-Job für docker build. Sicherer für Produktion: Kaniko oder Buildah als rootless Alternativen. Die Stage deploy_prod hat when: manual – ein menschlicher Klick im GitLab-UI ist nötig, bevor in Produktion deployt wird. Mehr in GitLab CI/CD.

5) Build-Caching – warum CI-Builds 10× schneller sein können

Ein erster docker build in einem frischen CI-Runner dauert lang – das Base-Image muss gepullt, alle Dependencies installiert, alle Tests ausgeführt werden. Bei jedem Push wieder von vorne wäre das eine massive Verschwendung. Lösung: Layer-Cache. Es gibt mehrere Mechanismen:

Strategie	Wie	Vorteil
Inline Cache	Cache-Metadaten werden ins Image selbst eingebettet	Funktioniert mit jeder Registry, kein zusätzliches Storage
Registry-Cache	Cache als separates Image in der Registry	Cleaner, getrennt vom Produktions-Image
GitHub Actions Cache	Eingebauter `type=gha` in BuildKit	Sehr schnell, keine Registry-Calls
S3 / Cloud Storage Cache	Cache in Object Storage	Plattformunabhängig, schnell
Persistenter Runner-Cache	Daemon-Cache am CI-Worker bleibt erhalten	Schnellste Option, aber Runner-gebunden

Genauso wichtig wie die Cache-Strategie ist eine gute Dockerfile-Struktur – die Reihenfolge der Anweisungen entscheidet, wie viel gecached werden kann. Goldene Regel: erst Dependencies kopieren und installieren, dann erst den Quellcode kopieren. Damit wird der lange npm install / pip install-Schritt nur dann neu ausgeführt, wenn sich die Abhängigkeiten ändern. Praxistypisch: Ein erster Build dauert 3-5 Minuten, alle folgenden mit gleichen Dependencies nur 20-40 Sekunden.

6) Image-Sicherheit in der Pipeline

Ein gebautes Image enthält oft hunderte Open-Source-Pakete (Base-OS-Pakete, Dependencies). Jedes davon kann eine bekannte Schwachstelle haben. Pflicht in moderner Pipeline: automatisches Vulnerability-Scanning. Die wichtigsten Tools:

Trivy (Aqua Security) – Open Source, sehr verbreitet, scannt OS und App-Dependencies. Integration in fast jede CI-Plattform.
Grype (Anchore) – ähnlich wie Trivy, oft schneller, gut mit dem SBOM-Tool Syft kombinierbar.
Snyk – kommerziell, aber sehr ausgereift, oft in größeren Unternehmen.
Docker Scout – Docker's eigenes Tool, integriert in Docker Desktop und Hub.
Harbor-eingebauter Scan (Clair / Trivy) – wenn man Harbor als Registry nutzt.

Die Frage: Was tun, wenn Schwachstellen gefunden werden? Realistisch hat jedes Image irgendwelche CVEs. Praxisansatz: Pipeline schlägt nur fehl bei CRITICAL und HIGH mit verfügbarem Fix. Niedrigere Schweregrade werden geloggt, aber nicht blockierend. Mehr zu Vulnerability-Management in CVE und CVSS.

7) Deployment-Strategien mit Containern

Nachdem das Image in der Registry liegt, bleibt die Frage: Wie kommt es in Produktion? Container-basiertes Deployment eröffnet mehrere Strategien, die in klassischer Software kaum machbar wären:

Deployment-Strategien für Container

Recreate

Alte Container stoppen, neue starten. Einfach, aber Downtime.

✓ einfach ✗ Downtime

Rolling Update

Container nacheinander austauschen, alter Pool wird leer, neuer Pool wird voll.

✓ keine Downtime ✗ alte+neue Version laufen kurz parallel

Blue-Green

Zwei komplett parallele Setups, Switch per Loadbalancer.

✓ instant rollback ✗ doppelte Ressourcen

Canary

5 %, dann 25 %, dann 100 % des Traffics auf neue Version.

✓ Risiko minimiert ✗ komplex zu orchestrieren

In Kubernetes ist RollingUpdate der Standard – die Plattform tauscht Pods nach und nach aus, mit konfigurierbaren maxUnavailable und maxSurge-Parametern. Canary und Blue-Green brauchen meist Service-Mesh-Komponenten (Istio, Linkerd) oder Ingress-Controller mit Traffic-Splitting. Bei Docker Compose ist meist nur Recreate oder ein einfaches Rolling per Skript möglich. Mehr in Deployment-Strategien.

Zusammenfassung

Docker-CI/CD-Pipelines folgen typisch acht Stages: Source → Build → Test → Scan → Tag → Push → Deploy Staging → Deploy Production. Tests laufen IM Container für identische Umgebung. Tag-Strategien: Git-SHA (unveränderlich), Semver-Versionen, Datums-Tags – mehrere Tags pro Image. latest nie in Produktion. GitHub Actions und GitLab CI sind die zwei häufigsten Plattformen; beide bieten Docker-Login, Build mit Layer-Cache, Push in Registry, Image-Scan, Deployment-Stages. Build-Caching (GHA-Cache, Registry-Cache, Inline-Cache) macht Folge-Builds 10× schneller; Dockerfile-Reihenfolge entscheidend (Dependencies vor Quellcode). Sicherheits-Scanning mit Trivy/Grype/Snyk/Docker Scout in jeder Pipeline Pflicht – Pipeline schlägt fehl bei CRITICAL/HIGH-CVEs. Deployment-Strategien: Recreate (einfach, Downtime), Rolling Update (Standard in K8s), Blue-Green (Instant-Rollback), Canary (schrittweise Migration). Die Kombination Container + CI/CD ist heute Standard in praktisch allen modernen Entwicklungsteams.