PostgreSQL und MySQL in Docker einrichten: Compose, Volumes und Backup

Wie richten Sie PostgreSQL und MySQL in Docker ein?

PostgreSQL und MySQL in Docker einzurichten heißt, das offizielle Image zu laden, einen Container zu starten, das Passwort per Umgebungsvariable oder Secret zu übergeben und das Datenverzeichnis auf ein Volume zu legen. Ohne Volume verschwinden die Daten also mit dem Container. Für die Entwicklung genügen docker run oder Compose, und der Port bleibt auf localhost.

Diese Anleitung richtet sich an Website Betreiber und Entwickler, die eine Datenbank auf dem eigenen Rechner oder dem eigenen VPS betreiben möchten. Außerdem können Sie die Befehle Schritt für Schritt nachvollziehen. Verwaltet Ihr Hostinganbieter die Datenbank für Sie, wissen Sie danach zumindest, welche Fragen Sie ihm stellen sollten.

Wir sind ein Team für digitales Marketing und Web, kein Hostinganbieter. Deshalb stützt sich alles hier auf die offizielle Dokumentation von Docker, das PostgreSQL Image und das MySQL Image. Was Docker ist, erklären wir hier nicht erneut; die Grundlagen finden Sie in unserem Leitfaden zu Docker Containern.

Am Ende des Artikels steht außerdem ganz offen, wann Sie diese Arbeit nicht selbst übernehmen sollten. Denn die Datenbank eines laufenden Shops ist eine ganz andere Verantwortung als ein Lernprojekt.

Wann sollten Sie eine Datenbank in Docker betreiben?

Ein Datenbank Container hilft vor allem bei Entwicklung, Tests und Experimenten. Sie starten zum Beispiel dieselbe Version auf jedem Rechner des Teams mit einem Befehl. Danach löschen Sie den Container, und Ihr Rechner bleibt sauber. Damit verschwinden die meisten "bei mir läuft es"-Probleme.

Im Produktivbetrieb müssen Sie dagegen genauer abwägen, denn die Folgen sind größer. Ein Container allein liefert weder Backups noch Monitoring oder Notfallwiederherstellung. Diese Teile müssen Sie also separat aufbauen. Die Tabelle fasst eine allgemeine Einteilung zusammen, die wir aus der Dokumentation ableiten. Sie ist also ein Entscheidungsrahmen, keine Garantie.

Was brauchen Sie, bevor Sie starten?

Sie brauchen Docker Engine oder Docker Desktop mit dem Compose Plugin. Installieren Sie es zunächst nach der offiziellen Dokumentation. Danach prüfen Sie mit den beiden Befehlen unten, ob alles läuft. Geben beide eine Versionsnummer aus, sind Sie bereit.

docker --version
docker compose version

Außerdem entscheiden Sie drei Dinge. Erstens, welche Datenbank Sie verwenden. Zweitens, wo die Daten liegen. Drittens, wer sich verbindet: nur Ihre Anwendung auf demselben Rechner oder auch ein Werkzeug von außen?

Die dritte Frage bestimmt den Sicherheitsteil dieser Anleitung. Lautet die Antwort "nur meine Anwendung", müssen Sie den Port womöglich gar nicht öffnen. Für die meisten Projekte ist das daher die richtige Antwort.

Welches Image Tag wählen Sie für PostgreSQL und MySQL in Docker?

Auf Docker Hub finden Sie offizielle Images namens postgres und mysql. Zudem listen ihre Seiten die unterstützten Tags auf. Schreiben Sie "latest" als Tag, kann der nächste Download eine andere Hauptversion bringen. Das führt zu Problemen, etwa weil das Datenverzeichnis nicht mehr passt.

Wählen Sie stattdessen ein Tag aus der aktuellen stabilen Linie, die Ihre Anwendung unterstützt. Tragen Sie es dann in Ihre Compose Datei ein und aktualisieren Sie es bewusst. Welche Version zu Ihrer Software passt, steht in deren eigener Dokumentation.

Lesen Sie außerdem vor jedem Wechsel der Hauptversion die Hinweise auf der offiziellen Image Seite erneut. Einzelheiten wie die Änderung des PostgreSQL Volume Pfads, die Sie gleich sehen, stehen nur dort.

