← Retour à la liste
★★★★½ 4.8 / 5
Catégorie 04SKILLS

Drupal Docker

Docker Compose Drupal — PHP 8.3, MariaDB 11.4, Caddy TLS, Xdebug 3, Makefile, prod

Installation
Via npx (recommandé)npx skill add ThomasRoger76/drupal-docker
Via gitgit clone https://github.com/ThomasRoger76/drupal-docker.git ~/.claude/skills/drupal-docker
Vérifier dans Claude Code/skills
VersionDocker Compose v2 (Compose 2.22+)
PrixGratuit
Plateformes
LinuxmacOSWindows WSL2
Commandes12
Exemples3
SKL
À propos

Skill de connaissance pure qui transforme Claude en expert environnement Docker pour Drupal 10/11 — génère une stack Docker Compose complète et production-ready, avec Xdebug configuré correctement du premier essai et onboarding en 5 minutes via make install. Contenu injecté : stack multi-services (PHP 8.3+Apache/FPM, MariaDB 11.4 avec healthcheck service_healthy + start_period:30s, Caddy TLS local automatique sans config SSL manuelle, Maildev capture SMTP, Redis, Solr 9.4), Dockerfiles multi-stage (stage base → stage dev avec Xdebug 3 + Composer 2 + DEV_UID/GID → stage production avec OPcache validate_timestamps=0 + memory=256M + JIT PHP 8.3), connexion .env↔settings.php via getenv() obligatoire (l'anti-pattern localhost = le container PHP lui-même est bloqué), Xdebug container→IDE via extra_hosts:host.docker.internal:host-gateway, Makefile/Taskfile.yml standardisés (install/up/build/verify/shell), optimisations bind mount (Mutagen async, VirtioFS macOS M1+, docker compose watch Compose 2.22+), push GitLab Registry tag SHA. Pas d'agents — skill de connaissance pure. Gain mesuré : stack Docker opérationnelle en 5 minutes (make install), Xdebug configuré sans galère host.docker.internal (erreur bloquante dans 80% des setups initiaux), Dockerfile multi-stage correct du premier essai.

Fonctionnalités clés
Stack 6 services — Caddy TLS local automatiquePHP 8.3+Apache/FPM, MariaDB 11.4 avec healthcheck service_healthy + start_period:30s, Caddy TLS local sans config SSL manuelle, Maildev capture SMTP, Redis, Solr 9.4. Named volumes obligatoires.
Dockerfile multi-stage — dev vs production identiques sauf debugStage dev : Xdebug 3, Composer 2, DEV_UID/GID pour éviter les permission denied. Stage production : OPcache validate_timestamps=0, memory=256M, JIT=1255, composer install --no-dev.
Xdebug container → IDE — step debugging sans frictionextra_hosts: host.docker.internal:host-gateway dans le container. xdebug.ini avec client_host=host.docker.internal. Variable XDEBUG_MODE=debug pour activer/désactiver sans rebuild.
Makefile standardisé — onboarding en 5 minutesmake install (up + composer + drush site:install + cim), make build, make logs, make shell, make verify. DEV_UID/GID exportés automatiquement. Un développeur est opérationnel en 5 minutes.
Performance bind mounts — Mutagen, VirtioFS, docker compose watchBind mounts lents sur Mac/Windows (vendor/ = 50 000+ fichiers). Solutions : Mutagen (async), VirtioFS (macOS M1+), docker compose watch (Compose 2.22+ — sync sélectif par règle).
GitLab Registry — images versionnées par SHA de commitdocker build --target=production + tag SHA + push GitLab Registry. Job CI test qui utilise l'image buildée. OPcache JIT avec benchmark obligatoire avant activation en production.
Commandes
CommandeDescription
docker compose up -dDémarrer tous les services en arrière-plan
docker compose downArrêter les services — SANS -v pour préserver la base de données
docker compose logs php -fStreamer les logs PHP/Apache en temps réel
docker compose exec php bashOuvrir un shell dans le container PHP
docker compose exec --user www-data php drush cim --yesDrush avec l'utilisateur www-data (évite les problèmes de permissions)
docker compose run --rm php composer installInstaller les dépendances Composer dans un container éphémère
make installInstallation complète : up + composer install + drush site:install + cim
make buildRebuild de l'image PHP (obligatoire après ajout d'extensions PHP)
make verifyVérifier l'état de l'environnement (DB connectée, site accessible, SA)
docker compose watchHot reload sans bind mount lent (Compose 2.22+ — sync sélectif par règle)
docker build --target production -t mon-site:$(git rev-parse --short HEAD) .Construire l'image de production (sans Xdebug, OPcache optimisé, JIT)
docker compose exec php php -i | grep -E 'opcache|xdebug|memory_limit'Vérifier la configuration PHP active dans le container
Exemples
docker-compose.yml — stack complète Drupal 11CODE
# docker-compose.yml
services:
  php:
    build: { context: ., target: dev, args: { DEV_UID: "${DEV_UID:-1000}", DEV_GID: "${DEV_GID:-1000}" } }
    volumes: [.:/var/www/html, ~/.composer:/root/.composer]
    environment: { MARIADB_HOSTNAME: mariadb, MARIADB_DATABASE: "${MARIADB_DATABASE}", XDEBUG_MODE: "${XDEBUG_MODE:-off}" }
    extra_hosts: ["host.docker.internal:host-gateway"]
    depends_on: { mariadb: { condition: service_healthy } }

  mariadb:
    image: mariadb:11.4
    environment: { MARIADB_ROOT_PASSWORD: "${MARIADB_ROOT_PASSWORD}", MARIADB_DATABASE: "${MARIADB_DATABASE}", MARIADB_USER: "${MARIADB_USER}", MARIADB_PASSWORD: "${MARIADB_PASSWORD}" }
    volumes: [database_data:/var/lib/mysql]
    healthcheck: { test: ["CMD", "mariadb", "-u", "${MARIADB_USER}", "-p${MARIADB_PASSWORD}", "-e", "SELECT 1"], interval: 5s, retries: 10, start_period: 30s }

  caddy:
    image: caddy:2-alpine
    ports: ["80:80", "443:443"]
    volumes: [./Caddyfile:/etc/caddy/Caddyfile:ro, .:/var/www/html:ro, caddy_data:/data]

  maildev: { image: maildev/maildev, ports: ["1080:1080", "1025:1025"] }

