# Arch in Docker: Wenn ‘Stable’ nicht aktuell genug ist

TL;DR / Management Summary Arch Linux im Container ist die Wahl für “Bleeding Edge” Software. Während man für Standard-Web-Apps zu Alpine (Artikel 196) greift, nutzt man das Arch-Base-Image, wenn man die absolut neuesten Compiler (GCC 13+), experimentelle Libraries oder spezifische Arch-Tools braucht. Ein Senior Admin muss jedoch wissen: Arch Images sind “fett” (~400MB) und erfordern eine konsequente Cache-Pflege innerhalb des Dockerfiles.

# 1. Einführung & Architektur

Warum Arch im Container?

Der Hauptgrund für Arch in Docker ist die Verfügbarkeit neuester Software ohne manuelles Kompilieren.

# Der Größenvergleich (Mermaid)

graph LR
    A[Alpine] -->|5 MB| B[Minimalist]
    C[Debian Slim] -->|30 MB| D[Balanced]
    E[Arch Linux] -->|450 MB| F[Feature Rich / Heavy]
    subgraph "Use Case"
        B --- G[Production Microservice]
        D --- H[Standard Enterprise App]
        F --- I[Modern Dev / Specialized Tools]
    end

# 2. Das perfekte Arch Dockerfile

Optimierung gegen den ‘Bloat’.

Arch installiert standardmäßig viele Dokumentationen und Caches mit. Im Container wollen wir das nicht.

# Beispiel: Eine moderne C++ Build-Umgebung

FROM archlinux:latest

# 1. System-Update und Installation
# Wir nutzen --noconfirm für Automatisierung
RUN pacman -Syu --noconfirm && \
    pacman -S --noconfirm gcc cmake make git

# 2. WICHTIG: Cache leeren im gleichen Layer!
RUN pacman -Scc --noconfirm

# 3. Verzeichnisse aufräumen (Dokumentation entfernen)
RUN rm -rf /usr/share/doc/* /usr/share/man/*

WORKDIR /src
COPY . .

CMD ["make", "build"]

# 3. Besonderheit: Pacman Hooks in Docker

Automatisierung verhindern.

In Arch führen Paket-Updates oft Hooks aus (z.B. Erneuerung des Initramfs). Diese sind im Container sinnlos und verlangsamen den Build.

• Lösung: Nutzen Sie das offizielle archlinux:base Image, das bereits viele unnötige Hooks deaktiviert hat.

# 4. Day-2 Operations: Image Lifecycle

Veraltete Images vermeiden.

Da Arch ein Rolling Release ist, veralten Images extrem schnell. Ein Image, das vor 3 Monaten gebaut wurde, hat hunderte Sicherheitslücken.

# Automatisierte Rebuilds

Stellen Sie sicher, dass Ihre CI/CD Pipeline (Artikel 209) das Arch-Image mindestens wöchentlich neu baut, auch wenn sich Ihr Code nicht geändert hat.

# In der Pipeline
docker build --pull -t my-arch-app:latest .

Das Flag --pull erzwingt das Herunterladen der neuesten archlinux:latest Basis.

# 5. Troubleshooting & “War Stories”

Wenn der Roll-over wehtut.

# Story 1: “Der GPG-Key Fail in der CI”

Symptom: Der Docker-Build bricht bei pacman -Syu mit Signaturfehlern ab. Ursache: Das Base-Image auf Docker Hub wurde vor Wochen aktualisiert, der lokale Keyring im Container ist aber abgelaufen. Lösung: Updaten Sie erst den Keyring und dann das System: RUN pacman -Sy --noconfirm archlinux-keyring && pacman -Su --noconfirm.

# Story 2: “Dependency Conflict durch pacman -Sy”

Symptom: Ein Admin fügt eine Zeile RUN pacman -Sy curl in ein bestehendes Dockerfile ein. Das Image baut, aber die App stürzt mit Library-Fehlern ab. Ursache: Teil-Update (Partial Upgrade). curl hat eine neuere Library-Abhängigkeit gezogen, der Rest des Systems blieb alt. Lösung: Niemals -Sy allein nutzen. Immer -Syu verwenden, um den konsistenten Stand des Rolling Release zu wahren.

# 6. Fazit & Empfehlung

• Einsatz: Ideal für Build-Server (CI-Runner), Machine Learning Workflows (neueste CUDA-Libs) und moderne C++/Rust Entwicklung.
• Performance: Die I/O-Last beim Bauen ist durch das Entpacken der großen ZST-Archive höher als bei Alpine.
• Wahl: Wenn Größe keine Rolle spielt, aber Aktualität alles ist, gibt es keine Alternative zu Arch in Docker.

# Anhang: Cheatsheet