Docker, Docker Compose und Portainer auf Ubuntu 24.04: Kompletter Nginx- und SSL-Ratgeber mit Bildern

Diese Anleitung dokumentiert eine reale Installation auf einem Ubuntu-24.04.4-LTS-VPS. In der Testumgebung liefen Docker Engine 29.7.2, Docker Compose v5.4.0 und Portainer Community Edition 2.39.5 LTS; diese Versionsnummern beschreiben den Test und sind keine dauerhafte Mindestanforderung.

Ziel war nicht nur eine erreichbare Portainer-Oberfläche. Docker wurde aus dem offiziellen Repository installiert, Portainer-Daten liegen in einem Named Volume, Nginx arbeitet als Reverse Proxy, Let's Encrypt liefert TLS und Port 9443 wurde final ausschließlich an 127.0.0.1 gebunden.

Internet :443
     ↓
Nginx + Let's Encrypt
     ↓
https://127.0.0.1:9443
     ↓
Portainer CE LTS
     ↓
/var/run/docker.sock → Docker Engine

Vor der Installation sollten Ubuntu-Version, Kernel, Architektur, RAM und Speicherplatz dokumentiert werden. Der Test-VPS lief mit Ubuntu 24.04.4 LTS Noble, Kernel 6.8.0-137-generic und x86-64.

Vor der Nutzung offizieller Docker-Pakete vorhandene Pakete wie docker.io, docker-compose, containerd, runc oder podman-docker prüfen. Auf Produktivsystemen keine Pakete ohne Prüfung laufender Workloads entfernen.

cat /etc/os-release | grep -E 'PRETTY_NAME|VERSION_ID|VERSION_CODENAME'
uname -r
dpkg --print-architecture

free -h
df -h /

dpkg --get-selections | grep -E 'docker|containerd|runc|podman' || true

Docker Engine wurde aus dem offiziellen Ubuntu-Repository von Docker installiert. ca-certificates und curl wurden vorbereitet, der Signaturschlüssel unter /etc/apt/keyrings/docker.asc gespeichert und docker.sources im deb822-Format erstellt.

Ein docker-ce-Kandidat aus Noble stable in apt-cache policy bestätigt die Repository-Verbindung. Im Test war Docker CE 29.7.2 der Kandidat.

apt-get update
apt-get install -y ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

cat >/etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
apt-get update
apt-cache policy docker-ce

Nach der Repository-Prüfung wurden docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin und docker-compose-plugin installiert. Im Test wurden 102 MB geladen; dieser Wert ist versionsabhängig.

Der Docker-Dienst wurde über systemd aktiviert und gestartet. Danach wurden Docker-, Compose- und Buildx-Versionen separat geprüft.

apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

systemctl enable --now docker
systemctl is-active docker

docker --version
docker compose version
docker buildx version

Das erste Automatisierungsskript stoppte trotz funktionierendem Docker-Repository bei head -n 20 mit Exit Code 141. head schloss die Pipe früh, der vorherige Prozess erhielt SIGPIPE und set -o pipefail wertete dies als Fehler.

Für reine Anzeige-Pipelines kann sed -n genutzt werden. || true sollte nur bei eindeutig harmlosen Anzeigeoperationen eingesetzt werden; echte Installationsfehler dürfen nicht verborgen werden.

apt-cache policy docker-ce | sed -n '1,20p'

apt-cache policy docker-ce | head -n 20 || true

docker --version bestätigt nur den Client. Deshalb wurde hello-world heruntergeladen und als Container ausgeführt. 'Hello from Docker!' bestätigte Client, Daemon, Image-Pull und Container-Ausführung gemeinsam.

Mit docker info wurden Storage Driver, Cgroup-Modus, Sicherheitsoptionen, Docker Root Dir und Ressourcen kontrolliert. Der Test zeigte overlayfs, cgroup v2, AppArmor und seccomp.

docker run --rm hello-world

docker info

systemctl --failed

Für dauerhafte Portainer-Konfiguration wurde das Named Volume portainer_data erstellt. Danach wurde portainer/portainer-ce:lts geladen und der lokale Docker-Socket in den Container eingebunden.

Für die erste reale Prüfung war 9443 kurz auf dem Host veröffentlicht. Nach Einrichtung von Nginx und Domain wurde Portainer final nur mit 127.0.0.1:9443 neu erstellt.

docker volume create portainer_data
docker pull portainer/portainer-ce:lts

docker run -d --name portainer --restart=always -p 9443:9443 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:lts

docker ps --filter name='^/portainer$'
curl -k -sS -o /dev/null -w '%{http_code}\n' https://127.0.0.1:9443/

Eine frische Portainer-Datenbank zeigt beim ersten Start die Einrichtung des Administratorkontos. Im Test erzeugten die Logs zusätzlich ein temporäres Setup-Token. Dieses Token wie Passwort oder API-Key behandeln und niemals veröffentlichen.

Nach dem Admin-Setup erkennt der Environment Wizard die lokale Docker-Umgebung. Läuft die initiale Einrichtung wegen Inaktivität ab, kann der Container neu gestartet werden.

docker logs portainer --tail 100

docker restart portainer

Für portainer.ekasunucu.com wurden Nginx und dnsutils installiert. Erst nachdem Cloudflare DNS und Google DNS auf den erwarteten Origin zeigten, wurde der Reverse Proxy aktiviert.

Nginx leitet zu https://127.0.0.1:9443 weiter. Da Portainer lokal ein selbstsigniertes Zertifikat nutzt, wird proxy_ssl_verify off nur für diesen localhost-Upstream verwendet; öffentliches TLS terminiert Nginx mit Let's Encrypt.

