db-prod-import, ssh-prod... encore des commandes DDEV pour rapatrier des db distantes

Dans un billet précédent, je présentais db-import et db-export, deux commandes DDEV globales pour gérer ses dumps en local. Restait la corvée d'avant : récupérer le dump de production. SSH sur le serveur, drush sql-dump, scp, import… toujours les mêmes gestes, réécrits dans un Makefile ou un script propre à chaque projet. 

Voici donc la suite logique : des commandes « serveur distant », toujours déposées dans ~/.ddev/commands/host/ et donc disponibles dans tous les projets DDEV de la machine : db-prod-dump, db-prod-get, db-prod-import et ssh-prod et leur équivalent pour l'environement de preprod db-preprod-* / ssh-preprod.

L'objectif final tient en une ligne : taper ddev db-prod-import dans n'importe quel projet et me retrouver connecté sur mon site local avec la base de prod fraîchement importée. Et l'ensemble est désormais packagé dans un addon DDEV : ddev-drupal-tools,

C'est en fait le portage de mon mini projet : https://github.com/kgaut/drupal-makefile que j'utilisais encore avant de passer à ces fonctions ddev.

Tout part du .env du projet

Les commandes sont globales, mais chaque projet a son serveur, son chemin, son drush. Toute la configuration est donc lue dans le .env à la racine du projet, avec un préfixe par environnement (PROD_ ou PREPROD_) :

# .env du projet
PROD_USER=kevin
PROD_HOST=mon-serveur.example.org
PROD_PORT=22                           # optionnel, défaut 22
PROD_PATH=/var/www/monprojet           # racine du projet sur le serveur
PROD_DRUSH=vendor/bin/drush            # binaire drush, relatif à PROD_PATH
PROD_DB_PATH=/var/www/monprojet/dumps  # dossier des dumps, sur le serveur
PROD_URL=monprojet.example.org         # sert à nommer les fichiers de dump

# même principe pour la préprod, préfixe PREPROD_
PREPROD_USER=kevin
PREPROD_HOST=preprod.example.org
# …

Si les variables ne sont pas définie, une erreur sera lancée : Erreur : PROD_HOST manquant…), 

ddev db-prod-dump : dumper la prod, sur le serveur

La commande se connecte en SSH au serveur et y lance un drush sql-dump --gzip, vers un fichier horodaté dans PROD_DB_PATH :

$ ddev db-prod-dump
Dump de la base de production (mon-serveur.example.org)…
Dump terminé.

À noter : le dump reste sur le serveur. C'est voulu — il sert aussi de sauvegarde ponctuelle avant une opération risquée, sans forcément être rapatrié.

ddev db-prod-get : rapatrier le dernier dump

Le pendant local : la commande repère le .sql.gz le plus récent dans PROD_DB_PATH sur le serveur, et le télécharge en scp :

$ ddev db-prod-get
Téléchargement du dump : /var/www/monprojet/dumps/2026-07-28_09-15-42-monprojet.example.org-prod.sql.gz
Dump téléchargé : /home/kevin/projets/monprojet/files/dumps/…

La destination locale est résolue dans cet ordre : LOCAL_DB_PATH, sinon DB_DUMP_DIR, sinon par défaut : files/dumps. Ce n'est pas un hasard : c'est exactement le dossier de dumps de db-import. Le fichier atterrit donc là où db-import ira chercher « le dump le plus récent », sans aucune configuration supplémentaire.

ddev db-prod-import : la totale

La commande que j'utilise vraiment au quotidien. Son code fait deux lignes :

ddev db-prod-get
ddev db-import

Soit, bout à bout : téléchargement du dernier dump de prod, base locale vidée, dump importé, drush deploy, drush cr, drush uli  pour au final obtenir un lien de connexion. et un lien de connexion dans le terminal.

À noter : db-prod-import ne relance pas de dump, elle prend le dernier présent sur le serveur.

ddev ssh-prod

Tant qu'à avoir les infos des serveur dans le .env, autant s'en servir : ddev ssh-prod ouvre une session SSH sur le serveur de production du projet courant.

Et la préprod ?

Chaque commande a sa jumelle preprod : db-preprod-dump, db-preprod-get, db-preprod-import, ssh-preprod. Ce sont des copies parfaites des variantes prod, où le préfixe des variables du .env devient simplement PREPROD_.

Installation et code source

Le plus simple est d'installer l'addon ddev-drupal-tools, qui fournit ces huit commandes ainsi que db-import / db-export et l'autocomplétion :

ddev add-on get kgaut/ddev-drupal-tools

À noter : même si l'addon installe ses fichiers globalement, ddev add-on get doit être lancée depuis un dossier de projet DDEV (ou avec --project <nom>), car DDEV n'a pas de vraie notion d'addon global et enregistre l'installation dans le projet utilisé comme contexte, dans .ddev/addon-metadata/. Pour mettre à jour, relancer la même commande depuis le même projet ; pour supprimer, ddev add-on remove drupal-tools. Le détail est dans le README du dépôt.

Si vous voulez regarder directement le code des fonctions : 

Pour une installation manuelle, il suffit de déposer ces fichiers dans ~/.ddev/commands/host/ et de les rendre exécutables : DDEV les découvre tout seul, rien à redémarrer. Le marqueur #ddev-generated en tête de chaque fichier sert à DDEV à les mettre à jour et à les supprimer proprement quand ils sont gérés via l'addon.

Écrit par Kevin Gautreau — développeur & formateur PHP/Drupal freelance en Auvergne. me contacter

Contenus en rapport

article · 27 Jul 2026 db-import / db-export : deux commandes DDEV globales pour gérer ses dumps À force de jongler entre plusieurs projets DDEV, j'ai fini par me lasser de réécrire les mêmes petits scripts d'import et d'export de base dans chaque dépôt.… snippet · 28 Jul 2026 Installer DDEV sous Linux (Ubuntu, Debian, Fedora, openSUSE) DDEV est une couche d'abstraction à Docker permettant de mettre en place une infrastructure pour développer simplement sur un projet Drupal (ou autre) sans…

Commentaires (0)