Tu utilises encore WAMP ? Docker t'attend déjà au bar

Sérieusement, tu ouvres encore WAMP ?

WAMP, XAMPP ou MAMP ont rendu service quand on découvrait PHP en 2010, mais aujourd'hui ils ressemblent à ces bars qui servent encore du Coca tiède. Tu veux reproduire une stack de prod en local ? Tu veux versionner ta config ? Tu veux éviter les conflits de ports quand tu bosses sur trois projets ? Docker a coché toutes les cases pendant que ton installeur Apache clignotait en rouge.

Les emmerdes de WAMP/XAMPP/MAMP

• Environnements figés : chaque pile impose sa version de PHP, MySQL et Apache. Tu veux tester PHP 8.3 ? Bonne chance pour ne pas casser les trois autres projets.
• Config introuvable : impossible de partager proprement ta stack avec ton équipe ou ton CI. Tu copies des .ini sur Slack ? C'est mignon.
• Isolation zéro : un module Apache activé pour un projet fuit directement sur tous les autres. Bonjour les bugs fantômes.

Pourquoi Docker change tout

• Stack décrite en YAML : un compose.yml versionné te permet de recréer l'environnement sur n'importe quelle machine ou pipeline CI en une commande.
• Isolation par service : chaque conteneur embarque sa version exacte de PHP, Redis, PostgreSQL, etc. Tu choisis, tu mixes, tu jettes.
• Observabilité native : logs, métriques, healthchecks... plus besoin de deviner si mysqld a bien démarré.
• Portabilité : Linux, macOS, Windows, ARM, x86… Docker s'en fiche, tant que le noyau sait lancer des conteneurs.

Compose moderne : finis les docker-compose.yml poussiéreux

Les bonnes pratiques de la doc Docker sont claires : file compose.yml à la racine, pas de champ version, variables dans .env, et des services décrits de façon déclarative. Voilà un extrait prêt à l'emploi :

yaml
1name: atelier-php
2
3services:
4  frankenphp:
5    image: dunglas/frankenphp:1.1-php8.3
6    pull_policy: always
7    ports:
8      - "8080:80"
9    environment:
10      APP_RUNTIME: frankenphp
11      SERVER_NAME: localhost
12    volumes:
13      - ./app:/app:delegated
14    depends_on:
15      mariadb:
16        condition: service_healthy
17
18  mariadb:
19    image: mariadb:11
20    environment:
21      MYSQL_ROOT_PASSWORD: root
22      MYSQL_DATABASE: app
23    volumes:
24      - db_data:/var/lib/mysql
25    healthcheck:
26      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
27      interval: 5s
28      retries: 10
29
30volumes:
31  db_data:

Quelques détails cruciaux :

• name facilite la lecture des logs et l'intégration avec docker compose ls.
• pull_policy: always évite les images obsolètes lorsque tu mets à jour la stack.
• depends_on couplé à condition: service_healthy attend que MariaDB soit prêt avant de lancer FrankenPHP.
• Les volumes déclarés en bas tiennent tes données MySQL à l'abri quand tu redéploies.

FrankenPHP, le remplaçant insolent d'Apache

Pourquoi s'entêter avec Apache ou Nginx dans un conteneur alors que FrankenPHP combine SAPI moderne, worker HTTP et support natif de Symfony/Laravel ?

• Performance : mode worker persistant, cache OPCache préchauffé, HTTP/2 et bientôt HTTP/3.
• Simplicité : pas besoin de configurer 14 fichiers .conf; tu poses ton app dans /app, tu exposes le port 80 et basta.
• Intégration dev : hot reload via symfony serve n'est plus nécessaire, FrankenPHP gère la boucle.

Et la CI/CD dans tout ça ?

Tu checkes ton code avec docker compose run --rm lint et tu déploies la même stack en prod. Pas de "ça marche sur ma machine", pas d'environnements mutants, pas de chasse au port 3306.

Conclusion cynique mais honnête

Tu peux continuer à caresser l'icône verte de WAMP si tu aimes souffrir. Mais si tu veux livrer plus vite, versionner ton infra et tester des combos improbables (Redis + Meilisearch + FrankenPHP + PostgreSQL) en trois lignes, Docker est déjà là, impatient. Range tes installeurs préhistoriques, compose ton compose.yml, et reviens nous dire merci quand ton prochain onboarding dure cinq minutes.