5.3Docker pour PHP : environnements reproductibles
L'essentiel en 30 secondes
- Fin du « ça marche sur ma machine » : le conteneur embarque l'app avec son environnement (version PHP, extensions, config) et tourne identiquement partout.
- Image → conteneur : le Dockerfile décrit la recette (image PHP, extensions, Composer), docker build fige l'image, docker run lance le conteneur.
- Compose pour la stack : PHP + base + cache décrits dans un fichier et lancés ensemble — onboarding en une commande.
Mini-cas filé — Riad conteneurise à Constantine
La boutique optimisée de Riad tourne parfaitement sur son poste à Constantine — mais plante chez sa collègue (version de PHP différente, extension PDO manquante, casse Windows/Linux). Il écrit un Dockerfile : image PHP, extensions installées dans l'image, dépendances Composer. Puis un fichier Compose avec MySQL : un seul lancement monte toute la stack. Suite des cas 5.1-5.2 — Riad rend son app reproductible partout.
Suite des cas 5.1-5.2 — Riad passe de « chez moi ça marche » à « partout pareil ».
1. Conteneuriser PHP : image et conteneur
Docker résout le « ça marche sur ma machine » — particulièrement fréquent en PHP (versions, extensions, configuration, sensibilité à la casse Windows/Linux) — en empaquetant l'application avec tout son environnement (la bonne version de PHP, les extensions, la configuration, les dépendances) dans un conteneur isolé et portable, qui tourne identiquement partout : poste, collègue, serveur, cloud. Concepts : l'image (modèle figé de l'app + environnement, défini par un Dockerfile — la recette : image PHP de base, extensions, code copié, dépendances Composer installées dans l'image, commande de démarrage) et le conteneur (instance en exécution d'une image). On construit (docker build), on lance (docker run). Riad ne débat plus des versions : l'environnement voyage avec le code.
Réflexe : tout ce qui est spécifique à votre poste et absent de l'image est un futur plantage ailleurs — l'image doit tout contenir (extensions comprises).
2. Docker Compose et bénéfices
Une application PHP réaliste a besoin de plusieurs conteneurs qui coopèrent : PHP (avec Nginx/Apache), la base (MySQL/MariaDB), éventuellement Redis. Docker Compose (docker-compose.yml) définit tous ces conteneurs et leurs relations, lancés ensemble d'une commande (docker compose up). Un seul fichier décrit toute la stack, reproductible à l'identique — et l'onboarding devient trivial : un nouveau développeur lance une commande et obtient tout l'environnement, sans installer ni configurer de pack local manuellement. Bénéfices : reproductibilité (identique partout), isolation (des projets avec des versions de PHP différentes cohabitent sans conflit), portabilité, facilité de déploiement, onboarding rapide. Riad ajoute MySQL au Compose : sa collègue démarre en minutes.
Docker est un standard du développement moderne et une compétence transversale : les bases suffisent pour commencer, l'orchestration avancée viendra selon les besoins.
3. Le bon dosage pour un développeur PHP
Pas besoin de devenir expert infrastructure : visez les bases utiles — écrire un Dockerfile PHP simple, construire et lancer, orchestrer la stack avec Compose, aligner l'image sur la production pour développer dans le même environnement que la mise en ligne. Pour apprendre PHP, un pack local suffit ; dès qu'on travaille en équipe, qu'on gère plusieurs projets (versions de PHP différentes) ou qu'on prépare un déploiement, Docker paie. À éviter : viser l'orchestration avancée avant les bases, ou conteneuriser un minuscule script d'apprentissage sans besoin réel. Riad garde son Dockerfile lisible : chaque instruction comprise vaut mieux qu'une recette copiée.
Le bon profil : un développeur qui connaît les bases de l'exploitation — autonome, capable non seulement de coder mais de livrer.
Le saviez-vous ?
Même image, même comportement — partout.
🔎 Exemple concret — Le Dockerfile de Riad
La recette de l'image PHP, lisible et générique.
FROM php:8.2-apache
RUN docker-php-ext-install pdo pdo_mysql opcache
COPY . /var/www/html/
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
RUN composer install --no-dev --optimize-autoloader
# docker compose up → PHP + MySQL ensembleLecture : chaque instruction a un rôle — base PHP, extensions, code, dépendances, optimisation prod.
Leçon : les extensions s'installent DANS l'image : plus d'écart entre les postes.
Vocabulaire de la section
- Docker
- Outil qui empaquette l'app avec son environnement dans un conteneur portable.
Exemple simple : La boutique de Riad tourne pareil à Constantine et chez sa collègue.
Ce que ce n'est pas : un pack local installé à la main sur chaque poste.
Réflexe : mon app dépend-elle encore de mon poste ?
- Image
- Modèle figé de l'app + environnement, construit depuis le Dockerfile.
Exemple simple : Riad construit une image versionnée de chaque livraison.
Ce que ce n'est pas : le conteneur en cours d'exécution.
Réflexe : puis-je reconstruire cette image à l'identique ?
- Dockerfile
- Recette de construction de l'image (base PHP, extensions, code, Composer).
Exemple simple : La recette lisible de la boutique de Riad, extensions comprises.
Ce que ce n'est pas : un script qui installe PHP à la main sur un serveur.
Réflexe : chaque instruction est-elle comprise, pas copiée ?
- Conteneur
- Instance en exécution d'une image, isolée et portable.
Exemple simple : Riad lance un conteneur identique en dev et en recette.
Ce que ce n'est pas : l'image figée elle-même.
Réflexe : dev et prod lancent-ils la même image ?
- Docker Compose
- Fichier décrivant plusieurs conteneurs lancés ensemble.
Exemple simple : PHP + MySQL de Riad démarrés d'une seule commande.
Ce que ce n'est pas : l'orchestration avancée de type Kubernetes.
Réflexe : un nouveau dev démarre-t-il en une commande ?
En pratique — Conteneuriser une application PHP
- Écrivez un Dockerfile : partir d'une image PHP, installer les extensions nécessaires, copier le code, installer les dépendances Composer.
- Orchestrez la stack avec Docker Compose : un docker-compose.yml définissant PHP (avec Nginx/Apache), MySQL, et éventuellement Redis, lancés ensemble (docker compose up).
- Vérifiez que l'application tourne dans les conteneurs et communique avec sa base (reproductibilité de l'environnement).
- Appréciez les bénéfices : isolation (versions de PHP par projet sans conflit), reproductibilité (fin du « ça marche chez moi »), onboarding (un docker compose up).
Script prêt à dire — proposer Docker à l'équipe
« Notre boutique marche sur mon poste mais pas ailleurs : c'est un problème d'environnement, pas de code — version de PHP, extension manquante. Je propose un Dockerfile simple plus un Compose avec MySQL. Chacun lancera la même image, et un nouvel arrivant démarrera en une commande. Les secrets resteront hors de l'image, passés par l'environnement. »
À dire en réunion d'équipe pour faire adopter la conteneurisation sans viser l'expertise DevOps.
Modèle copier-coller — Dockerfile PHP + Compose génériques
FROM php:8.2-apache
RUN docker-php-ext-install pdo pdo_mysql opcache
COPY . /var/www/html/
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
RUN composer install --no-dev --optimize-autoloader
# --- docker-compose.yml (stack générique) ---
# services:
# app:
# build: .
# ports: ["8080:80"]
# environment:
# - DB_HOST=db
# db:
# image: mysql:8.0
# environment:
# - MYSQL_DATABASE=boutique
# - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db_rootSolo / petit budget
Riad seul : un Dockerfile simple sans Compose suffit — l'image fige déjà l'environnement PHP.
TPE / équipe réduite
Compose PHP + MySQL : chaque collègue démarre la stack complète sans installation manuelle.
PME à Constantine
Riad partage l'image avec l'équipe à Constantine : tout le monde teste la même version, fin des écarts de poste.
Équipe qui démarre
Binôme : l'un écrit le Dockerfile, l'autre le relit ligne à ligne ; build testé sur deux postes avant adoption.
✓ Bonnes pratiques
- Installer les extensions DANS l'image (plus d'écart entre les postes).
- Aligner l'image sur la production (même version de PHP, mêmes extensions).
- Utiliser Docker Compose pour orchestrer la stack (onboarding rapide).
✗ Pièges fréquents
- Oublier une extension PHP dans l'image (plante ailleurs, pas chez soi).
- Mettre des secrets dans le Dockerfile ou l'image (lisibles par tous).
- Vouloir maîtriser l'orchestration avancée avant les bases.
Points clés à retenir
- DOCKER (conteneurisation) empaquette l'application AVEC son environnement (PHP, extensions, config, dépendances) dans un CONTENEUR isolé et portable, qui tourne IDENTIQUEMENT partout — fin du « ça marche sur ma machine » (fréquent en PHP).
- IMAGE (modèle figé, défini par un DOCKERFILE : image PHP + extensions + code + Composer) → CONTENEUR (instance en exécution).
- DOCKER COMPOSE (docker-compose.yml) orchestre la STACK PHP : plusieurs conteneurs (PHP/Nginx + MySQL + Redis) lancés ensemble (`docker compose up`).
- Bénéfices : REPRODUCTIBILITÉ, ISOLATION (versions de PHP par projet sans conflit), portabilité, déploiement facile, onboarding rapide. Standard moderne (transversal DevOps).
Défi 48h — appliquez demain
Écrivez le Dockerfile de votre app (modèle ci-dessus) et lancez-la en conteneur : répond-elle pareil que sur votre poste ?
- Je peux expliquer image vs conteneur en une phrase.
- Mon Dockerfile construit une image qui tourne.
- Je sais pourquoi les secrets n'y figurent pas.
Questions fréquentes
Qu'apporte Docker à un développeur PHP, et est-ce nécessaire quand un pack local fonctionne déjà ?
Un pack local est parfait pour débuter : simple, opérationnel en minutes — ne vous compliquez pas au début. Mais ses limites apparaissent en contexte professionnel : l'environnement peut différer de la production (versions, extensions, config — le classique « ça marche en local mais pas en ligne »), gérer plusieurs projets avec des versions de PHP différentes est compliqué, et l'environnement n'est pas facilement partageable. Docker apporte la reproductibilité (même environnement partout, y compris la production), l'isolation (chaque projet son conteneur, sans conflit de versions), la portabilité et un onboarding en une commande. Quasi incontournable en développement professionnel — à apprendre quand on travaille en équipe ou prépare un déploiement.
Docker, déploiement, CI/CD... un développeur PHP doit-il devenir un expert DevOps ?
Non, pas un expert — mais connaître les bases change tout : autonomie (mettre son travail en production sans dépendre d'autres), employabilité (les offres demandent Docker/déploiement/CI-CD), meilleure collaboration (apps faciles à déployer), vision complète du cycle. Visez les bases : conteneuriser et Compose (pas l'orchestration avancée), déployer sur un hébergement simple, un pipeline CI/CD simple, secrets et config en variables d'environnement, notions de logs et HTTPS. Le bon profil : un développeur qui connaît les bases de l'exploitation — capable non seulement de coder mais de livrer.
Quel problème Docker résout-il principalement ?