07 — Pipeline in der Praxis

Teil C — Wie man ausliefert. Zurück zur Übersicht.

Eine Pipeline ist eine Beschreibung. Ausgeführt wird sie von einem Runner (GitLab), Agent (Jenkins) oder Runner (GitHub Actions) — einem Prozess, der Aufträge abholt und abarbeitet.

In regulierten Umgebungen ist die Frage schnell beantwortet: Selbst betriebene Runner im eigenen Netz, weil sie sonst weder an interne Registries noch an Testdatenbanken herankommen — und weil Quellcode das Haus nicht verlässt.

Ephemere Runner sind der Standard. Für jeden Auftrag entsteht ein frischer Container, der danach verworfen wird.

Ein Artefakt ist das Ergebnis des Bauvorgangs: ein Container-Image, ein Python-Rad, ein JAR, ein RPM. Es wird einmal erzeugt und in einer Registry abgelegt.

Warum eine interne Registry auch ohne eigene Images sinnvoll ist: Sie spiegelt externe Images und macht dich unabhängig von deren Verfügbarkeit, Rate Limits und Löschungen. Wer schon einmal erlebt hat, dass ein Basis-Image aus dem Netz verschwand und damit sämtliche Builds standen, richtet die Spiegelung beim nächsten Mal vorher ein.

# Nachvollziehbar: Commit, Version, Zeitpunkt
podman build \
  --label "org.opencontainers.image.revision=$CI_COMMIT_SHA" \
  --label "org.opencontainers.image.version=$CI_COMMIT_TAG" \
  --label "org.opencontainers.image.created=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --label "org.opencontainers.image.source=$CI_PROJECT_URL" \
  -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .

Diese Beschriftungen sind kein Selbstzweck. Sie beantworten im Störungsfall in einem einzigen Befehl die Frage, welcher Commit gerade produktiv läuft:

podman inspect kfz-rechner --format '{{index .Labels "org.opencontainers.image.revision"}}'

Die Pipeline braucht Zugangsdaten: für die Registry, für Zielsysteme, für Signaturschlüssel. Sie dürfen niemals im Repository stehen.

# GitLab: Variable als "masked" und "protected" anlegen
# masked   -> wird in Logs durch [MASKED] ersetzt
# protected -> nur auf geschützten Zweigen verfügbar

deploy:
  script:
    - echo "$DEPLOY_KEY" > /tmp/key && chmod 600 /tmp/key
    - ssh -i /tmp/key conops@server './deploy.sh'
  after_script:
    - shred -u /tmp/key

Bei zwanzig Projekten will niemand zwanzigmal dieselben achtzig Zeilen pflegen.

ci-vorlagen/python.yml

# Zentrale Vorlage, eigenes Repository
.python-tests:
  image: python:3.12-slim
  before_script:
    - pip install --quiet -r requirements.txt
  script:
    - ruff check src/ tests/
    - pytest --cov=src
  cache:
    key:
      files: [requirements.txt]
    paths: [.cache/pip]

.gitlab-ci.yml

include:
  - project: 'betrieb/ci-vorlagen'
    ref: v2.1.0                 # feste Version, nicht "main"
    file: '/python.yml'

unit-tests:
  extends: .python-tests
  stage: testen

Bei GitHub Actions leisten Reusable Workflows und Composite Actions dasselbe.

Wichtig ist die feste Versionsangabe. Eine eingebundene Vorlage ist fremder Code, der in deiner Pipeline mit deinen Zugangsdaten läuft. Wer ref: main schreibt, übernimmt jede Änderung ungeprüft — auch die, die jemand anders versehentlich hineingeschrieben hat.

Ein Aspekt, der in Schulungen fast immer fehlt: Die Pipeline hat Zugriff auf Quellcode, Registry und Produktivsysteme. Wer sie kontrolliert, kontrolliert die Auslieferung.

# Schlecht: beweglicher Tag
- uses: actions/checkout@v4
 
# Besser: auf den Commit festgenagelt
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

Der Angriff auf die Lieferkette ist kein theoretisches Szenario mehr — mehrere große Vorfälle der letzten Jahre liefen genau über kompromittierte Build-Prozesse. Mehr dazu in Kapitel 14.