Wie starten Sie PostgreSQL in Docker mit docker run?

Zunächst der kürzeste Weg: der Befehl docker run. Das offizielle PostgreSQL Image verlangt die Variable POSTGRES_PASSWORD; laut Docker Hub Seite darf sie nicht leer oder undefiniert sein. Das Beispiel nutzt ein benanntes Volume und öffnet den Port nur auf localhost.

docker run --name beispiel-postgres -d \
  -e POSTGRES_PASSWORD=IHR_STARKES_PASSWORT \
  -e POSTGRES_USER=appnutzer \
  -e POSTGRES_DB=appdb \
  -v pgdaten:/var/lib/postgresql/data \
  -p 127.0.0.1:5432:5432 \
  postgres:IHR_TAG

Ersetzen Sie IHR_TAG durch das Tag Ihrer gewählten Version. Verwenden Sie das Tag latest nicht in einer produktionsnahen Umgebung, denn der nächste Download kann auf eine neue Hauptversion springen. Die aktuelle Tag Liste sehen Sie auf der Docker Hub Seite.

Ein Detail ist wichtig, denn der Pfad hat sich geändert. Laut Docker Hub Dokumentation verschiebt sich der PGDATA Pfad ab PostgreSQL 18 in ein versionsspezifisches Verzeichnis. Der Pfad /var/lib/postgresql/data im Beispiel gilt daher nur für Version 17 und älter. Laden Sie eine neuere Version, lesen Sie den Volume Hinweis dieser Version auf der offiziellen Seite.

Wie starten Sie MySQL in Docker mit docker run?

Im MySQL Image ist die Pflichtvariable MYSQL_ROOT_PASSWORD. Mit MYSQL_DATABASE, MYSQL_USER und MYSQL_PASSWORD legen Sie beim ersten Start eine Datenbank und einen Nutzer an. Das Datenverzeichnis ist /var/lib/mysql, und Sie sollten dort ein Volume einhängen; die offizielle Seite sagt dasselbe.

docker run --name beispiel-mysql -d \
  -e MYSQL_ROOT_PASSWORD=IHR_ROOT_PASSWORT \
  -e MYSQL_DATABASE=appdb \
  -e MYSQL_USER=appnutzer \
  -e MYSQL_PASSWORD=IHR_APP_PASSWORT \
  -v mysqldaten:/var/lib/mysql \
  -p 127.0.0.1:3306:3306 \
  mysql:IHR_TAG

Die MySQL Dokumentation nennt außerdem MYSQL_RANDOM_ROOT_PASSWORD. Geben Sie dort einen nicht leeren Wert wie yes an, erzeugt das Image das Startpasswort selbst, und Sie lesen es später im Container Log. Zudem erlaubt die Option MYSQL_ALLOW_EMPTY_PASSWORD ein leeres Root Passwort. Wir raten davon ab, lassen Sie sie also weg.

Passwörter in die Kommandozeile zu tippen ist bequem, aber riskant, weil sie in Ihrem Shell Verlauf bleiben. Deshalb behandeln die nächsten Abschnitte die .env Datei und die Secret Methode.

Welche Datenbank wählen Sie: PostgreSQL oder MySQL?

Beide sind verbreitete relationale Open Source Datenbanken, und Sie betreiben beide in Docker auf dieselbe Weise. Meist entscheidet also Ihre Anwendung. Wählen Sie, was Ihre Software oder Ihr Framework unterstützt. Fertige Systeme wie WordPress erwarten zum Beispiel MySQL oder eine kompatible Variante.

Startet Ihr Projekt bei null und schreibt keine Software etwas vor, wählen Sie das System, das Ihr Team schon kennt. Ein unbekanntes System zu betreiben macht Backups und Updates schwerer.

Wie halten Volumes die Daten von PostgreSQL und MySQL in Docker sicher?

Das Dateisystem eines Containers ist vorübergehend. Entfernen Sie den Container, gehen die Daten darin somit verloren. Um sie zu behalten, legen Sie das Datenverzeichnis auf ein Volume. Es gibt zwei gängige Wege: ein benanntes Volume, das Docker verwaltet, und einen Bind Mount, der auf einen Ordner des Hosts zeigt.

Mit diesen beiden Befehlen listen Sie Volumes auf und sehen die Details eines Volumes.

docker volume ls
docker volume inspect pgdaten

Achten Sie auf eine Falle. Mit Compose entfernt docker compose down die Container, behält aber die Volumes. Dagegen löscht docker compose down -v auch die Volumes. Ein einziges Flag kann also Ihre ganze Datenbank auslöschen.

Wie verwalten Sie Umgebungsvariablen und Passwörter?

Schreiben Sie das Passwort nicht direkt in die Compose Datei. Legen Sie stattdessen im selben Ordner eine .env Datei an und lesen Sie die Werte daraus. Halten Sie diese Datei außerdem aus der Versionsverwaltung heraus; nutzen Sie git, tragen Sie sie in .gitignore ein. Zu den git Grundlagen hilft unsere Git und GitHub Anleitung.

# .env Datei (Beispielwerte, erzeugen Sie Ihr eigenes Passwort)
POSTGRES_PASSWORD=IHR_STARKES_PASSWORT
MYSQL_ROOT_PASSWORD=IHR_ROOT_PASSWORT

Die Compose Dokumentation hält fest, dass Werte im Attribut environment die Werte aus env_file überschreiben. Definieren Sie also dieselbe Variable an beiden Stellen, gewinnt environment. Ein starkes Passwort erzeugen Sie mit unserem Passwortgenerator.

Noch eine Warnung: Umgebungsvariablen sehen Sie in der Ausgabe von docker inspect. Deshalb kann jeder mit Serverzugriff sie lesen. Für eine strengere Methode lesen Sie den nächsten Abschnitt.

Wie übergeben Sie Datenbank Passwörter mit Docker Secrets?

Sowohl das PostgreSQL als auch das MySQL Image lesen einen Wert aus einer Datei, wenn Sie dem Variablennamen _FILE anhängen. Die Docker Hub Seiten empfehlen das zudem besonders für Secrets. Definieren Sie in Compose ein Secret, erscheint es im Dienst als schreibgeschützte Datei unter /run/secrets/NAME.

services:
  db:
    image: postgres:IHR_TAG
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_passwort
    secrets:
      - db_passwort

secrets:
  db_passwort:
    file: ./geheim/db_passwort.txt

Halten Sie die Passwortdatei aus der Versionsverwaltung heraus und beschränken Sie ihre Rechte, zum Beispiel so, dass nur Ihr Nutzer sie lesen kann. Für MySQL gilt dieselbe Idee: Die Variable MYSQL_ROOT_PASSWORD_FILE zeigt auf eine Datei unter /run/secrets/.

Bedenken Sie allerdings, dass diese Methode das Passwort aus dem Shell Verlauf und aus docker inspect heraushält. Übernimmt ein Angreifer jedoch den Server, kann er die Datei trotzdem lesen. Kurz gesagt: Sicherheit besteht aus Schichten. Die weiteren Schichten behandeln der Abschnitt zur Sicherheit unten und unser Leitfaden zu den OWASP Top 10.

Wie richten Sie PostgreSQL in Docker mit Compose ein?

Compose bündelt alle Einstellungen in einer Datei und macht Wiederholungen einfach. Die Datei unten gibt PostgreSQL ein Volume, ein Secret, einen Healthcheck und einen Port, der nur auf localhost offen ist. Speichern Sie sie als compose.yaml in einem Ordner und starten Sie mit docker compose up -d.

services:
  db:
    image: postgres:IHR_TAG
    restart: unless-stopped
    environment:
      POSTGRES_USER: appnutzer
      POSTGRES_DB: appdb
      POSTGRES_PASSWORD_FILE: /run/secrets/db_passwort
    secrets:
      - db_passwort
    volumes:
      - pgdaten:/var/lib/postgresql/data
    ports:
      - "127.0.0.1:5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appnutzer -d appdb"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

secrets:
  db_passwort:
    file: ./geheim/db_passwort.txt

