# Multi-Platform Ops: Dienste unter Arch und Alpine bändigen

TL;DR / Management Summary Wer in hybriden Umgebungen arbeitet, muss oft zwischen Arch Linux (systemd) und Alpine Linux (OpenRC) wechseln. Während systemd die Konfiguration in statischen Unit-Files kapselt, verlässt sich OpenRC auf Shell-Skripte. In diesem Modul lernen wir, wie wir diese Unterschiede in der Automatisierung (z.B. Ansible) handhaben, wie wir Logs konsistent auswerten und wie wir sicherstellen, dass Dienste auf beiden Plattformen zuverlässig starten.

# 1. Einführung & Architektur

Zwei Philosophien im Alltag.

• Arch (systemd): “Alles aus einer Hand”. Services sind deklarativ definiert.
• Alpine (OpenRC): “Zurück zu den Wurzeln”. Services sind imperative Skripte.

# Der Management-Workflow (Mermaid)

graph TD
    subgraph "Arch Linux"
        A[systemctl] --> B[Unit: /etc/systemd/system/]
        B --> C[Log: journald]
    end
    subgraph "Alpine Linux"
        D[rc-service] --> E[Script: /etc/init.d/]
        E --> F[Log: /var/log/messages]
    end
    G[Ansible Service Module] --> A
    G --> D

# 2. Die Sprachbarriere überwinden

Befehle im Vergleich.

# 3. Automatisierung (Ansible)

Plattformübergreifend denken.

Ansible abstrahiert diese Unterschiede glücklicherweise. Das service Modul erkennt automatisch, ob systemd oder OpenRC läuft.

- name: Ensure Nginx is running
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: yes

# 4. Logging-Konsolidierung

Wo sind die Daten?

Dies ist der schwierigste Teil beim Wechsel zwischen Arch und Alpine.

# In Arch (Journald)

Logs sind binär und enthalten Metadaten.

journalctl -u nginx --since "1 hour ago"

# In Alpine (Syslog)

Logs sind Textdateien.

grep "nginx" /var/log/messages | tail -n 20

# 5. Troubleshooting & “War Stories”

Wenn die Abstraktion bricht.

# Story 1: “Der fehlende Restart-Limit”

Symptom: Ein Dienst auf Alpine stürzt in einer Schleife ab und verbraucht 100% CPU. Unter Arch wird der Dienst nach 5 Versuchen gestoppt. Ursache: systemd hat einen integrierten StartLimitBurst. OpenRC (SysV-basierte Skripte) startet Dienste oft endlos neu, wenn respawn in der inittab genutzt wird oder das Init-Skript keine interne Fehlerprüfung hat. Lösung: Bauen Sie in Ihre OpenRC-Skripte manuelle Zähler ein oder nutzen Sie das Tool Monit, um Dienste auf Alpine proaktiv zu überwachen.

# Story 2: “Dependency-Mismatch”

Symptom: Ein Datenbank-Container startet auf Arch sofort nach dem Boot, auf Alpine schlägt er fehl, weil das Netzwerk noch nicht “ready” ist. Ursache: systemds After=network-online.target ist sehr präzise. OpenRCs need net prüft oft nur, ob das Interface up ist, nicht ob eine IP via DHCP bereits zugewiesen wurde. Lösung: Nutzen Sie in Alpine das Paket ifplugd oder fügen Sie ein sleep 5 in das start_pre() Ihres Init-Skripts ein.

# 6. Fazit & Empfehlung

• Standardisierung: Nutzen Sie nach Möglichkeit Docker für Applikationen. So müssen Sie sich nicht um das Init-System des Hosts kümmern.
• Wartung: Dokumentieren Sie die Pfade zu den Logs und Configs für beide Systeme in Ihrem Team-Wiki.
• Wahl: Nutzen Sie Arch für alles, was komplexe systemd-Features (Slices, Timers) braucht. Nutzen Sie Alpine für einfache, statische Aufgaben.

# Anhang: Cheatsheet