# Parallelisieren, was unabhängig ist
stages: [pruefen, testen]

lint:
  stage: pruefen
unit-tests:
  stage: testen
integration-tests:
  stage: testen        # läuft parallel zu unit-tests
 
# Matrix: mehrere Varianten gleichzeitig
test:
  parallel:
    matrix:
      - PYTHON: ["3.11", "3.12", "3.13"]
  image: python:$PYTHON
 
# Nur bauen, was sich geändert hat
container-bauen:
  rules:
    - changes:
        - src/**/*
        - Containerfile

Was am meisten bringt, in dieser Reihenfolge: Abhängigkeiten zwischenspeichern, unabhängige Schritte parallelisieren, Container-Schichten so anordnen, dass der Cache greift (Kapitel 10), langsame E2E-Tests nachgelagert ausführen.

.gitlab-ci.yml

stages:
  - pruefen
  - testen
  - bauen
  - scannen
  - ausrollen

variables:
  IMAGE: "$CI_REGISTRY_IMAGE"
  TAG: "$CI_COMMIT_SHORT_SHA"

default:
  interruptible: true          # alter Lauf wird bei neuem Push abgebrochen
 
# ---------------------------------------------------------------
lint:
  stage: pruefen
  image: python:3.12-slim
  script:
    - pip install --quiet ruff
    - ruff check src/ tests/
    - ruff format --check src/ tests/

geheimnisse-suchen:
  stage: pruefen
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --verbose --no-git
 
# ---------------------------------------------------------------
unit-tests:
  stage: testen
  image: python:3.12-slim
  script:
    - pip install --quiet -r requirements.txt
    - pytest --junitxml=report.xml --cov=src --cov-report=xml
  artifacts:
    when: always
    reports:
      junit: report.xml

integration-tests:
  stage: testen
  image: python:3.12-slim
  services:
    - name: postgres:16
      alias: db
  variables:
    POSTGRES_PASSWORD: test
    DB_HOST: db
  script:
    - pip install --quiet -r requirements.txt
    - pytest tests/integration/ -v
 
# ---------------------------------------------------------------
container-bauen:
  stage: bauen
  image: quay.io/podman/stable
  script:
    - podman login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
    - |
      podman build \
        --label "org.opencontainers.image.revision=$CI_COMMIT_SHA" \
        --label "org.opencontainers.image.source=$CI_PROJECT_URL" \
        -t "$IMAGE:$TAG" .
    - podman push "$IMAGE:$TAG"
    - podman inspect "$IMAGE:$TAG" --format '{{.Digest}}' > digest.txt
  artifacts:
    paths: [digest.txt]
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
 
# ---------------------------------------------------------------
schwachstellen:
  stage: scannen
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 0 --severity LOW,MEDIUM "$IMAGE:$TAG"
    - trivy image --exit-code 1 --severity HIGH,CRITICAL "$IMAGE:$TAG"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
 
# ---------------------------------------------------------------
ausrollen-test:
  stage: ausrollen
  environment:
    name: test
  script:
    - ./scripts/deploy.sh test "$IMAGE@$(cat digest.txt)"
    - ./scripts/smoketest.sh https://kfz-test.intern
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Aufgaben:

1. Bring die Pipeline vollständig zum Laufen und miss die Gesamtdauer.
2. Verschiebe geheimnisse-suchen testweise in die letzte Stufe. Was ändert sich an der Rückmeldezeit?
3. Lass trivy eine kritische Schwachstelle finden — etwa mit einem absichtlich veralteten Basis-Image.
4. Baue die Vorlage aus 7.4 und lagere die Python-Stufen dorthin aus.
5. Prüfe im Protokoll, ob irgendwo ein Geheimnis unmaskiert auftaucht.

Wer könnte in deiner Umgebung eine Änderung an der Pipeline-Definition vornehmen, die beim nächsten Lauf mit Produktionsrechten ausgeführt wird — und würde das jemandem auffallen?

Weiter mit Kapitel 08 — Deployment-Strategien