# Alpine Edge: Bleeding Edge im minimalistischen Gewand

TL;DR / Management Summary Während die meisten Admins Alpine wegen seiner stabilen Releases (z.B. v3.18) schätzen, bietet Alpine Edge einen kontinuierlichen Rolling-Release-Zweig. Er ist das Testfeld für neue Kernel-Versionen, aktuellste Compiler und brandneue Applikationen. Empfehlung: Nutzen Sie Edge für die Entwicklung von Containern, die neueste Features (wie eBPF oder spezifische Cloud-Treiber) brauchen, aber halten Sie Ihre kritische Infrastruktur auf den stabilen Zweigen.

# 1. Einführung & Architektur

Stable vs. Edge.

Alpine Stable wird ca. alle 6 Monate eingefroren und erhält nur Sicherheits-Updates. Edge hingegen wird täglich aktualisiert.

# Die Repository-Struktur (Mermaid)

graph TD
    A[Alpine Development] --> B[Edge: Main]
    A --> C[Edge: Community]
    A --> D[Edge: Testing]
    B -->|Stabilisierung| E[Stable: v3.18 Main]
    C -->|Stabilisierung| F[Stable: v3.18 Community]
    subgraph "The Bleeding Edge"
        B
        C
        D
    end

• Testing: Hier landen Pakete, die noch keine offiziellen Maintainer haben oder instabil sein könnten.

# 2. Wechsel auf Edge

Das System umstellen.

Um eine bestehende Alpine-Instanz auf Edge umzustellen, müssen die Repositories angepasst werden.

# Schritt 1: Repositories editieren

Datei: /etc/apk/repositories

# Ersetzen Sie v3.x durch 'edge'
http://dl-cdn.alpinelinux.org/alpine/edge/main
http://dl-cdn.alpinelinux.org/alpine/edge/community
# Optional:
http://dl-cdn.alpinelinux.org/alpine/edge/testing

# Schritt 2: System-Upgrade

apk update
apk upgrade --available

Das Flag --available erzwingt den Abgleich aller Pakete mit dem neuen Index, auch wenn die Versionsnummern scheinbar niedriger sind (Downgrade-Schutz).

# 3. Hybrid-Modus: Stable mit Prise Edge

Das Beste aus beiden Welten.

Oft braucht man ein stabiles System, aber nur ein spezifisches Paket aus Edge (z.B. den neuesten PHP-Interpreter).

# Repository-Tagging nutzen

Datei: /etc/apk/repositories

http://dl-cdn.alpinelinux.org/alpine/v3.18/main
@edge http://dl-cdn.alpinelinux.org/alpine/edge/main

Installation:

# Installiert nur nginx aus Edge, den Rest aus Stable
apk add nginx@edge

# 4. Day-2 Operations: Risiko-Management

Den ‘Break’ verhindern.

Da Edge rollend ist, können Paketabhängigkeiten jederzeit brechen.

• Wartung: Führen Sie vor jedem apk upgrade auf einem Edge-System einen Backup via lbu commit (Artikel 227) durch.
• Abhängigkeiten: Nutzen Sie apk info -R <paket>, um zu sehen, welche anderen Dienste durch ein Update von Core-Libraries (z.B. openssl) betroffen sein könnten.

# 5. Troubleshooting & “War Stories”

Wenn der Edge-Zweig abbricht.

# Story 1: “Der Kernel-Mismatch im Docker-Build”

Symptom: Ein Docker-Build auf Basis von alpine:edge schlägt fehl, wenn er auf einem alten Host-Kernel (z.B. CentOS 7) ausgeführt wird. Ursache: Edge nutzt oft neueste System-Calls, die von uralten Kernels noch nicht unterstützt werden. Lösung: Nutzen Sie für Builds immer einen Host, dessen Kernel mindestens so neu ist wie die Libraries im Container.

# Story 2: “Das Testing-Paket Chaos”

Symptom: Nach der Installation eines Pakets aus dem testing Repo lässt sich das System nicht mehr updaten. Ursache: Ein Paket aus testing hat eine harte Abhängigkeit zu einer instabilen Library-Version gezogen, die nun andere Pakete blockiert. Lösung: Entfernen Sie das Testing-Paket und nutzen Sie apk fix, um die Abhängigkeiten des Stable-Zweigs wiederherzustellen. Lektion: Nutzen Sie testing nur in isolierten Containern, nie auf dem Host.

# 6. Fazit & Empfehlung

• Entwicklung: Ideal für Entwickler, die moderne Toolchains brauchen.
• Produktion: Nur für mutige Admins oder wenn die Hardware (neue CPUs) es erfordert.
• Sicherheit: Edge enthält oft Patches für Sicherheitslücken, bevor sie in Stable landen.

# Anhang: Cheatsheet