Was ist ein Container (Docker)?

Einfach erklärt

Ein Container ist ein Paket, das ein Programm mit allem enthält, was es zum Laufen braucht: Bibliotheken, Einstellungen, Hilfsprogramme. Das Bild stammt aus der Schifffahrt. Ein Frachtcontainer passt auf jedes Schiff und jeden Lkw, egal was darin steckt. Ein Software-Container läuft ebenso auf jedem passenden Server, beim Entwickler, beim IT-Dienstleister oder im Rechenzentrum.

Das bekannteste Werkzeug dafür ist Docker. Viele Open-Source-Programme, etwa Paperless-ngx oder Docmost, werden als Container ausgeliefert.

Was das für Ihren Betrieb bedeutet

Container machen Einrichtung und Updates einfacher. Ein Update tauscht das alte Paket gegen ein neues, die Daten liegen getrennt davon und bleiben erhalten. Mehrere Programme laufen auf einem Server nebeneinander, ohne sich gegenseitig in die Quere zu kommen. Zieht eine Anwendung auf einen anderen Server um, kommt sie in derselben Form mit. Nur die Daten werden getrennt übertragen.

Was Container nicht erledigen

Ein Container aktualisiert sich nicht von selbst. Bleibt die alte Version stehen, bleiben auch ihre Sicherheitslücken. Die Daten eines Containers sind auch nicht automatisch im Backup. Ihr IT-Dienstleister sollte Ihnen sagen können, welche Container laufen, in welcher Version und wo ihre Daten liegen.

Gut zu wissen: Ein Container ist kein eigener Server. Alle Container auf einer Maschine teilen sich den Kern ihres Betriebssystems. Fällt der Server aus, fallen alle Container darauf aus.

Aufbau

Container isolieren Prozesse mit Mitteln des Linux-Kernels: Namespaces trennen Prozesse, Netz, Dateisystem und Benutzer, cgroups begrenzen CPU und Arbeitsspeicher. Anders als eine virtuelle Maschine bringt ein Container keinen eigenen Kernel mit. Ein Image ist eine schreibgeschützte Vorlage aus Schichten, ein Container eine laufende Instanz davon. Was beim Entfernen eines Containers nicht in einem Volume liegt, ist verloren. Die Open Container Initiative (OCI) vereinheitlicht Image-Format, Laufzeit und Verteilung in drei Spezifikationen, deshalb verarbeiten Docker, Podman und containerd dieselben Images. Der BSI-Baustein SYS.1.6 „Containerisierung“ beschreibt die Anforderungen an den Betrieb.

Zusammengehörige Container, etwa Anwendung und Datenbank, beschreibt Docker Compose in einer Datei. Für größere Umgebungen verteilt Kubernetes Container auf mehrere Server.

services:
  app:
    image: ghcr.io/beispiel/app:2.14.1     # feste Version statt latest
    ports:
      - "127.0.0.1:8000:8000"             # nur lokal, davor der Reverse Proxy
    volumes:
      - ./data:/app/data                  # Nutzdaten außerhalb des Containers
    env_file: .env                        # Zugangsdaten nicht im Image
    restart: unless-stopped
  db:
    image: postgres:17
    volumes:
      - ./pg:/var/lib/postgresql/data

Typische Fehler

• Ports an alle Adressen gebunden. Ohne Adresse veröffentlicht Docker Ports auf 0.0.0.0 und [::]. Docker leitet diesen Verkehr an den Regeln von ufw vorbei, der Dienst ist trotz Firewall erreichbar. Für Dienste hinter einem Reverse Proxy gehört 127.0.0.1: davor.
• latest als Tag. Das nächste pull holt unbemerkt eine neue Hauptversion, womöglich mit Datenbankmigration. SYS.1.6.A6 verlangt eindeutige Versionsnummern und Images aus vertrauenswürdigen Quellen.
• Zugangsdaten im Image. Passwörter und API-Schlüssel gehören in Secrets oder eine geschützte Datei, nicht ins Image (SYS.1.6.A8).
• Docker-Socket eingebunden. Wer /var/run/docker.sock erreicht, kann den Docker-Dienst steuern und hat damit praktisch Root-Rechte auf dem Host.
• Logs nur im Container. SYS.1.6.A7 verlangt, Protokolle außerhalb des Containers zu speichern, mindestens auf dem Host.

Prüfen

docker ps --format '{{.Names}}\t{{.Image}}\t{{.Ports}}'
nc -zv -w 3 <server-ip> 8000

In der Spalte Ports steht bei internen Diensten 127.0.0.1:8000->8000/tcp, nicht 0.0.0.0:. Ob ein Port tatsächlich offen ist, zeigt erst ein Test von einem anderen Rechner aus.