volumes:
  pgdaten:

Die Restart Richtlinie unless-stopped holt den Container nach einem Neustart des Rechners zurück. Die Compose Referenz für Services nennt für restart die Werte no, always, on-failure und unless-stopped, wobei no der Standard ist.

Wie richten Sie MySQL in Docker mit Compose ein?

Die MySQL Datei folgt also derselben Logik. Unterschiede gibt es bei den Variablennamen und beim Healthcheck Befehl. Für den Healthcheck können Sie mysqladmin ping nutzen. Allerdings kann dieser Befehl auch bei einem Authentifizierungsfehler Erfolg melden, solange der Server lebt. Er sagt Ihnen also nur, dass der Prozess antwortet.

services:
  mysql:
    image: mysql:IHR_TAG
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: appdb
      MYSQL_USER: appnutzer
      MYSQL_PASSWORD_FILE: /run/secrets/mysql_passwort
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root
    secrets:
      - mysql_passwort
      - mysql_root
    volumes:
      - mysqldaten:/var/lib/mysql
    ports:
      - "127.0.0.1:3306:3306"
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s

secrets:
  mysql_passwort:
    file: ./geheim/mysql_passwort.txt
  mysql_root:
    file: ./geheim/mysql_root.txt

volumes:
  mysqldaten:

Die Compose Dokumentation definiert außerdem das Attribut start_period: Es ist die Zeit, die Sie dem Container zum Hochfahren geben. Beim ersten Start bereitet die Datenbank ihre Dateien vor. Halten Sie den Wert daher großzügig und stellen Sie ihn ein, indem Sie die echte Startzeit auf Ihrem Rechner beobachten.

Können Sie PostgreSQL und MySQL in Docker in derselben Compose Datei betreiben?

Ja, das können Sie. Zunächst legen Sie beide Dienste in eine Datei und führen Sie die beiden Blöcke von oben zusammen. Zu beachten sind nur die Host Ports. PostgreSQL nutzt standardmäßig 5432 und MySQL 3306, die beiden stoßen also nicht zusammen. Betreiben Sie zwei Container derselben Art, ändern Sie den Host Port eines davon.

Läuft Ihre Anwendung ebenfalls in Compose, müssen Sie den Datenbank Port gar nicht auf dem Host öffnen. Denn Dienste im selben Compose Netzwerk erreichen sich über den Dienstnamen. Ihre Anwendung verbindet sich also mit db:5432 oder mysql:3306.

Wie verbinden Sie sich im Container und verfolgen die Logs?

Nach der Einrichtung prüfen Sie zuerst, ob die Datenbank wirklich antwortet. Arbeiten Sie mit Compose, öffnen Sie den Client direkt im Container. Hier zwei Beispielbefehle; passen Sie Nutzer und Datenbanknamen an Ihre Einrichtung an.

docker compose exec db psql -U appnutzer -d appdb
docker compose exec mysql mysql -u appnutzer -p appdb

Der MySQL Befehl fragt nach dem Passwort, und Sie tippen es selbst ein. So landet es nie in Ihrem Befehlsverlauf, daher bleibt es geheim. Zum Beenden geben Sie in PostgreSQL \q und in MySQL exit ein.

Für Logs genügt der Befehl docker compose logs. Hängen Sie das Flag -f an, verfolgen Sie den Strom live. Besonders beim ersten Start sehen Sie in dieser Ausgabe, ob die Init Skripte liefen und ob Passwort oder Rechte Fehler auftraten.

docker compose ps
docker compose logs -f db

Die Ausgabe von docker compose ps zeigt auch den Gesundheitszustand. Starten Sie Ihre Anwendung erst, wenn dort healthy steht. Gibt es ein Problem, kopieren Sie die Log Ausgabe in eine Notiz. Bitten Sie Ihren Anbieter oder Entwickler um Hilfe, beschleunigt diese Ausgabe die Arbeit enorm.

Warum brauchen Sie einen Healthcheck, und wie nutzt depends_on ihn?

