# Alpine in Docker: Das Fundament moderner Microservices

TL;DR / Management Summary Wer heute “Docker” sagt, meint oft insgeheim Alpine. Mit einer Basisgröße von nur ca. 5 MB hat Alpine Linux den Markt der Container-Basis-Images erobert. Es ist die radikale Abkehr von “fettem” Ubuntu- oder CentOS-Unterbau. In diesem Modul lernen wir, wie wir Alpine als sichere und performante Basis für unsere Applikationen nutzen und dabei die Stolperfallen der musl libc elegant umgehen.

# 1. Einführung & Architektur

Warum Alpine der Standard ist.

Container sollen flüchtig, schnell und sicher sein. Alpine erfüllt alle drei Kriterien perfekt.

# Der Größenvergleich (Mermaid)

graph LR
    A[Ubuntu Base Image] -->|75 MB| B[Disk Usage]
    C[Debian Slim] -->|30 MB| B
    D[Alpine Linux] -->|5 MB| B
    subgraph "Attack Surface"
        A --- E[High: ~500 Packages]
        C --- F[Medium: ~150 Packages]
        D --- G[Low: ~15 Packages]
    end

# 2. Das perfekte Dockerfile mit Alpine

Layer-Hygiene.

# Beispiel: Eine Python-App

# Nutzen Sie immer spezifische Tags, niemals :latest
FROM alpine:3.18

# 1. System-Abhängigkeiten installieren
# --no-cache verhindert das Speichern des APK-Index
RUN apk add --no-cache python3 py3-pip gcompat

# 2. App-Code kopieren
WORKDIR /app
COPY . .

# 3. Python-Libs laden
RUN pip install --no-cache-dir -r requirements.txt

# 4. Security: Non-Root User
RUN adduser -D -u 1000 appuser
USER appuser

CMD ["python3", "main.py"]

# 3. Die musl libc Hürde

Wenn das Binary nicht startet.

Die meisten kommerziellen Binaries (z.B. Oracle DB Treiber, manche Java-Versionen) sind gegen die glibc gelinkt. Da Alpine musl nutzt, führt der Start oft zu: Error: File not found (obwohl die Datei da ist).

# Die Lösung: gcompat

# Injects a compatibility layer for glibc
apk add --no-cache gcompat

# 4. Day-2 Operations: Security & Patching

Images frisch halten.

# Automatisches Patching

Alpine-Images erhalten fast täglich Sicherheitsupdates. Nutzen Sie Tools wie Renovate oder Dependabot, um das Base-Image-Tag in Ihrem Dockerfile automatisch zu aktualisieren.

# Image Scans

Nutzen Sie Trivy, um Ihr fertiges Image zu scannen:

trivy image my-alpine-app:latest

Aufgrund der minimalen Paketanzahl wird die Liste der Schwachstellen deutlich kürzer sein als bei anderen Distributionen.

# 5. Troubleshooting & “War Stories”

Praxisfallen im Container.

# Story 1: “Der DNS-Timeout in Kubernetes”

Symptom: Pods mit Alpine-Basis brauchen 5 Sekunden für jede DNS-Abfrage. Ursache: Alpine (musl) wartet bei DNS-Anfragen auf A und AAAA Records gleichzeitig. In manchen K8s-Konfigurationen führt dies zu Paketen, die sich gegenseitig blockieren. Lösung: Setzen Sie options single-request in der /etc/resolv.conf via Kubernetes-Spec oder nutzen Sie einen neueren Alpine-Stand (3.17+), der Optimierungen hierfür enthält.

# Story 2: “Das hängende Python-Build”

Symptom: pip install dauert auf Alpine 10 Minuten, auf Ubuntu nur 10 Sekunden. Ursache: Für Alpine gibt es oft keine vorkompilierten “Wheels”. Pip muss alle C-Extensions lokal kompilieren (erfordert gcc, make, python3-dev). Lösung: Nutzen Sie Multi-Stage Builds. Bauen Sie die Libs in einem “fetten” Alpine-Builder und kopieren Sie nur die fertigen Files in das finale “schlanke” Image.

# 6. Fazit & Empfehlung

• Standard: Alpine sollte Ihre erste Wahl für jedes neue Projekt sein.
• Ausnahme: Nutzen Sie Debian-Slim, wenn Ihre Applikation zwingend glibc braucht und gcompat nicht stabil genug ist.
• Wichtig: Verwenden Sie immer die py3- Pakete von Alpine statt alles via pip zu ziehen, da diese bereits für musl optimiert sind.

# Anhang: Cheatsheet