Symfony Docker

Docker avec les commandes composer, symfony et bin/console

Pour pouvoir exécuter des commandes composer, symfony et bin/console depuis votre machine locale tout en les faisant affecter le conteneur Docker, voici une approche optimale basée sur des volumes montés et des alias pratiques.

---

1. Montage des volumes pour synchroniser les fichiers

L’idée est de monter votre code local dans le conteneur pour que les modifications soient immédiatement visibles des deux côtés.

Solution 1 : Utilisation de docker-compose.yml (recommandé)

version: '3.8'

services:
  app:
    build: .
    volumes:
      - ./:/var/www/html  # Monte le projet Symfony (y compris vendor/)
      - ~/.composer:/tmp/composer  # Cache Composer (optionnel)
    working_dir: /var/www/html
    ports:
      - "8000:8000"  # Symfony CLI ou PHP-FPM
    tty: true
    stdin_open: true

Explications :

• ./:/var/www/html : Synchronise le code local avec le conteneur (y compris vendor/).
• ~/.composer:/tmp/composer : Cache Composer pour éviter de retélécharger les dépendances.
• working_dir : S’assure que les commandes s’exécutent dans /var/www/html.

---

2. Exécuter des commandes dans le conteneur depuis l’hôte

Méthode 1 : docker-compose exec (pour les commandes ponctuelles)

# Commande Composer (ex: ajouter un bundle)
docker-compose exec app composer require mon/bundle-local

# Commande Symfony CLI (ex: lancer le serveur)
docker-compose exec app symfony serve -d

# Commande Console (ex: migrer la base)
docker-compose exec app php bin/console make:migration

Méthode 2 : Alias shell pour simplifier (dans ~/.bashrc ou ~/.zshrc)

# Alias pour Composer
alias dc-composer="docker-compose exec app composer"

# Alias pour Symfony CLI
alias dc-symfony="docker-compose exec app symfony"

# Alias pour la Console Symfony
alias dc-console="docker-compose exec app php bin/console"

Utilisation :

dc-composer require mon/bundle-local
dc-console make:migration
dc-symfony serve -d

---

3. Cas particulier : Développement d’un bundle local

Si vous développez un bundle en local et qu’il est lié via composer.json en "type": "path", assurez-vous que : 1. Le chemin est correct dans composer.json : json { "require": { "mon/bundle-local": "*", "symfony/framework-bundle": "^6.0" }, "repositories": [ { "type": "path", "url": "./packages/mon-bundle-local" } ] } 2. Le volume est bien monté dans docker-compose.yml : yaml volumes: - ./:/var/www/html - ./packages/mon-bundle-local:/var/www/html/packages/mon-bundle-local # Si le bundle est dans un sous-dossier 3. Reconstruire l’autoload après modification du bundle : bash docker-compose exec app composer dump-autoload

---

4. Optimisation pour le dev : Xdebug + volumes

Si vous utilisez Xdebug ou souhaitez un rechargement automatique :

# docker-compose.yml (extrait)
services:
  app:
    environment:
      XDEBUG_MODE: "develop,debug"
    volumes:
      - ./:/var/www/html
      - ~/.composer:/tmp/composer

---

Récapitulatif des bonnes pratiques

Besoin	Solution
Exécuter composer	docker-compose exec app composer require mon/bundle
Lancer bin/console	docker-compose exec app php bin/console make:migration
Utiliser Symfony CLI	docker-compose exec app symfony serve -d
Développer un bundle local	Monter le dossier du bundle + composer dump-autoload après modification
Optimiser l’expérience dev	Alias shell + volumes montés + Xdebug

---

Conclusion

• ✅ Pour les commandes composer/symfony/console : Utilisez docker-compose exec.
• ✅ Pour le dev de bundles locaux : Montez le dossier et utilisez composer dump-autoload.
• ✅ Pour simplifier les commandes : Créez des alias (dc-composer, dc-console).

Cette approche permet un développement fluide sans avoir à reconstruire l’image à chaque modification. 🚀

composer dump-autoload

La commande composer dump-autoload est une commande essentielle dans l’écosystème PHP/Composer. Elle régénère le fichier d’autoloading (chargement automatique des classes) sans réinstaller les dépendances. Voici ce qu’elle fait en détail :

---

À quoi sert composer dump-autoload ?

1. Reconstruit l’autoloader de Composer
   • Met à jour le fichier vendor/autoload.php qui gère le chargement automatique des classes PHP.
   • Utile quand vous ajoutez/modifiez des classes sans passer par composer install/update.
2. Optimise les performances (si utilisé avec -o)

   • Avec l’option --optimize (-o), Composer génère une version optimisée de l’autoloader (classe map statique), ce qui accélère le chargement des classes en production :

     composer dump-autoload --optimize
     

3. Prend en compte les classes dans autoload ou autoload-dev

   • Si vous avez des classes définies dans composer.json sous :

     "autoload": {
         "psr-4": { "MonApp\\": "src/" }
     }
     

   • La commande les intègre dans l’autoloader.

---

Quand l’utiliser ?