volumes: { database_data: {}, caddy_data: {} }
Dockerfile multi-stage — dev (Xdebug) + production (OPcache JIT)CODE
# Dockerfile
FROM php:8.3-apache AS base
RUN apt-get update && apt-get install -y --no-install-recommends \
    libpng-dev libjpeg-dev libwebp-dev libzip-dev git unzip mariadb-client \
    && docker-php-ext-install pdo_mysql gd zip opcache \
    && rm -rf /var/lib/apt/lists/*
RUN a2enmod rewrite

FROM base AS dev
ARG DEV_UID=1000
ARG DEV_GID=1000
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
RUN pecl install xdebug && docker-php-ext-enable xdebug
COPY docker/php/xdebug.ini /usr/local/etc/php/conf.d/xdebug.ini

FROM base AS production
COPY docker/php/opcache-prod.ini /usr/local/etc/php/conf.d/
COPY --chown=www-data:www-data . /var/www/html/
RUN cd /var/www/html && composer install --no-dev --optimize-autoloader --no-interaction
Makefile + Xdebug → PhpStorm/VSCodeCODE
# Makefile
export DEV_UID  := $(shell id -u)
export DEV_GID  := $(shell id -g)

install: build up
	docker compose exec --user www-data php composer install
	docker compose exec --user www-data php drush site:install --yes
	docker compose exec --user www-data php drush cim --yes
	docker compose exec php drush cr

up:     docker compose up -d
down:   docker compose down
build:  docker compose build php
logs:   docker compose logs php -f
shell:  docker compose exec php bash
verify: docker compose exec php drush core:requirements --format=table

# PhpStorm : Settings → PHP → Servers → /var/www/html → chemin local
# VSCode launch.json : "pathMappings": { "/var/www/html": "${workspaceFolder}" }
# Variable : XDEBUG_MODE=debug docker compose up -d (sans rebuild)
Points forts & faibles
Points forts
+Stack Docker Compose complète et production-ready dès le premier essai
+Xdebug configuré clé en main — plus de galère host.docker.internal
+Makefile standardisé — onboarding nouveau dev en 5 minutes (make install)
+Dockerfile multi-stage — une source, deux environnements distincts
Points faibles
Bind mounts lents sur Mac sans optimisation (Mutagen ou VirtioFS requis)
Multi-projets simultanés nécessite Traefik ou gestion manuelle des ports
Verdict

Stack Docker Drupal complète et battle-tested. Xdebug configuré correctement du premier coup, Makefile standardisé pour tout onboarding, Dockerfile multi-stage pour dev et production à partir de la même source.

Développeurs Drupal, DevOps, équipes qui cherchent un environnement Docker reproductible et maintenable