10 — Container und Orchestrierung

Teil D — Wie man betreibt. Zurück zur Übersicht.

Die technischen Grundlagen — Namespaces, cgroups, Image-Schichten, Podman gegen Docker — behandelt die Container-Unterlage dieses Wikis ausführlich. Dieses Kapitel beschränkt sich auf die Frage: Was leisten Container für die Auslieferungskette?

Die Antwort besteht aus vier Punkten, die alle an früher Gesagtes anknüpfen:

Die Twelve-Factor App ist eine Sammlung von Regeln für Anwendungen, die in solchen Umgebungen betrieben werden sollen. Sechs davon sind für diese Unterlage unmittelbar relevant.

# Faktor III und XI in der Praxis
import logging
import os
import sys
 
logging.basicConfig(
    stream=sys.stdout,                     # XI: nach stdout, nicht in Dateien
    format='{"zeit":"%(asctime)s","stufe":"%(levelname)s","text":"%(message)s"}',
)
 
DB_HOST = os.environ["DB_HOST"]            # III: aus der Umgebung
DB_PASS = os.environ["DB_PASSWORD"]        # kein Standardwert bei Geheimnissen
LOG_LEVEL = os.environ.get("LOG_LEVEL", "INFO")

Die ehrliche Antwort lautet: seltener, als angenommen wird.

Der Sprung von Stufe 2 auf Stufe 4 lohnt sich, wenn einer dieser Punkte zutrifft:

• Der Ausfall eines einzelnen Servers ist nicht hinnehmbar.
• Die Last schwankt so stark, dass automatisch skaliert werden muss.
• Mehrere Teams brauchen abgestufte Rechte auf derselben Plattform.
• Die Anzahl der Dienste übersteigt das, was eine Person überblicken kann.

Trifft nichts davon zu, ist Stufe 2 die wirtschaftlichere Wahl. Ein einzelner Server mit Quadlet-Units, Git-Anbindung und einem Deployment-Skript liefert Reproduzierbarkeit, Versionierung, Rollback und saubere Protokollierung — mit Werkzeugen, die jeder Linux-Administrator bereits beherrscht.

Nur so viel, wie zur Einordnung nötig ist.

Das Grundprinzip ist eine Regelschleife: Man beschreibt den Sollzustand, ein Controller vergleicht laufend mit dem Ist-Zustand und korrigiert. Genau dasselbe Denkmuster wie bei Ansible aus Kapitel 9 — nur dauerhaft statt einmalig.

OpenShift ist Kubernetes mit integrierter Registry, Weboberfläche, Pipelines, Monitoring und deutlich strengeren Sicherheitsvorgaben. Der wichtigste praktische Unterschied: Container laufen dort mit einer zufällig zugewiesenen Benutzerkennung und niemals als Root. Ein Image, das unter OpenShift läuft, läuft überall — umgekehrt gilt das nicht.

Containerfile

# ---------- Stufe 1: Abhängigkeiten ----------
FROM registry.access.redhat.com/ubi9/python-312:latest AS builder

WORKDIR /build
COPY requirements.txt .
RUN pip install --no-cache-dir --target=/build/deps -r requirements.txt

# ---------- Stufe 2: Laufzeit ----------
FROM registry.access.redhat.com/ubi9/python-312-minimal:latest

LABEL org.opencontainers.image.title="KFZ-Rechner" \
      org.opencontainers.image.vendor="Beispiel AG"

WORKDIR /app
COPY --from=builder /build/deps /app/deps
COPY src/ ./src/

ENV PYTHONPATH=/app/deps \
    PYTHONUNBUFFERED=1 \
    LOG_LEVEL=INFO

# Gruppe 0 statt fester UID -> läuft auch unter OpenShift
RUN chgrp -R 0 /app && chmod -R g=u /app
USER 1001

EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD python -c "import urllib.request,sys; \
      sys.exit(0 if urllib.request.urlopen('http://localhost:8080/health').status==200 else 1)"

CMD ["python", "-m", "src.server"]

~/.config/containers/systemd/kfz-rechner.container

[Unit]
Description=KFZ-Prämienrechner
After=network-online.target

[Container]
Image=registry.intern/kfz-rechner:2.5.0
ContainerName=kfz-rechner
PublishPort=127.0.0.1:8081:8080
Environment=UMGEBUNG=produktion
Environment=LOG_LEVEL=INFO
Secret=kfz_db_passwort,type=env,target=DB_PASSWORD
Volume=/srv/kfz/daten:/app/daten:Z
ReadOnly=true
Tmpfs=/tmp:rw,size=32m
NoNewPrivileges=true
DropCapability=ALL
Memory=512m
AutoUpdate=registry

[Service]
Restart=always
TimeoutStartSec=90

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user start kfz-rechner.service
systemctl --user status kfz-rechner.service
journalctl --user -u kfz-rechner.service -f

Aufgaben:

1. Bring den Dienst zum Laufen und prüfe nach einem Neustart des Servers, dass er von selbst wiederkommt.
2. Ergänze sauberes Herunterfahren auf SIGTERM im Python-Code und beobachte den Unterschied bei systemctl restart.
3. Vergleiche die Größe des Images mit und ohne Multi-Stage-Build.
4. Ergänze den Bau des Images in der Pipeline aus Kapitel 7 und rolle das Ergebnis über das Blue/Green-Skript aus Kapitel 8 aus.
5. Erzeuge mit podman kube generate kfz-rechner eine Kubernetes-Beschreibung und sieh sie dir an. Was fehlt darin für den Produktivbetrieb?

Wie viele Dienste betreibt ihr, und wie oft ist im letzten Jahr ein Server so ausgefallen, dass ein Cluster geholfen hätte?

Die zweite Zahl ist meist kleiner, als die Diskussion über Kubernetes vermuten lässt.

Weiter mit Kapitel 11 — GitOps