Ein laufender Container heißt nicht, dass die Datenbank Verbindungen annimmt. Beim ersten Start bereitet die Datenbank ihre Dateien vor und lehnt in der Zwischenzeit Verbindungen ab. Startet Ihre Anwendung in dieser Lücke, schlägt sie fehl. Ein Healthcheck schließt also die Lücke.

Für PostgreSQL nutzen Sie pg_isready. Laut offizieller Dokumentation bedeutet Exit Code 0, dass der Server Verbindungen annimmt. Code 1 heißt, der Server lehnt sie ab, zum Beispiel beim Start. Code 2 steht für keine Antwort, Code 3 für keinen Versuch wegen ungültiger Parameter. Docker macht daraus die Entscheidung healthy oder unhealthy.

services:
  app:
    image: IHR_APP_IMAGE
    depends_on:
      db:
        condition: service_healthy

Laut Compose Dokumentation wartet die Bedingung service_healthy, bis die Abhängigkeit ihren Healthcheck besteht. Ihre Anwendung startet also nicht, bevor die Datenbank bereit ist. Den Zustand sehen Sie in der Ausgabe von docker compose ps.

Warum ist ein offener Datenbank Port im Internet riskant?

Konkret: Dieser Abschnitt ist der wichtigste der Anleitung. Die Docker Dokumentation zum Veröffentlichen von Ports sagt es deutlich: Ein veröffentlichter Port ist nicht nur für den Docker Host erreichbar, sondern auch für die Außenwelt. Wer 5432:5432 unter ports schreibt, bietet seine Datenbank also womöglich dem ganzen Internet an.

Schlimmer noch: Ihre Firewall schützt Sie unter Umständen nicht. Laut der Docker Dokumentation zu Firewalls leitet Docker den Verkehr eines veröffentlichten Ports um, bevor er die ufw Regeln erreicht. Docker routet Container Verkehr in der nat Tabelle, und die Pakete erreichen die INPUT und OUTPUT Ketten von ufw nie. "Ich habe es mit ufw gesperrt" reicht daher nicht.

Die Lösung ist einfach: Schreiben Sie die IP Adresse zusammen mit dem Port. Laut Dokumentation erreicht nur der Docker Host den Port, wenn Sie 127.0.0.1 oder ::1 an das Flag zum Veröffentlichen hängen. Deshalb tragen alle Beispiele oben das Präfix 127.0.0.1. Außerdem bindet in der kurzen Compose Schreibweise ein Port ohne Host IP an alle Schnittstellen.

Die Docker Dokumentation weist außerdem darauf hin, dass in Versionen vor 28.0.0 Hosts im selben Netzwerksegment auf an localhost veröffentlichte Ports zugreifen können. Halten Sie Ihre Docker Version daher aktuell. Welche Adressen nach außen offen sind, prüfen Sie mit unserer IP Abfrage.

Wie verbinden Sie sich sicher mit einer entfernten Datenbank?

Möchten Sie sich mit einem Verwaltungswerkzeug auf Ihrem Rechner mit der Datenbank auf einem Server verbinden, nutzen Sie einen SSH Tunnel statt eines offenen Ports. Der Tunnel trägt einen lokalen Port über die SSH Verbindung zum localhost des Servers. Die Datenbank lauscht weiterhin nur auf localhost.

ssh -N -L 5433:127.0.0.1:5432 nutzer@server.example.com

Solange dieser Befehl läuft, erreicht ein Werkzeug, das sich auf Ihrem Rechner mit 127.0.0.1:5433 verbindet, PostgreSQL auf dem Server. Wir haben den lokalen Port 5433 gewählt, weil auf Ihrem Rechner vielleicht schon ein PostgreSQL läuft. Für MySQL wenden Sie dieselbe Idee mit Port 3306 an.

Diese Methode verkleinert die Angriffsfläche, selbst wenn das Datenbank Passwort schwach ist. Denn ein Angreifer muss zuerst Ihren SSH Schlüssel überwinden. Trotzdem sollten Sie weiter ein starkes Passwort nutzen; eine Schutzschicht ersetzt nie die andere.

Wie laden Sie Startdaten mit Init Skripten?

