In der heutigen DevOps-Landschaft spielen Container eine zentrale Rolle bei der Bereitstellung von Anwendungen. Docker als Container-Engine und Docker Compose als Tool zur Orchestrierung bilden dabei das Fundament für viele Automatisierungsworkflows. Auf Alma Linux, einer stabilen und enterprise-fähigen Linux-Distribution, die als 1:1-Klon von Red Hat Enterprise Linux fungiert, kannst du diese Tools nahtlos integrieren. Die Installation ist unkompliziert, wenn du die richtigen Schritte befolgst. Sie ermöglicht dir, Container in Produktion zu betreiben, ohne Kompatibilitätsprobleme zu riskieren.
Warum ist die Kombination aus Docker und Docker Compose auf Alma Linux besonders relevant?
Alma Linux bietet langfristigen Support und hohe Sicherheit, was für Serverumgebungen in Unternehmen entscheidend ist. Docker erlaubt die Verpackung von Anwendungen zusammen mit allen Abhängigkeiten in portable Images. Das löst das klassische Es läuft bei mir, aber nicht auf dem Server-Problem. Docker Compose geht darüber hinaus und definiert Services, Networks und Volumes in einer YAML-Datei.
Damit orchestriert du ganze Anwendungslandschaften mit wenigen Zeilen Code.
In der Praxis bedeutet das für dich als Administrator weniger manuelle Konfiguration und mehr Reproduzierbarkeit. Du kannst Entwicklung, Testing und Produktion identisch halten.
💡 Viele Junior DevOps Engineers unterschätzen, wie viel Zeit sie durch diese Tools sparen können, sobald die Basis steht. Die Kombination aus Stabilität von Alma Linux und Flexibilität von Docker schafft eine ideale Umgebung für skalierbare Infrastrukturen.
Der Artikel zielt darauf ab, dir die Installation detailliert zu erklären.
Er deckt alle notwendigen Schritte ab, von der Systemvorbereitung bis zur ersten erfolgreichen Ausführung eines Container-Stacks. Dabei bleibt der Fokus auf Praxis und Verständnis. Du erfährst nicht nur die Befehle, sondern auch die Hintergründe, warum bestimmte Konfigurationen notwendig sind.
Der Aufbau des Artikels ist so gestaltet, dass du schrittweise vorgehst.
Jeder Abschnitt baut auf dem vorherigen auf und enthält Erklärungen, Beispiele und Warnungen zu potenziellen Problemen. So baust du ein fundiertes Wissen auf, das du in realen Projekten direkt einsetzen kannst.
❗ Dieser Artikel richtet sich primär an Junior DevOps Engineers mit grundlegenden Linux-Kenntnissen. Du solltest dich mit der Kommandozeile, SSH-Verbindungen und einfachen Skripten auskennen. Wenn du neu in DevOps bist, aber Linux beherrschst, bist du hier richtig – wir bauen schrittweise auf. Für absolute Anfänger empfehle ich, erst grundlegende Linux-Tutorials zu absolvieren.
Praktisches Beispiel:
Nehmen wir an, du hast einen Alma Linux Server für ein Webprojekt. Du brauchst einen NGINX-Webserver, eine PostgreSQL-Datenbank und einen Redis-Cache. Ohne Docker würdest du alles einzeln installieren und konfigurieren, mit Risiko von Versionskonflikten. Mit Docker und Compose schreibst du eine docker-compose.yml, die die Services verknüpft, und startest den Stack. Das gesamte Setup läuft isoliert und kann mit einem Befehl heruntergefahren werden.
Damit demonstrierst du die Macht der Containerisierung in der täglichen Administration.
⚠️ Wichtig: Stelle sicher, dass dein Alma Linux System die erforderlichen Kernel-Module für Container geladen hat, um spätere Probleme zu vermeiden.
Die Vorteile dieser Installation gehen über die reine Technik hinaus. Du lernst, wie du den Docker-Dienst als Systemd-Unit verwaltest und wie du Sicherheitseinstellungen anpasst.
Der Artikel hält sich an bewährte Praktiken. Du erhältst klare Anleitungen, die du sofort umsetzen kannst.
Im nächsten Abschnitt bereiten wir das Alma Linux System vor.
Vorbereitung des Alma Linux Systems
System auf den neuesten Stand bringen
Das erste konkrete Vorgehen bei der Vorbereitung besteht darin, alle installierten Pakete auf den aktuellen Stand zu bringen. Was passiert hier? Der Paketmanager dnf lädt die neuesten Metadaten aus den offiziellen Alma Linux-Repositories und aktualisiert sämtliche Systemkomponenten, inklusive Kernel, Bibliotheken und Sicherheitsupdates. Warum machen wir das? Nur so stellst du sicher, dass die Basisumgebung stabil und kompatibel mit der Docker Engine ist. Warum ist das wichtig? Veraltete Pakete können zu Konflikten bei der späteren Installation führen, Sicherheitslücken offen lassen oder die Container-Laufzeitumgebung beeinträchtigen.
Der Befehl dafür ist einfach und direkt ausführbar.
Du loggst dich als root oder mit sudo ein und startest den Update-Prozess.
sudo dnf update -y
Dieser Aufruf lädt alle verfügbaren Updates herunter und installiert sie ohne weitere Nachfrage. Danach prüfst du mit dnf list updates ob wirklich alles aktuell ist. In der Praxis siehst du oft mehrere hundert Pakete, die aktualisiert werden, besonders auf frisch installierten Servern.
❗ Viele Admins überspringen diesen Schritt aus Zeitdruck, doch gerade bei Alma Linux als Enterprise-Distribution zahlt sich die gründliche Aktualisierung aus, weil sie langfristige Stabilität garantiert.
Nach dem Update überprüfst du den Kernel und die Systemversion.
uname -r
cat /etc/os-release
Diese Ausgaben bestätigen, dass Alma Linux 9 oder höher läuft und der Kernel mindestens Version 5.14 oder neuer ist. Das ist entscheidend, denn Docker benötigt bestimmte Kernel-Features wie cgroups v2 und OverlayFS.
Warum ist das wichtig? Ein nicht aktualisierter Kernel kann verhindern, dass Container korrekt starten oder Netzwerk- und Speicher-Isolation richtig funktionieren.
❗ Typische Fehlerquellen treten auf, wenn das Update mitten in einer laufenden Produktionslast durchgeführt wird oder wenn der Server keine Internetverbindung hat. In solchen Fällen bricht dnf ab und hinterlässt ein halb aktualisiertes System. Stelle daher immer sicher, dass die Verbindung stabil ist und plane das Update außerhalb der Hauptbetriebszeiten ein.
⚠️ Achte darauf, dass nach einem Kernel-Update ein Neustart erforderlich sein kann. Ohne Reboot bleibt der alte Kernel geladen, was zu Inkonsistenzen bei der Docker-Installation führt.
Der gesamte Vorgang dauert je nach Internetgeschwindigkeit und Anzahl der Updates zwischen fünf und zwanzig Minuten. Auf einem minimalen Alma Linux Server mit 2 vCPUs und 4 GB RAM läuft er reibungslos.
🔧 Praktisches Beispiel:
Du hast gerade Alma Linux 9 frisch installiert und möchtest Docker vorbereiten. Zuerst führst du
sudo dnf update -y
aus. Die Ausgabe zeigt Zeilen wie
Upgraded: kernel-5.14.0-xxx.el9.x86_64
Und weitere Pakete. Danach startest du:
sudo reboot
falls der Kernel aktualisiert wurde. Nach dem Neustart bestätigst du mit:
dnf check-update
Dass keine weiteren Updates ausstehen. Nun ist das System bereit für die nächsten Schritte.
In einer realen Umgebung wie einem Hetzner-Server oder einem Proxmox-Host hast du damit die Grundlage geschaffen, um Docker ohne Fehlermeldungen zu installieren. Das Beispiel zeigt, wie ein kurzer Befehl langfristig Probleme vermeidet und die Container-Performance optimiert.
In Produktionsumgebungen führst du zusätzlich ein Backup der Konfigurationsdateien durch, bevor du aktualisierst.
sudo rsync -a /etc/ /root/backup-etc-$(date +%Y%m%d)/
Das schützt vor unvorhergesehenen Konfigurationsänderungen durch Updates. Die Aktualisierung stellt außerdem sicher, dass alle Abhängigkeiten wie containerd oder runc auf dem neuesten Stand sind, die Docker später benötigt.
Du siehst, dieser Schritt ist keine bloße Formalität, sondern der Grundstein für eine zuverlässige Container-Infrastruktur. Er minimiert Risiken und schafft die Voraussetzung für eine saubere Docker-Installation.
Im nächsten Abschnitt konfigurieren wir die notwendigen Abhängigkeiten und das offizielle Repository.
Abhängigkeiten installieren
Nachdem das System aktualisiert ist, installierst du die notwendigen Abhängigkeiten. Was passiert hier? Der Paketmanager dnf lädt und installiert spezielle Werkzeuge, die das Hinzufügen externer Repositories ermöglichen und Konflikte mit vorinstallierten Container-Tools vermeiden. Warum machen wir das? Alma Linux liefert standardmäßig Podman und Buildah aus, die mit der offiziellen Docker Engine kollidieren können.
Warum ist das wichtig? Ohne diese Vorbereitung scheitert die spätere Repository-Konfiguration oder es entstehen Versionskonflikte, die den gesamten Container-Stack instabil machen.
Der zentrale Befehl installiert zuerst das dnf-plugin-core-Paket.
sudo dnf install -y dnf-plugins-core
Dieses Paket stellt den Befehl dnf config-manager bereit, den du später für das Docker-Repository brauchst. In vielen Alma Linux-Installationen ist es noch nicht vorhanden, deshalb holst du es jetzt nach. Gleichzeitig entfernst du konkurrierende Pakete, falls sie existieren.
sudo dnf remove -y podman buildah skopeo docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-selinux docker-engine-selinux docker-engine
Der Befehl räumt auf, ohne dass du später Fehlermeldungen wie package conflicts bekommst.
💡 In der Praxis sparst du damit Stunden Debugging, weil Alma Linux als RHEL-Klon standardmäßig Red-Hat-eigene Container-Tools bevorzugt.
Danach prüfst du, ob alle benötigten Kernel-Module und Bibliotheken geladen sind. Docker benötigt unter anderem OverlayFS als Storage-Driver und cgroups v2. Mit
lsmod | grep overlay
cat /proc/filesystems | grep overlay
verifizierst du das. Fehlt etwas, lädst du die Module manuell nach. Das ist besonders relevant auf minimalen Installationen, wo nicht alles vorinstalliert ist.
Warum ist das wichtig? Docker läuft nur zuverlässig, wenn das Betriebssystem die erforderlichen Low-Level-Funktionen für Namespaces, Control Groups und Dateisystem-Layer bereitstellt. Ohne sie starten Container nicht oder verlieren Daten bei Neustarts.
❗ Häufiger Fehler ist das Ignorieren vorhandener Podman-Pakete. Dann schlägt die Docker-Installation mit kryptischen Abhängigkeits fehlern fehl. Der remove-Befehl verhindert genau das und stellt eine saubere Umgebung her.
Zusätzlich installierst du in manchen Umgebungen noch Hilfspakete für persistente Speicher und LVM, falls du später den devicemapper-Driver nutzen möchtest.
sudo dnf install -y device-mapper-persistent-data lvm2
Diese Pakete sind zwar nicht mehr zwingend für den Standard-Overlay2-Driver, aber sie schaden nicht und bereiten dich auf erweiterte Storage-Konfigurationen vor.
⚠️ Stelle sicher, dass SELinux im enforcing-Modus bleibt, es sei denn, du deaktivierst ihn explizit. Docker arbeitet mit SELinux zusammen, wenn die richtigen Policy-Module installiert sind. Ein falscher Modus führt später zu Zugriffsverweigerungen bei Volumes.
Der gesamte Vorgang ist bewusst schlank gehalten. Du installierst nur das absolut Notwendige, damit die Systemlast gering bleibt und der Server performant für Container bleibt. Auf einem typischen Alma Linux 9-Server mit 4 GB RAM und 2 vCPUs dauert die Installation weniger als eine Minute.
🔧 Praktisches Beispiel:
Du betreibst einen Alma Linux 9-Server in einer kleinen DevOps-Umgebung und willst Docker für eine CI/CD-Pipeline vorbereiten.
Zuerst führst du
sudo dnf install -y dnf-plugins-core
aus. Die Ausgabe zeigt
Installed: dnf-plugins-core-4.0.21-...
Danach räumst du mit dem remove-Befehl auf. Anschließend prüfst du mit
dnf list installed | grep -E 'podman|buildah'
ob wirklich nichts mehr vorhanden ist. Zum Abschluss lädst du
sudo modprobe overlay
und bestätigst mit
lsmod | grep overlay
dass das Modul aktiv ist. In dieser realen Konfiguration auf einem Hetzner Cloud-Server hast du jetzt eine saubere Basis, auf der später Docker Engine und Compose ohne Konflikte laufen. Das Beispiel zeigt, wie wenige Befehle eine stabile Grundlage für produktive Container-Workloads schaffen.
Du siehst, diese Abhängigkeiten sind kein Selbstzweck, sondern die technische Voraussetzung für eine konfliktfreie Docker-Installation. Sie sorgen dafür, dass das System bereit ist für externe Paketquellen und die spezifischen Anforderungen der Container-Engine.
Als nächstes werden wir die offizielle Docker-Repository konfigurieren.
Docker-Repository konfigurieren
Nachdem die Abhängigkeiten nun installiert sind, konfigurierst du das offizielle Docker-Repository. Was passiert hier? Der Befehl dnf config-manager fügt eine neue Repository-Datei unter /etc/yum.repos.d/ hinzu, die auf die Docker-Pakete von download.docker.com verweist. Warum machen wir das? Alma Linux verwendet standardmäßig nur seine eigenen Repositories, in denen keine aktuellen Docker-Versionen enthalten sind. Warum ist das wichtig? Nur über das offizielle Repository erhältst du signierte, kompatible Pakete der Docker Engine, die regelmäßig gepatcht und auf die aktuelle RHEL-Basis abgestimmt sind.
Der entscheidende Befehl lautet:
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
Er erstellt die Datei /etc/yum.repos.d/docker-ce.repo.
Danach aktualisierst du den Cache mit
sudo dnf makecache --refresh
Das stellt sicher, dass dnf die neuen Metadaten kennt. Die Repository-Datei enthält mehrere Abschnitte für docker-ce, docker-ce-cli und containerd.io. Jeder Abschnitt definiert BaseURL, GPG-Key und Enabled-Status.
Du kannst die Datei einsehen mit
cat /etc/yum.repos.d/docker-ce.repo
Dort siehst du Zeilen wie
baseurl=https://download.docker.com/linux/rhel/$releasever/$basearch/stable
und den GPG-Key-Pfad.
💡 Der stabile Channel ist für Produktionsumgebungen die richtige Wahl, weil er nur getestete Releases liefert und keine experimentellen Features.
Docker signiert alle Pakete mit einem GPG-Schlüssel. Deshalb importierst du diesen Schlüssel explizit, damit dnf die Pakete vertraut.
Der Befehl dafür lautet:
sudo rpm --import https://download.docker.com/linux/rhel/gpg
Ohne diesen Schritt würde dnf bei der späteren Installation mit GPG key verification failed abbrechen.
❗ Ein häufiger Fehler ist das Vergessen des
--add-repo-Befehls oder das manuelle Bearbeiten der Repo-Datei ohnednf config-manager. Das führt zu falschen URLs oder fehlenden Metadaten und verhindert die Installation der korrekten Paketversionen.
Die Konfiguration ist bewusst auf RHEL 9 ausgelegt, da Alma Linux 1:1-kompatibel ist. Das Repository erkennt automatisch die Version über $releasever und $basearch. Du kannst die Repo-Datei bei Bedarf anpassen, zum Beispiel indem du den enabled=1 auf 0 setzt und nur bei Bedarf aktivierst. Das minimiert unbeabsichtigte Updates.
⚠️ Achte darauf, dass kein Proxy oder Firewall den Zugriff auf download.docker.com blockiert. In vielen Unternehmensumgebungen muss der Port 443 freigegeben werden, sonst scheitert der makecache-Befehl mit Timeout-Fehlern.
Der gesamte Vorgang ist in unter einer Minute erledigt und erzeugt keine zusätzliche Systemlast. Du kannst die hinzugefügten Repositories mit
dnf repolist | grep docker
überprüfen. Die Ausgabe zeigt dann docker-ce-stable und die Anzahl der verfügbaren Pakete.
Warum ist das wichtig? Das offizielle Repository garantiert, dass du immer die neueste, vom Docker-Team gepflegte Version bekommst und nicht auf veraltete oder kompilierte Pakete aus Drittquellen zurückgreifen musst. Das reduziert Sicherheitsrisiken und vereinfacht spätere Updates.
🔧 Praktisches Beispiel:
Auf einem frisch vorbereiteten Alma Linux 9-Server in einer Entwicklungs-Umgebung führst du zuerst
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
aus. Die Ausgabe bestätigt
Adding repo from: https://download.docker.com/linux/rhel/docker-ce.repo
Danach führst du
sudo rpm --import https://download.docker.com/linux/rhel/gpg
aus und aktualisierst mit
sudo dnf makecache
Zum Abschluss prüfst du mit cat /etc/yum.repos.d/docker-ce.repo und siehst die vollständige Konfiguration mit BaseURL, GPG-Key und Enabled-Abschnitten. In dieser realen Konfiguration auf einem dedizierten Server für eine Microservices-Anwendung hast du jetzt direkten Zugriff auf docker-ce-27.3.1 und alle zugehörigen Pakete. Der Befehl dnf repolist docker-ce-stable listet über 50 Pakete auf, die ab sofort verfügbar sind. Das Beispiel zeigt, wie die Repository-Konfiguration in weniger als 60 Sekunden eine saubere Paketquelle schafft und den Weg für die eigentliche Docker-Installation ebnet.
Du siehst, diese Konfiguration ist der entscheidende Brückenschlag zwischen dem Alma Linux-Basisystem und der Docker-Welt. Sie sorgt für eine saubere, nachvollziehbare und wartbare Paketquelle, die du später mit einem einfachen dnf update pflegen kannst.
Nach dem wir nun die Vorbereitung des Alma Linux Systems abgeschlossen haben, können wir mit der Installation der Docker Engine beginnen.
Docker-Pakete installieren
Mit dem Repository konfiguriert, installierst du jetzt die Docker-Pakete. Was passiert hier? Der Paketmanager dnf lädt die neuesten Versionen von docker-ce, docker-ce-cli, containerd.io sowie der Plugins docker-buildx-plugin und docker-compose-plugin herunter und integriert sie vollständig in das Alma Linux-System. Warum machen wir das? Diese Pakete bilden die Kernkomponenten der Docker Engine, die für die Erstellung, Verwaltung und Ausführung von Containern unverzichtbar sind.
Warum ist das wichtig? Nur eine vollständige Installation aus dem offiziellen Kanal gewährleistet Kompatibilität mit dem Kernel, signierte Pakete und langfristige Wartbarkeit ohne manuelle Nachinstallationen.
Der Installationsbefehl ist bewusst umfassend gehalten, damit alle Abhängigkeiten in einem Schritt aufgelöst werden:
sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Dnf prüft zuerst die Abhängigkeiten und installiert containerd als Runtime, docker-ce als eigentliche Engine und die CLI für die Kommandozeilensteuerung. Die Plugins erweitern die Funktionalität um erweiterte Build-Prozesse und die native Compose-Unterstützung. Während der Installation siehst du Fortschrittsmeldungen wie
Installing: docker-ce-27.3.1-1.el9.x86_64
und
Running transaction check
Der Vorgang dauert je nach Internetverbindung zwischen 30 Sekunden und drei Minuten.
💡 In Produktionsumgebungen empfiehlt es sich, die genaue Version mit
--enablerepo=docker-ce-stableeinzugrenzen, falls du eine bestimmte Release für Stabilität brauchst.
Nach der Installation legt dnf automatisch die notwendigen Systemd-Unit-Dateien an und erstellt Gruppen wie docker. Du kannst die installierten Pakete sofort mit
rpm -qa | grep -E 'docker|containerd'
überprüfen. Die Ausgabe zeigt exakt die Versionen, die du nun nutzen kannst.
❗ Ein typischer Fehler tritt auf, wenn du nur
docker-ceohne die CLI oder containerd installierst. Dann startet der Daemon nicht oder Befehle wiedocker runfehlen komplett.
Die Pakete sind so aufgebaut, dass containerd die Low-Level-Container-Laufzeit übernimmt, während docker-ce die höheren API-Schichten bereitstellt. Das ermöglicht eine saubere Trennung und verbesserte Performance bei vielen parallelen Containern. Auf Alma Linux 9 passt sich die Installation automatisch an cgroups v2 und SELinux an, ohne zusätzliche Konfigurationsschritte.
Warum ist das wichtig? Eine korrekte Paketinstallation verhindert spätere Laufzeitfehler wie „daemon not responding“ oder fehlende Bridge-Networks und schafft die Grundlage für produktive Workloads.
Die Installationsroutine aktualisiert auch die GPG-Prüfungen und stellt sicher, dass zukünftige Updates über denselben Kanal laufen. Du kannst die verfügbaren Versionen vorab mit
dnf list docker-ce --showduplicates
auflisten und bei Bedarf eine ältere stabile Version wählen. Das gibt dir volle Kontrolle über den Update-Zyklus.
⚠️ Vermeide es, während der Installation andere dnf-Operationen parallel laufen zu lassen, da das zu Transaktionskonflikten führen kann. Schließe zuerst alle anderen Paketmanager-Prozesse.
Der gesamte Schritt ist auf Minimalismus ausgelegt. Du installierst nur das, was Docker wirklich braucht, und vermeidest unnötige Zusatzpakete, die die Angriffsfläche vergrößern würden. Auf einem Server mit 8 GB RAM und 4 vCPUs bleibt die Systemlast während der Installation unter 10 % CPU und der Speicherbedarf minimal.
🔧 Praktisches Beispiel:
Du betreibst einen Alma Linux 9-Server für eine kleine Entwicklungsplattform und führst den Installationsbefehl aus. Die Ausgabe beginnt mit Last metadata expiration check: 0:01:12 ago und listet dann Installing: containerd.io-1.7.25-3.1.el9.x86_64 sowie die Docker-Pakete auf.
Nach Abschluss prüfst du mit
rpm -qa | grep docker
und siehst
docker-ce-27.3.1-1.el9.x86_64
docker-ce-cli-27.3.1-1.el9.x86_64
docker-compose-plugin-2.31.0-1.el9.x86_64
Anschließend startest du
docker --version
und erhältst
Docker version 27.3.1, build ce12230
Der Befehl
docker info | grep -E 'Server Version|Storage Driver'
bestätigt Overlay2 als Driver und zeigt, dass alles korrekt integriert ist. Das Beispiel verdeutlicht, wie ein einziger dnf-Aufruf die komplette Container-Infrastruktur aktiviert und den Weg für den ersten Container-Start ebnet.
Du siehst, die Installation der Docker-Pakete ist der zentrale Meilenstein, der die Engine betriebsbereit macht. Sie verbindet das vorbereitete System mit der vollen Funktionalität von Docker und schafft eine stabile Basis für alle weiteren Schritte.
Im nächsten Abschnitt behandeln wir, wie man den Docker-Dienst startet und aktiviert.
Docker-Dienst starten und aktivieren
Nachdem du die Pakete installiert hast, startest du nun den Docker-Dienst. Was passiert hier? Systemd lädt die Unit-Datei /usr/lib/systemd/system/docker.service und startet den dockerd-Prozess als Daemon, der den Container-Runtime-Loop übernimmt. Warum machen wir das? Ohne laufenden Dienst kannst du keine Container starten, Images pullen oder Volumes mounten. Warum ist das wichtig? Der Daemon bildet das Herzstück der gesamten Engine und stellt die API für alle Docker-Befehle bereit – ein nicht gestarteter Dienst macht die komplette Installation nutzlos.
Der Befehl zum manuellen Start lautet:
sudo systemctl start docker
Er gibt keine Ausgabe zurück, wenn alles korrekt läuft. Danach aktivierst du den Dienst für den automatischen Start nach jedem Reboot mit:
sudo systemctl enable docker
Dieser Aufruf erstellt einen Symlink in /etc/systemd/system/multi-user.target.wants/docker.service. Ab sofort startet Docker bei jedem Boot ohne manuelles Eingreifen. Du überprüfst den aktuellen Status mit:
sudo systemctl status docker
Die Ausgabe zeigt Active: active (running) sowie die Haupt-PID des dockerd-Prozesses und die letzten Log-Zeilen. Mit journalctl -u docker -xe greifst du auf detaillierte Logs zu, falls etwas nicht startet.
💡 In produktiven Umgebungen kombinierst du den Enable-Befehl oft mit einem Reboot-Test, um sicherzustellen, dass die Engine nach Wartungsarbeiten automatisch hochfährt.
Der Dienst verwendet standardmäßig den Overlay2-Storage-Driver und die Bridge-Netzwerkkonfiguration. Systemd verwaltet Ressourcenlimits und Abhängigkeiten automatisch, sodass Docker erst startet, nachdem containerd und die notwendigen Kernel-Module geladen sind. Das reduziert manuelle Fehlkonfigurationen erheblich.
Warum ist das wichtig? Ein korrekt gestarteter und aktivierter Dienst garantiert Verfügbarkeit rund um die Uhr und verhindert, dass Container nach Server-Neustarts nicht mehr laufen – ein klassisches Problem in Container-Umgebungen ohne Enable.
❗ Typische Fehler entstehen, wenn SELinux oder Firewalld den Socket blockiert. Dann zeigt
systemctl status docker„Failed to start“ mit einer Permission-Denied-Meldung. In solchen Fällen hilftsudo restorecon -Rv /var/lib/dockeroder das temporäre Deaktivieren von SELinux zur Fehlersuche.
Du kannst den Dienst jederzeit stoppen mit sudo systemctl stop docker und neu starten, ohne das System neu zu booten. Das ist besonders nützlich bei Konfigurationsänderungen an /etc/docker/daemon.json. Der Befehl sudo systemctl restart docker kombiniert Stopp und Start in einem Schritt und sorgt dafür, dass laufende Container nicht abrupt terminiert werden, sondern ein Graceful-Shutdown erhalten.
⚠️ Achte darauf, dass keine anderen Container-Runtimes wie Podman parallel laufen, da sie denselben Socket
/var/run/docker.sockbeanspruchen und den Start verhindern können.
Der gesamte Vorgang benötigt nur wenige Sekunden und verursacht keine nennenswerte CPU-Last. Auf einem Alma Linux 9-Server mit aktueller Docker-Version 27.x siehst du in der Status-Ausgabe auch die integrierten Plugins für Buildx und Compose, die bereits als Teil des Dienstes geladen sind.
🔧 Praktisches Beispiel:
Du hast auf einem Alma Linux 9-Server in einer Testumgebung gerade die Pakete installiert und führst
sudo systemctl start docker
aus. Danach aktivierst du mit
sudo systemctl enable docker
Der Befehl
sudo systemctl status docker
liefert eine Ausgabe mit
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: disabled)
Active: active (running) since ...
und
Main PID: 12345 (dockerd)
Du prüfst zusätzlich mit
docker info | grep -E 'Server Version|Root Dir'
und siehst die Engine-Version sowie /var/lib/docker als Storage-Pfad. In dieser realen Konfiguration auf einem dedizierten Entwicklungs-Server startet Docker jetzt bei jedem Boot automatisch. Wenn du nun mit docker run hello-world einen ersten Testlauf startest, bestätigt dir die Ausgabe Hello from Docker! dass die Engine korrekt mit dem Kernel kommuniziert und bereit für den produktiven Einsatz ist. Das zeigt, wie zwei kurze systemctl-Befehle dein Alma Linux in einen vollwertigen Container-Host verwandeln, der ab sofort jede beliebige Applikation stabil beheimaten kann.
Du siehst, das Starten und Aktivieren des Dienstes ist der letzte technische Schritt, der die Engine vollständig betriebsbereit macht. Es verbindet die installierten Pakete mit der Systemd-Infrastruktur und sorgt für zuverlässige Verfügbarkeit.
Bevor wir Docker-Compose installieren, kommen wir zum letzten Schritt in diesem Abschnitt: dem Nicht-Root-Zugriff.
Nicht-root-Zugriff einrichten
Nachdem nun der Docker-Dienst läuft, richtest du den Nicht-root-Zugriff ein. Was passiert hier? Die Docker-Engine legt eine Unix-Socket-Datei unter /var/run/docker.sock an, die standardmäßig nur root oder Mitgliedern der Gruppe docker Zugriff gewährt. Du erstellst diese Gruppe und fügst deinen Benutzer hinzu, sodass nachfolgende Docker-Befehle ohne sudo ausgeführt werden können. Warum machen wir das? Der Daemon selbst benötigt root-Rechte für Kernel-Interaktionen, doch der tägliche Zugriff über die CLI sollte nicht mit vollen Administratorrechten erfolgen. Warum ist das wichtig? Das reduziert die Angriffsfläche erheblich, denn ein fehlerhafter oder kompromittierter Container kann sonst leicht root-Rechte auf dem Host übernehmen.
Der erste Befehl erstellt die Gruppe, falls sie noch nicht existiert:
sudo groupadd docker
Danach fügst du deinen aktuellen Benutzer hinzu:
sudo usermod -aG docker $USER
Der Schalter -aG appendet die Gruppe, ohne bestehende Gruppenmitgliedschaften zu überschreiben. Die Änderung wird erst nach einem erneuten Login wirksam. Du kannst das sofort testen, indem du dich aus- und wieder einloggst oder den temporären Gruppenwechsel mit newgrp docker ausführst. Anschließend prüfst du die Gruppenzugehörigkeit mit:
groups
Die Ausgabe sollte nun docker enthalten. Ab diesem Moment startest du Container ohne sudo, zum Beispiel mit docker run hello-world. Der Socket-Zugriff erfolgt direkt über die Gruppenrechte, und du vermeidest ständig root-ähnliche Befehle.
💡 Viele Admins belassen es bei sudo, doch in Team-Umgebungen oder CI/CD-Pipelines spart der Nicht-root-Zugriff Zeit und erhöht die Sicherheit nachhaltig.
Die Socket-Datei selbst bleibt unter root:root mit 660 Rechten, sodass nur berechtigte Nutzer schreiben können. Das verhindert unbefugten Zugriff durch gewöhnliche Benutzer.
❗ Ein häufiger Fehler ist das Vergessen des Logout nach der Gruppenänderung. Dann schlägt
docker psweiterhin mit „permission denied“ fehl, obwohl die Gruppe korrekt gesetzt ist. Ein einfachesnewgrp dockeroder vollständiger Re-Login löst das zuverlässig.
Die Einrichtung ist bewusst minimal gehalten und wirkt sich nicht auf laufende Container aus. Du kannst den Vorgang für mehrere Benutzer wiederholen, ohne den Daemon neu zu starten. In Umgebungen mit mehreren Administratoren legst du die Gruppe zentral an und verwaltest Mitglieder über /etc/group.
⚠️ Deaktiviere niemals den root-Zugriff vollständig, wenn du den Daemon später über Remote-API oder in automatisierten Skripten brauchst. Die Gruppe
dockerbleibt die empfohlene und sichere Methode.
🔧 Praktisches Beispiel:
Auf deinem Alma Linux 9-Server bist du als Benutzer devops angemeldet.
Du führst
sudo groupadd docker
aus, gefolgt von
sudo usermod -aG docker devops
Nach newgrp docker zeigt groups die Mitgliedschaft an. Dann startest du ohne sudo docker run --rm hello-world. Die Ausgabe bestätigt Hello from Docker! und beweist, dass der Socket-Zugriff funktioniert. In dieser realen Konfiguration auf einem Produktions-Server für interne Tools hast du den vollen CLI-Zugriff ohne root und kannst Skripte oder Docker-Compose-Dateien sicher ausführen.
Der Befehl ls -l /var/run/docker.sock zeigt die Rechte srw-rw---- 1 root docker, was die Gruppenbasierte Isolation verdeutlicht.
Du siehst, der Nicht-root-Zugriff ist der entscheidende Sicherheitsbaustein, der die Engine produktionsreif macht.
In diesen Abschnitt hast du nun gelernt, wie man die Docker-Engine auf Alma Linux 9 installiert und konfiguriert. Daher ist es nun Zeit uns mit Docker-Compose zu befassen, dem Werkzeug, das es dir ermöglicht, mehrere Container gleichzeitig zu starten und zu verwalten.
Docker Compose installieren
Nachdem du den Nicht-root-Zugriff eingerichtet hast, kannst du nun Docker Compose V2 als Plugin installieren. Was passiert hier? Der Paketmanager dnf lädt das offizielle docker-compose-plugin-Paket aus dem Docker-Repository herunter und platziert es automatisch unter /usr/libexec/docker/cli-plugins/docker-compose. Warum machen wir das? Die Plugin-Variante ist die empfohlene Methode seit Docker 20.10, weil sie Compose direkt in die bestehende CLI einbindet und keine separate Binärdatei erfordert.
Warum ist das wichtig? Es verhindert Versionskonflikte zwischen Docker Engine und Compose, vereinfacht Updates und sorgt dafür, dass Befehle wie docker compose up nahtlos funktionieren, ohne zusätzliche Pfad-Variablen oder Wrapper-Skripte zu pflegen.
Der Installationsbefehl ist bewusst einfach gehalten:
sudo dnf install -y docker-compose-plugin
Dnf prüft zuerst die Abhängigkeiten zum bereits installierten docker-ce und containerd, lädt dann die aktuelle Version (typischerweise 2.31.x oder höher) und integriert das Plugin. Die Ausgabe zeigt detailliert Installed: docker-compose-plugin-2.31.0-1.el9.x86_64 und bestätigt die erfolgreiche Installation. Danach ist das Plugin sofort verfügbar, ohne dass du den Docker-Daemon neu starten musst. Die Integration erfolgt über den offiziellen CLI-Plugin-Mechanismus, der das Subcommand compose in die Docker-Befehlsstruktur einhängt.
💡 Viele DevOps-Teams bevorzugen diese Methode, weil sie die Compose-Funktionalität wie ein natives Feature behandelt und die Lernkurve für neue Teammitglieder deutlich senkt.
Du kannst die Installation sofort verifizieren, indem du die Version abfragst:
docker compose version
Die Ausgabe liefert Docker Compose version 2.31.0 zusammen mit Build-Informationen. Das zeigt, dass das Plugin korrekt geladen wurde und mit der aktuellen Engine-Version kompatibel ist. Das Plugin nutzt dieselben API-Endpunkte wie der Daemon, wodurch Features wie Buildx, Watch-Mode und erweiterte Network-Optionen direkt verfügbar sind. In der Praxis bedeutet das, dass du komplexe Multi-Container-Stacks mit einer einzigen YAML-Datei definieren und mit einem Befehl starten kannst, ohne zusätzliche Tools zu installieren.
❗ Ein häufiger Fehler ist der Versuch, das veraltete docker-compose V1 parallel zu installieren. Das führt zu Namenskonflikten im PATH und unvorhersehbarem Verhalten bei compose-Befehlen. Vermeide pip- oder curl-basierte V1-Installationen auf Systemen mit dem Plugin.
Die Plugin-Architektur ist so gestaltet, dass sie die Docker-CLI erweitert, ohne den Kern zu verändern. Das Plugin lädt bei Bedarf und verwendet dieselben Berechtigungen wie der restliche Docker-Stack. Auf Alma Linux passt es sich automatisch an SELinux und cgroups v2 an, sodass keine zusätzlichen Policy-Anpassungen nötig sind. Du kannst die aktiven Plugins jederzeit mit
docker info | grep -A 10 "Plugins"
auflisten und siehst compose dort als eines der geladenen Module.
Warum ist das wichtig? In einer modernen DevOps-Umgebung reduziert die Plugin-Methode den Wartungsaufwand erheblich. Updates der Engine ziehen automatisch die passende Compose-Version nach, und du behältst eine einheitliche Toolchain für alle Container-Operationen. Das spart Zeit bei CI/CD-Pipelines, lokalen Entwicklungs-Setups und Produktions-Deployments.
Die Installation fügt nur wenige Megabyte hinzu und hat keinen messbaren Einfluss auf die Systemperformance. Sie ist ressourcenschonend und bleibt auch auf minimalen Alma Linux-Servern stabil. Du kannst das Plugin bei Bedarf später deinstallieren, ohne die Engine selbst zu beeinträchtigen.
⚠️ Achte darauf, dass der Benutzer in der docker-Gruppe ist, bevor du das Plugin testest. Andernfalls schlägt der erste compose-Befehl mit einer Socket-Permission-Fehlermeldung fehl, obwohl die Engine läuft.
Die Plugin-Variante unterstützt alle aktuellen Compose-Spezifikationen bis Version 3.8 und höher und integriert sich nahtlos mit Features wie secrets, configs und healthchecks. In Teams mit mehreren Entwicklern sorgt sie für konsistente Umgebungen, weil jeder dieselbe Compose-Version verwendet.
🔧 Praktisches Beispiel:
Auf einem Alma Linux 9-Server für ein Webprojekt erstellst du nach der Plugin-Installation eine einfache docker-compose.yml im aktuellen Verzeichnis. Der Inhalt definiert einen NGINX-Webserver und einen Redis-Cache:
version: '3.8'
services:
web:
image: nginx:alpine
ports:
- "8080:80"
volumes:
- ./html:/usr/share/nginx/html
cache:
image: redis:alpine
Du startest den Stack mit
docker compose up -d
Der Befehl pulled die Images, erstellt die Netzwerke und startet beide Container.
Mit
docker compose ps
siehst du die laufenden Services und mit
docker compose logs web
die Logs des Webservers. In dieser realen Konfiguration auf einem Entwicklungs-Server hast du innerhalb von Sekunden einen vollständigen Stack laufen, der per Browser unter Port 8080 erreichbar ist. Der Befehl docker compose down beendet alles sauber. Das Beispiel zeigt, wie das Plugin aus einer einfachen YAML-Datei eine komplette Anwendungslandschaft hochfährt und den täglichen Workflow in DevOps-Teams enorm beschleunigt.
Die gesamte Plugin-Installation ist so konzipiert, dass sie zukunftssicher bleibt und mit zukünftigen Docker-Releases mitwächst. Du behältst volle Kontrolle über die Compose-Funktionalität, ohne zusätzliche Abhängigkeiten zu managen.
Damit ist die empfohlene Plugin-Methode vollständig eingerichtet und du kannst den alternativen Installationsweg bei Bedarf prüfen.
Installation über Binary
Während die Plugin-Variante die Standardempfehlung darstellt, bietet die Installation über Binary eine flexible Alternative für spezielle Einsatzszenarien. Was passiert hier? Du lädst die vorkompilierte statische Binärdatei direkt von den offiziellen GitHub-Releases des Docker Compose Projekts herunter, legst sie in das CLI-Plugins-Verzeichnis der Docker-Installation und machst sie ausführbar. Warum machen wir das? In air-gapped Umgebungen, auf Servern ohne dnf-Zugriff zum Docker-Repository oder bei Bedarf an einer exakten Version, die noch nicht als RPM-Paket vorliegt, ermöglicht die Binary-Methode eine vollständig unabhängige Bereitstellung.
Warum ist das wichtig? Sie gewährleistet maximale Kontrolle über Versionszyklen und Kompatibilität, ohne Abhängigkeit von Paketquellen, und bleibt auch in regulierten oder isolierten Produktionsumgebungen auf Alma Linux einsetzbar.
Der Prozess beginnt mit der Ermittlung der gewünschten Version. Du rufst die GitHub-API oder die Releases-Seite ab, um die aktuelle stabile Tag zu erhalten.
Anschließend lädst du die passende Architektur-spezifische Binary herunter.
Für ein x86_64-System auf Alma Linux 9 lautet der Befehl:
VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep '"tag_name"' | cut -d '"' -f 4)
sudo curl -L "https://github.com/docker/compose/releases/download/${VERSION}/docker-compose-linux-x86_64" -o /usr/libexec/docker/cli-plugins/docker-compose
Der Download speichert die Datei direkt im Plugin-Pfad, den Docker automatisch erkennt.
Danach setzt du die Ausführberechtigung mit:
sudo chmod +x /usr/libexec/docker/cli-plugins/docker-compose
Falls der Plugin-Ordner noch nicht existiert, legst du ihn vorher an. Die Binary ist eine Go-kompilierte, statisch gelinkte Datei ohne externe Bibliotheksabhängigkeiten, was sie besonders robust gegenüber Alma Linux-spezifischen Bibliotheksversionen macht. Du kannst optional eine SHA256-Prüfsumme herunterladen und verifizieren:
sudo curl -L "https://github.com/docker/compose/releases/download/${VERSION}/docker-compose-linux-x86_64.sha256" -o compose.sha256
sha256sum -c compose.sha256
Das stellt die Integrität der Datei sicher. Die Binary-Methode erlaubt auch die parallele Nutzung mehrerer Versionen, indem du sie in versionsspezifische Pfade legst und Symlinks oder Aliase in der Shell-Konfiguration definierst. Für Legacy-Kompatibilität erstellst du bei Bedarf einen Symlink:
sudo ln -sf /usr/libexec/docker/cli-plugins/docker-compose /usr/local/bin/docker-compose
Damit bleibt der klassische Aufruf docker-compose weiterhin möglich. Die Integration erfolgt über den Docker-CLI-Plugin-Mechanismus, der die Datei bei jedem docker compose-Aufruf automatisch lädt. Im Gegensatz zum dnf-Paket gibt es keine automatische Abhängigkeitsauflösung, dafür aber volle Freiheit bei der Versionswahl.
💡 Für Skripte in CI/CD-Pipelines speicherst du die VERSION-Variable persistent und automatisierst den gesamten Download-Prozess, sodass alle Server exakt dieselbe Compose-Version erhalten.
Die Binary unterstützt alle aktuellen Compose-Spezifikationen bis Version 3.8 und höher, inklusive Features wie profiles, watch-Mode und erweiterte Build-Optionen mit Buildx. Sie kommuniziert direkt über die Docker-Socket-API und benötigt keine separaten Runtime-Komponenten. Auf Alma Linux passt sie sich nahtlos an SELinux im enforcing-Modus an; bei Zugriffsproblemen stellst du den korrekten Kontext mit restorecon -v /usr/libexec/docker/cli-plugins/docker-compose wieder her.
❗ Häufig tritt der Fehler auf, dass die falsche Architektur heruntergeladen wird. Auf einem x86_64-System führt eine arm64-Binary zu „exec format error“. Prüfe daher immer mit
uname -mvor dem Download.
Die Update-Prozedur ist manuell:
Du wiederholst den Download mit neuer Version und überschreibst die alte Datei. Das gibt dir die Möglichkeit, gezielt Downgrades durchzuführen, wenn eine neuere Engine-Version inkompatibel ist. Die Dateigröße liegt bei rund 55 MB, was auf modernen Servern vernachlässigbar bleibt. Im Gegensatz zum Plugin-Paket gibt es keine automatische Aktualisierung über dnf, was in manchen Umgebungen aber gewünscht ist, um Kontrolle zu behalten.
Warum ist das wichtig? Die Binary-Alternative schließt Lücken, die Paketmanager in restriktiven Netzwerken hinterlassen, und sorgt für reproduzierbare Installationen über unterschiedliche Server hinweg. Sie eignet sich besonders für dedizierte Build-Agents oder Umgebungen mit strengen Compliance-Anforderungen, wo jede externe Paketquelle genehmigt werden muss.
Die Methode erfordert keine Neustart des Docker-Daemons.
Sobald die Datei im cli-plugins-Verzeichnis liegt und ausführbar ist, erkennt die CLI sie beim nächsten Aufruf. Du kannst die aktiven Plugins jederzeit mit docker info | grep -A 20 "Plugins" auflisten und siehst dort das compose-Plugin. Die Binary-Methode ist vollständig portabel und funktioniert auch auf Systemen, auf denen du das Docker-Repository bewusst deaktiviert hast.
⚠️ In hoch-sicheren Umgebungen speicherst du die Binary nach dem Download in einem schreibgeschützten Verzeichnis und prüfst regelmäßig die Integrität mit Hash-Werten, um Manipulationen auszuschließen.
Die Installation über Binary erweitert deine Optionen erheblich und macht Docker Compose unabhängig von den Standard-Paketquellen. Sie bleibt auch bei zukünftigen Docker-Engine-Updates stabil und erlaubt präzise Anpassung an projekt-spezifische Anforderungen.
Im nächsten Abschnitt von Docker-Compose schauen wir uns an, wie du die Installation verifizierst und welche grundlegenden Befehle du kennen musst.
Installation verifizieren
Nach der erfolgreichen Installation, egal ob über das Plugin oder die Binary, solltest du die Funktionsfähigkeit von Docker Compose verifizieren. Was passiert hier? Die Docker-CLI lädt das Plugin und ruft die interne Version sowie die Kompatibilitätsinformationen ab, während gleichzeitig der Socket-Zugriff und die Integration mit dem laufenden Daemon geprüft werden. Warum machen wir das? Nur eine vollständige Verifikation stellt sicher, dass alle Komponenten korrekt zusammenarbeiten und keine versteckten Konflikte aus der Plugin- oder Binary-Installation bestehen.
Warum ist das wichtig? In Produktionsumgebungen auf Alma Linux verhindert dieser Schritt spätere Laufzeitfehler, Versionsinkompatibilitäten oder fehlende Features, die sonst erst während eines produktiven Deployments auffallen würden.
Der primäre Befehl zur Versionsprüfung lautet:
docker compose version
Er gibt die exakte Compose-Version, die Build-Nummer und die verwendete Go-Runtime aus. Ergänzend rufst du die Hilfe auf, um alle verfügbaren Subkommandos zu sehen:
docker compose --help
Die Ausgabe listet detailliert Optionen wie up, down, ps, logs und config auf und bestätigt damit die vollständige Funktionalität. Zusätzlich prüfst du den Plugin-Status innerhalb der Docker-Engine mit:
docker info | grep -A 20 "Plugins"
Dort erscheint compose als geladenes Plugin mit dem korrekten Pfad zur Binary. Die Prüfung umfasst auch den Socket-Zugriff, da der Nicht-root-Benutzer den Daemon ohne sudo erreichen muss. Mit docker compose ls testest du die grundlegende API-Kommunikation, die keinerlei aktiven Stacks voraussetzt.
💡 Die Kombination aus Versionsausgabe und Plugin-Listing gibt dir sofort Aufschluss darüber, ob die Installation mit der aktuellen Docker-Engine-Version harmoniert, was bei manuellen Binary-Updates besonders relevant ist.
Die Verifikation berücksichtigt außerdem die Umgebungsvariablen wie COMPOSE_FILE und DOCKER_HOST, die bei abweichenden Konfigurationen Einfluss nehmen können. Du kannst gezielt die API-Version abfragen, indem du docker compose version --short ausführst. Das reduziert die Ausgabe auf das Wesentliche und erleichtert die Integration in Überwachungsskripte. Die Prüfung der Binary-Integrität erfolgt bei Bedarf durch einen Hash-Vergleich der heruntergeladenen Datei, der die Authentizität der Quelle nachweist.
❗ Ein typischer Fehler tritt auf, wenn das Plugin im falschen Verzeichnis liegt oder die Ausführrechte fehlen. Dann meldet die CLI „docker: 'compose' is not a docker command“ – ein klares Zeichen, dass der Pfad unter /usr/libexec/docker/cli-plugins nicht korrekt gesetzt wurde.
Die gesamte Verifikation ist ressourcenschonend und benötigt nur Sekunden. Sie liefert nicht nur Versionsnummern, sondern auch implizite Hinweise auf die aktuelle Storage-Konfiguration und Netzwerk-Defaults der Engine. Auf Alma Linux bleibt SELinux dabei aktiv und überwacht den Zugriff, sodass keine zusätzlichen Policy-Anpassungen notwendig sind. Die Ausgabe von docker compose version enthält zudem die genaue Commit-Hash, die bei Support-Anfragen wertvolle Informationen liefert.
Warum ist das wichtig? Eine gründliche Verifikation schafft Vertrauen in die Installation und bildet die Basis für reproduzierbare Deployments. Sie deckt Inkonsistenzen frühzeitig auf und vermeidet, dass später in komplexen YAML-Dateien unerwartete Fehler auftreten.
Die Verifikation umfasst ebenfalls einen kurzen Check der Docker-Socket-Berechtigungen, da Compose direkt auf den Daemon zugreift. Mit ls -l /var/run/docker.sock siehst du, ob die docker-Gruppe korrekte Rechte besitzt. Das rundet den Prozess ab und stellt sicher, dass auch Nicht-root-Benutzer ohne Einschränkungen arbeiten können. Die Methode ist bewusst so gestaltet, dass sie sowohl Plugin- als auch Binary-Installationen gleichermaßen abdeckt und ein einheitliches Ergebnis liefert.
⚠️ In Umgebungen mit aktiviertem Firewalld oder strengen AppArmor-Profilen kann der erste compose-Befehl eine temporäre Verzögerung verursachen – hier hilft ein kurzer Blick in die Journal-Logs des Docker-Daemons.
Damit hast du die Installation von Docker Compose vollständig überprüft und du bist bereit für den nächsten Abschnitt, wo wir uns die wichtigen Post-Installation-Einstellungen ansehen.
Post-Installation-Einstellungen
Nach der erfolgreichen Verifikation von Docker Compose richtest du nun die entscheidenden Post-Installation-Einstellungen ein. Was passiert hier? Du erstellst die zentrale Konfigurationsdatei /etc/docker/daemon.json und passt damit das Verhalten der gesamten Engine an. Warum machen wir das? Die Standardeinstellungen sind für Testumgebungen gedacht und müssen für stabile, sichere und performante Produktionsbetrieb optimiert werden. Warum ist das wichtig? Nur mit diesen Anpassungen erreichst du zuverlässige Log-Rotation, korrekte Storage-Isolation und erhöhte Sicherheit auf Alma Linux.
Zuerst legst du die Datei an, falls sie noch nicht existiert:
sudo mkdir -p /etc/docker
sudo nano /etc/docker/daemon.json
Die Datei erhält eine klare JSON-Struktur. Du definierst den Log-Driver mit Rotation, aktivierst Live-Restore und legst den Storage-Driver explizit fest. Ein typischer Minimalinhalt sieht so aus:
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "5"
},
"live-restore": true,
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
Diese Konfiguration sorgt dafür, dass Logs nicht unbegrenzt wachsen und Container nach Daemon-Neustarts weiterlaufen können. Du speicherst die Datei und lädst die neue Konfiguration mit:
sudo systemctl restart docker
Anschließend überprüfst du die aktiven Einstellungen mit docker info | grep -E 'Logging Driver|Live Restore'. Die Ausgabe bestätigt sofort, ob alle Änderungen übernommen wurden.
💡 Viele Admins vergessen diesen Schritt und wundern sich später über volle Festplatten durch ungebremste Container-Logs.
Zusätzlich konfigurierst du die User-Namespace-Remapping für erhöhte Isolation. Dazu bearbeitest du die Datei erneut und fügst den Abschnitt hinzu:
{
"userns-remap": "default"
}
Danach startest du den Daemon neu. Diese Maßnahme verhindert, dass Container-Prozesse als root auf dem Host laufen und reduziert das Risiko bei einem Container-Ausbruch erheblich. Die Einstellung greift nur, wenn du die entsprechenden Sub-UID- und Sub-GID-Dateien im System vorbereitet hast.
⚠️ Achte darauf, dass nach jeder Änderung der Daemon neu gestartet wird, da Docker die daemon.json nur beim Start einliest.
Weiterhin optimierst du die Firewall-Regeln für den Docker-Socket und die Bridge-Netzwerke. Mit sudo firewall-cmd --permanent --add-service=docker und einem anschließenden Reload stellst du sicher, dass interne Container-Kommunikation nicht blockiert wird. SELinux bleibt dabei im enforcing-Modus; Docker bringt eigene Policy-Module mit, die automatisch greifen.
Warum ist das wichtig? Diese Einstellungen bilden die Grundlage für skalierbare, wartbare und sichere Container-Infrastrukturen und verhindern typische Ausfälle durch Ressourcenmangel oder Log-Flut.
Du kannst auch den Datenordner auf ein separates Dateisystem verschieben, indem du in der daemon.json den Eintrag "data-root": "/mnt/docker-data" setzt. Das trennt Container-Daten von der Root-Partition und vereinfacht Backups.
❗ Ein häufiger Fehler entsteht, wenn die JSON-Syntax fehlerhaft ist. Dann startet der Daemon gar nicht mehr und du findest den Grund nur in den Journal-Logs mit
journalctl -u docker -xe.
Die Post-Installation-Einstellungen umfassen ebenfalls die Konfiguration von Ressourcenlimits pro Container über docker run oder Compose-Dateien, doch die daemon.json legt die globalen Defaults fest. Du testest die neue Konfiguration abschließend mit einem einfachen Container-Start und beobachtest die Log-Dateien unter /var/lib/docker/containers.
🔧 Praktisches Beispiel:
Auf einem Alma Linux 9-Server für eine Produktivumgebung erstellst du /etc/docker/daemon.json mit dem oben gezeigten Inhalt für Log-Rotation und Live-Restore.
Nach dem Speichern führst du
sudo systemctl restart docker
aus. Mit
docker info
siehst du sofort
Logging Driver: json-file
Live Restore: true
Anschließend startest du einen Test-Container mit
docker run -d --name test nginx:alpine
und überprüfst mit
ls -l /var/lib/docker/containers/*/json.log
die rotierenden Log-Dateien. In dieser realen Konfiguration auf einem Server mit mehreren Microservices hast du nun eine Engine, die automatisch Logs begrenzt und Container bei Daemon-Neustarts am Leben hält. Die Einstellung verhindert Speicherüberläufe und sorgt für hohe Verfügbarkeit ohne manuelle Eingriffe.
Mit diesen Anpassungen ist deine Docker-Engine vollständig auf den produktiven Einsatz vorbereitet.
Erste praktische Beispiele
Nach den Post-Installation-Einstellungen wendest du die ersten praktischen Beispiele mit Docker und Compose an. Was passiert hier? Du startest isolierte Container und orchestrierst sie mit einer YAML-Datei, um die komplette Engine in Aktion zu sehen. Warum machen wir das? Es überprüft nicht nur die Installation, sondern zeigt dir sofort, wie Container in der Praxis interagieren. Warum ist das wichtig? Nur durch konkrete Ausführung baust du das notwendige Verständnis auf, das später komplexe Produktionsstacks ermöglicht.
Beginne mit einem einzelnen Container, um die Grundfunktionen zu testen.
Der Befehl
docker run --rm hello-world
pullt das offizielle Test-Image, startet es und gibt eine Erfolgsmeldung aus. Der Parameter --rm sorgt dafür, dass der Container nach Beendigung automatisch gelöscht wird. Ohne diesen Parameter bleibt er als gestoppter Container erhalten und belegt Speicher. Die Ausgabe zeigt detailliert, wie der Daemon das Image aus dem Registry lädt, den Container erzeugt und das Programm ausführt. Du siehst damit, dass Storage-Driver, Networking und Runtime korrekt arbeiten.
Erweitere den Befehl auf ein reales Szenario.
Starte einen NGINX-Webserver im Hintergrund mit
docker run -d --name webserver -p 8080:80 nginx:alpine
Der -d startet detached, --name vergibt einen lesbaren Namen und -p mappt den Host-Port 8080 auf den Container-Port 80. Über den Browser rufst du http://localhost:8080 auf und siehst die Standard-Willkommensseite. Mit docker logs webserver liest du die Access-Logs und erkennst, wie Anfragen verarbeitet werden.
Der Befehl docker ps listet laufende Container mit Status, Ports und Namen auf.
💡 Viele Einsteiger starten ohne
-dund wundern sich, warum die Shell blockiert. Der detached-Modus ist daher essenziell für produktive Umgebungen.
Wechsle zu Docker Compose, um mehrere Services gleichzeitig zu steuern. Erstelle eine Datei docker-compose.yml im aktuellen Verzeichnis. Die Datei definiert Services, Volumes und Networks in einer strukturierten Form. Ein einfacher Stack mit Webserver und Cache sieht so aus:
services:
web:
image: nginx:alpine
ports:
- "8080:80"
volumes:
- ./html:/usr/share/nginx/html
restart: unless-stopped
cache:
image: redis:alpine
command: redis-server --appendonly yes
volumes:
- redis-data:/data
volumes:
redis-data:
Der Befehl docker compose up -d startet beide Services. Compose erstellt ein eigenes Network, pulled die Images und startet die Container in der richtigen Reihenfolge. Mit docker compose ps siehst du beide Services laufen. Die Ausgabe zeigt Container-IDs, Namen, Status und Ports. Logs holst du mit docker compose logs -f web, um Echtzeit-Ausgaben zu verfolgen.
Der Befehl docker compose down beendet und entfernt alles, inklusive der Volumes, wenn du --volumes hinzufügst.
Die YAML-Struktur folgt der Compose-Spezifikation. Jeder Service erhält einen eigenen Container. Volumes persistieren Daten außerhalb des Containers, damit Redis bei Neustarts nichts verliert. Das restart: unless-stopped sorgt dafür, dass der Service nach Daemon-Neustart automatisch wieder hochfährt. Compose verwaltet Abhängigkeiten und Netzwerkverbindungen automatisch, sodass der Webserver den Cache über den Servicenamen cache erreichen kann.
Warum ist das wichtig? Ein einzelner docker run-Befehl reicht für einfache Tests, doch Compose zeigt die wahre Stärke von Docker: reproduzierbare, versionierte Multi-Container-Anwendungen. Du kannst die gleiche docker-compose.yml auf Entwicklungs-, Test- und Produktionsservern einsetzen und bist sicher, dass alles identisch läuft.
Erweitere das Beispiel um Umgebungsvariablen und Healthchecks.
Füge im Web-Service hinzu:
environment:
- NGINX_HOST=example.com
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost"]
interval: 30s
timeout: 10s
retries: 3
Compose startet den Container erst, wenn der Healthcheck grün ist. Das verhindert, dass abhängige Services zu früh mit der Arbeit beginnen. Mit docker compose config validierst du die YAML-Syntax, bevor du startest. Fehler in der Einrückung oder falsche Schlüssel führen zu klaren Fehlermeldungen.
❗ Häufig übersieht man, dass Volume-Pfade relativ zum Verzeichnis der YAML-Datei aufgelöst werden. Ein falscher Pfad führt zu leeren Volumes und Datenverlust.
Die Befehle docker compose build und docker compose push erlauben das Bauen eigener Images aus einem Dockerfile und das Pushen in eine Docker Registry. In Kombination mit docker compose up --build aktualisierst du Images bei jeder Änderung. Das ist besonders nützlich in CI/CD-Pipelines, wo du mit einem einzigen Befehl den gesamten Stack aktualisierst.
Die praktische Nutzung zeigt, wie Docker die Isolation auf Port-, Dateisystem- und Prozessebene handhabt. Jeder Container hat seinen eigenen Network-Namespace, sodass Konflikte mit Host-Ports vermieden werden. Compose fügt ein Overlay-Netzwerk hinzu, das interne Kommunikation ohne Port-Mapping erlaubt. Das reduziert die Angriffsfläche und vereinfacht die Konfiguration.
Warum machen wir das? Die ersten Beispiele festigen das Gelernte und zeigen den Unterschied zwischen einzelnen Containern und orchestrierten Stacks. Du erkennst sofort, ob die Engine stabil läuft und ob SELinux oder Firewall Einstellungen noch angepasst werden müssen.
⚠️ Starte nie produktive Stacks, ohne vorher
docker compose configauszuführen, denn Syntaxfehler stoppen den gesamten Vorgang.
Die Beispiele skalieren leicht.
Du kannst weitere Services hinzufügen, Secrets einbinden oder Profiles für Entwicklung und Produktion nutzen. Mit docker compose --profile dev up startest du nur bestimmte Teile des Stacks. Das hält die Entwicklungsumgebung schlank.
Die detaillierte Ausführung der Befehle vermittelt, wie Docker die Ressourcen des Hosts nutzt. Mit docker stats beobachtest du CPU, Memory und I/O in Echtzeit. Das hilft, Engpässe frühzeitig zu erkennen. Die Kombination aus docker run für schnelle Tests und Compose für persistente Anwendungen bildet das tägliche Handwerkszeug jedes DevOps-Engineers auf Alma Linux.
In der Praxis kopierst du die docker-compose.yml in ein Git-Repository und versionierst sie. Jeder Entwickler kann mit einem einzigen Befehl die exakte Umgebung hochfahren. Das eliminiert das klassische „Bei mir läuft es“-Problem und schafft reproduzierbare Entwicklungsumgebungen.
Die Beispiele machen deutlich, wie wenig Aufwand nötig ist, um komplexe Anwendungen containerisiert zu betreiben. Ein einzelner Container-Test dauert Sekunden, ein Compose-Stack mit mehreren Services nur Minuten. Die Engine verarbeitet alles automatisch und gibt dir klare Fehlermeldungen, wenn etwas nicht stimmt.
Warum ist das wichtig? Diese ersten praktischen Schritte bauen das Vertrauen auf, das du brauchst, um später produktive Systeme mit Hunderten Containern zu betreiben. Du lernst die Befehle nicht nur theoretisch, sondern siehst sie in Aktion und verstehst ihre Auswirkungen auf Stabilität und Performance.
🔧 Praktisches Beispiel:
Du hast auf einem Alma Linux 9-Server ein Webprojekt mit NGINX und Redis. Erstelle das Verzeichnis ~/webstack und lege darin die docker-compose.yml an mit dem oben gezeigten Inhalt. Im Unterverzeichnis html legst du eine index.html mit einfachem Inhalt ab.
Führe
docker compose up -d
aus. Compose pulled beide Images, erstellt das Volume webstack_redis-data und startet die Container.
Mit
docker compose ps
siehst du web auf Port 8080 und cache intern erreichbar. Öffne den Browser unter http://localhost:8080 und siehst deine index.html.
Logs mit
docker compose logs -f
zeigen Echtzeit-Informationen.
Stoppe mit
docker compose down --volumes
und entferne alle Daten. In dieser realen Konfiguration auf einem Entwicklungs-Server hast du innerhalb weniger Minuten eine vollständige, isolierte Anwendungsumgebung hochgefahren, die du jederzeit exakt reproduzieren kannst. Die Befehle docker compose config und docker stats geben dir volle Kontrolle über den Stack und zeigen, wie effizient die Ressourcen genutzt werden. Das Beispiel macht klar, wie Docker und Compose aus einer einfachen YAML-Datei eine produktionsreife Anwendung erzeugen.
Wichtige Ressourcen
Zum Abschluss des Artikels findest du hier die zentralen offiziellen Quellen. Diese Links führen dich direkt zu aktuellen Anleitungen, Sicherheitsupdates und detaillierten Referenzen, die du für den produktiven Betrieb von Docker und Compose auf Alma Linux brauchst. Sie ergänzen die in diesem Artikel behandelten Schritte und helfen dir bei der Fehlersuche sowie bei der Planung zukünftiger Updates.
Docker Engine Installation Docker Engine Dokumentation Docker Compose Dokumentation Docker Engine Release Notes Docker Compose GitHub Releases Docker Best Practices Guide Docker Security Documentation Alma Linux Docker Community
Diese Ressourcen halten dich auf dem neuesten Stand und ersparen dir langes Suchen. Lese sie regelmäßig, besonders vor größeren Updates.
Fazit
Du hast nun eine vollständige, stabile und produktionsreife Installation von Docker und Docker Compose auf Alma Linux abgeschlossen. Von der gründlichen Systemvorbereitung über die korrekte Repository-Konfiguration bis hin zu den ersten praktischen Stacks mit Compose beherrschst du den gesamten Prozess.
Die Kombination aus der langfristigen Stabilität von Alma Linux und der Flexibilität von Docker ermöglicht dir reproduzierbare, isolierte und skalierbare Anwendungen. Du kannst Entwicklungs-, Test- und Produktionsumgebungen exakt gleich aufbauen, Versionskonflikte vermeiden und den klassischen „Bei mir läuft es“-Effekt eliminieren. Mit Compose orchestrierst du komplexe Multi-Container-Anwendungen über eine einzige YAML-Datei – einfach, versionierbar und teamfähig.
Halte die Engine durch regelmäßige Updates aktuell, passe die daemon.json an deine Anforderungen an und nutze Compose konsequent für alle neuen Projekte. So baust du eine professionelle Container-Infrastruktur auf, die den hohen Ansprüchen moderner DevOps-Teams gerecht wird.
Mit diesem fundierten Setup bist du bestens gerüstet für den nächsten Schritt: automatisierte Deployments, CI/CD-Pipelines oder die Vorbereitung größerer Orchestrierungslösungen. Die Grundlage ist gelegt – jetzt liegt es an dir, sie täglich einzusetzen.