Warum ich LXC bevorzuge – und Docker nur selten nutze
In Self-Hosting- und Homelab-Umgebungen scheint es heute nur noch zwei Zustände zu geben:
entweder Docker überall – oder man gilt als „stehen geblieben“.
Ich sehe das anders.
Ich nutze Container intensiv,
aber bewusst nicht Docker-zentriert.
Mein bevorzugtes Werkzeug ist LXC –
und das aus ganz praktischen Gründen.
Dieser Artikel ist keine Abrechnung,
sondern eine ehrliche Einordnung aus dem Alltag.
1. Das eigentliche Ziel: saubere Trennung
Egal ob VM, Container oder klassischer Service –
das Ziel ist immer dasselbe:
- klare Rollen
- saubere Trennung
- einfache Wartung
- nachvollziehbares Verhalten
Die Frage ist nicht:
„Was ist modern?“
Sondern:
„Was ist beherrschbar?“
2. Warum ich LXC bevorzuge
LXC ist für mich kein „Container-Hype“,
sondern leichtgewichtige Virtualisierung.
Was LXC für mich richtig gut macht:
- fühlt sich wie ein echtes System an
- vollständiges Init-System
- normale Paketverwaltung
- saubere Logs
- klare Netzwerkzuordnung
- kaum Abstraktion
Ein LXC-Container ist für mich
eine kleine VM ohne Overhead.
3. Wartbarkeit schlägt Bequemlichkeit
Ein zentraler Punkt:
Debugging.
In einem LXC-Container kann ich:
- mich einloggen
- Logs lesen wie gewohnt
- Services normal starten/stoppen
- das System verstehen
Ich brauche keine speziellen CLI-Tools,
keine Compose-Dateien
und keine Image-Magie.
Das reduziert Komplexität –
und genau das ist mir wichtig.
4. Docker – warum ich bewusst Abstand halte
Docker löst reale Probleme,
aber bringt auch neue mit.
Was mich an Docker stört:
- zusätzliche Abstraktionsschicht
- eigenes Netzwerk-Universum
- Volumes und Mounts werden schnell unübersichtlich
- Debugging oft indirekt
- starke Abhängigkeit vom Docker-Ökosystem
Für Tests oder isolierte Tools ist das okay.
Für dauerhafte, produktive Dienste
ist es mir oft zu viel Magie.
5. Infrastruktur gehört nicht in Docker
Bestimmte Dinge haben bei mir klare Grenzen.
Nicht dockerisiert sind bei mir:
- Firewall
- DNS
- DHCP
- VPN
- zentrale Netzwerkdienste
- sicherheitskritische Komponenten
Diese laufen entweder:
- direkt im LXC
- oder in dedizierten VMs
Je kritischer der Dienst,
desto weniger Abstraktion will ich.
6. Wo Docker trotzdem seine Berechtigung hat
Ich verteufle Docker nicht.
Ich begrenze es.
Docker nutze ich höchstens für:
- Tests
- kurzlebige Projekte
- fremde Software, die nur so geliefert wird
Aber:
Docker ist bei mir nie Fundament,
sondern maximal ein Werkzeug am Rand.
7. LXC + VMs: meine bevorzugte Mischung
Mein Standard-Setup:
- Hypervisor → Proxmox
- Basisdienste → LXC
- komplexe oder kritische Systeme → VM
- Experimente → LXC oder Docker (isoliert)
Damit bekomme ich:
- Übersicht
- Kontrolle
- saubere Trennung
- geringe Komplexität
8. Der größte Denkfehler
Der häufigste Fehler ist:
Container mit Docker gleichzusetzen.
Container sind ein Konzept.
Docker ist nur eine Implementierung –
und nicht zwingend die beste für jedes Szenario.
LXC ist kein Rückschritt.
Es ist eine bewusst einfachere, transparentere Lösung.
9. Fazit
Ich bin kein Docker-Gegner.
Aber auch kein Docker-All-in-Fan.
Für mich gilt:
- LXC für dauerhafte Services
- VMs für kritische Systeme
- Docker nur dort, wo es wirklich passt
Nicht weil Docker schlecht ist,
sondern weil Kontrolle, Wartbarkeit und Verständnis
für mich wichtiger sind als Bequemlichkeit.
Technik soll helfen.
Nicht verschleiern.
