Training Module

Docker Datenbanken: Persistenz, Backup & Betrieb

In diesem 3-Stunden-Aufbaumodul lernt ihr, was Datenbank-Container von normalen Anwendungs-Containern unterscheidet: das Persistenzmodell mit Datenverzeichnis als Volume und dem Erstinit-Mechanismus von /docker-entrypoint-initdb.d, ein konsistentes Backup/Restore-Verfahren über einen ephemeren Backup-Container sowie die typischen Stolperfallen – vom fehlenden Volume-Mount über das :latest-Tag-Risiko bis zu unsicheren Auth-Defaults. In zwei vollständigen Hands-on-Übungen an MariaDB und PostgreSQL liefert ihr den Beweis am eigenen Rechner: einmal, dass ein Volume und nicht der Container den Zustand hält, einmal, dass ein Restore exakt dieselben Daten zurückliefert. Die komplette Session – auch beide Hands-on-Übungen – läuft vollständig lokal auf eurem eigenen Rechner, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

3 Stunden, live (remote oder vor Ort), Input & zwei vollständige Hands-on-Blöcke

Teilnehmende

Absolvent:innen von “Docker Fortgeschritten” oder gleichwertige Vorkenntnisse in Docker Compose

Voraussetzungen

Sicherer Umgang mit compose.yaml (services/volumes/networks) und dem _FILE-Secrets-Pattern, eine lauffähige Docker-Umgebung mit Docker Compose. Keine Cloud-/AWS-Kostenwirkung – alles läuft lokal.

Warum dieses Training für deine Organisation wirkt

Zustand statt zustandslos

Alles bisher Gelernte drehte sich um zustandslose Container. Datenbank-Container sind der Sonderfall: Wo genau liegt der Zustand, was überlebt einen Neustart und was nicht – der Bogen läuft vom Datenverzeichnis als Volume bis zum belegten Erstinit-Verhalten.

Backup ist kein Zufallsprodukt

Ein wiederholbares Backup/Restore-Verfahren über einen ephemeren –rm-Container, statt Hoffnung auf ein zufällig noch vorhandenes Volume – Teilnehmende bauen den kompletten Weg von Dump bis Restore einmal selbst, mit echtem Datenverlust dazwischen.

Fallstricke vor dem Produktivbetrieb kennen

:latest-Tag-Risiko, Alpine/musl-Locale-Abweichungen, MongoDB ohne Auth per Default und die Grenzen einer MariaDB↔MySQL-Migration – Themen, die in der Praxis erst nach dem ersten Datenverlust auffallen, hier vorher.

Was Teilnehmende mitnehmen

  • Das Persistenzmodell von Datenbank-Containern verstehen: das Datenverzeichnis als Volume sowie den Unterschied zwischen Erstinit (leeres Datenverzeichnis) und Neustart-Verhalten von /docker-entrypoint-initdb.d.
  • Ein konsistentes Backup/Restore-Verfahren für einen laufenden Datenbank-Container aufbauen, ausgeführt über einen ephemeren –rm-Backup-Container statt über den Datenbank-Container selbst.
  • Die typischen Stolperfallen einordnen: Datenverlust durch falschen oder fehlenden Volume-Mount, das :latest-Tag-Risiko bei Versionssprüngen, Alpine/musl-Locale-Abweichungen gegenüber glibc, sowie unsichere Auth-Defaults wie MongoDB ohne –auth.
  • Engine-Wahl und Migrationsgrenzen einschätzen: MariaDB und MySQL sind nur auf einem uninitialisierten Datenverzeichnis kompatibel, nicht als nachträglicher Austausch gegen ein bestehendes.
  • Zugangsdaten für Datenbank-Images konsequent über das _FILE-Pattern verwalten statt im Klartext in der compose.yaml.
  • In zwei vollständigen Hands-on-Übungen an MariaDB (Volume-Beweis nach Neustart) und PostgreSQL (Backup, Datenverlust, Restore) den kompletten Weg selbst gehen und gegen eine Musterlösung abgleichen.

Für wen dieses Modul ideal ist

  • • Absolvent:innen von “Docker Fortgeschritten” oder Entwickler:innen mit gleichwertigen Compose-Vorkenntnissen
  • • Teams, die Datenbank-Container bisher wie zustandslose Anwendungs-Container behandelt haben und den Unterschied jetzt sauber verstehen wollen
  • • Alle, die vor dem ersten Produktivbetrieb einer MariaDB/PostgreSQL/MongoDB/Redis-Instanz ein wiederholbares Backup/Restore-Verfahren aufbauen wollen

