In dem voran gegangen Artikel Virtualisierung wurde das Zusammenspiel zwischen Proxmox und Docker einmal kurz erläutert. Zu beiden Produkten gibt es im Netz unzählige Anleitungen und Hilfestellungen. Dieser Beitrag wird daher nicht besonders tief eintauchen, aber die Grundlagen kompakt zusammenfassen: Neben Szenarien, Installation und typischen Fragen und Fehlern.
Um es noch einmal aufzugreifen: Docker ist eine Software, die es ermöglicht, Anwendungen in Containern zu betreiben, meistens als Stack – also als Stapel verschiedener Komponenten – wie z.B. WebServer, Datenbank, PHP Instanz. Diese sind dann vollständig voneinander isoliert und im Fall eines Schadens oder der Kompromittierung scharf abgegrenzt vom Rest des Systems.
Es lassen sich die unterschiedlichsten Dienste mit Docker betreiben – welche du sonst in mehr als nur einer Cloud / SaaS betreiben würdest. Einmal aufgesetzt und das Handwerkszeugs gelernt, ist dies der nächste Schritt in die digitale Unabhängigkeit.
Da es sich grundsätzlich um lokale Installationen von Docker handelt und das GUI, wie eine WebApp, eine IP Adresse benötigt, werden an die Adresse vom Host Portnummern angehängt, um Kollisionen zu vermeiden. Im einfachsten Falle wird dann zB ein http://192.168.1.10 Aufruf an den Port 8080 vorgenommen; Docker leitet diesen aufgerufenen Port 8080 an den http Server des Stacks weiter, der unter der Port 80 erreichbar ist. So können diverse WebApps /-Server alle auf Port 80 lauschen, während diese an der lokalen IP über verschiedene Ports aufgerufen werden.
Dazu ist eine lokale Installation nicht immer gleich, drei Szenarien sind denkbar:
- Auf dem wirklich lokalen PC, welcher nach getaner Arbeit abgeschaltet wird – wenn nur die Isolierung benötigt wird zum Beispiel.
- Auf einem eigenständigen Server mit zB Linux ohne Proxmox etc im 24/7 Betrieb.
- Auf einer virtuellen Maschine oder eines LXC innerhalb Proxmox, neben vielen anderen VMs.
Einzige Voraussetzung ist, dass du die Kommandozeile auf dem Bildschirm und root-Zugriff hast; das Vorgehen, die Befehle, das Aussehen und die Fragen & Fehler sind allen Installations-Arten gleich, was eine gemeinsame Betrachtung hier ermöglicht.
Tip
Ein Stack kann auch in seinem IST-Zustand wieder verpackt und transportiert werden – zum Beispiel per USB Stick auf ein völlig anderes Netzwerk oder ein Upload zum Weiterverteilen. Und wo wir schon beim Verpacken und transportieren sind: Bitte fertige Backups an; die Daten in den einzelnen Containern sind wertvoll und anfällig zugleich bei Ausfall eines Datenträgers. Ohne Backup bist du nicht der Hausherr, du bist nur der Mieter.
Docker dir einen
Installiert wird das Ganze wie folgt:
Die Voraussetzungen schaffen und GPG-Key hinzufügen:
sudo apt update
sudo apt install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
(sudo Verwendung ist hoffentlich klar? – bei Login als root natürtlich weg lassen!)
Repository hinzufügen:
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
Anschließend Docker installieren mit:
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Wichtig: Hier installieren wir direkt das moderne Plugin (v2). Vergiss alles, was du über docker-compose (mit Bindestrich) gelesen hast. Die alte Version (v1) ist veraltet, wird nicht mehr gewartet und führt in modernen Umgebungen oft zu Konflikten oder Datenverlust, wenn man sie neben dem Plugin installiert. Das Plugin ist der Standard.
Erst einmal sollten wir die Funktionsfähigkeit von Docker überprüfen:
sudo systemctl is-active docker
# Sollte 'active' zurückgeben
Das war auch schon die Installation von Docker selbst. Wie sie sehn, sehn sie nix. Und ohne Container wird das auch so bleiben.
Sicherheit: Nicht als Root!
Ein Punkt, der oft unterschätzt wird: Standardmäßig laufen viele Docker-Container als root. Das klingt erst mal bequem, ist aber ein Sicherheitsrisiko. Wenn ein Angreifer den Container kompromittiert, hat er sofort Root-Rechte innen – und bei schlechter Konfiguration sogar Zugriff auf dein Host-System.
Die Lösung ist simpel, aber wichtig: Laufende Container sollten so wenig Rechte wie möglich haben. Bei vielen modernen Images (besonders die von linuxserver.io) reicht es, zwei Umgebungsvariablen in deiner docker-compose.yml zu setzen:
environment:
- PUID=1000
- PGID=1000
Das PUID (User ID) und PGID (Group ID) mappen den Container auf deine normale Benutzer-ID im System. So läuft der Dienst als normaler User, nicht als Root.
Bei anderen Images musst du direkt im Dockerfile oder in der YML einen User definieren:
user: "1000:1000"
Wenn ein Container als Root läuft und gehackt wird, kann der Angreifer theoretisch Dateien auf deinem Host lesen oder schreiben. Mit einem nicht-root User ist die Schadensbegrenzung viel größer.
Achtung: Nicht alle Apps unterstützen das sofort. Teste es vorsichtig. Wenn der Container nicht startet, prüfe die Logs (
docker logs). Oft fehlen dann nur die Schreibrechte auf dem Volume. Dann musst du die Berechtigungen auf dem Host anpassen:Bashsudo chown -R 1000:1000 /pfad/zu/deinem/dataDas ist kein Zwang, aber eine Empfehlung für einen sicheren Betrieb. Je weniger Rechte ein Container hat, desto geringer ist das Risiko.
Klick mich an
Wer es bunt und mit Web-Interface / GUI mag, dem sei als Einstieg direkt die Installation von Portainer empfohlen, den bringst du in diesem Fall mit docker run zum Laufen und legst vorher noch ein Volume für persistente Daten an:
docker volume create portainer_data
docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest
Nun kannst du den Portainer mit der Port-Nummer 9443 in deinem Browser erreichen. Zuerst musst du dort nun den Admin Account einrichten und dann könntest du dort los legen. Ich habe meine ersten Gehversuche in Docker im Portainer begonnen seinerzeit, bin aber dann irgendwann auf die Bedienung über die Kommandozeile (CLI) gewechselt, weil ich dies einfacher finde. Aber das ist Geschmackssache, funktionell besteht kein Unterschied. Portainer führt im Hintergrund nur den Befehlssatz von der Docker Engine selbst aus. Wohlgemerkt sind diese Befehle dann in Portainer alle auf einmal sichtbar und die Funktionalität kann überwältigend sein. Bist du hier fertig mit deinen Einstellungen für ein neuen Container (oder Stack) klickst du auf „deploy“ und der Startprozess legt los. Hier hast du ebenfalls einen guten Zugriff auf den Docker Hub und kannst diesen durchstöbern (Siehe unten).
Arbeitsvorbereitung für die CLI
Hier wirst du recht viel in den Verzeichnissen deines Linux Rechners unterwegs sein und on Top oft die Konfigurationsdateien wie docker-compose.yml oder andere YML / ENV Dateien per Hand editieren, Logfiles durchgraben. Dies bringt die eine oder andere Überlegung mit sich, speziell bei frisch aufgesetzten Rechnern / Servern:
- Filemanager für die CLI vorhanden?
- Wirf einen Blick auf den Midnight Commaner (MC), Superfile oder Yazi.
- Welcher Editor liegt dir am ehesten?
- Mcedit ist der integrierte des Midnight Commanders, für YML Datein aber zu schwer zu lesen dort. Nano als Alternative, auch Emacs oder VIM.
Du wirst diese Werkzeuge öfter brauchen als es dir jetzt auf den ersten Blick erscheint. In einem Subreddit war zu der Frage, was die Alternatiiven zum MC sind, eine wirklich dämliche Antwort dabei „lerne bash“. DAS war nicht die Frage, die Antwort ist sinnlos und überheblich zugleich. Ignoriere solche Posts einfach – wir suchen schließlich eine Lösung, die uns das Leben erleichtert. Und bei aller Liebe zu bash: MC & Co sind da eindeutig im Vorteil. Man muss sich das Leben nicht unnötig schwer machen.
Tip
Hast du nun ein Filemanager und / oder einen Editor deiner Wahl installiert, so ist hier eine weitere Überlegung angebracht – sofern du den Docker-Host in eine VM gepackt hast: Oft folgen noch weitere VMs mit Docker-Instanzen – bevor du nun deine Docker-VM mit Containern befüllst, und dabei eventuell auch mal die VM unbrauchbar machst – lege eine Kopie davon an, vielleicht machst du auch direkt ein Template draus. So hast du sämtliche Schritte mit Docker bereits abgearbeitet und dein Gespann aus Portainer und / oder Filemanager & Editor für die CLI sind auch bereits installiert.
Die Befehlskette im Überblick
Vorab empfiehlt es sich, einen zentralen Ort für die Konfiguration sämtlicher Container & Stacks festzulegen. Hier landen dann alle YML Dateien und was sonst noch dazu gehört drin. Dies könnte dein Home Verzeichnis sein wie zB /home/[deinname]/docker sein oder /srv/docker (Linux Standard Pfad für Server-Setups). Hier erstellst du dann für deinen jeweiligen Container / Stack einen Unterordner. Beim pullen von GitHub oder woher auch immer die YML Dateien kommen, befinde dich im jeweiligen Ordner und die Ablage der docker-compose.yml gelingt nachvollziehbar und vor allem wieder auffindbar.
Hinweis zu YML Dateien:
Nichts ist ärgerlicher, als wenn man im Fieber in irgendeinem Verzeichnis unterwegs war, die YML zusammen gebaut hat, alles läuft – und man den Container Prozess aus irgendwelchen Gründen hart killen muss – und für den Neustart die verdammte YML Datei nicht mehr wiederfindet.
Was im Einzelnen in den jeweiligen docker-compose.yml drin steht, welche Parameter welche Auswirkungen haben etc – dafür muss ich an die Referenz des jeweiligen Containers verweisen an dieser Stelle. Davon gibt es unzählige, und darauf kann man hier unmöglich eingehen. Zwei wichtige Eintragungen in dieser Datei kommen immer wieder vor:
Die Port-Durchreichung wie oben Beschrieben:
ports:
- 3617:1337
Beschreibt zum Beispiel, dass du in deinem Browser den Port 3617 hinter deine IP Adresse stellst um diesen Dienst zu erreichen – docker dies intern auf den Port 1337 für den Container umleitet. Dein Browser lauscht also auf 3617, während der echte Container auf 1337 lauscht – und Docker zwischen diesen beiden vermittelt sozusagen.
Die Volumes für persistente Daten (siehe ebenfalls ganz oben):
volumes:
- db-data:/var/lib/postgresql/data
damit wird die nur im Container abgelegte Datenbank dauerhaft in deinem Verzeichnisbaum auf dem PC abgelegt. Docker vergisst eingegebene Daten sonst bei Neustart des Containers. Zwar ist bei weitem nicht für alle Container ein Volume überhaupt sinnvoll, zum Beispiel wenn keine Daten anfallen. Bei vielen aber doch – suche also nach diesem Eintrag in der YML einfach mal nach, wo die Daten abgelegt werden sollen und passe dies an. Bei Video und Bilderservern sind diese Angaben hoch relevant, wie auch bei Fileservern, die in einem Container betrieben werden wie zB Samba. Findest du in so einem Fall kein volumes: Eintrag in der YML, werde skeptisch – und suche im Netz nach der passenden Einstellung.
Ab und zu wird ein Secret Key notwendig. Diesen kannst du recht simpel erzeugen mit:
openssl rand -hex 64 # 64 Bytes im Hexadezimalformat
openssl rand 1024 # 1024 Bytes im binärformat
openssl rand -base 4096 # 4096 Zeichen im Base-64 codiertem Format
Für Docker sollten 128-256 zeichen reichen, am besten aus Zeichen von 0-9 und a-f:
openssl rand -hex 128
openssl rand -hex 256
Einfach aus dem Terminal raus kopieren und in die entsprechende Zeile der docker-compose.yml kopieren, fertig. Aber Achtung: Kopiere keine echten Passwörter direkt in die YML, wenn du die Datei versionierst (z.B. mit Git). Nutze stattdessen eine .env Datei. Das ist sicherer.
Wir starten!
Bist du so weit, dass du deinen Container / Stack starten möchtest, also alle Eintragungen in der YML sind nach Anleitung erledigt und angepasst? docker compose up -d ist der richtige Befehl hierfür. -d sagt dabei lediglich, dass der Container dann detached läuft, also im Hintergrund – du deine CLI weiter nutzen kannst. je nach Umfang kann so ein UP etwas dauern. Existieren die Images für die Container noch nicht, so werden diese nun gebaut.
Wenn alles ohne Fehler gestartet ist, kannst du dir den Prozessstatus von docker ansehen:
docker ps # Zeigt alle laufenden Container
docker ps a # zeigt auch die gestoppten Container
stößt du hier auf einen Eintrag, der den Zusatz „unhealthy“ anzeigt, denn ist irgendwas mit dem Container nicht korrekt.
Diesen kannst du auf verschiedene Methoden untersuchen:
docker inspect # Als zentrales Werkzeug zur Fehlerbehebung
docker logs # zeigt die Logdateien des Containers, gut für debugging und monitoring
docker exec # führt Kommandos innerhalb des Containers aus - zum Beispiel eine root Konsole durch start von /bin/bash - auch /bin/sh, falls der Container nicht mit bash als Shell arbeitet
wenn dir bei einem der Kommandos des Bildschirm überläuft, filtere genauer mit Hilfe von | grep _suchbegriff_.
Einen Container kannst du unterschiedliche stoppen:
docker stop # sauberer Stop, Container bleibt erhalten
docker compose down # Sauberer Stop, Container und Netzwerk werden entfernt
docker compose down -v # löscht auch persistente Daten mit (Nützlich, wenn eine Datenbank beim ersten Start falsche Werte angelegt hat, die sich nicht mehr korrigieren lassen) zB - bereinigt gesamte Umgebung
docker kill # wenn der Container sich nicht anders beenden lässt - harter Stop, Container bleibt erhalten
Gestoppte Container, die du mit docker ps a findest, aber nicht mehr aktiv sind und gelöscht werden sollen, entfernst du mit:
docker rm # füge den Parameter _-f_ hinzu, um auch laufende Container zu entfernen.
einen Container neu starten tust du mit:
docker restart
Hinweis:
Es gibt eine ganze Latte an Containern / Stacks, die nicht so ohne weiteres laufen wollen, trotz eigentlich klarer YML Dateien. Dies kann frustrierend bis ermüdend sein – Stunden des docker up, docker restart & docker down können in endlose Orgien münden, ohne etwas zum Laufen zu bringen. Andere funktionieren auf Anhieb und ich habe manchmal selbst nicht verstanden, warum die mit dieser Konfiguration laufen. Deine persönliche Frust-Toleranz solltest du im Blick haben und wenn es so überhaupt nichts werden will, dich von dem einen Tool jetzt erst einmal abwenden.
Es gibt so viele im Docker-Universum für den gleichen Zweck – und andere Töchter haben auch hübsche Mütter – und sind funktionsfähiger. Schwierig wird, wenn du eine KI heran ziehen möchtest zur Bildung einer funktionsfähigen YML / ENV etc. Das kann klappen, es kann in einer Orgie enden oder es wird nie etwas. Die KI’s haben auch hier Hallus natürlich und daher wird deren Ratschlag manchmal nicht zum Ziel führen. Das merkt man daran, dass diese Modelle sich dann irgendwann wiederholen oder um Kopf und Kragen quasseln. Dann bist du in Foren zum Thema besser aufgehoben.
Updates nicht vergessen
Docker aktualisiert sich nicht von selbst. Daher solltest du in regelmäßigen Abständen prüfen, ob neue Images vorliegen. Der einfache Weg:
docker compose pull(zieht die neuen Images)docker compose up -d(startet die neuen Container)- Alte Container werden automatisch entfernt. Für den dauerhaften Betrieb gibt es Tools wie Watchtower, die das automatisch machen – aber das ist dann schon Fortgeschrittenen-Bereich.
Vertraue dabei NICHT darauf, dass die neuen Images immer funktionieren. Wie alles in der Software-Welt kann so ein Update ohne jede Erklärung auch einfach den Container zerlegen. Wenn du kein automatisches Backup erstellen lässt, denn ist jetzt der richtige Zeitpunkt für ein manuelles Backup. Dies nennt man einen „Rollback“, als eine Rolle rückwärts, im Falle eines Crashes. Und glaube mir, der wird kommen – früher als dir lieb ist.
Dank Backup lächelst du dies denn aber einfach weg und machst dich evtl. in den Foren schlau, was du nun los ist und ob ein Fix des Fehlers ansteht oder zB nur eine Einstellung in der YAML nun fehlt oder sich geändert hat.
Die Quellen für deine Container
Mit dem Stichwort Foren ist schon eine ganz wichtige Quelle für allerlei Anregungen rund um das eigene HomeLab mit Docker genannt. Der eine oder andere Subreddit ist hierzu vorhanden und gut gefüllt. Ich habe nicht mal einen Reddit Account, aber diese Foren sind offen – und mit lesen oder nachschlagen geht hier problemlos. Du wirst vermutlich den einen oder anderen konkreten ersten oder nächsten Anwendungsfall haben, den du in deinem HomeLab abbilden möchtest – oder auch gewerblich.
Hier hilft dir die KI tatsächlich als Agent für Zusammenfassungen des Internets. Frage einfach zu deinem Fall und formuliere den Prompt ein wenig wie hier:
„stelle mit eine Liste zusammen mit Heimdall und seinen Alternativen in Docker Umgebungen, dazu der geschätzte Aufwand und ob für Einsteiger oder Experten, wenn verfügbar Lizenzmodell und ob es noch gepflegt wird. Zeige mir insgesamt sechs Apps“
Die KI Antwort in diesem Fall war dann eine detaillierte Betrachtung:
Vergleichstabelle: Heimdall & Alternativen für Docker
| App | Geschätzter Aufwand | Zielgruppe | Lizenzmodell | Aktuelle Wartung |
|---|---|---|---|---|
| Heimdall | Niedrig | Einsteiger & Fortgeschrittene | Open Source (GPL-3.0) | Ja, aktiv gepflegt |
| Homarr | Niedrig bis mittel | Einsteiger & Fortgeschrittene | Open Source (MIT) | Ja, aktiv gepflegt |
| Homepage | Mittel | Fortgeschrittene | Open Source (MIT) | Ja, aktiv gepflegt |
| Dashy | Mittel | Fortgeschrittene | Open Source (MIT) | Ja, aktiv gepflegt |
| Homer Dashboard | Niedrig (nach Einarbeitung) | Einsteiger (nach Einarbeitung) | Open Source (MIT) | Ja, aktiv gepflegt |
| Flame | Sehr niedrig | Einsteiger & Fortgeschrittene | Open Source (MIT) | Ja, aktiv gepflegt |
Und dann folgte noch eine detailierte Betrachtung.
Der Docker-Hub ist die Universalquelle für über 100.000 Images unter https://hub.docker.com/ erreichbar und zeigt auch aktuelle Trends etc an.
Weiterhin gibt es diverse Webseiten, die das Thema „empfohlene Container“ oder ähnliches haben. Die Schwierigkeit hierbei dürfte ähnlich wie bei Excel sein: Du kannst alles damit machen, solltest aber wissen, was du überhaupt am Ende vor hast:
- Baust Du dir eine Medienzentrale zusammen?
- Eine Sammlung für Notizen, spannenden Webseiten oder Rezepten?
- Sind gewerbliche Anwendungen für deine Firma dein Fokus?
- Willst du deinen eigenen Webserver und eigenen Email Server betreiben?
- Experimentierst du mit Low-/Nocode Umgebungen?
- Cloud- oder Fileserver?
- usw
Die Schwarmintelligenz
Wer sich mit docker befasst und im Internet herum gräbt zu diesem Thema, der wird unweigerlich früher oder später auf die Werkzeuge docker swarm und / oder kubernetes stoßen. Diese beiden sind, vereinfacht gesagt, die nächste Stufe in einem sich immer weiter ausdehnenden Universum:
Sie erlauben die Orchestrierung, Skalierung und einheitliche Verwaltung verschiedener Docker-Nodes. Dazu werden diese in Manager- und Worker- Node definiert und sorgen dann für eine Lastverteilung und Ausfallsicherung.
Für einen Single-Node-Server ist dies jedoch Unsinn, da eine Lastverteilung nur von einer virtuellen Maschine zu einer anderen – auf dem gleichen (Proxmox-) Host stattfände. Zum anderen ist die Ausfallsicherheit in so einem Setup auch nicht gegeben. Geht dieser eine Server den Bach runter, dann sind alle VM’s gleichermaßen zum Teufel bzw für den Moment des Ausfalls nicht mehr erreichbar. Dann braucht es auch keine Redundanz, wenn die Hardware nur aus einem Node besteht.
Anders schaut es aus, wenn mindestens zwei Bare-Metal-Server vorhanden sind, die mit Docker laufen. Hier lassen sich die Themen Redundanz, Lastverteilung und Hochverfügbarkeit dann entsprechend angehen und umsetzen.
Dies ist jedoch so gar kein Spaziergang und ich würde wirklich empfehlen, sich erst einmal mit Docker selbst vernünftig vertraut zu machen.
Dazu gehört auch, nicht nur YML Dateien nach Internet-Vorlagen zu konfigurieren und ein wenig docker compose up/down auswendig zu können – sondern die Container und die Arbeitsweise dieser auch als Micro-Applications bezeichneten Infrastruktur zu verstehen. Dazu gehört eben auch das Verständnis für docker- Volumes, docker-Netzwerk sowie die Kenntnisse darüber, was welcher Container eigentlich macht bzw machen soll.
Das ist zwar kein Muss für einen „einfachen“ Docker-Betrieb, allerdings für das Orchestrieren mittels docker swarm oder kubernetes eine Grundvoraussetzung.
Fazit: So weit weg ist dein eigens Universum auch nicht
In reddits ist öfter mal etwas zu lesen, wie z.B. „ich hab jetzt den Server xy günstig geschossen und möchte mein eigenes Homelab aufbauen – welche Container könnt ihr empfehlen?“ – das mag für den einen ein legitimes Herangehen sein, für den anderen wirkt es befremdlich, erst die Hardware zu kaufen und dann zu fragen, was man damit machen könnte. Aber es zeigt hier und da den Trend, dass dies immer mal wieder gewagt wird – auch ohne viel technischen Background – und die Community meistens auch nicht abgeneigt ist, den einen oder anderen Tip zu geben.
Nur wird es auch hier, wie überall im Netz, saublöde Antworten geben von Besserwissern und vermeintlichen Experten des Selbst-Hostings – denen man an dieser Stelle direkt jede soziale Kompetenz absprechen möchte. Drüber stehen ist die Devise.
Auf keinzugriff.de werdet ihr an unterschiedlichen Stellen auch Tips oder zumindest Vergleiche zu Container-Lösungen finden, die zum Thema passen. Daher hier nun einmal der Überblick über Docker selbst und die wichtigsten Befehle / Probleme und Quellen.
Feel free – denn genau das ist es, wo keinzugriff.de hin zeigt: Die Freiheit wieder erlangen und für sich reklamieren. Den Export von Daten in US Clouds zu beenden.
Und mit Docker ist dir ein mächtiges Werkzeug an die Hand gegeben, der Hausherr über deine Daten zu bleiben. Die Nutzung liegt bei dir.
Thinkin ‚bout
