« Symfony Docker » : différence entre les versions

← Modification précédente Modification suivante →

@@ Ligne 667 : / Ligne 667 : @@
 C’est particulièrement important pour des services comme PHP-FPM qui doivent être le processus principal du container pour fonctionner correctement.
+----
+=== composer:latest (optionnel) ===
+Ce service Composer optionnel pour vous donner une '''alternative plus propre et isolée''' pour exécuter les commandes Composer, plutôt que de les exécuter directement dans le container PHP-FPM. Voici les raisons détaillées :
+-----
+=== 1. '''Séparation des responsabilités''' ===
+* '''Problème sans ce service''' :<br />
+Si vous utilisez <code>composer install/update</code> directement dans le container PHP (via <code>docker-compose exec php composer ...</code>), vous mélangez deux rôles :
+** Le service PHP-FPM (qui doit rester dédié à l’exécution PHP)
+** La gestion des dépendances (qui est un besoin ponctuel lors du développement)
+* '''Solution''' :<br />
+Un service dédié à Composer est éphémère (''run-and-die'') et ne pollue pas votre environnement PHP-FPM.
+-----
+=== 2. '''Avantages concrets''' ===
+==== a) '''Gestion propre des permissions''' ====
+* Les fichiers générés par Composer (vendor/, composer.lock) auront les '''mêmes permissions''' que votre utilisateur local (car le container Composer hérite des permissions du volume monté).
+* Évite les problèmes classiques de permissions quand on utilise <code>composer install</code> dans le container PHP.
+==== b) '''Isolation des dépendances''' ====
+* Le container PHP n’a pas besoin d’avoir Composer installé en permanence (même si mon Dockerfile l’inclut pour la flexibilité).
+* Réduction de l’image finale en production (vous pouvez créer une image sans Composer).
+==== c) '''Compatibilité avec les bundles locaux''' ====
+* Comme vous utilisez des bundles locaux (via <code>&quot;type&quot;: &quot;path&quot;</code>), le service Composer monte à la fois <code>./app</code> et <code>./Bundles</code>, garantissant que les symlinks fonctionnent correctement.
+-----
+=== 3. '''Comment l’utiliser ?''' ===
+Exemples d’utilisation :
+<syntaxhighlight lang="bash"># Installation des dépendances
+docker-compose run --rm composer install
+# Mise à jour d'un bundle local
+docker-compose run --rm composer update vendor/bundlea
+# Ajout d'une nouvelle dépendance
+docker-compose run --rm composer require symfony/package</syntaxhighlight>
+* <code>--rm</code> : Détruit le container après l’exécution (pour éviter l’accumulation de containers stoppés).
+* Le <code>working_dir: /var/www</code> fait que les commandes s’exécutent directement dans le dossier du projet.
+-----
+=== 4. '''Alternative : Composer dans le container PHP''' ===
+Si vous préférez ne pas utiliser ce service optionnel, vous pouvez : 1. Utiliser le Composer inclus dans le container PHP :<br />
+<code>bash    docker-compose exec php composer install</code> 2. Ou via le script <code>entrypoint.sh</code> (qui vérifie déjà si <code>vendor/</code> existe).
+-----
+=== 5. '''Pourquoi “optionnel” ?''' ===
+* Beaucoup de développeurs préfèrent exécuter Composer '''en dehors de Docker''' (sur leur machine host) pour des raisons de performance (cache Composer partagé, pas de overhead Docker).
+* Mais dans votre cas, avec des bundles locaux et une configuration spécifique, avoir un service dédié est plus fiable.
+-----
+=== En résumé : ===
+{| class="wikitable"
+|-
+! Approche
+! Avantages
+! Inconvénients
+|-
+| '''Service Composer dédié'''
+| Propre, isolé, permissions cohérentes
+| Un peu plus verbeux à taper
+|-
+| '''Composer dans le container PHP'''
+| Rapide à exécuter
+| Pollue le container PHP
+|-
+| '''Composer sur la machine host'''
+| Meilleures performances
+| Peut causer des problèmes de permissions
+|}
+Le choix dépend de votre workflow, d’où le caractère optionnel !
 [[Catégorie:Symfony]] [[Catégorie:Docker]]

« Symfony Docker » : différence entre les versions

« Symfony Docker » : différence entre les versions