Rahmendaten

  • • Dauer: 3 Stunden live (remote oder vor Ort)
  • • Format: Input, Live-Demo, zwei vollständige Hands-on-Übungen mit Musterlösungs-Abgleich
  • • Voraussetzungen: abgeschlossenes Modul “Docker Fortgeschritten” oder gleichwertige Compose-Vorkenntnisse, lauffähige Docker-Umgebung mit Docker Compose, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Warum DB-Container anders sind (15 min): Abgrenzung zu zustandslosen Anwendungs-Containern aus “Docker Fortgeschritten”, der Zustand als eigentliches Risiko.

  2. Persistenz & Init-Skripte live (30 min): das Datenverzeichnis je Engine als Volume, Erstinit vs. Neustart-Verhalten von /docker-entrypoint-initdb.d live demonstriert.

  3. Hands-on 1: MariaDB mit Compose + Init + Volume-Beweis (45 min): eigene compose.yaml und init/01_schema.sql anlegen, Stack starten, Log-Beweis für den Erstinit prüfen, Container löschen (nicht das Volume) und neu starten.

  4. Backup/Restore-Pattern (20 min): ein konsistentes Verfahren über einen ephemeren Backup-Container statt Ad-hoc-Befehle im laufenden Datenbank-Container.

  5. Hands-on 2: PostgreSQL Backup/Restore + Datencheck (45 min): Postgres per Init-Skript befüllen, pg_dump über einen –rm-Einmal-Container ausführen, Original-Datenbank und -Volume löschen, aus dem Dump restaurieren.

  6. Fallstricke & Abgrenzung, kurzer Ausblick MongoDB/Redis ohne Hands-on (15 min): Volume-Mount-Fehler, :latest-Tag-Risiko, Alpine/musl-Locale, MongoDB-Auth-Default, MariaDB↔MySQL-Migrationsgrenzen.

  7. Abschluss/Q&A (10 min): offene Fragen, Einordnung in die weiteren Docker-Aufbaumodule.

Hands-on Inhalte (Auszug)

Persistenz & Init-Skripte

  • Das Datenverzeichnis je Engine als das eine Verzeichnis, das wirklich ein Volume braucht
  • /docker-entrypoint-initdb.d: Skripte laufen nur beim Erstinit auf leerem Datenverzeichnis, nicht bei jedem Neustart
  • Live-Beweis über die Container-Logs, wann der Init tatsächlich ausgeführt wurde

Hands-on 1: MariaDB-Volume-Beweis

  • Eigene compose.yaml und init/01_schema.sql aus dem Nichts aufbauen
  • Container komplett löschen, Volume bewusst stehen lassen
  • SELECT * FROM kunden liefert nach dem Neustart weiterhin dieselben Daten

Hands-on 2: PostgreSQL Backup/Restore

  • pg_dump über einen ephemeren –rm-Container gegen die laufende Datenbank
  • Originaldatenbank samt Volume vollständig löschen – echter, beabsichtigter Datenverlust
  • Restore aus dem Dump, Beweis per Query: exakt dieselben Zeilen wie vor dem Datenverlust

Fallstricke & Secrets

  • Datenverlust durch falschen oder fehlenden Volume-Mount, :latest-Tag-Risiko bei Versionssprüngen
  • Alpine/musl-Locale-Abweichungen, unsichere Auth-Defaults wie MongoDB ohne –auth
  • MariaDB↔MySQL nur uninitialisiert kompatibel, Zugangsdaten über das _FILE-Pattern

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zum erfolgreichen Restore, Ergebnis der beiden Hands-on-Übungen) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Explizit nicht Teil dieses Kurses

  • • Compose- und Netzwerk-Grundlagen (compose.yaml-Grundstruktur, Service Discovery, internal: true) – vorausgesetzt aus Docker Fortgeschritten und hier nicht wiederholt.
  • • Monitoring, Ressourcen-Limits und eine eigene Registry für Datenbank- oder andere Container – Thema von Docker Betrieb.
  • • Cluster-/Multi-Host-Orchestrierung von Datenbank-Services (z. B. ein MongoDB-Replica-Set über docker stack deploy) – Thema von Docker Swarm Hands-on.
  • • Datenbank-Persistenz auf Kubernetes (PersistentVolume/PersistentVolumeClaim, StatefulSet) – Thema von Docker & Kubernetes sowie den eigenständigen Kubernetes-Aufbaumodulen zu Storage und StatefulSets.
  • • MongoDB und Redis als eigenes Hands-on – beide werden in Modul 6 konzeptionell eingeordnet (Auth-Default, Persistenzmodell), aber nicht praktisch geübt.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übungen auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen