Docker auf dem vServer: Anwendungen sauber getrennt betreiben

Docker auf dem vServer lohnt sich, sobald Sie mehr als eine Anwendung betreiben. Jede Anwendung läuft in einem eigenen Container mit allen Abhängigkeiten, und eine Datei namens compose.yaml beschreibt, wie alles zusammenspielt. Updates werden damit zum Zweizeiler, und ein Umzug auf einen neuen Server dauert Minuten statt Tage. Zwei Fallen sollten Sie aber von Anfang an kennen: Docker öffnet Ports an der Firewall vorbei, und die Daten in den Containern sind nicht automatisch gesichert.

Was Docker macht

Ein Container ist ein abgeschotteter Prozess auf Ihrem Server. Er bringt seine eigenen Programme und Bibliotheken mit, teilt sich aber den Kernel mit dem System. Darin liegt der Unterschied zu einer virtuellen Maschine: Ein Container startet in Sekunden und braucht kaum zusätzlichen Arbeitsspeicher. Mit Docker auf dem vServer laufen so bei 4 GB RAM leicht ein Dutzend kleiner Dienste nebeneinander.

Vier Begriffe begegnen Ihnen ständig. Ein Image ist die Vorlage, etwa für WordPress oder eine Datenbank. Ein Container ist eine laufende Instanz davon. In einem Volume liegen die Daten, die einen Neustart überleben sollen. Und über ein Netzwerk sprechen Container miteinander, ohne dass Sie dafür Ports nach außen öffnen müssen.

Voraussetzungen für Docker auf dem vServer

Docker braucht einen eigenen Kernel mit bestimmten Funktionen. Das bietet ein vServer mit KVM-Virtualisierung, und das ist heute bei fast allen Anbietern Standard. Auf älteren Containern mit OpenVZ oder LXC läuft Docker nur eingeschränkt oder gar nicht. Den Unterschied erklärt der Vergleich KVM und OpenVZ.

• Arbeitsspeicher: 2 GB reichen für zwei, drei kleine Dienste. Mit Datenbank, WordPress und einem Werkzeug für die Überwachung planen Sie besser 4 GB.
• Speicherplatz: Images belegen schnell 10 bis 20 GB. Rechnen Sie das zu Ihren Daten dazu.
• System: ein aktuelles Debian oder Ubuntu, frisch eingerichtet und abgesichert. Wie das geht, zeigt der Leitfaden vServer für Einsteiger.
• Zugang: ein SSH-Zugang mit Schlüssel und ein Benutzer mit sudo-Rechten.

Docker auf dem vServer installieren

Die Pakete in Debian und Ubuntu heißen docker.io und sind oft deutlich älter als die aktuelle Version. Besser nutzen Sie die Paketquelle von Docker selbst. Unter Debian sieht das so aus, für Ubuntu ersetzen Sie in der Adresse debian durch ubuntu:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Ob alles läuft, zeigt sudo docker run --rm hello-world. Die Befehle ändert Docker gelegentlich. Halten Sie sich im Zweifel an die Installationsanleitung von Docker.

Viele Anleitungen empfehlen, den eigenen Benutzer in die Gruppe docker aufzunehmen, damit das sudo wegfällt. Das ist bequem, aber wer in dieser Gruppe ist, hat praktisch Root-Rechte auf dem ganzen Server. Machen Sie das nur für Ihren eigenen Admin-Benutzer, nie für Dienstkonten oder Mitarbeiter ohne Root-Zugang.

Die erste Anwendung mit Docker Compose

Einzelne docker run-Befehle sind schnell vergessen. Mit Docker Compose beschreiben Sie alle Container einer Anwendung in einer Datei. Für ein WordPress mit Datenbank legen Sie einen Ordner ~/wordpress an und darin die Datei compose.yaml:

services:
  db:
    image: mariadb:11.4
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress
      MARIADB_PASSWORD: ${DB_PASSWORT}
      MARIADB_RANDOM_ROOT_PASSWORD: "1"
    volumes:
      - db:/var/lib/mysql
  wordpress:
    image: wordpress:6-apache
    restart: unless-stopped
    depends_on: [db]
    ports:
      - "127.0.0.1:8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORT}
    volumes:
      - wp:/var/www/html
volumes:
  db:
  wp:

Das Passwort steht in einer Datei .env im selben Ordner, etwa DB_PASSWORT=langes-zufälliges-passwort, und gehört nicht in die Versionsverwaltung. Mit docker compose up -d startet alles im Hintergrund. Die Datenbank ist dabei von außen gar nicht erreichbar, WordPress spricht sie über das interne Netzwerk unter dem Namen db an.

Die Firewall-Falle: veröffentlichte Ports

Das ist der häufigste und gefährlichste Fehler, wenn Sie Docker auf dem vServer betreiben. Schreiben Sie in der Compose-Datei nur "8080:80", ist der Port aus dem ganzen Internet erreichbar, auch wenn Ihre Firewall mit ufw alles außer SSH und HTTPS sperrt. Docker trägt seine Regeln direkt in die Netzfilter des Kernels ein, und zwar vor den Regeln von ufw. Die Firewall zeigt dabei keinen Fehler an.

