Datenbanken gehören zu den wichtigsten Komponenten einer IT-Infrastruktur. Egal ob Webanwendung, Onlineshop, Monitoring-System oder Unternehmenssoftware – sobald Informationen dauerhaft gespeichert werden müssen, kommt in vielen Fällen eine Datenbank zum Einsatz. Während es inzwischen selbstverständlich geworden ist, Webserver und Anwendungen in Docker-Containern bereitzustellen, sieht die Diskussion bei Datenbanken häufig anders aus.
Immer wieder hört man die Aussage, dass Datenbanken nicht in Container gehören. Schließlich seien Container kurzlebig, während Datenbanken ihre Informationen dauerhaft speichern müssen. Andere Administratoren betreiben PostgreSQL, MySQL oder MariaDB seit Jahren erfolgreich in Containern und sehen darin überhaupt kein Problem.
Doch wer hat recht? Sind Datenbanken im Container tatsächlich eine schlechte Idee oder handelt es sich eher um ein Missverständnis darüber, wie Container funktionieren?
Meiner Meinung nach lässt sich diese Frage nicht pauschal beantworten. Denn entscheidend ist nicht, ob eine Datenbank in einem Container läuft, sondern wie ihre Daten gespeichert werden, welche Anforderungen an die Verfügbarkeit bestehen und wie gut die Umgebung administriert wird.
In diesem Artikel schauen wir uns deshalb an, wie Datenbanken innerhalb von Docker funktionieren, welche Rolle Volumes spielen und worauf du beim produktiven Betrieb achten solltest. Außerdem beschäftigen wir uns mit Backups, Performance, Sicherheit und der Frage, ob Kubernetes eine geeignete Plattform für zustandsbehaftete Anwendungen ist.
Datenbanken im Container – warum wird darüber überhaupt diskutiert?
Um die Diskussion zu verstehen, müssen wir zunächst zwischen zwei unterschiedlichen Arten von Anwendungen unterscheiden: zustandslosen und zustandsbehafteten Anwendungen.
Eine klassische Webanwendung kann unter bestimmten Voraussetzungen zustandslos betrieben werden. Das bedeutet, dass eine einzelne Instanz keine dauerhaft benötigten Informationen in ihrem lokalen Dateisystem speichert. Wird der Container beendet, kann einfach eine neue Instanz gestartet werden, ohne dass wichtige Anwendungsdaten verloren gehen.
Bei Datenbanken sieht die Situation anders aus. Hier besteht die eigentliche Aufgabe gerade darin, Daten dauerhaft und zuverlässig zu speichern. Benutzerkonten, Bestellungen, Konfigurationen oder Geschäftsprozesse dürfen nicht verschwinden, nur weil ein Container neu erstellt wird.
Genau an dieser Stelle entsteht häufig das Missverständnis. Container werden gerne als kurzlebige oder austauschbare Laufzeitumgebungen beschrieben. Daraus wird manchmal abgeleitet, dass sie grundsätzlich ungeeignet für Anwendungen mit dauerhaftem Speicherbedarf seien.
Allerdings muss man zwischen dem Lebenszyklus eines Containers und dem Lebenszyklus seiner Daten unterscheiden.
Ein Container kann jederzeit entfernt und durch eine neue Instanz ersetzt werden. Seine Daten müssen deshalb aber nicht ebenfalls gelöscht werden. Voraussetzung ist lediglich, dass der Speicher unabhängig vom Container verwaltet wird.
Und genau hier kommen Docker Volumes, Bind Mounts und bei Kubernetes sogenannte Persistent Volumes ins Spiel.
Wie funktioniert eine Datenbank innerhalb eines Containers?
Technisch betrachtet ist eine Datenbank innerhalb eines Containers zunächst nichts Besonderes. PostgreSQL oder MySQL laufen dort ebenfalls als gewöhnliche Prozesse. Der wesentliche Unterschied zu einer klassischen Installation besteht darin, dass diese Prozesse innerhalb einer isolierten Container-Umgebung gestartet werden.
Das entsprechende Container-Image enthält normalerweise bereits die benötigten Programmdateien, Bibliotheken und Startskripte. Dadurch musst du die Datenbanksoftware nicht direkt auf dem Host-Betriebssystem installieren.
Bei PostgreSQL könnte beispielsweise ein offizielles Container-Image verwendet werden. Dieses bringt die benötigte PostgreSQL-Installation mit und ermöglicht es, die Datenbank über definierte Umgebungsvariablen zu initialisieren.
Der Vorteil liegt vor allem in der reproduzierbaren Bereitstellung. Statt auf mehreren Servern manuell dieselbe Datenbankversion zu installieren, kannst du ein festgelegtes Image verwenden. Außerdem lassen sich unterschiedliche Versionen leichter voneinander isolieren, solange die notwendigen Ressourcen vorhanden sind.
Allerdings darf man nicht vergessen, dass Container weiterhin den Kernel des Hosts verwenden. Auch Festplattenzugriffe, Netzwerkverbindungen und CPU-Ressourcen laufen letztlich über die zugrunde liegende Infrastruktur.
Ein Container macht eine Datenbank deshalb weder automatisch schneller noch zuverlässiger. Vielmehr bietet er eine standardisierte Umgebung, in der die Datenbank ausgeführt wird.
Warum persistenter Speicher bei Datenbanken entscheidend ist
Wenn du eine Datenbank einfach in einem Container startest, kann es zunächst so aussehen, als wäre bereits alles erledigt. Die Datenbank läuft, Verbindungen werden akzeptiert und neue Tabellen können erstellt werden.
Problematisch wird es jedoch, wenn die benötigten Daten ausschließlich in der beschreibbaren Dateisystemebene des Containers gespeichert werden.
Diese Ebene gehört zur jeweiligen Container-Instanz. Wird der Container gelöscht, verschwindet normalerweise auch seine beschreibbare Ebene. Ein einfacher Neustart desselben Containers ist dabei nicht das Problem, wohl aber das Entfernen und anschließende Neuerstellen ohne korrekt eingebundenen persistenten Speicher.
Deshalb sollte eine produktive Datenbank ihre Daten niemals ausschließlich innerhalb dieser kurzlebigen Ebene speichern.
Docker bietet dafür verschiedene Möglichkeiten. Besonders verbreitet sind Volumes und Bind Mounts. Beide können Daten außerhalb der beschreibbaren Container-Ebene speichern, unterscheiden sich jedoch in ihrer Verwaltung.
Docker Volumes für Datenbanken verwenden
Ein Docker Volume ist ein Speicherbereich, der von Docker verwaltet wird. Er existiert unabhängig von einer einzelnen Container-Instanz und kann beim Erstellen eines neuen Containers erneut eingebunden werden.
Das bedeutet, dass du einen Datenbank-Container aktualisieren oder ersetzen kannst, während seine Daten weiterhin im Volume gespeichert bleiben.
Ein Volume lässt sich beispielsweise mit folgendem Befehl erstellen:
docker volume create postgres_dataAnschließend kannst du das Volume bei einem Datenbank-Container einbinden.
Dadurch werden die Daten unabhängig vom eigentlichen Container gespeichert. Allerdings solltest du bedenken, dass ein Docker Volume zunächst an die vorhandene Docker-Infrastruktur gebunden ist. Wird der komplette Host beschädigt oder fällt das zugrunde liegende Storage aus, kann auch das Volume betroffen sein.
Ein Volume sorgt also für Persistenz, ist aber noch keine vollständige Backup- oder Hochverfügbarkeitslösung.
Bind Mounts als Alternative
Eine weitere Möglichkeit besteht darin, ein Verzeichnis des Hosts direkt in den Container einzubinden. Diese Technik wird als Bind Mount bezeichnet.
Der Vorteil liegt darin, dass du den Speicherort selbst festlegen kannst. Beispielsweise könnten die Daten auf einem separaten Dateisystem oder einem speziell vorgesehenen Storage-Bereich liegen.
Allerdings musst du dabei auf die richtigen Zugriffsrechte achten. Außerdem solltest du das Verzeichnis nicht unkontrolliert verändern, während die Datenbank darauf zugreift.
Für kleinere Umgebungen können beide Varianten sinnvoll sein. In vielen Docker-Installationen sind benannte Volumes jedoch die unkompliziertere Lösung.
Praxisbeispiel: PostgreSQL mit Docker starten
Schauen wir uns an, wie eine PostgreSQL-Datenbank mit Docker bereitgestellt werden kann.
Für dieses Beispiel verwenden wir PostgreSQL 18 und ein benanntes Docker Volume. Wichtig ist, dass sich bei der offiziellen PostgreSQL-Image-Reihe ab Version 18 der vorgesehene Volume-Mount-Pfad geändert hat. Deshalb verwenden wir hier /var/lib/postgresql und nicht einfach den aus älteren Tutorials bekannten Pfad.
Zunächst erstellen wir unser Volume:
docker volume create postgres_dataDanach starten wir den PostgreSQL-Container:
docker run -d \
--name postgres-db \
-e POSTGRES_USER=appuser \
-e POSTGRES_PASSWORD='NurEinLokalesTestpasswort123!' \
-e POSTGRES_DB=appdb \
-v postgres_data:/var/lib/postgresql \
postgres:18Mit diesem Befehl wird eine PostgreSQL-Datenbank erstellt. Der Benutzer heißt appuser, während die Datenbank den Namen appdb erhält.
Das Volume postgres_data wird unter dem vorgesehenen Datenverzeichnis eingebunden. Dadurch bleiben die Daten unabhängig vom Container bestehen.
Das hier verwendete Passwort dient ausschließlich als Beispiel für eine lokale Testumgebung. In produktiven Installationen solltest du Passwörter nicht direkt in Shell-Befehlen oder öffentlich zugänglichen Konfigurationsdateien speichern.
Interessant ist außerdem, dass wir keinen Datenbank-Port auf dem Host veröffentlicht haben. Für einen ersten lokalen Test ist das auch nicht notwendig, da wir direkt innerhalb des Containers auf PostgreSQL zugreifen können.
Verbindung zur Datenbank herstellen
Nachdem der Container gestartet wurde, überprüfen wir zunächst seinen Status:
docker psZusätzlich können wir uns die Logausgaben anschauen:
docker logs postgres-dbWenn PostgreSQL erfolgreich gestartet ist, können wir über den PostgreSQL-Client eine Verbindung herstellen:
docker exec -it postgres-db \
psql -U appuser -d appdbInnerhalb der Datenbank können wir anschließend eine einfache Tabelle erstellen:
CREATE TABLE testdaten (
id SERIAL PRIMARY KEY,
name VARCHAR(100)
);
INSERT INTO testdaten (name)
VALUES ('Container Test');
SELECT * FROM testdaten;Damit haben wir unsere ersten Daten innerhalb der PostgreSQL-Datenbank gespeichert.
Jetzt können wir testen, ob diese Daten auch nach dem Entfernen des Containers erhalten bleiben.
Persistenz überprüfen
Beende zunächst die PostgreSQL-Sitzung mit \q. Anschließend stoppen und entfernen wir den Container:
docker stop postgres-db
docker rm postgres-dbDas Docker Volume bleibt bestehen. Deshalb können wir einen neuen Container mit derselben PostgreSQL-Hauptversion starten und das vorhandene Volume wieder einbinden:
docker run -d \
--name postgres-db \
-v postgres_data:/var/lib/postgresql \
postgres:18Da das Datenverzeichnis bereits initialisiert wurde, verwendet PostgreSQL die vorhandenen Daten. Die ursprünglichen Initialisierungsvariablen werden für die bestehende Datenbank nicht erneut angewendet.
Mit folgendem Befehl können wir unsere Tabelle überprüfen:
docker exec -it postgres-db \
psql -U appuser -d appdb \
-c "SELECT * FROM testdaten;"Der zuvor gespeicherte Eintrag sollte weiterhin vorhanden sein.
Dieses einfache Beispiel zeigt bereits, warum die Aussage, Container könnten keine Daten dauerhaft speichern, technisch nicht korrekt ist.
Entscheidend ist die richtige Trennung zwischen Container und persistentem Speicher.
Docker Compose vereinfacht den Datenbankbetrieb
Einzelne Docker-Befehle sind praktisch, um die Grundlagen zu verstehen. Sobald mehrere Container oder zusätzliche Konfigurationen benötigt werden, wird die Verwaltung über die Kommandozeile jedoch schnell unübersichtlich.
Deshalb verwende ich für zusammengehörige Container-Anwendungen lieber eine deklarative Konfiguration mit Docker Compose.
Damit lässt sich festlegen, welche Images verwendet werden, welche Volumes benötigt werden und welche Netzwerkverbindungen zwischen den Diensten bestehen.
Ein einfaches Beispiel für PostgreSQL sieht so aus:
services:
postgres:
image: postgres:18
restart: unless-stopped
environment:
POSTGRES_USER: appuser
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: appdb
volumes:
- postgres_data:/var/lib/postgresql
healthcheck:
test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
interval: 10s
timeout: 5s
retries: 5
volumes:
postgres_data:Das Datenbankpasswort wird in diesem Beispiel über eine Umgebungsvariable bereitgestellt. Für einen lokalen Test kannst du eine entsprechende Variable in deiner Shell setzen oder eine nicht versionierte, zugriffsgeschützte Umgebungsdatei verwenden. Für produktive Umgebungen sollte eine geeignete Secret-Verwaltung eingesetzt werden.
Mit folgendem Befehl lässt sich die Umgebung starten:
docker compose up -dEin Vorteil dieser Variante liegt darin, dass die Konfiguration nachvollziehbar und reproduzierbar bleibt. Dadurch lassen sich Entwicklungs- und Testumgebungen leichter aufbauen.
Allerdings gilt auch hier: Docker Compose ersetzt weder ein Backup-Konzept noch eine Überwachung der Datenbank.
Datenbanken im Container: Welche Rolle spielt die Performance?
Bei produktiven Datenbanken ist die Performance ein besonders wichtiger Punkt. Schließlich müssen Abfragen schnell verarbeitet und Schreiboperationen zuverlässig auf dem Storage gespeichert werden.
Grundsätzlich muss eine Datenbank innerhalb eines Containers nicht wesentlich langsamer sein als eine direkt auf dem Host installierte Datenbank.
Container nutzen unter Linux denselben Kernel wie andere Prozesse. Deshalb entsteht nicht automatisch derselbe zusätzliche Aufwand wie bei einem vollständigen Gastbetriebssystem.
Allerdings hängt die tatsächliche Leistung stark von der Storage-Konfiguration ab.
Ein langsames Netzlaufwerk, ungünstige Dateisystemeinstellungen oder überlastete Storage-Systeme können eine Datenbank erheblich beeinträchtigen. Das gilt unabhängig davon, ob sie innerhalb eines Containers oder auf einer virtuellen Maschine betrieben wird.
Besonders wichtig sind dabei zufällige Lese- und Schreibzugriffe, Latenzen und das Verhalten bei synchronen Schreiboperationen.
Hinzu kommt, dass Datenbanken häufig große Mengen Arbeitsspeicher für Caching und interne Prozesse verwenden. Werden die Container-Limits zu niedrig angesetzt, kann dies die Performance verschlechtern oder sogar zum Beenden des Datenbankprozesses führen.
Deshalb solltest du Ressourcenlimits nicht einfach möglichst klein wählen, sondern anhand realer Lasttests und Messwerte festlegen.
Für die Bewertung der Performance ist ein Vergleich unter ähnlichen Bedingungen sinnvoll. Nur so lässt sich feststellen, ob tatsächlich die Container-Umgebung oder eine andere Komponente der Infrastruktur die Ursache für Leistungseinbußen ist.
Backups: Der wichtigste Punkt beim produktiven Betrieb
Eine Datenbank kann technisch perfekt innerhalb eines Containers laufen und trotzdem ein erhebliches Betriebsrisiko darstellen, wenn keine funktionierenden Backups vorhanden sind.
Gerade bei diesem Thema würde ich keine Kompromisse eingehen.
Ein Docker Volume sorgt lediglich dafür, dass Daten beim Entfernen eines Containers nicht automatisch verschwinden. Wird das Volume jedoch beschädigt, versehentlich gelöscht oder durch einen Hardwaredefekt unbrauchbar, hilft diese Form der Persistenz alleine nicht weiter.
Deshalb benötigst du eine unabhängige Datensicherung.
Bei PostgreSQL lassen sich beispielsweise logische Backups mit pg_dump erstellen.
Für unsere Testdatenbank könnte der Befehl folgendermaßen aussehen:
docker exec postgres-db \
pg_dump -U appuser -d appdb \
> backup.sqlHierbei wird die Datenbank über pg_dump exportiert. Die Shell-Umleitung sorgt dafür, dass die Backup-Datei auf dem Rechner gespeichert wird, auf dem der Befehl ausgeführt wird.
Zum Wiederherstellen in eine bereits vorhandene, geeignete Zieldatenbank kann beispielsweise folgender Befehl verwendet werden:
docker exec -i postgres-db \
psql -U appuser -d appdb \
< backup.sqlEine Wiederherstellung sollte allerdings zunächst in einer separaten Testdatenbank erfolgen. Beim Import in eine bereits befüllte Datenbank können Konflikte entstehen.
Für größere produktive PostgreSQL-Umgebungen können außerdem physische Backups und die Archivierung von Write-Ahead-Logs sinnvoll sein. Damit lassen sich je nach Konfiguration auch Wiederherstellungen auf bestimmte Zeitpunkte ermöglichen.
Entscheidend ist dabei nicht nur, dass regelmäßig Sicherungen erstellt werden. Du musst auch prüfen, ob sich diese Sicherungen tatsächlich wiederherstellen lassen.
Ein Backup, das noch nie getestet wurde, bietet nur eingeschränkte Sicherheit.
Wie sieht es mit MySQL und MariaDB in Containern aus?
Die bisher beschriebenen Grundlagen gelten nicht nur für PostgreSQL. Auch MySQL und MariaDB lassen sich in Docker-Containern betreiben.
Allerdings unterscheiden sich die Images hinsichtlich ihrer Konfiguration, Initialisierung und Datenverzeichnisse.
Bei MySQL wird häufig das Verzeichnis /var/lib/mysql für persistente Daten verwendet. Die genauen Vorgaben solltest du jedoch immer anhand der verwendeten Image-Version überprüfen.
Auch beim Backup unterscheiden sich die verfügbaren Verfahren. Neben logischen Datenbank-Dumps können bei größeren Installationen weitere datenbankspezifische Sicherungs- und Replikationsmechanismen eingesetzt werden.
Der entscheidende Grundsatz bleibt dennoch gleich: Die Datenbanksoftware kann als Container betrieben werden, während ihre Daten unabhängig vom Container gespeichert werden.
Dadurch lassen sich Datenbank-Images leichter austauschen, solange Kompatibilität und Upgrade-Prozesse berücksichtigt werden.
Datenbanken in Kubernetes – sinnvoll oder unnötig kompliziert?
Während Docker für einzelne Datenbank-Container relativ unkompliziert ist, wird der Betrieb innerhalb von Kubernetes deutlich komplexer.
Das liegt hauptsächlich daran, dass Kubernetes ursprünglich besonders gut für die Verwaltung austauschbarer, containerisierter Anwendungen geeignet ist.
Bei zustandslosen Anwendungen lässt sich ein ausgefallener Pod häufig problemlos durch einen neuen ersetzen.
Bei einer Datenbank reicht das jedoch nicht aus. Neben dem eigentlichen Datenbankprozess müssen auch der persistente Speicher, die Datenkonsistenz und möglicherweise die Replikation berücksichtigt werden.
Deshalb stellt Kubernetes spezielle Mechanismen für zustandsbehaftete Anwendungen bereit.
StatefulSets für zustandsbehaftete Anwendungen
Ein wichtiges Kubernetes-Objekt für diesen Anwendungsbereich ist das StatefulSet.
Anders als ein klassisches Deployment ermöglicht ein StatefulSet die Verwaltung von Pods mit stabilen Identitäten.
Das ist beispielsweise dann relevant, wenn mehrere Datenbankinstanzen unterschiedliche Rollen innerhalb eines Clusters übernehmen oder an bestimmte Speicherbereiche gebunden bleiben müssen.
Ein StatefulSet kann zusammen mit PersistentVolumeClaims verwendet werden, um den einzelnen Pods eigene Speicherressourcen zuzuordnen.
Wird ein Pod ersetzt, kann der neue Pod wieder auf den zugehörigen persistenten Speicher zugreifen, sofern die Storage-Infrastruktur dies ermöglicht.
Allerdings solltest du einen Punkt nicht übersehen: Ein StatefulSet alleine macht aus einer einzelnen PostgreSQL-Instanz noch keinen hochverfügbaren Datenbank-Cluster.
Replikation, automatisches Failover und Datenkonsistenz müssen weiterhin durch geeignete Datenbankmechanismen oder zusätzliche Werkzeuge umgesetzt werden.
Persistent Volumes und PersistentVolumeClaims
In Kubernetes wird persistenter Speicher über ein eigenes Ressourcenmodell verwaltet.
Ein PersistentVolume stellt dabei eine Speicherressource innerhalb des Clusters dar. Ein PersistentVolumeClaim beschreibt dagegen die Speicheranforderung einer Anwendung.
Mit einer StorageClass können Administratoren festlegen, wie Speicher dynamisch bereitgestellt werden soll.
Dadurch lässt sich der Speicher von der eigentlichen Anwendungskonfiguration trennen.
Das klingt zunächst komfortabel. In der Praxis hängt die Zuverlässigkeit jedoch stark vom verwendeten Storage-System ab.
Gerade bei Datenbanken solltest du deshalb genau verstehen, wie sich das Storage bei Node-Ausfällen, Netzwerkunterbrechungen und erneuten Pod-Zuweisungen verhält.
Ein PersistentVolume ist schließlich keine Garantie dafür, dass die Daten jederzeit verfügbar sind.
Datenbank-Operatoren in Kubernetes
Eine weitere Möglichkeit für den Betrieb von Datenbanken innerhalb eines Kubernetes-Clusters bieten sogenannte Operatoren.
Ein Kubernetes Operator erweitert die Plattform um anwendungsspezifische Verwaltungslogik.
Bei einer Datenbank kann das beispielsweise bedeuten, dass bestimmte Aufgaben rund um Initialisierung, Replikation, Backups und Failover automatisiert werden.
Für PostgreSQL existieren verschiedene Operator-Projekte, beispielsweise CloudNativePG.
Solche Lösungen können den Betrieb erheblich vereinfachen, weil sie wiederkehrende Administrationsaufgaben automatisieren.
Allerdings sollte man auch hier vorsichtig sein. Ein Operator nimmt dir nicht automatisch die Verantwortung für die Datenbank ab.
Du musst weiterhin verstehen, wie die Replikation funktioniert, welche Backup-Verfahren verwendet werden und wie sich die Datenbank nach einem vollständigen Ausfall wiederherstellen lässt.
Gerade bei produktiven Datenbanken ist es deshalb sinnvoll, die eingesetzten Operatoren und deren Wiederherstellungsverfahren zunächst ausführlich zu testen.
Sicherheit: Datenbank-Container richtig absichern
Beim Thema Sicherheit unterscheidet sich eine containerisierte Datenbank grundsätzlich nicht von einer klassischen Datenbankinstallation: Unnötige Zugriffe sollten vermieden und Berechtigungen möglichst eingeschränkt werden.
Allerdings kommen durch die Container-Umgebung zusätzliche Aspekte hinzu.
Ein besonders häufiger Fehler besteht darin, Datenbankports ohne ausreichenden Grund öffentlich erreichbar zu machen.
Wenn beispielsweise eine Webanwendung und eine PostgreSQL-Datenbank innerhalb desselben Docker-Netzwerks laufen, muss die Datenbank normalerweise nicht über einen öffentlichen Host-Port erreichbar sein.
Stattdessen kann die Anwendung direkt über den internen Dienstnamen kommunizieren.
Außerdem solltest du folgende Punkte berücksichtigen:
- Verwende möglichst konkrete und freigegebene Image-Versionen.
- Aktualisiere Datenbanksoftware und Host-System regelmäßig.
- Speichere Passwörter nicht fest innerhalb von Container-Images.
- Verwende getrennte Benutzerkonten mit minimal notwendigen Berechtigungen.
- Beschränke den Netzwerkzugriff auf benötigte Anwendungen.
- Prüfe Zugriffsrechte auf Volumes und Konfigurationsdateien.
- Vermeide unnötig privilegierte Container.
- Nutze geeignete Verschlüsselung für Verbindungen und vertrauliche Daten.
Auch der Schutz der Backups gehört zum Sicherheitskonzept. Schließlich enthalten Datenbanksicherungen häufig dieselben vertraulichen Informationen wie das produktive System.
Was passiert bei einem Datenbank-Update?
Ein großer Vorteil von Containern ist die einfache Austauschbarkeit der Laufzeitumgebung.
Allerdings solltest du diesen Vorteil bei Datenbanken nicht mit einem beliebig einfachen Versionswechsel verwechseln.
Während ein Webserver häufig durch einen Container mit einer neuen Image-Version ersetzt werden kann, erfordern Datenbanken unter Umständen ein eigenes Upgrade-Verfahren.
Besonders bei einem Wechsel zwischen PostgreSQL-Hauptversionen können Änderungen am Datenformat oder notwendige Migrationsschritte relevant werden.
Es reicht deshalb nicht grundsätzlich aus, einfach den Image-Tag zu ändern und denselben Datenbestand mit einer neueren Hauptversion zu starten.
Stattdessen solltest du dich an die dokumentierten Upgrade-Verfahren der jeweiligen Datenbank halten.
Ein sinnvoller Ablauf umfasst normalerweise ein aktuelles und überprüftes Backup, einen Test des Upgrades, die Prüfung der Anwendungskompatibilität und einen klaren Wiederherstellungsplan.
Außerdem sollten Images möglichst über feste Versionen oder Digests referenziert werden, damit nicht unbemerkt andere Softwarestände zum Einsatz kommen.
Wann würde ich eine Datenbank im Container betreiben?
Für Entwicklungsumgebungen ist meine Einschätzung relativ eindeutig. Hier bieten Datenbank-Container zahlreiche Vorteile.
Wenn Entwickler für ein Projekt PostgreSQL, MySQL oder Redis benötigen, lässt sich die passende Umgebung mit Docker Compose häufig innerhalb kurzer Zeit bereitstellen.
Dadurch entfallen viele manuelle Installationsschritte. Außerdem kann jedes Projekt seine benötigten Datenbankversionen verwenden, ohne andere Anwendungen auf dem Rechner zu beeinflussen.
Auch für Integrationstests und temporäre Testumgebungen eignen sich Datenbank-Container hervorragend.
Bei produktiven Anwendungen würde ich dagegen genauer hinschauen.
Eine kleinere Webanwendung mit überschaubaren Anforderungen kann durchaus mit einer PostgreSQL-Datenbank in Docker betrieben werden. Voraussetzung ist allerdings, dass persistenter Speicher, Monitoring, Updates und Backups vernünftig umgesetzt sind.
Bei größeren, geschäftskritischen Datenbanken spielen dagegen weitere Anforderungen eine Rolle. Dazu gehören Hochverfügbarkeit, Replikation, garantierte Wiederherstellungszeiten und die Belastbarkeit der Storage-Infrastruktur.
In diesen Fällen kann eine Datenbank innerhalb von Kubernetes sinnvoll sein, insbesondere wenn bereits entsprechende Betriebskenntnisse vorhanden sind.
Genauso kann es aber die bessere Entscheidung sein, die Datenbank außerhalb des Kubernetes-Clusters auf einer virtuellen Maschine oder als Managed Database Service zu betreiben.
Die Anwendung selbst kann trotzdem vollständig containerisiert sein.
Für mich ist das kein Widerspruch, sondern eine saubere Trennung unterschiedlicher Anforderungen.
Die häufigsten Fehler beim Betrieb von Datenbanken in Containern
Viele Probleme entstehen nicht dadurch, dass eine Datenbank containerisiert wurde, sondern durch unzureichende Planung.
Besonders häufig sehe ich in Beispielkonfigurationen Datenbanken ohne bewusst konfigurierten persistenten Speicher. Solche Umgebungen funktionieren möglicherweise zunächst problemlos, können aber beim Neuerstellen eines Containers zu unangenehmen Überraschungen führen.
Ein weiterer Fehler ist die Annahme, dass ein vorhandenes Volume bereits ein Backup ersetzt. Tatsächlich schützt ein Volume nicht zuverlässig vor Hardwareausfällen, beschädigten Daten oder versehentlichen Löschungen.
Auch die Ressourcenplanung wird gerne unterschätzt. Eine Datenbank benötigt ausreichend Arbeitsspeicher, zuverlässigen Storage und genügend Reserven für Lastspitzen.
Hinzu kommen unkontrollierte Updates, öffentlich erreichbare Datenbankports und fehlendes Monitoring.
Wenn du diese Punkte von Anfang an berücksichtigst, lassen sich viele typische Probleme bereits vermeiden.
Häufig gestellte Fragen zu Datenbanken im Container
Kann man PostgreSQL produktiv in Docker betreiben?
Ja, PostgreSQL kann produktiv innerhalb eines Docker-Containers betrieben werden. Entscheidend sind eine geeignete Storage-Konfiguration, regelmäßige Backups, Monitoring, Sicherheitsmaßnahmen und ein dokumentiertes Update-Verfahren. Die Containerisierung alleine macht den Betrieb weder sicher noch unsicher.
Gehen Daten verloren, wenn ein Container neu gestartet wird?
Ein normaler Neustart desselben Containers führt nicht automatisch zum Verlust seiner Daten. Problematisch wird es insbesondere beim Entfernen und Neuerstellen des Containers, wenn benötigte Daten nur in der beschreibbaren Container-Ebene gespeichert wurden. Deshalb sollten Datenbanken persistenten Speicher verwenden.
Sind Datenbanken im Container langsamer?
Nicht grundsätzlich. Eine containerisierte Datenbank kann eine vergleichbare Leistung wie eine direkt auf dem Host installierte Datenbank erreichen. Entscheidend sind unter anderem Storage-Latenzen, Ressourcenlimits, Dateisystem und die Datenbankkonfiguration.
Ist ein Docker Volume ein Backup?
Nein. Ein Docker Volume ermöglicht die dauerhafte Speicherung von Daten unabhängig von einer Container-Instanz. Es ersetzt jedoch keine separate Datensicherung und schützt nicht automatisch vor defekten Festplatten, beschädigten Daten oder versehentlichem Löschen.
Sollte man Datenbanken in Kubernetes betreiben?
Das hängt von den Anforderungen und den vorhandenen Betriebskenntnissen ab. Kubernetes bietet mit StatefulSets, PersistentVolumeClaims und Operatoren geeignete Mechanismen für zustandsbehaftete Anwendungen. Allerdings benötigen produktive Datenbanken weiterhin ein durchdachtes Konzept für Storage, Replikation, Backups und Wiederherstellung.
Was ist besser: Datenbank im Container oder virtuelle Maschine?
Beide Varianten können sinnvoll sein. Eine virtuelle Maschine stellt eine vollständige Betriebssystemumgebung bereit, während ein Container eine standardisierte und meist ressourcenschonendere Laufzeitumgebung ermöglicht. Die bessere Lösung hängt von Verfügbarkeit, Performance, Administrationsaufwand und vorhandener Infrastruktur ab.
Fazit: Datenbanken im Container sind kein grundsätzliches Problem
Die Frage, ob Datenbanken in Containern betrieben werden sollten, wird häufig zu pauschal beantwortet.
Natürlich haben Datenbanken besondere Anforderungen. Im Gegensatz zu vielen zustandslosen Anwendungen müssen sie Informationen dauerhaft und konsistent speichern. Deshalb reichen ein funktionierender Container und ein gestarteter Datenbankprozess für einen zuverlässigen Betrieb noch lange nicht aus.
Allerdings bedeutet das nicht, dass Container grundsätzlich ungeeignet wären.
Mit persistentem Speicher, einer sauberen Konfiguration und einem funktionierenden Backup-Konzept können PostgreSQL, MySQL und andere Datenbanken durchaus zuverlässig in Docker-Umgebungen betrieben werden.
Auch Kubernetes bietet mit StatefulSets, Persistent Volumes und spezialisierten Operatoren Möglichkeiten, Datenbanken zu verwalten. Dennoch sollte man den zusätzlichen Betriebsaufwand nicht unterschätzen.
Gerade bei geschäftskritischen Anwendungen würde ich deshalb zuerst die Anforderungen an Verfügbarkeit, Wiederherstellung und Storage untersuchen, bevor ich mich für eine bestimmte Plattform entscheide.
Mein persönlicher Ansatz wäre, zunächst mit einer kleinen PostgreSQL-Testumgebung zu beginnen. Erstelle ein Docker Volume, starte eine Datenbank, speichere einige Datensätze und entferne anschließend den Container. Wenn du danach dieselben Daten wiederverwenden kannst, hast du bereits ein wichtiges Grundprinzip verstanden.
Im nächsten Schritt würde ich ein Backup erstellen und die Wiederherstellung auf einer neuen Umgebung testen. Denn genau dort zeigt sich, ob du deine Datenbank tatsächlich unter Kontrolle hast.
Mein Fazit: Nicht der Container ist das Risiko, sondern eine Datenbank ohne durchdachtes Storage-, Sicherheits- und Backup-Konzept.
Wenn diese Grundlagen berücksichtigt werden, können Datenbanken im Container eine ebenso praktische wie sinnvolle Lösung sein. Entscheidend ist letztlich nicht, ob du Docker, Kubernetes oder virtuelle Maschinen verwendest, sondern ob die gewählte Architektur zu deinen Anforderungen passt und zuverlässig betrieben werden kann.
Weiterführende Informationen
Weitere technische Informationen findest du in der offiziellen Docker-Dokumentation zu Volumes.
Für PostgreSQL lohnt sich außerdem ein Blick auf das offizielle PostgreSQL-Container-Image, insbesondere auf die Hinweise zu Datenverzeichnissen und Versionen.
Wenn du dich näher mit Datenbanken in Kubernetes beschäftigen möchtest, findest du zusätzliche Informationen in der Kubernetes-Dokumentation zu StatefulSets.