Pourquoi ne pas utiliser l’image Docker "officielle" de Drupal pour vos projets en production ?

Drupal

Docker

Partager sur

L’image officielle de Drupal sur Docker Hub (https://hub.docker.com/_/drupal) intègre le code de Drupal dans une version donnée, ainsi qu’un ensemble cohérent des autres éléments de la stack nécessaires (Apache, extensions PHP générales, etc.). Si cette solution peut sembler pratique en apparence, elle présente plusieurs limites majeures pour un usage en production. Voici pourquoi il est préférable d’éviter cette approche et d’opter pour une image Docker personnalisée.

Problème n°1 : Les extensions manquantes

L’image officielle ne contient pas les librairies tierces ni les extensions PHP spécifiques dont votre projet pourrait avoir besoin. Par exemple, il est impossible d’installer Drupal Commerce ou tout autre module nécessitant des extensions comme bcmath (ou zip).

Conséquences :
- Vous devrez toujours créer votre propre image Docker (via un `Dockerfile` personnalisé) en partant de l’image officielle, puis installer les dépendances manquantes (repos, extensions PECL, etc.). Cela ajoute une étape de build conséquente, alors que l’on s’attend à une solution « plug and play ».
- Pour les entreprises avec une politique de sécurité stricte (accès internet restreint, utilisation d’un repository interne comme Artifactory), cette approche complique la maintenance. Il faut en effet garantir la compatibilité des versions en interne, tout en dépendant des choix de l’image Docker officielle.

Problème n°2 : Le mélange des versions compatibles

L’image officielle de Drupal sur Docker Hub combine deux éléments critiques :
- La version de Drupal (le code core fourni).
- La version de PHP (avec une règle de compatibilité floue).

Problème :
- Un tag de version Drupal fournira la stack Apache/PHP dans sa dernière version compatible.
- Un tag de version PHP fournira le code Drupal dans sa dernière version compatible avec cette version de PHP.

Résultat : Impossible de choisir simultanément une version spécifique de Drupal et une version spécifique de PHP. Cette contrainte limite la flexibilité et peut entraîner des incompatibilités.

Problème n°3 : Le code Drupal embarqué

Dans un projet, on ne se limite généralement pas au code core de Drupal. On ajoute des modules, et dans la majorité des cas, on utilise **Composer** pour gérer les dépendances.

Exemple de workflow classique :

FROM php:8.4-cli-alpine AS layer-composer
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
# Build du code
...

Puis, on copie le code construit dans la couche Drupal :

FROM drupal:11.3-php8.4
COPY --from=layer-composer /drupal /opt/drupal

Risque majeur :

La commande COPY de Docker équivaut à un cp. Vous risquez donc de mélanger deux versions de Drupal :

• Le code fourni par l’image officielle.
• Votre code construit via Composer.

Cas concret :

• Vous ciblez une image Drupal pour une version spécifique de PHP.
• Votre couche de build se concentre uniquement sur PHP, et vous construisez une version Drupal 10.
• L’image officielle inclut automatiquement la dernière version compatible de Drupal (par exemple, la 11).
• Si un fichier a changé d’emplacement entre deux versions (comme le driver MySQL), votre déploiement échouera.

Témoignage : Ce scénario m’a coûté 3 heures de debug et des adaptations importantes du Dockerfile.

Problème n°4 : Un support limité

Un bundle tout-en-un peut sembler attrayant, mais en cas de problème, la résolution devient plus complexe. Pourquoi ?

• Moins d’utilisateurs = moins de retours d’expérience partagés.
• Moins de solutions documentées en ligne.

Conclusion : Optez pour une image Docker personnalisée

Pour éviter ces écueils, construisez votre propre image Docker en suivant les bonnes pratiques de la communauté. Voici un exemple de structure optimisée :

# Build avec Composer
FROM php:8.4-cli-alpine AS layer-composer
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
WORKDIR /drupal
COPY myapp/ ./
RUN composer install --no-dev --no-interaction --no-autoloader --no-scripts

# Build Node (pour les assets du thème)

# FPM + Nginx avec Supervisord
FROM php:8.4-fpm
# Installation des extensions PHP nécessaires
# Installation de Nginx et Supervisord
COPY --from=layer-composer /drupal /var/www/html
...

Pourquoi cette approche est-elle meilleure ?

• Contrôle total sur les versions de Drupal et PHP.
• Flexibilité pour ajouter des dépendances spécifiques.
• Maintenance simplifiée et alignée sur les standards de la communauté.

En résumé : Une image Docker personnalisée, construite étape par étape, vous fera gagner en stabilité, en sécurité et en temps.

Si vous tenez à utiliser l’image "officielle" :

Supprimez son contenu avant de copier votre code pour éviter les conflits :

FROM drupal:11.3-php8.4
RUN rm -rf /opt/drupal
COPY --from=layer-composer /drupal /opt/drupal

Faites quand même un tour sur https://www.drupal.org/docs/develop/local-server-setup/docker-with-solr-cloud-integration/docker-configuration avant et focalisez votre attention sur ceci : 

Image

Pour l'environnement de développement, vous avez tout ici: https://www.drupal.org/docs/develop/local-server-setup/docker-based-development-environments-for-macos-linux-and-windows