apt-get update
apt-get install -y nginx dnsutils
systemctl enable --now nginx

dig +short A portainer.ekasunucu.com @1.1.1.1
dig +short A portainer.ekasunucu.com @8.8.8.8

cat >/etc/nginx/conf.d/portainer-websocket.conf <<'EOF'
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}
EOF

cat >/etc/nginx/sites-available/portainer.ekasunucu.com <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name portainer.ekasunucu.com;

    location / {
        proxy_pass https://127.0.0.1:9443;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_ssl_verify off;
    }
}
EOF
ln -sfn /etc/nginx/sites-available/portainer.ekasunucu.com /etc/nginx/sites-enabled/portainer.ekasunucu.com
nginx -t
systemctl reload nginx

curl -sS -o /dev/null -w '%{http_code}\n' -H 'Host: portainer.ekasunucu.com' http://127.0.0.1/

Der erste snap-install-Versuch für Certbot lief beim Download von core24 über Canonicals CDN in einen TCP-443-Timeout. Nginx und Portainer waren dabei weiterhin funktionsfähig; die Ursache lag im Snap-Downloadpfad.

snap changes und snapd-Status bestätigten dies. Ein späterer Versuch installierte Certbot 5.7.0 erfolgreich. Bei temporären CDN-/Netzwerkfehlern nicht vorschnell die Reverse-Proxy-Konfiguration ändern.

snap changes
systemctl is-active snapd

snap install --classic certbot

snap list certbot
/snap/bin/certbot --version

Während der Fehlersuche wurden kurzzeitig auch Ubuntu-APT-Pakete von Certbot getestet. Final wurden certbot, python3-certbot und python3-certbot-nginx aus APT entfernt und ausschließlich Certbot 5.7.0 als Snap genutzt.

Eine einzige Binary und ein Renewal-Mechanismus vereinfachen Diagnose und Wartung. Auf bestehenden Produktivsystemen vorher Zertifikats- und Renewal-Konfiguration prüfen.

apt-get remove -y certbot python3-certbot python3-certbot-nginx python3-certbot || true

snap install --classic certbot
ln -sfn /snap/bin/certbot /usr/local/bin/certbot
certbot --version

Nachdem der HTTP-Reverse-Proxy 200 lieferte, wurde das Let's-Encrypt-Zertifikat ausgestellt. Certbot speicherte es unter /etc/letsencrypt/live/portainer.ekasunucu.com und konfigurierte Nginx für HTTPS.

Nach der Ausstellung wurden nginx -t, HTTPS-Antwort sowie Subject, Issuer und Gültigkeitsdaten mit openssl geprüft.

certbot --nginx -d portainer.ekasunucu.com -m [email protected] --agree-tos --no-eff-email --redirect

nginx -t
systemctl is-active nginx

curl -I https://portainer.ekasunucu.com/

openssl s_client -connect portainer.ekasunucu.com:443 -servername portainer.ekasunucu.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Nach erfolgreichem Domain-/TLS-Pfad wurde Portainer mit demselben portainer_data-Volume neu erstellt und die Host-Zuordnung auf 127.0.0.1:9443:9443 geändert. Der Verwaltungsport lauscht damit nicht mehr auf öffentlichen Interfaces.

Das Named Volume erhält die Portainer-Datenbank beim Container-Neustart. Final sollte 9443 nur auf Loopback und 80/443 über Nginx sichtbar sein.

docker stop portainer
docker rm portainer

docker run -d --name portainer --restart=always -p 127.0.0.1:9443:9443 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:lts

docker ps --filter name='^/portainer$'
ss -lntp | grep -E ':(80|443|9443)\b'

curl -k -sS -o /dev/null -w '%{http_code}\n' https://127.0.0.1:9443/
curl -sS -o /dev/null -w '%{http_code}\n' https://portainer.ekasunucu.com/

Ein heute gültiges Zertifikat braucht einen überprüften Erneuerungsweg. Daher wurde der snap.certbot.renew-Timer kontrolliert und certbot renew --dry-run ausgeführt.

Die simulierte Erneuerung war erfolgreich. Zusammen mit nginx -t ist dies ein wichtiger Test vor dem unbeaufsichtigten Betrieb.

systemctl list-timers --all | grep -i certbot || true

certbot renew --dry-run

nginx -t

Die finale Portainer-Anmeldung erfolgte nur über https://portainer.ekasunucu.com. Nach dem Login erkannte der Environment Wizard den lokalen Docker-Socket und bot die lokale Umgebung an.

Auf der Startseite erschien local als Up; Container, Volume, Images sowie CPU/RAM wurden angezeigt. Damit war auch die tatsächliche Docker-Verwaltung über Portainer bestätigt.

https://portainer.ekasunucu.com

Zum Abschluss Docker- und Nginx-Dienste, Portainer-Container, Named Volume, Docker-Speicher, HTTPS-Status und fehlgeschlagene systemd-Units getrennt prüfen. Der Test endete mit HTTP 200 und null failed units.

Diese Prüfungen nach einem Reboot wiederholen. Docker-Restart-Policy, Nginx-Autostart, Portainer und Domain-TLS dürfen nicht von einer interaktiven SSH-Sitzung abhängen.

systemctl is-active docker nginx
docker ps
docker volume ls

docker system df

curl -sS -o /dev/null -w 'HTTPS %{http_code}\n' https://portainer.ekasunucu.com/

ss -lntp | grep -E ':(80|443|9443)\b'
systemctl --failed