Cas d’usage	Commande recommandée
Après avoir ajouté une nouvelle classe manuellement (sans Composer).	composer dump-autoload
En production pour optimiser les performances.	composer dump-autoload --optimize
Après avoir modifié composer.json (sans vouloir réinstaller les dépendances).	composer dump-autoload
Pour vérifier les espaces de noms (PSR-4).	composer dump-autoload

---

Différence avec composer install et composer update

• composer install :
  

Installe les dépendances ET régénère l’autoloader.

• composer update :
  

Met à jour les dépendances ET régénère l’autoloader.

• composer dump-autoload :
  

Ne touche pas aux dépendances – ne fait que mettre à jour l’autoloader.

---

Exemple concret dans un projet Symfony

1. Vous ajoutez une nouvelle entité src/Entity/Product.php :

   • Symfony utilise l’autoloading PSR-4, donc la classe sera automatiquement détectée.
     

   • Si elle n’est pas reconnue, exécutez :

     composer dump-autoload
     

2. Vous développez un bundle local (lié via "type": "path" dans composer.json) :

   • Après avoir modifié le bundle, pour que Symfony reconnaisse les nouvelles classes :

     composer dump-autoload
     

---

Bonnes pratiques

• En développement :
  Utilisez composer dump-autoload après avoir ajouté des classes manuellement.
  

• En production :
  Utilisez composer dump-autoload --optimize pour des performances optimales.
  

• Avec Docker :
  Si vous montez un volume (./:/var/www/html), exécutez la commande dans le conteneur :

  docker-compose exec app composer dump-autoload
  

---

Résumé

composer dump-autoload est un outil léger pour rafraîchir l’autoloader sans toucher aux dépendances. Indispensable pour :
- Le développement de bundles locaux.
- L’ajout manuel de classes.
- L’optimisation en production.

Utilisez-la dès que vous rencontrez des erreurs du type :
> “Class ‘MonApp\Entity\Product’ not found”

🚀 Astuce : Combinez-la avec --optimize en prod pour un boost de performances !

Symfony cache et composer cache avec Docker :

---

1. Rôle du dossier /var/cache dans Symfony

Symfony utilise ce dossier pour : - Le cache applicatif (ex : compilation des templates Twig, cache des routes, annotations) - Le cache système (ex : fichiers de configuration compilés comme srcApp_KernelDevDebugContainer.php)

Problème avec Docker :
Par défaut, ce cache est régénéré à chaque démarrage du conteneur → ralentissements (surtout en dev).

---

2. Stratégies pour optimiser le cache avec Docker

A. Monter /var/cache en volume (pour le dev)

# docker-compose.yml
services:
  php:
    volumes:
      - ./var/cache:/var/www/html/var/cache  # Monte le cache Symfony

Avantages : - Le cache persiste entre les redémarrages du conteneur. - Meilleures performances en développement.

Inconvénients : - Peut causer des problèmes de permissions (solved avec chmod ou entrypoint.sh).

---

B. Utiliser un volume Docker nommé (prod + dev)

volumes:
  symfony_cache:  # Volume dédié pour le cache

services:
  php:
    volumes:
      - symfony_cache:/var/www/html/var/cache

Bonus : Ajoutez un entrypoint.sh pour fixer les permissions :

#!/bin/bash
set -e

# Fixe les permissions du cache
chown -R www-data:www-data /var/www/html/var

exec "$@"

---

C. Cache warming en production

Dans votre Dockerfile :

FROM composer AS builder
WORKDIR /app
COPY . .
RUN composer install --no-dev --optimize-autoloader

FROM php:8.2-fpm
COPY --from=builder /app /var/www/html
RUN php bin/console cache:warmup  # ⚡ Pré-chauffe le cache

---

3. Gestion des environnements

Environnement	Recommandation
Développement	Volume monté (./var/cache:/...) + chmod
Production	Volume nommé + cache warming dans l’image
CI/CD	Cache éphémère (pas de montage)

---

4. Exemple complet (docker-compose.yml)

version: '3.8'

volumes:
  symfony_cache:  # Pour le cache
  composer_cache: # Pour Composer

services:
  app:
    build: .
    volumes:
      - ./:/var/www/html
      - symfony_cache:/var/www/html/var/cache
      - composer_cache:/tmp/composer
    environment:
      APP_ENV: dev
      COMPOSER_CACHE_DIR: /tmp/composer

---

5. Bonnes pratiques

1. En dev : Montez var/cache pour éviter de tout recompiler.

2. En prod : Utilisez cache:warmup dans l’image + volume nommé.

3. Permissions : Résolvez-les via entrypoint.sh ou docker-compose :

   user: "${UID:-1000}:${GID:-1000}"
   

---

Différence avec Composer Cache

	Composer (~/.composer)	Symfony (/var/cache)
Type	Cache de dépendances	Cache applicatif
Montage	Toujours utile	Surtout en dev
Prod	Volume nommé recommandé	Warming dans l’image + volume

---

Résumé

• Oui, on peut appliquer le même principe de volume monté pour /var/cache.
  

• Mais : Symfony a besoin d’une gestion plus active (warming, permissions).
  

• Optimisez :
  • Dev → Volume monté + permissions
    

• • Prod → Cache warming + volumes nommés

Cela garantit des performances optimales dans tous les cas ! 🚀