Die Lösung ist einfach: Binden Sie Ports an 127.0.0.1, wie im Beispiel oben. Dann ist der Dienst nur auf dem Server selbst erreichbar, und ein Webserver davor reicht die Anfragen weiter. Datenbanken veröffentlichen Sie gar nicht. Prüfen Sie nach jeder Änderung von einem anderen Rechner aus, welche Ports wirklich offen sind, etwa mit nmap ihre-server-ip. Mehr zu Regeln und Ports steht in der Anleitung zur Firewall-Konfiguration.

HTTPS mit einem Reverse Proxy

Damit Besucher Ihre Anwendung unter einer Domain mit HTTPS erreichen, setzen Sie einen Webserver als Reverse Proxy davor. Er nimmt Anfragen auf Port 443 an, kümmert sich um das Zertifikat und leitet an den Container auf 127.0.0.1:8080 weiter. Besonders einfach geht das mit Caddy, der Zertifikate von Let's Encrypt selbst holt und erneuert. Die vollständige Konfiguration für eine Subdomain ist drei Zeilen lang:

blog.beispiel.de {
    reverse_proxy 127.0.0.1:8080
}

Wer schon Nginx nutzt, erreicht dasselbe mit einem Server-Block und proxy_pass. Für mehrere Anwendungen bekommt jede ihren eigenen Port auf 127.0.0.1 und ihre eigene Subdomain.

Updates und Pflege

Ein Container wird nicht aktualisiert, sondern ersetzt. Das ist einer der großen Vorteile, denn ein Update lässt sich genauso leicht rückgängig machen:

cd ~/wordpress
docker compose pull
docker compose up -d
docker image prune -f

Wählen Sie Image-Versionen bewusst. Mit mariadb:11.4 bekommen Sie Fehlerkorrekturen innerhalb dieser Version, aber keinen überraschenden Sprung auf die nächste Hauptversion. Ein Tag wie latest ist bequem und sorgt irgendwann für eine Datenbank, die nach dem Update nicht mehr startet. Vergessen Sie auch das System darunter nicht: Docker selbst und der Kernel kommen weiter über apt.

Ein häufiger Grund für volle Festplatten sind die Protokolle der Container. Docker speichert sie standardmäßig ohne Grenze. Legen Sie deshalb in /etc/docker/daemon.json eine Rotation fest und starten Sie Docker danach mit sudo systemctl restart docker neu. Die Einstellung gilt für neu erstellte Container:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Ressourcen begrenzen

Ohne Grenzen darf jeder Container so viel Arbeitsspeicher nehmen, wie er bekommt. Läuft eine Anwendung aus dem Ruder, beendet der Kernel irgendwann Prozesse, um Platz zu schaffen, im ungünstigen Fall die Datenbank. Setzen Sie deshalb für jeden Dienst in der Compose-Datei eine Obergrenze:

  wordpress:
    mem_limit: 512m
    cpus: 1.0

Wie viel die Container gerade verbrauchen, zeigt docker stats. Für die dauerhafte Überwachung des ganzen Servers eignet sich ein Werkzeug wie Netdata, mehr dazu im Ratgeber zum Root Server Monitoring.

Backups: Volumes richtig sichern

Images lassen sich bei Docker auf dem vServer jederzeit neu herunterladen. Wichtig sind nur Ihre Daten in den Volumes und die Dateien compose.yaml und .env. Datenbanken sichern Sie nicht durch Kopieren ihrer Dateien im laufenden Betrieb, sondern mit einem Export:

docker compose exec -T db sh -c 'mariadb-dump -u wordpress -p"$MARIADB_PASSWORD" wordpress' | gzip > db-$(date +%F).sql.gz

Die übrigen Volumes liegen unter /var/lib/docker/volumes/ und lassen sich mit einem Backup-Programm wie restic sichern. Wie Sie Sicherungen auf einen zweiten Ort bringen und automatisieren, beschreibt der Ratgeber zu Backup-Strategien für Server. Für Docker gilt er genauso.

Typische Fehler mit Docker auf dem vServer

• Ports ohne 127.0.0.1: Datenbanken oder Admin-Oberflächen stehen offen im Internet.
• Daten im Container statt im Volume: Nach docker compose down und einem neuen Start sind sie weg.
• Tag latest: Ein Update springt ungeplant auf eine neue Hauptversion.
• Keine Rotation der Protokolle: Die Festplatte läuft nach Wochen still voll.
• Passwörter in der compose.yaml: Sie landen in Backups und Repositories, wo sie niemand vermutet.
• Images aus unbekannter Quelle: Nehmen Sie offizielle Images oder die des Herstellers. Ein fremdes Image kann alles enthalten.

Wofür sich Docker auf dem vServer eignet

Gut geeignet sind Anwendungen, für die es gepflegte offizielle Images gibt: WordPress, Nextcloud, Uptime Kuma, Gitea, Matomo und viele mehr. Mehrere davon laufen sauber getrennt nebeneinander, jede mit ihrer eigenen PHP- oder Datenbankversion. Weitere Ideen sammelt der Überblick der vServer Anwendungsfälle.

Weniger gut passt Docker, wenn Sie nur eine einzige Website betreiben und keine Erfahrung mit Linux haben. Dann kommen zu Webserver, PHP und Datenbank noch Container, Volumes und Netzwerke als weitere Ebene dazu. Ein Mailserver in Containern ist möglich, etwa mit Mailcow, braucht aber viel Arbeitsspeicher und Pflege.