DDEV: Staging-Datenbank per ddev pull importieren (TYPO3)

Bei meinem damaligen Projekt arbeiteten die Redakteure parallel sehr fleißig am Content der Seite, und ständig kamen Fragen oder Bugs zu neuen Inhaltselementen, die ich auf meiner lokalen Umgebung noch gar nicht angelegt hatte. Bisher hab’ ich mir die Datenbank immer manuell geholt: per SSH auf den Server, mysqldump, herunterladen und in DDEV (öffnet in neuem Tab) einspielen. Aber das muss doch einfacher gehen – vor allem, wenn man das alle paar Stunden einmal machen muss.

Auf Twitter (öffnet in neuem Tab) habe ich einige Anregungen und Hilfen bekommen. An dieser Stelle danke an Geddo2k (öffnet in neuem Tab), Matthias (öffnet in neuem Tab), Stefan (öffnet in neuem Tab) und Andreas (öffnet in neuem Tab)!

Anfangs wollte ich es als externes Bash-Skript machen, habe mich dann aber für die DDEV-Provider entschieden. Ein Provider ist eine YAML-Datei unter .ddev/providers/, die beschreibt, wie DDEV Datenbank und Dateien von einem Server holt.

So wird’s verwendet

Befehle für dich anpassen

Deine Eingaben werden in allen Befehlen dieser Seite eingesetzt und nur in deinem Browser gespeichert.

SSH-Login des ServersProjektpfad auf dem Server

Variante 1: mysqldump mit .my.cnf auf dem Server

environment_variables:
  server: user@staging.example.com

auth_command:
  command: |
    set -eu -o pipefail
    ssh-add -l > /dev/null || ( echo "Please 'ddev auth ssh' before running this command." && exit 1 )

db_pull_command:
  command: |
    set -x
    set -eu -o pipefail
    ssh -t ${server} -p 22222 'mysqldump --defaults-file=~/.mysql/db.cnf dbname' > .ddev/.downloads/db.sql
    gzip .ddev/.downloads/db.sql
  service: web

files_import_command:
  command: |
    set -eu -o pipefail
    echo "doing nothing ..."
  service: web

DDEV-Provider erwarten den SQL-Dump gezippt, daher mache ich das noch. Eigentlich wollte ich am Server zippen und die Datei dann per rsync herunterladen, aber das hat nicht auf Anhieb funktioniert – und irgendwann war meine Geduld am Ende. Schließlich wollte ich eine 5-Minuten-Arbeit automatisieren und nicht 3+ Stunden an einem Skript feilen.

Wichtig ist vor allem die Datei ~/.mysql/db.cnf im Home-Verzeichnis am Server. Ich wollte unbedingt vermeiden, dass ich lokal die Zugangsdaten für die Datenbank speichern muss oder diese womöglich irgendwann im Git landen:

[client]
user = "foo"
password = "bar"
host = "127.0.0.1"

Die Datei sollte nur für dich lesbar sein (chmod 600 ~/.mysql/db.cnf). Mehr zu solchen Konfigurationsdateien steht in All-Inkl: Datenbank & Dateien per SSH sichern.

Vielen Dank an Kay (öffnet in neuem Tab) für das initiale Skript und die Hilfe beim Anpassen an meine Bedürfnisse!

Variante 2: TYPO3 Console (empfohlen)

Für ein anderes Projekt konnte ich dann endlich die TYPO3 Console (öffnet in neuem Tab) von Helmut verwenden – an dieser Stelle ein Danke für diese großartige Extension! In Variante 1 ging das nicht, weil die Console dort Schreibrechte im Webroot gebraucht hätte, die mein Benutzer am Server nicht hatte.

environment_variables:
  server: user@staging.example.com
  deploymentPath: /var/www/staging/releases/current

auth_command:
  command: |
    set -eu -o pipefail
    ssh-add -l >/dev/null || ( echo "Please 'ddev auth ssh' before running this command." && exit 1 )

db_pull_command:
  service: host
  command: |
    # set -x   # Bash-Debugging bei Bedarf aktivieren
    set -eu -o pipefail
    ssh -t ${server} -p 222 "cd ${deploymentPath}; ./vendor/bin/typo3 database:export -c Default -e 'cf_*' -e 'cache_*' -e '[bf]e_sessions' -e sys_log" > .ddev/.downloads/db.sql
    gzip .ddev/.downloads/db.sql

db_import_command:
  service: host
  command: |
    set -eu -o pipefail
    ddev import-db --file=".ddev/.downloads/db.sql.gz"
    ddev typo3 database:updateschema

files_pull_command:
  service: host
  command: |
    set -eu -o pipefail
    rsync -rzv -e 'ssh -p 222' ${server}:${deploymentPath}/htdocs/fileadmin/ htdocs/fileadmin/ --max-size=1.5m --exclude=_processed_

files_import_command:
  service: host
  command: |
    set -eu -o pipefail
    echo "doing nothing ..."

Der große Vorteil: Ich muss mich um keine Zugangsdaten kümmern, weil die TYPO3 Console sie aus der TYPO3-Konfiguration holt – ab TYPO3 12 aus config/system/settings.php (früher LocalConfiguration.php) bzw. in meinem Fall aus einer .env.

Im db_pull_command exportiere ich die Datenbank ohne Cache-Tabellen, be_sessions/fe_sessions und sys_log und zippe den Dump anschließend wieder. Mit mysqldump geht das Ausschließen zwar auch (--ignore-table=datenbank.tabelle), aber nur Tabelle für Tabelle – Wildcards wie cache_* kann nur die TYPO3 Console. Zu dem Thema kann ich den Artikel im in2code (öffnet in neuem Tab) Tech-Corner empfehlen: MySQL und mysqldump – alles, was ihr wissen müsst (öffnet in neuem Tab).

Da ich nach dem Import einen DB-Compare laufen lassen wollte, überschreibe ich den db_import_command und kümmere mich selbst um den Import.

Der Webroot heißt in diesem Projekt htdocs – bei dir ist das vermutlich public. Den files_pull_command habe ich auf Dateien bis 1,5 MB begrenzt und den Ordner _processed_ ausgeschlossen – den erzeugt TYPO3 lokal ohnehin neu. Oft löse ich das mit den Dateien aber auch einfach über die Extension filefill (öffnet in neuem Tab), die fehlende Dateien bei Bedarf vom Server nachlädt.