So stellen Sie einen Docker-Container im Jahr 2026 für die Produktion bereit: Ein praktischer Leitfaden

Es ist einfach, einen Docker-Container lokal zum Laufen zu bringen. Um es in der Produktion sicher zum Laufen zu bringen – mit der richtigen Konfiguration, Zustandsprüfungen und Updates ohne Ausfallzeiten – sind noch ein paar weitere Schritte erforderlich. Dieser Leitfaden führt Sie durch die richtige Bereitstellung einer Containeranwendung für die Produktion im Jahr 2026, von einem produktionsbereiten Image bis hin zu einem Reverse-Proxy und Updates, die den Datenverkehr nicht beeinträchtigen.

Schritt 1: Schreiben Sie eine produktionsbereite Docker-Datei

Beginnen Sie mit einem mehrstufigen Build, damit Ihr endgültiges Image nur das enthält, was es zum Ausführen benötigt – keine Build-Tools und Entwicklungsabhängigkeiten. Kleinere Bilder ziehen schneller, starten schneller und haben eine kleinere Angriffsfläche.

# Build stage
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Runtime stage
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]

Beachten Sie dasUSER node Zeile – Führen Sie niemals Produktionscontainer als Root aus. Durch die Ausführung als nicht privilegierter Benutzer wird der Schaden begrenzt, wenn die App kompromittiert wird.

Schritt 2: Behandeln Sie die Konfiguration mit Umgebungsvariablen

Backen Sie niemals Geheimnisse in Ihr Image ein. Übergeben Sie Konfiguration und Geheimnisse zur Laufzeit über Umgebungsvariablen oder einen Geheimnisse-Manager. Ihr Bild sollte bei der Inszenierung und Produktion identisch sein; Nur die Umgebung unterscheidet sich.

docker run -d \
  --name myapp \
  --env-file /etc/myapp/production.env \
  --restart unless-stopped \
  -p 3000:3000 \
  myapp:1.4.0

Behalte das.env Datei aus dem Image entfernen und der Versionskontrolle entziehen. Auf einem einzelnen Host funktioniert eine env-Datei mit gesperrten Berechtigungen; Verwenden Sie im großen Maßstab Docker-Geheimnisse, AWS Secrets Manager oder den Secret Store Ihrer Plattform.

Schritt 3: Fügen Sie einen Gesundheitscheck hinzu

Durch eine Gesundheitsprüfung erfahren Docker (und Ihr Orchestrator oder Reverse-Proxy), ob der Container tatsächlich für die Verarbeitung von Datenverkehr bereit ist und nicht nur ausgeführt wird. Fügen Sie einen Endpunkt wie/healthhinzu zu Ihrer App hinzufügen und dann den Scheck deklarieren.

HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD wget -qO- http://localhost:3000/health || exit 1

Damit istdocker ps zeigt einhealthy or unhealthy Status, und Orchestratoren können vermeiden, Datenverkehr an Container weiterzuleiten, die sich noch in der Aufwärmphase befinden oder fehlerhaft sind.

Schritt 4: Verwenden Sie Docker Compose für ein sauberes Setup

Selbst auf einem einzelnen Server macht Compose Ihre Bereitstellung reproduzierbar und selbstdokumentierend. Es erfasst das Image, die Ports, die Umgebung, die Neustartrichtlinie und die Abhängigkeiten in einer Datei.

services:
  app:
    image: myapp:1.4.0
    restart: unless-stopped
    env_file: /etc/myapp/production.env
    expose:
      - "3000"
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"]
      interval: 30s
      timeout: 3s
      retries: 3
    depends_on:
      - db
  db:
    image: postgres:17-alpine
    restart: unless-stopped
    env_file: /etc/myapp/db.env
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

Beachten Sie das benannte Volume für Postgres – Containerspeicher ist kurzlebig, sodass alle Daten, die Sie aufbewahren müssen, in ein Volume gehören und niemals in die beschreibbare Ebene des Containers.

Schritt 5: Setzen Sie einen Reverse-Proxy vor

Setzen Sie den Port Ihrer App nicht direkt dem Internet aus. Setzen Sie einen Reverse-Proxy (Nginx, Caddy oder Traefik) vor, um TLS zu beenden, Sicherheitsheader hinzuzufügen und den Datenverkehr weiterzuleiten. Caddy ist beliebt, weil es HTTPS-Zertifikate automatisch erhält und erneuert.