Beide offiziellen Images führen die Dateien im Ordner /docker-entrypoint-initdb.d beim ersten Start aus. Die PostgreSQL Seite nennt die Endungen .sql, .sql.gz und .sh. Die MySQL Seite ergänzt .sql.bz2, .sql.xz und .sql.zst und sagt, dass die Dateien in alphabetischer Reihenfolge laufen.

    volumes:
      - pgdaten:/var/lib/postgresql/data
      - ./init:/docker-entrypoint-initdb.d:ro

Das entscheidende Detail: Laut PostgreSQL Seite laufen diese Skripte nur, wenn das Datenverzeichnis leer ist. Ändern Sie ein Skript später und starten den Container neu, greift die Änderung also nicht. Um das Skript erneut zu probieren, müssen Sie das Volume löschen und akzeptieren, dass die Daten verschwinden.

Überlassen Sie Schema Änderungen deshalb nicht den Init Skripten. Für Schema Änderungen an Live Daten nutzen Sie ein Migrationswerkzeug. Frameworks wie Laravel, Django oder Prisma bringen zum Beispiel ein solches Werkzeug selbst mit.

Wie sichern Sie eine Datenbank, die in Docker läuft?

Backups sind die unverhandelbarste Regel dieser Anleitung. Volume Dateien aus einer laufenden Datenbank zu kopieren liefert womöglich kein konsistentes Backup. Bevorzugen Sie daher einen logischen Dump. Die MySQL Seite zeigt ein Beispiel mit docker exec und mysqldump; für PostgreSQL leistet pg_dump dasselbe.

# PostgreSQL Backup
docker compose exec -T db pg_dump -U appnutzer appdb > backup-pg.sql

# MySQL Backup (nach dem Beispiel der offiziellen Seite)
docker exec beispiel-mysql sh -c 'exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD"' > backup-mysql.sql

Das offizielle MySQL Beispiel liest das Passwort aus der Umgebungsvariable. Nutzen Sie Secrets, ist diese Variable nicht definiert; dann müssen Sie das Passwort stattdessen aus der Datei lesen. Zum Zurückspielen gehen Sie umgekehrt vor und geben die Datei mit docker exec -i an den Befehl mysql.

# PostgreSQL Wiederherstellung
docker compose exec -T db psql -U appnutzer appdb < backup-pg.sql

Ob ein Backup funktioniert, wissen Sie nur, wenn Sie es zurückspielen. Probieren Sie das daher einmal im Monat in einer Testumgebung. Den allgemeinen Rahmen einer Backup Strategie erklärt unsere Anleitung zur Website Backup Strategie.

Wie gehen Sie mit Hauptversionen und Updates um?

Kleine Updates bedeuten meist, das Tag zu ändern und den Container neu zu erstellen. Sprünge der Hauptversion sind dagegen anders, also planen Sie sie getrennt. Datenbanksoftware kann das Datenverzeichnis einer alten Hauptversion nicht immer mit einer neuen öffnen. Erstellen Sie daher zuerst ein Backup und testen Sie die neue Version dann mit einem eigenen Volume.

Sie können in drei Schritten vorgehen. Zunächst ziehen Sie einen Dump aus der aktuellen Datenbank. Dann starten Sie die neue Version mit einem leeren Volume und laden den Dump hinein. Schließlich verbinden Sie Ihre Anwendung mit der neuen Datenbank und testen sie. Löschen Sie das alte Volume dann erst, wenn alles stimmt.

• Legen Sie das Tag fest und meiden Sie latest.
• Ziehen Sie vor jedem Update einen Dump.
• Probieren Sie den Sprung der Hauptversion zuerst in einer Testumgebung.
• Behalten Sie das alte Volume eine Weile als Rückweg.

Zudem sind die Migrationsschritte für jede Datenbank gesondert dokumentiert. Führen Sie nichts aus, bevor Sie die offiziellen Upgrade Hinweise Ihrer Version gelesen haben.

Worauf achten Sie bei einem Datenbank Container im Produktivbetrieb?

Im Produktivbetrieb trägt der Container Daten, die Sie nicht verlieren dürfen. Bauen Sie daher jeden Schritt bewusst auf. Die Liste unten sammelt die Punkte, die Sie vor dem Livegang prüfen sollten.

