# CI/CD Masterclass: Arch und Alpine im Zusammenspiel

TL;DR / Management Summary In einer modernen DevOps-Pipeline erfüllen Arch Linux und Alpine Linux unterschiedliche, aber sich ergänzende Rollen. Während wir Arch Linux nutzen, um unsere Software gegen die neuesten Compiler und Bibliotheken zu testen (Forward Compatibility), dient Alpine als Basis für das finale, gehärtete Produktions-Image. In diesem Modul lernen wir, wie wir diese “Two-Stage” Strategie implementieren, um Fehler früh zu finden und maximale Sicherheit beim Deployment zu garantieren.

# 1. Einführung & Architektur

Die duale Pipeline.

• Arch (Stage: Test): Findet Bugs, die durch kommende Library-Updates entstehen (Rolling Release).
• Alpine (Stage: Release): Garantiert einen minimalen Footprint und höchste Sicherheit in der Produktion.

# Die Architektur-Pipeline (Mermaid)

graph LR
    A[Code Commit] --> B[CI Stage: Arch Test]
    B -->|Bugs found?| C{Fix Code}
    B -->|Passed| D[CI Stage: Alpine Build]
    D --> E[Artifact: Production Image]
    E --> F[Security Scan: Trivy]
    F -->|Clean| G[Deploy to Prod]
    subgraph "The Testing Grounds"
        B
    end
    subgraph "The Fortress"
        D
        E
    end

# 2. Arch in der CI: Die Frühwarn-Station

Bugs finden, bevor sie in Produktion landen.

Nutzen Sie Arch-Runner, um sicherzustellen, dass Ihre Applikation mit dem nächsten glibc oder openssl Update funktioniert.

# GitLab Beispiel
test_next_gen:
  image: archlinux:latest
  script:
    - pacman -Syu --noconfirm base-devel
    - ./run_unit_tests.sh

# 3. Alpine in der CI: Die Image-Fabrik

Optimierung für den Betrieb.

In dieser Stage wird das Multi-Stage Build (Artikel 212) ausgeführt.

# Security Scanning

Jedes Alpine-Image muss durch einen Scanner laufen.

# Trivy scannt das Image gegen die CVE-Datenbank
trivy image --severity CRITICAL,HIGH my-app:alpine

# 4. Day-2 Operations: Artefakt-Promotion

Vom Build zur Registry.

Images sollten niemals direkt in die Produktions-Registry gepusht werden.

1. Registry dev: Build-Ergebnis.
2. Registry qa: Nach erfolgreichen Integrations-Tests.
3. Registry prod: Nach Bestätigung durch das Security-Team.

Nutzen Sie Skopeo (Artikel 106) für den Transfer zwischen diesen Registries, ohne die Images lokal zu speichern.

# 5. Troubleshooting & “War Stories”

Wenn Welten kollidieren.

# Story 1: “Der Arch-Pass, Alpine-Fail”

Symptom: Die Tests auf Arch Linux verlaufen perfekt, aber das Image auf Alpine-Basis stürzt beim Start mit Segmentation Fault ab. Ursache: Inkompatibilität zwischen glibc (Arch) und musl (Alpine). Oft verursacht durch fehlerhaftes Error-Handling bei Memory Allocation oder DNS-Timeouts. Lösung: Nutzen Sie für die finalen Unit-Tests ebenfalls Alpine, um musl-spezifische Probleme frühzeitig zu erkennen. Arch dient nur als Test für zukünftige globale Standards.

# Story 2: “Das verwaiste Image”

Symptom: Ein Image wird in die Produktion gepusht, aber es gibt keine Informationen darüber, aus welchem Git-Commit es stammt. Ursache: Fehlende Metadaten. Lösung: Nutzen Sie Docker Labels, um Commit-Hash, Build-Zeit und Pipeline-ID fest im Image zu verankern: LABEL org.opencontainers.image.revision=$CI_COMMIT_SHA.

# 6. Fazit & Empfehlung

• Zweigleisig fahren: Nutzen Sie die Aktualität von Arch zur Qualitätskontrolle und die Schlankheit von Alpine für das Deployment.
• Signierung: Integrieren Sie die digitale Signierung (Artikel 210) fest in die Alpine-Build-Stage.
• Wartung: Halten Sie Ihre CI-Basis-Images (Runner) immer aktuell (docker build --pull).

# Anhang: Cheatsheet