# Caddyfile
myapp.example.com {
    reverse_proxy app:3000
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options nosniff
    }
}

Der Proxy verarbeitet HTTPS und Header, während sich Ihre App auf die Bearbeitung von Anfragen über einfaches HTTP innerhalb des privaten Docker-Netzwerks konzentriert.

Schritt 6: Updates ohne Ausfallzeit bereitstellen

Das naive Update – alten Container stoppen, neuen starten – verringert den Datenverkehr während der Lücke. Für Updates ohne Ausfallzeiten starten Sie den neuen Container, warten Sie, bis er die Integritätsprüfungen besteht, wechseln Sie dann den Proxy und entfernen Sie den alten. Traefik und Orchestratoren automatisieren dies; Bei einem einfachen Setup können Sie zwei Versionen kurz ausführen und dann umstellen.

# Pull the new version and recreate with Compose
docker compose pull app
docker compose up -d --no-deps app
# Compose starts the new container; verify health before removing old

Kennzeichnen Sie Bilder immer mit einer bestimmten Version (myapp:1.4.0), verlassen Sie sich niemals auflatest in der Produktion. Explizite Tags machen Rollbacks trivial – Sie wissen genau, welche Version Sie erneut bereitstellen müssen.

Schritt 7: Protokollierung und Überwachung

Konfigurieren Sie einen Protokolltreiber, damit Protokolle an einem dauerhaften Ort gespeichert werden, und begrenzen Sie die Protokollgröße, damit ein Container die Festplatte nicht füllen kann. Versenden Sie Protokolle an einen zentralen Ort (Loki, CloudWatch oder einen ELK-Stack) für alles, was über ein Hobbyprojekt hinausgeht.

docker run -d \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  myapp:1.4.0

Häufig gestellte Fragen

F: Sollte ich meine Datenbank in einem Container in der Produktion ausführen?
A: Für kleine Projekte ja – mit einem benannten Volume für Persistenz und regelmäßige Backups. Bei kritischen oder umfangreichen Aufgaben reduziert eine verwaltete Datenbank (RDS, Cloud SQL) das Betriebsrisiko erheblich.

F: Warum nicht einfach den App-Port direkt verfügbar machen?
A: Sie würden die TLS-Terminierung, Sicherheitsheader und einen einzigen Punkt zur Verwaltung des Routings verlieren. Mit einem Reverse-Proxy können Sie außerdem mehrere Apps auf einem Host ausführen und Zertifikate zentral verwalten.

F: Wie halte ich Geheimnisse aus dem Bild fern?
A: Übergeben Sie sie zur Laufzeit über Umgebungsvariablen, eine Env-Datei mit gesperrten Berechtigungen oder einen Secrets-Manager. NiemalsCOPY eine Secrets-Datei in das Image oder Hardcode-Anmeldeinformationen in der Docker-Datei.

F: Welche Neustartrichtlinie sollte ich verwenden?
A: unless-stopped Bei den meisten Diensten wird der Container bei einem Fehler und nach einem Host-Neustart neu gestartet, ein manueller Stopp wird jedoch berücksichtigt.

F: Wie kann ich eine fehlerhafte Bereitstellung rückgängig machen?
A: Da Sie Bilder nach Version getaggt haben, stellen Sie das vorherige Tag (docker compose up -dmit der alten Version) erneut bereit. Deshalblatestist in der Produktion gefährlich – es macht Rollbacks mehrdeutig.

Fazit

Die sichere Bereitstellung von Docker in der Produktion hängt von einer Handvoll Disziplinen ab:Erstellen Sie ein schlankes mehrstufiges Image, das als Nicht-Root-Benutzer ausgeführt wird, fügen Sie Konfigurationen und Geheimnisse zur Laufzeit ein, fügen Sie Gesundheitsprüfungen hinzu, stellen Sie der App einen Reverse-Proxy für TLS zur Verfügung, kennzeichnen Sie Images nach Version für saubere Rollbacks und begrenzen Sie Ihre Protokolle. Erfassen Sie alles in einer Compose-Datei, damit das Setup reproduzierbar ist. Wenn Sie diese Grundlagen richtig befolgen, läuft Ihre Container-App zuverlässig, wird aktualisiert, ohne dass der Datenverkehr verloren geht, und kann problemlos zurückgesetzt werden, wenn etwas schief geht.