Erschienen auf system-ecke.de
1. Einleitung
Die digitale Infrastruktur im Wandel
Die Art und Weise, wie wir Software entwickeln, betreiben und skalieren, hat sich in den letzten zwei Jahrzehnten fundamental verändert. Während früher jede Anwendung ihren eigenen physischen Server benötigte – mit all den damit verbundenen Kosten, dem Platzbedarf und dem Energieverbrauch – ermöglichen moderne Technologien heute eine vollkommen neue Herangehensweise an IT-Infrastruktur.
Virtualisierung und Containerisierung sind dabei keine bloßen Buzzwords aus der Marketingabteilung, sondern fundamentale Technologien, die den Betrieb moderner Rechenzentren, Cloud-Plattformen und Entwicklungsumgebungen erst möglich machen. Ob du ein Heimlabor betreibst, als Systemadministrator in einem Unternehmen arbeitest oder als Entwickler deine Anwendungen in reproduzierbaren Umgebungen testen möchtest – an diesen Konzepten führt heute kein Weg mehr vorbei.
Problemstellung: Warum diese Technologien heute unverzichtbar sind
Stell dir vor, du betreibst zehn verschiedene Dienste – einen Webserver, eine Datenbank, ein Monitoring-System, einen Mailserver und so weiter. In der klassischen Welt bedeutete das: zehn physische Server, zehn Betriebssysteminstallationen, zehn Wartungsverträge, zehn Stromkabel. Die Ressourcenauslastung lag dabei häufig bei unter 20 %, der Rest der Rechenleistung verpuffte ungenutzt.
Hinzu kommt das Problem der Abhängigkeiten: Anwendung A benötigt Python 3.8, Anwendung B setzt Python 3.11 voraus. Auf einem gemeinsamen System führt das unweigerlich zu Konflikten. Und wenn ein Dienst abstürzt oder kompromittiert wird, kann er im schlimmsten Fall das gesamte System gefährden.
Genau hier setzen Virtualisierung und Containerisierung an. Sie lösen diese Probleme durch Abstraktion, Isolation und effiziente Ressourcenteilung – und schaffen damit die Grundlage für moderne DevOps-Praktiken, Continuous Integration und Cloud-native Architekturen.
Ziel dieses Artikels
Dieser Artikel richtet sich an Technikbegeisterte, Systemadministratoren und Entwickler, die ein fundiertes Verständnis beider Technologien aufbauen möchten. Du wirst lernen:
- Was Virtualisierung und Containerisierung grundlegend unterscheidet
- Welche konkreten Lösungen es gibt (Proxmox VE, Hyper-V, KVM, Docker, Incus)
- Wann du welche Technologie einsetzen solltest
- Welche Sicherheitsaspekte du beachten musst
- Wie aktuelle Trends die Grenzen zwischen VMs und Containern verschwimmen lassen
Abgrenzung
Dieser Artikel behandelt die konzeptionellen Grundlagen sowie einen praxisnahen Überblick über die wichtigsten Plattformen. Detaillierte Schritt-für-Schritt-Installationsanleitungen, spezifische Konfigurationsdateien oder tiefgehende Netzwerkkonfigurationen würden den Rahmen sprengen und sind Thema separater Artikel auf system-ecke.de. Kubernetes als Container-Orchestrierungsplattform wird nur am Rande erwähnt, da es ein eigenes, umfangreiches Thema darstellt.
2. Grundlagen & Begriffe
2.1 Virtualisierung
Was ist Virtualisierung?
Virtualisierung bezeichnet die Technik, physische Hardware durch Software so zu abstrahieren, dass mehrere voneinander isolierte Systeme gleichzeitig auf derselben physischen Maschine betrieben werden können. Das Ergebnis sind sogenannte Virtuelle Maschinen (VMs) – vollständige, in sich geschlossene Computersysteme, die aus Sicht des Betriebssystems wie echte Hardware wirken.
Die zentrale Komponente dabei ist der Hypervisor (auch Virtual Machine Monitor, VMM). Er ist die Softwareschicht, die zwischen der physischen Hardware und den virtuellen Maschinen vermittelt. Er verwaltet den Zugriff auf CPU, RAM, Speicher und Netzwerk und stellt sicher, dass die VMs sich gegenseitig nicht beeinflussen.
Technisch gesehen emuliert oder paravirtualisiert der Hypervisor Hardwarekomponenten. Moderne Prozessoren von Intel (VT-x) und AMD (AMD-V) bieten spezielle Erweiterungen, die Hardwarevirtualisierung direkt auf CPU-Ebene unterstützen und damit den Overhead erheblich reduzieren.
Vorteile der Virtualisierung
Ressourcennutzung: Mehrere VMs teilen sich die physische Hardware, was die Auslastung von Servern dramatisch verbessert. Statt zehn Server mit je 10 % Auslastung betreibst du einen Server mit 80–90 % Auslastung.
Isolation: Jede VM ist vollständig von anderen VMs isoliert. Ein Absturz oder eine Kompromittierung einer VM hat keine direkten Auswirkungen auf andere VMs auf demselben Host.
Flexibilität: VMs können als Snapshots gesichert, geklont, migriert und wiederhergestellt werden. Live-Migration ermöglicht es sogar, laufende VMs ohne Downtime auf andere physische Hosts zu verschieben.
Betriebssystemunabhängigkeit: Auf einem Linux-Host können Windows-VMs laufen und umgekehrt. Das ermöglicht heterogene Umgebungen auf einheitlicher Hardware.
Nachteile der Virtualisierung
Overhead: Jede VM benötigt ein vollständiges Betriebssystem inklusive Kernel, Systemdienste und Bibliotheken. Das kostet RAM, Speicherplatz und CPU-Zeit. Eine minimale VM belegt typischerweise 512 MB bis mehrere Gigabyte RAM, noch bevor die eigentliche Anwendung startet.
Startzeit: Das Booten einer VM dauert – je nach Betriebssystem und Konfiguration – zwischen 30 Sekunden und mehreren Minuten.
Komplexität: Die Verwaltung einer virtualisierten Infrastruktur erfordert Kenntnisse in Netzwerkkonfiguration, Storage-Management und Hypervisor-Administration.
2.2 Containerisierung
Was sind Container?
Container sind eine Form der Betriebssystem-Virtualisierung. Im Gegensatz zu VMs teilen sich Container den Kernel des Host-Betriebssystems, sind aber durch Linux-Kernel-Mechanismen – insbesondere Namespaces und Control Groups (cgroups) – voneinander und vom Host isoliert.
Ein Container enthält alles, was eine Anwendung zum Laufen benötigt: den Anwendungscode, die Laufzeitumgebung, Bibliotheken und Konfigurationsdateien. Was er nicht enthält, ist ein eigener Kernel. Das macht ihn erheblich leichtgewichtiger als eine VM.
Die Idee ist nicht neu – Linux-Container (LXC) existieren seit 2008, und das Konzept der chroot-Umgebungen ist noch älter. Docker hat diese Technologie jedoch 2013 popularisiert und mit einem benutzerfreundlichen Ökosystem versehen.
Unterschied zu VMs: Leichtgewicht und Portabilität
Der fundamentale Unterschied liegt in der Abstraktionsebene:
- VMs virtualisieren Hardware → jede VM hat ihren eigenen Kernel
- Container virtualisieren das Betriebssystem → alle Container teilen den Host-Kernel
Das hat weitreichende Konsequenzen: Ein Container-Image für eine Node.js-Anwendung kann wenige Megabyte groß sein. Eine vergleichbare VM mit Ubuntu und Node.js belegt schnell mehrere Gigabyte.
Portabilität ist ein weiterer Schlüsselvorteil: Ein Container-Image, das auf deinem Entwicklungslaptop läuft, läuft identisch auf dem Produktionsserver – unabhängig von der darunterliegenden Linux-Distribution. Das löst das berühmte „Works on my machine“-Problem.
Vorteile der Containerisierung
Schneller Start: Container starten in Sekunden oder sogar Millisekunden, da kein Betriebssystem gebootet werden muss.
Effizienz: Auf einem Server, auf dem vielleicht 10–20 VMs laufen könnten, lassen sich problemlos Hunderte von Containern betreiben.
DevOps-Praxis: Container sind die Grundlage moderner CI/CD-Pipelines. Images werden gebaut, getestet und in Registries gespeichert – der gesamte Lebenszyklus einer Anwendung wird reproduzierbar und versionierbar.
Unveränderlichkeit (Immutability): Container-Images sind unveränderlich. Statt einen laufenden Container zu patchen, baut man ein neues Image und ersetzt den alten Container. Das erhöht die Zuverlässigkeit und Nachvollziehbarkeit.
2.3 Vergleich: Virtualisierung vs. Containerisierung
| Merkmal | Virtuelle Maschinen | Container |
|---|---|---|
| Abstraktionsebene | Hardware | Betriebssystem |
| Kernel | Eigener Kernel pro VM | Geteilter Host-Kernel |
| Startzeit | 30 Sek. – mehrere Min. | < 1 Sekunde – wenige Sek. |
| Image-Größe | GB-Bereich | MB-Bereich |
| RAM-Overhead | Hoch (mind. 256–512 MB pro VM) | Gering (nur Anwendung + Libs) |
| Isolation | Sehr stark (eigener Kernel) | Mittel (Kernel-Namespaces) |
| Portabilität | Eingeschränkt (Hypervisor-abhängig) | Sehr hoch |
| Betriebssystem | Beliebig (Windows, Linux, BSD) | Nur Linux (nativ) |
| Snapshot/Backup | Einfach, vollständig | Möglich, aber komplexer |
| Typische Use Cases | Legacy-Apps, Windows-Workloads, starke Isolation | Microservices, CI/CD, Cloud-native Apps |
| Verwaltungskomplexität | Mittel bis hoch | Gering bis mittel |
3. Virtualisierung mit Hypervisoren
3.1 Typ-1 vs. Typ-2 Hypervisoren
Die Welt der Hypervisoren ist in zwei grundlegende Kategorien unterteilt, die sich in ihrer Architektur und ihrem Einsatzgebiet fundamental unterscheiden.
Typ-1 Hypervisoren (Bare-Metal)
Ein Typ-1 Hypervisor läuft direkt auf der physischen Hardware, ohne ein darunterliegendes Betriebssystem. Er ist gewissermaßen das Betriebssystem. Die virtuellen Maschinen laufen direkt auf dem Hypervisor, der den Zugriff auf die Hardware verwaltet.
Beispiele: VMware ESXi, Microsoft Hyper-V (als Rolle auf Windows Server), Proxmox VE (basierend auf KVM), Xen
Vorteile:
- Geringer Overhead, da keine zusätzliche OS-Schicht vorhanden ist
- Höhere Performance und Stabilität
- Für Produktionsumgebungen und Rechenzentren konzipiert
- Direkter Hardwarezugriff ermöglicht bessere Ressourcenverwaltung
Nachteile:
- Komplexere Einrichtung
- Dedizierte Hardware erforderlich
- Weniger flexibel für Desktop-Nutzung
Typ-2 Hypervisoren (Hosted)
Ein Typ-2 Hypervisor läuft als Anwendung auf einem bestehenden Host-Betriebssystem. Das Host-OS verwaltet die Hardware, der Hypervisor läuft darüber und erstellt VMs.
Beispiele: Oracle VirtualBox, VMware Workstation, Parallels Desktop (macOS)
Vorteile:
- Einfache Installation auf bestehenden Systemen
- Ideal für Entwicklung, Testing und Heimlabore
- Keine dedizierte Hardware notwendig
- Benutzerfreundlich
Nachteile:
- Höherer Overhead durch zusätzliche OS-Schicht
- Geringere Performance im Vergleich zu Typ-1
- Ressourcen werden mit dem Host-OS geteilt
- Nicht für Produktionsumgebungen geeignet
Hinweis: Die Grenze zwischen Typ-1 und Typ-2 ist in der Praxis manchmal fließend. KVM beispielsweise ist technisch gesehen ein Typ-1 Hypervisor, da er direkt in den Linux-Kernel integriert ist – wird aber auf einem vollständigen Linux-System betrieben, was ihn oberflächlich wie einen Typ-2 wirken lässt.
3.2 Proxmox VE
Architektur und Konzepte
Proxmox Virtual Environment (Proxmox VE) ist eine Open-Source-Virtualisierungsplattform, die auf Debian Linux basiert und zwei Virtualisierungstechnologien unter einer einheitlichen Oberfläche vereint:
- KVM (Kernel-based Virtual Machine): Für vollständige virtuelle Maschinen mit eigenem Kernel
- LXC (Linux Containers): Für leichtgewichtige Linux-Container
Die Architektur von Proxmox VE ist elegant: Das Debian-Basissystem dient als stabile Grundlage, KVM ist als Kernel-Modul integriert, und die gesamte Verwaltung erfolgt über eine webbasierte Oberfläche sowie eine REST-API. Proxmox bringt außerdem ein eigenes Cluster-Framework mit, das die Verwaltung mehrerer Nodes aus einer zentralen Oberfläche ermöglicht.
Ein wichtiges Konzept in Proxmox ist das Storage-System: Proxmox unterstützt eine Vielzahl von Storage-Backends – von lokalen Verzeichnissen über LVM und ZFS bis hin zu Netzwerkspeicher wie NFS, Ceph und iSCSI. Besonders ZFS ist in der Proxmox-Community sehr beliebt, da es Snapshots, Kompression und Datenintegrität auf Dateisystemebene bietet.
Einsatzgebiete
Proxmox VE ist besonders beliebt in:
- Heimlaboren und Homelabs: Günstige, leistungsfähige Alternative zu kommerziellen Lösungen
- Kleinen und mittleren Unternehmen: Vollständige Virtualisierungsplattform ohne Lizenzkosten
- Bildungseinrichtungen: Ideal zum Lernen und Experimentieren
- Hosting-Providern: Als Basis für VPS-Angebote
Vorteile
- Kostenlos und Open Source: Keine Lizenzkosten, aktive Community
- Webbasierte Verwaltung: Intuitive GUI für alle wichtigen Aufgaben
- Dual-Technologie: KVM und LXC in einer Plattform
- Cluster-Unterstützung: Mehrere Nodes zu einem Cluster zusammenfassen
- Hochverfügbarkeit (HA): Automatisches Failover bei Node-Ausfall
- Backup-Lösung: Integriertes Backup mit Proxmox Backup Server
- Aktive Community: Umfangreiche Dokumentation und Foren
Nachteile
- Enterprise-Support kostenpflichtig: Ohne Subscription gibt es keine offiziellen Enterprise-Repositories (Community-Repos sind aber verfügbar)
- Lernkurve: Für Einsteiger kann die Fülle an Optionen überwältigend sein
- Kein Windows-Support als Host: Proxmox läuft nur auf Linux (Debian-Basis)
- Begrenzte kommerzielle Unterstützung: Im Vergleich zu VMware oder Microsoft
3.3 Microsoft Hyper-V
Architektur
Microsoft Hyper-V ist Microsofts Hypervisor-Lösung und seit Windows Server 2008 R2 fester Bestandteil des Windows-Server-Ökosystems. Technisch ist Hyper-V ein Typ-1 Hypervisor: Wenn Hyper-V aktiviert wird, läuft der Hypervisor direkt auf der Hardware, und selbst das Windows-Host-Betriebssystem wird zu einer privilegierten VM (der sogenannten Management Partition oder Root Partition).
Hyper-V nutzt das Konzept der Partitionen: Die Root Partition hat direkten Zugriff auf die Hardware und stellt Dienste für die Child Partitions (die eigentlichen VMs) bereit. Für optimale Performance in VMs werden Integration Services (Treiber und Dienste) in den Gast-Betriebssystemen installiert.
Hyper-V ist in verschiedenen Varianten verfügbar:
- Als Rolle in Windows Server (Standard und Datacenter)
- Als Hyper-V Server (kostenlose, eigenständige Version – mittlerweile eingestellt)
- Als Client Hyper-V in Windows 10/11 Pro und Enterprise
Integration in Windows-Umgebungen
Hyper-V glänzt besonders in reinen Microsoft-Umgebungen:
- Active Directory Integration: VMs können nahtlos in bestehende AD-Strukturen eingebunden werden
- System Center Virtual Machine Manager (SCVMM): Zentrales Management-Tool für große Hyper-V-Umgebungen
- Windows Admin Center: Moderne, webbasierte Verwaltungsoberfläche
- Azure-Integration: Hyper-V ist die Grundlage von Microsoft Azure, was eine enge Integration ermöglicht (Azure Site Recovery, Azure Migrate)
- PowerShell-Verwaltung: Vollständige Automatisierung über PowerShell möglich
Vorteile
- Nahtlose Windows-Integration: Ideal für Windows-lastige Umgebungen
- Kostenlos mit Windows Server: Keine zusätzlichen Lizenzkosten (wenn Windows Server bereits lizenziert ist)
- Azure-Kompatibilität: Einfache Migration zwischen On-Premises und Azure
- Gute Performance für Windows-Gäste: Optimierte Treiber und Integration Services
- Bekannte Verwaltungstools: Für Windows-Admins vertraute Oberflächen
Nachteile
- Windows-zentriert: Linux-Gäste werden unterstützt, aber die Verwaltung ist weniger intuitiv als bei Linux-nativen Lösungen
- Lizenzkosten: Windows Server selbst ist kostenpflichtig
- Weniger flexibel als Proxmox/KVM: Eingeschränktere Storage-Optionen
- Vendor Lock-in: Starke Bindung an das Microsoft-Ökosystem
- Ressourcenintensiv: Die Root Partition verbraucht selbst Ressourcen
3.4 KVM (Kernel-based Virtual Machine)
Die Open-Source-Grundlage
KVM ist kein eigenständiges Produkt, sondern ein Kernel-Modul, das seit Linux 2.6.20 (2007) Teil des Linux-Kernels ist. Es verwandelt den Linux-Kernel in einen Typ-1 Hypervisor. KVM nutzt Hardware-Virtualisierungserweiterungen (Intel VT-x / AMD-V) und ermöglicht so nahezu native Performance für virtuelle Maschinen.
Technisch gesehen ist KVM ein Kernel-Modul (kvm.ko sowie kvm-intel.ko oder kvm-amd.ko), das den Linux-Kernel um Hypervisor-Fähigkeiten erweitert. Für die eigentliche Emulation von Hardware (Netzwerkkarten, Festplatten, etc.) wird QEMU verwendet. KVM und QEMU arbeiten eng zusammen: QEMU übernimmt die Emulation, KVM stellt die Hardwarebeschleunigung bereit.
Integration in Linux
KVM ist tief in das Linux-Ökosystem integriert:
- libvirt: Die Standard-Abstraktionsschicht für die Verwaltung von VMs unter Linux. libvirt bietet eine einheitliche API für verschiedene Hypervisoren (KVM, Xen, LXC, etc.)
- virsh: Das Kommandozeilenwerkzeug für libvirt. Damit lassen sich VMs erstellen, starten, stoppen und konfigurieren
- virt-manager: Eine grafische Oberfläche für libvirt/KVM, ideal für Desktop-Nutzung
- cockpit-machines: Web-basierte Verwaltung über Cockpit
Ein einfaches Beispiel für die Verwaltung mit virsh:
# Liste aller VMs anzeigen
virsh list --all
# VM starten
virsh start meine-vm
# VM herunterfahren
virsh shutdown meine-vm
# Snapshot erstellen
virsh snapshot-create-as meine-vm snapshot-nameEinsatzgebiete
KVM ist die Grundlage vieler bekannter Plattformen:
- Proxmox VE nutzt KVM für vollständige VMs
- OpenStack unterstützt KVM als primären Hypervisor
- oVirt/Red Hat Virtualization basiert auf KVM
- Viele Cloud-Provider (inklusive AWS mit Nitro) nutzen KVM-basierte Technologien
3.5 Vergleichstabelle: Proxmox VE vs. Hyper-V vs. KVM
| Feature | Proxmox VE | Microsoft Hyper-V | KVM (standalone) |
|---|---|---|---|
| Typ | Typ-1 (KVM-basiert) | Typ-1 | Typ-1 (Kernel-Modul) |
| Lizenz | Open Source (AGPLv3) | Proprietär (mit Windows Server) | Open Source (GPL) |
| Kosten | Kostenlos (Enterprise-Support optional) | Lizenzkosten für Windows Server | Kostenlos |
| Host-OS | Debian Linux | Windows Server / Windows 10/11 | Beliebige Linux-Distribution |
| GUI | Webbasiert (integriert) | Windows Admin Center / SCVMM | virt-manager / Cockpit |
| Cluster | Ja (integriert) | Ja (Failover Cluster) | Über oVirt/OpenStack |
| HA | Ja (integriert) | Ja (mit Failover Cluster) | Über externe Tools |
| Live-Migration | Ja | Ja (Live Migration) | Ja (virsh migrate) |
| Snapshots | Ja | Ja (Checkpoints) | Ja |
| Container | Ja (LXC integriert) | Nein (nur Hyper-V VMs) | Nein (nur VMs) |
| Storage-Backends | Sehr viele (ZFS, Ceph, NFS, etc.) | Begrenzt (SMB, iSCSI, FC) | Abhängig von libvirt |
| Windows-Gäste | Ja | Ja (optimal) | Ja |
| Linux-Gäste | Ja (optimal) | Ja (eingeschränkt) | Ja (optimal) |
| Community | Groß und aktiv | Microsoft-Support | Sehr groß |
| Ideal für | Homelab, KMU, Hosting | Windows-Umgebungen, Enterprise | Entwickler, Cloud-Basis |
4. Container-Lösungen
4.1 Docker
Architektur
Docker ist seit seiner Veröffentlichung 2013 zur Referenzimplementierung für Container-Technologie geworden. Die Architektur besteht aus mehreren Komponenten:
Docker Daemon (dockerd): Der Hintergrunddienst, der auf dem Host läuft und Container verwaltet. Er empfängt Befehle über die Docker API.
Docker Client (docker): Das Kommandozeilenwerkzeug, mit dem Benutzer mit dem Daemon interagieren. Client und Daemon können auf verschiedenen Maschinen laufen.
Docker Images: Unveränderliche, schichtweise aufgebaute Vorlagen für Container. Jede Schicht (Layer) repräsentiert eine Änderung am Dateisystem. Durch dieses Layer-System werden Images effizient gespeichert und übertragen – gemeinsame Schichten werden nur einmal gespeichert.
Docker Container: Eine laufende Instanz eines Images. Container sind kurzlebig und zustandslos – ihr Zustand geht beim Löschen verloren, sofern keine Volumes verwendet werden.
Docker Volumes: Persistenter Speicher für Container, der unabhängig vom Container-Lebenszyklus existiert.
Container Registry: Ein Repository für Docker Images. Docker Hub ist die öffentliche Standard-Registry, aber private Registries (Harbor, GitLab Registry, etc.) sind in Unternehmensumgebungen üblich.
Ein typisches Dockerfile sieht so aus:
# Basis-Image
FROM node:20-alpine
# Arbeitsverzeichnis setzen
WORKDIR /app
# Abhängigkeiten installieren
COPY package*.json ./
RUN npm ci --only=production
# Anwendungscode kopieren
COPY . .
# Port freigeben
EXPOSE 3000
# Startbefehl
CMD ["node", "server.js"]Das Docker-Ökosystem
Docker Hub: Die größte öffentliche Container-Registry mit Millionen von Images. Von offiziellen Images (nginx, postgres, redis) bis hin zu Community-Images ist alles verfügbar.
Docker Compose: Ein Tool zur Definition und Verwaltung von Multi-Container-Anwendungen. Mit einer einzigen docker-compose.yml-Datei lassen sich komplexe Anwendungsstacks definieren und starten:
version: '3.8'
services:
web:
image: nginx:alpine
ports:
- "80:80"
depends_on:
- app
app:
build: .
environment:
- DATABASE_URL=postgresql://db:5432/myapp
depends_on:
- db
db:
image: postgres:15
volumes:
- postgres_data:/var/lib/postgresql/data
environment:
- POSTGRES_PASSWORD=secret
volumes:
postgres_data:Docker Swarm: Dockers natives Clustering- und Orchestrierungssystem. Einfacher als Kubernetes, aber weniger mächtig. Für kleinere Deployments durchaus eine valide Option.
Typische Use Cases
- Entwicklungsumgebungen: Reproduzierbare Entwicklungsumgebungen für Teams
- CI/CD-Pipelines: Build, Test und Deploy in isolierten Containern
- Microservices: Jeder Service läuft in seinem eigenen Container
- Lokales Testing: Datenbanken, Message Broker und andere Dienste lokal starten
- Anwendungsverteilung: Anwendungen als Images paketieren und verteilen
Vorteile
- Riesiges Ökosystem: Docker Hub, umfangreiche Tooling-Unterstützung
- Standardisierung: Docker ist de facto Standard für Container-Images (OCI-Standard)
- Einfacher Einstieg: Schnell zu lernen, gut dokumentiert
- Portabilität: Images laufen überall, wo Docker installiert ist
- DevOps-Integration: Nahtlose Integration in CI/CD-Tools (Jenkins, GitLab CI, GitHub Actions)
Nachteile
- Sicherheitsbedenken: Der Docker Daemon läuft standardmäßig als root, was ein Sicherheitsrisiko darstellt
- Rootless-Modus: Möglich, aber mit Einschränkungen
- Kein natives Windows-Container-Support auf Linux: Windows-Container benötigen einen Windows-Host
- Orchestrierung: Für große Deployments ist Kubernetes notwendig, was die Komplexität erhöht
- Daemon-Abhängigkeit: Alle Container hängen vom Docker Daemon ab – fällt er aus, sind alle Container betroffen
4.2 Incus
Entstehung: Der Nachfolger von LXD
Incus ist ein relativ junges Projekt mit einer interessanten Geschichte. LXD war ursprünglich ein Projekt von Canonical (dem Unternehmen hinter Ubuntu), das eine benutzerfreundliche Verwaltungsschicht für LXC-Container bereitstellte. 2023 entschied Canonical, LXD unter die Kontrolle von Canonical zu stellen und aus dem Linux Containers-Projekt zu entfernen.
Als Reaktion darauf wurde Incus als Community-Fork von LXD gegründet, unter der Schirmherrschaft des Linux Containers-Projekts. Incus ist der direkte Nachfolger von LXD und wird aktiv weiterentwickelt. Für Nutzer, die LXD kennen, ist der Umstieg auf Incus unkompliziert.
Architektur und Features
Incus ist mehr als nur ein Container-Manager – es ist ein System-Container- und VM-Manager. Das unterscheidet es fundamental von Docker:
System-Container vs. Anwendungs-Container:
- Docker-Container sind für einzelne Anwendungen oder Prozesse konzipiert
- Incus-Container (LXC-basiert) sind vollständige Linux-Systeminstanzen – mit Init-System, mehreren Prozessen, SSH-Zugang und allem, was ein normales Linux-System ausmacht
Incus unterstützt zwei Arten von Instanzen:
- Container: LXC-basierte System-Container
- Virtuelle Maschinen: QEMU/KVM-basierte VMs
Beide werden über dieselbe API und dieselben Befehle verwaltet, was die Verwaltung vereinfacht.
Wichtige Features:
- Profile: Wiederverwendbare Konfigurationsvorlagen für Container und VMs
- Netzwerk-Management: Integrierte Bridge-Netzwerke, VLAN-Unterstützung, OVN-Integration
- Storage-Pools: Unterstützung für ZFS, Btrfs, LVM und mehr
- Snapshots und Backups: Einfache Snapshot-