• Binden Sie den Port nur an localhost und erreichen Sie ihn per SSH Tunnel.
• Übergeben Sie Passwörter mit Secrets oder _FILE Variablen.
• Halten Sie Daten auf einem Volume und kopieren Sie Backups an einen Ort abseits des Servers.
• Definieren Sie Healthcheck und Restart Richtlinie.
• Beobachten Sie Plattenplatz und Container Logs regelmäßig.
• Legen Sie das Tag fest und planen Sie Ihre Updates.

Für einen laufenden Shop oder ein Buchungssystem braucht jeder Punkt dieser Liste einen Verantwortlichen. Somit ist ein Punkt ohne Verantwortlichen der, für den im Ernstfall niemand einsteht. Deshalb halten viele Unternehmen einen verwalteten Datenbankdienst für sicherer. Für Ihre Hosting Entscheidung hilft unser Leitfaden zur Wahl des Webhostings.

Welche Fehler passieren bei PostgreSQL und MySQL in Docker am häufigsten?

Die meisten Fehler häufen sich also um wenige Themen. Die Tabelle ordnet Symptome und Ursachen zu, damit Sie bei einem Problem schnell den passenden Abschnitt wiederfinden.

Die Variablen zum Anlegen der Datenbank wirken nur, wenn das Datenverzeichnis leer ist. Erwarten Sie daher nicht, dass eine Passwortänderung allein in der env Datei funktioniert. Nach dem ersten Start ändern Sie das Passwort mit dem eigenen Befehl der Datenbank.

Wann sollten Sie das nicht selbst tun und Ihrem Hostinganbieter überlassen?

Seien wir ehrlich: Die Datenbank selbst zu betreiben ist nicht für jedes Projekt die richtige Entscheidung. In einem Live System mit Kundendaten, Bestellungen oder Zahlungsdaten brauchen Backups und Sicherheitsupdates ständige Aufmerksamkeit. Kann niemand diese Aufmerksamkeit aufbringen, überlassen Sie die Aufgabe dem Anbieter.

In diesen Fällen tun Sie es nicht selbst. Sie betreiben einen Shop, bei dem ein Datenbankausfall direkt Umsatz kostet. Außerdem wartet niemand den Server regelmäßig. Sie haben nie versucht, ein Backup zurückzuspielen. Sie halten personenbezogene Daten und tragen DSGVO Pflichten. Bitten Sie Ihren Anbieter dann um eine verwaltete Datenbank, automatische Backups und Monitoring.

Auch die Fragen an einen Anbieter sind einfach. Wie oft sichert er, und wo bewahrt er die Backups auf? Wie lange dauert eine Wiederherstellung? Wer spielt die Sicherheitsupdates ein? Bekommen Sie keine klaren Antworten, suchen Sie einen anderen Anbieter. Für den Ausbau Ihrer Datenbankkenntnisse helfen unser SQL Fahrplan und unser Artikel zu Redis und Memcached.

Wie sieht die Checkliste für PostgreSQL und MySQL in Docker aus?

Gehen Sie nach der Einrichtung diese Liste von oben nach unten durch. Denn jeder Punkt schließt ein Risiko, das wir in dieser Anleitung beschrieben haben. Können Sie alle abhaken, haben Sie eine solide Basis für Entwicklung oder ein kleines Projekt geschaffen.

1. Sie haben das offizielle Image und ein festes Versions Tag genutzt.
2. Das Datenverzeichnis liegt auf einem Volume.
3. Passwörter kommen aus .env oder Secrets, fern der Versionsverwaltung.
4. Der Port ist mit 127.0.0.1 begrenzt.
5. Ein Healthcheck existiert, und Ihre Anwendung wartet auf service_healthy.
6. Sie haben ein Backup erstellt und eine Wiederherstellung getestet.
7. Ein Plan deckt Sprünge der Hauptversion ab.

Möchten Sie diese Infrastruktur als Teil eines Website oder Anwendungsprojekts aufbauen, schauen Sie sich die individuelle Softwareentwicklung unseres Teams an.