Marmits Wiki

« Symfony Docker » : différence entre les versions

← Modification précédente
 
(23 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
== '''Docker avec les commandes <code>composer</code>, <code>symfony</code> et <code>bin/console</code>''' ==
Pour pouvoir exécuter des commandes '''<code>composer</code>''', '''<code>symfony</code>''' et '''<code>bin/console</code>''' 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 <code>docker-compose.yml</code> (recommandé)''' ====
<syntaxhighlight lang="yaml">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</syntaxhighlight>
==== '''Explications :''' ====
* <code>./:/var/www/html</code> : Synchronise le code local avec le conteneur (y compris <code>vendor/</code>).
* <code>~/.composer:/tmp/composer</code> : Cache Composer pour éviter de retélécharger les dépendances.
* <code>working_dir</code> : S’assure que les commandes s’exécutent dans <code>/var/www/html</code>.
=== '''2. Exécuter des commandes dans le conteneur depuis l’hôte''' ===
==== '''Méthode 1 : <code>docker-compose exec</code> (pour les commandes ponctuelles)''' ====
<syntaxhighlight lang="bash"># 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</syntaxhighlight>
==== '''Méthode 2 : Alias shell pour simplifier (dans <code>~/.bashrc</code> ou <code>~/.zshrc</code>)''' ====
<syntaxhighlight lang="bash"># 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"</syntaxhighlight>
'''Utilisation :'''
<syntaxhighlight lang="bash">dc-composer require mon/bundle-local
dc-console make:migration
dc-symfony serve -d</syntaxhighlight>
=== '''3. Cas particulier : Développement d’un bundle local''' ===
Si vous développez un bundle en local et qu’il est lié via <code>composer.json</code> en <code>"type": "path"</code>, assurez-vous que :<br />
1. '''Le chemin est correct''' dans <code>composer.json</code> :
<syntaxhighlight lang="json">{     
    "require": {
        "mon/bundle-local": "*",
        "symfony/framework-bundle": "^6.0"
    },       
    "repositories": [
        {
            "type": "path",
            "url": "./packages/mon-bundle-local"
        }
    ]
}
</syntaxhighlight>
2. '''Le volume est bien monté''' dans <code>docker-compose.yml</code> :
<syntaxhighlight lang="yaml"> 
volumes:
- ./:/var/www/html
- ./packages/mon-bundle-local:/var/www/html/packages/mon-bundle-local
# Si le bundle est dans un sous-dossier
</syntaxhighlight>
3. '''Reconstruire l’autoload''' après modification du bundle :
<syntaxhighlight lang="bash" copy>bash docker-compose exec app composer dump-autoload</syntaxhighlight>
=== '''4. Optimisation pour le dev : Xdebug + volumes''' ===
Si vous utilisez '''Xdebug''' ou souhaitez un rechargement automatique :
<syntaxhighlight lang="yaml"># docker-compose.yml (extrait)
services:
  app:
    environment:
      XDEBUG_MODE: "develop,debug"
    volumes:
      - ./:/var/www/html
      - ~/.composer:/tmp/composer</syntaxhighlight>
=== '''Récapitulatif des bonnes pratiques''' ===
{| class="wikitable"
|-
! Besoin
! Solution
|-
| '''Exécuter <code>composer</code>'''
| <code>docker-compose exec app composer require mon/bundle</code>
|-
| '''Lancer <code>bin/console</code>'''
| <code>docker-compose exec app php bin/console make:migration</code>
|-
| '''Utiliser Symfony CLI'''
| <code>docker-compose exec app symfony serve -d</code>
|-
| '''Développer un bundle local'''
| Monter le dossier du bundle + <code>composer dump-autoload</code> après modification
|-
| '''Optimiser l’expérience dev'''
| Alias shell + volumes montés + Xdebug
|}
==== '''Conclusion''' ====
* ✅ '''Pour les commandes <code>composer</code>/<code>symfony</code>/<code>console</code>''' : Utilisez <code>docker-compose exec</code>.
* ✅ '''Pour le dev de bundles locaux''' : Montez le dossier et utilisez <code>composer dump-autoload</code>.
* ✅ '''Pour simplifier les commandes''' : Créez des alias (<code>dc-composer</code>, <code>dc-console</code>).
Cette approche permet un '''développement fluide''' sans avoir à reconstruire l’image à chaque modification. 🚀
== '''composer dump-autoload''' ==
== '''composer dump-autoload''' ==


La commande '''<code>composer dump-autoload</code>''' 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 :
La commande '''<code>composer dump-autoload</code>''' 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 <code>composer dump-autoload</code> ?''' ===
=== '''À quoi sert <code>composer dump-autoload</code> ?''' ===
Ligne 27 : Ligne 156 :
<li><p>La commande les intègre dans l’autoloader.</p></li></ul>
<li><p>La commande les intègre dans l’autoloader.</p></li></ul>
</li></ol>
</li></ol>
-----


=== '''Quand l’utiliser ?''' ===
=== '''Quand l’utiliser ?''' ===
Ligne 50 : Ligne 176 :
| <code>composer dump-autoload</code>
| <code>composer dump-autoload</code>
|}
|}
-----


=== '''Différence avec <code>composer install</code> et <code>composer update</code>''' ===
=== '''Différence avec <code>composer install</code> et <code>composer update</code>''' ===
Ligne 64 : Ligne 187 :
* '''<code>composer dump-autoload</code>''' :<br />
* '''<code>composer dump-autoload</code>''' :<br />
'''Ne touche pas aux dépendances''' – ne fait que mettre à jour l’autoloader.
'''Ne touche pas aux dépendances''' – ne fait que mettre à jour l’autoloader.
-----


=== '''Exemple concret dans un projet Symfony''' ===
=== '''Exemple concret dans un projet Symfony''' ===
Ligne 83 : Ligne 203 :
<syntaxhighlight lang="bash">composer dump-autoload</syntaxhighlight></li></ul>
<syntaxhighlight lang="bash">composer dump-autoload</syntaxhighlight></li></ul>
</li></ol>
</li></ol>
-----


=== '''Bonnes pratiques''' ===
=== '''Bonnes pratiques''' ===
Ligne 99 : Ligne 216 :
Si vous montez un volume (<code>./:/var/www/html</code>), exécutez la commande '''dans le conteneur''' :</p>
Si vous montez un volume (<code>./:/var/www/html</code>), exécutez la commande '''dans le conteneur''' :</p>
<syntaxhighlight lang="bash">docker-compose exec app composer dump-autoload</syntaxhighlight></li></ul>
<syntaxhighlight lang="bash">docker-compose exec app composer dump-autoload</syntaxhighlight></li></ul>
-----


=== '''Résumé''' ===
=== '''Résumé''' ===
Ligne 116 : Ligne 230 :


== '''Symfony cache et composer cache avec Docker''' : ==
== '''Symfony cache et composer cache avec Docker''' : ==
-----


=== '''1. Rôle du dossier <code>/var/cache</code> dans Symfony''' ===
=== '''1. Rôle du dossier <code>/var/cache</code> dans Symfony''' ===
Ligne 126 : Ligne 237 :
'''Problème avec Docker :'''<br />
'''Problème avec Docker :'''<br />
Par défaut, ce cache est régénéré à chaque démarrage du conteneur → '''ralentissements''' (surtout en dev).
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''' ===
=== '''2. Stratégies pour optimiser le cache avec Docker''' ===
Ligne 142 : Ligne 250 :


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


==== '''B. Utiliser un volume Docker nommé (prod + dev)''' ====
==== '''B. Utiliser un volume Docker nommé (prod + dev)''' ====
Ligne 164 : Ligne 269 :


exec "$@"</syntaxhighlight>
exec "$@"</syntaxhighlight>
-----


==== '''C. Cache warming en production''' ====
==== '''C. Cache warming en production''' ====
Ligne 179 : Ligne 282 :
COPY --from=builder /app /var/www/html
COPY --from=builder /app /var/www/html
RUN php bin/console cache:warmup  # ⚡ Pré-chauffe le cache</syntaxhighlight>
RUN php bin/console cache:warmup  # ⚡ Pré-chauffe le cache</syntaxhighlight>
-----


=== '''3. Gestion des environnements''' ===
=== '''3. Gestion des environnements''' ===
Ligne 198 : Ligne 299 :
| Cache éphémère (pas de montage)
| Cache éphémère (pas de montage)
|}
|}
-----


=== '''4. Exemple complet (docker-compose.yml)''' ===
=== '''4. Exemple complet (docker-compose.yml)''' ===
Ligne 220 : Ligne 318 :
       APP_ENV: dev
       APP_ENV: dev
       COMPOSER_CACHE_DIR: /tmp/composer</syntaxhighlight>
       COMPOSER_CACHE_DIR: /tmp/composer</syntaxhighlight>
-----
=== '''5. Bonnes pratiques''' ===
=== '''5. Bonnes pratiques''' ===


Ligne 230 : Ligne 325 :
<li><p>'''Permissions''' : Résolvez-les via <code>entrypoint.sh</code> ou <code>docker-compose</code> :</p>
<li><p>'''Permissions''' : Résolvez-les via <code>entrypoint.sh</code> ou <code>docker-compose</code> :</p>
<syntaxhighlight lang="yaml">user: "${UID:-1000}:${GID:-1000}"</syntaxhighlight></li></ol>
<syntaxhighlight lang="yaml">user: "${UID:-1000}:${GID:-1000}"</syntaxhighlight></li></ol>
-----


=== '''Différence avec Composer Cache''' ===
=== '''Différence avec Composer Cache''' ===
Ligne 254 : Ligne 346 :
| Warming dans l’image + volume
| Warming dans l’image + volume
|}
|}
-----


=== '''Résumé''' ===
=== '''Résumé''' ===
Ligne 270 : Ligne 359 :


Cela garantit des performances optimales dans tous les cas ! 🚀
Cela garantit des performances optimales dans tous les cas ! 🚀
== '''Configuration Docker pour un projet Symfony 6 / PHP FPM / avec des bundles locaux''' ==
Voici une méthode complète pour configurer votre environnement Docker avec Symfony 6, PHP 8.2, Apache, PostgreSQL et la gestion des bundles locaux.
=== 1. Structure recommandée ===
<pre>~/debian/projet/
├── app/                  # Votre projet Symfony principal
│  ├── src/
│  ├── vendor/
│  └── ...
├── Bundles/              # Vos bundles locaux
│  ├── bundlea/          # Bundle A
│  └── bundleb/          # Bundle B
├── docker/
│  ├── apache/
│  │  └── vhost.conf  # Configuration Apache
│  ├── php/
│  │  └── php.ini      # Configuration PHP
│  └── entrypoint.sh    # Script d'initialisation
├── Dockerfile            # Fichier de build
└── docker-compose.yml    # Configuration des services</pre>
=== 2. Dockerfile ===
<syntaxhighlight lang="dockerfile"># Dockerfile
FROM php:8.2-fpm
# Install system dependencies
RUN apt-get update && apt-get install -y \
    git \
    curl \
    libpng-dev \
    libonig-dev \
    libxml2-dev \
    libzip-dev \
    libpq-dev \
    unzip \
    libevent-dev \
    && rm -rf /var/lib/apt/lists/*
# Install PHP extensions
RUN docker-php-ext-install \
    pdo \
    pdo_pgsql \
    pgsql \
    mbstring \
    exif \
    pcntl \
    bcmath \
    gd \
    zip \
    sockets
# Install event extension
RUN pecl install event && docker-php-ext-enable event
# Install Composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
# Set working directory
WORKDIR /var/www
# Copy entrypoint
COPY docker/entrypoint.sh /usr/local/bin/entrypoint
RUN chmod +x /usr/local/bin/entrypoint
ENTRYPOINT ["entrypoint"]</syntaxhighlight>
=== 3. docker-compose.yml ===
<syntaxhighlight lang="yaml">version: '3.8'
services:
  php:
    build: .
    volumes:
      - ./app:/var/www
      - ./Bundles:/var/www/bundles
    environment:
      - DATABASE_URL=postgresql://symfony:ChangeMe@postgres:5432/app?serverVersion=15&charset=utf8
    depends_on:
      - postgres
  apache:
    image: httpd:2.4
    ports:
      - "8080:80"
    volumes:
      - ./app/public:/var/www/html
      - ./docker/apache/vhost.conf:/usr/local/apache2/conf/extra/httpd-vhosts.conf
    command: ["httpd-foreground"]
    depends_on:
      - php
  postgres:
    image: postgres:15
    environment:
      POSTGRES_USER: symfony
      POSTGRES_PASSWORD: ChangeMe
      POSTGRES_DB: app
    volumes:
      - postgres_data:/var/lib/postgresql/data
volumes:
  postgres_data:</syntaxhighlight>
=== 3 bis. docker-compose.yml (option dans compose.yml) ===
Voir [[#composer-optionnel|Composer optionnel]].
<syntaxhighlight lang="yaml">
  # Optionnel: Composer en tant que service
  composer:
    image: composer:latest
    volumes:
      - ./app:/var/www
      - ./Bundles:/var/www/bundles
    working_dir: /var/www
    entrypoint: ['composer']
</syntaxhighlight>
=== 4. Configuration Apache (docker/apache/vhost.conf) ===
<syntaxhighlight lang="apache"><VirtualHost *:80>
    ServerName localhost
    DocumentRoot /var/www/html
    <Directory /var/www/html>
        AllowOverride All
        Require all granted
    </Directory>
    ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://php:9000/var/www/public/$1
</VirtualHost></syntaxhighlight>
=== 5. Script entrypoint.sh ===
<syntaxhighlight lang="bash">#!/bin/bash
set -e
# Installer les dépendances si le vendor n'existe pas
if [ ! -d "/var/www/vendor" ]; then
  cd /var/www
  composer install
fi
# Lancer PHP-FPM
exec docker-php-entrypoint "$@"</syntaxhighlight>
=== 6. Configuration Composer dans votre projet Symfony ===
Dans votre <code>app/composer.json</code>, assurez-vous d’avoir:
<syntaxhighlight lang="json">{
  "repositories": [
    {
      "type": "path",
      "url": "../Bundles/bundlea",
      "options": {
        "symlink": true
      }
    },
    {
      "type": "path",
      "url": "../Bundles/bundleb",
      "options": {
        "symlink": true
      }
    }
  ]
}</syntaxhighlight>
=== 7. Workflow recommandé ===
<ol style="list-style-type: decimal;">
<li><p>'''Initialisation''':</p>
<syntaxhighlight lang="bash">docker-compose build
docker-compose up -d</syntaxhighlight></li>
<li><p>'''Pour utiliser Composer''':</p>
<ul>
<li><p>Soit via le service Composer:</p>
<syntaxhighlight lang="bash">docker-compose run --rm composer install
docker-compose run --rm composer update</syntaxhighlight></li>
<li><p>Soit en entrant dans le container PHP:</p>
<syntaxhighlight lang="bash">docker-compose exec php bash
composer install</syntaxhighlight></li></ul>
</li>
<li><p>'''Configuration PHPStorm''':</p>
<ul>
<li>Configurer l’interpréteur PHP dans Settings &gt; PHP</li>
<li>Ajouter les mappings de chemins:
<ul>
<li><code>/var/www</code> → <code>./app</code></li>
<li><code>/var/www/bundles</code> → <code>./Bundles</code></li></ul>
</li>
<li>Configurer le serveur Apache dans Settings &gt; PHP &gt; Servers
<ul>
<li>Nom: Docker Apache</li>
<li>Host: localhost</li>
<li>Port: 8080</li>
<li>Debugger: Xdebug</li>
<li>Path mappings comme ci-dessus</li></ul>
</li></ul>
</li></ol>
=== 8. Avantages de cette configuration ===
# '''Développement simultané''':
#* Vos bundles locaux sont accessibles dans le container via <code>/var/www/bundles</code>
#* Les modifications sont immédiatement visibles dans les deux sens
# '''Performance''':
#* Les dépendances sont installées dans le container
#* Les symlinks Composer fonctionnent correctement
# '''Flexibilité''':
#* Vous pouvez utiliser Composer de plusieurs manières
#* Configuration facilement extensible
Cette configuration vous permettra de travailler efficacement avec PHPStorm tout en bénéficiant d’un environnement Docker isolé et reproductible.
Cette ligne est assez importante dans le contexte d’un Dockerfile et d’un script d’entrée (entrypoint). Je vais vous l’expliquer en détail :
=== Explication de <code>exec docker-php-entrypoint &quot;$@&quot;</code> ===
# '''<code>exec</code>''' :
#* En shell, la commande <code>exec</code> remplace le processus courant (le script entrypoint.sh) par le nouveau processus spécifié
#* Cela signifie que le processus PID 1 du container devient <code>docker-php-entrypoint</code> au lieu de <code>entrypoint.sh</code>
#* Avantages :
#** Évite d’avoir un processus shell inutile qui reste en vie
#** Permet de recevoir correctement les signaux système (comme SIGTERM)
# '''<code>docker-php-entrypoint</code>''' :
#* C’est le script d’entrée par défaut de l’image officielle PHP
#* Il est fourni par les mainteneurs de l’image Docker PHP
#* Son rôle principal est de :
#** Configurer certaines variables d’environnement
#** Préparer le runtime PHP
#** Finalement lancer PHP-FPM
# '''<code>&quot;$@&quot;</code>''' :
#* C’est une notation spéciale en shell qui signifie “tous les arguments passés au script”
#* Si vous lancez le container avec <code>docker run votre-image php -v</code>, alors <code>&quot;$@&quot;</code> contiendra <code>php -v</code>
#* Cela permet de transmettre tous les arguments au processus suivant
=== Pourquoi c’est important dans votre cas ? ===
Dans votre entrypoint.sh, vous faites d’abord :
<syntaxhighlight lang="bash"># Vérifie si vendor existe, sinon installe les dépendances
if [ ! -d "/var/www/vendor" ]; then
  cd /var/www
  composer install
fi</syntaxhighlight>
Puis vous terminez avec :
<syntaxhighlight lang="bash"># Passe le relais au entrypoint officiel PHP
exec docker-php-entrypoint "$@"</syntaxhighlight>
Cela signifie : 1. Votre script fait d’abord son travail personnalisé (vérifier/vendor et installer les dépendances si besoin) 2. Ensuite, il “passe la main” au processus PHP-FPM officiel, devenant ainsi le processus principal du container
=== Alternative sans <code>exec</code> ===
Si vous écriviez simplement :
<syntaxhighlight lang="bash">docker-php-entrypoint "$@"</syntaxhighlight>
Au lieu de :
<syntaxhighlight lang="bash">exec docker-php-entrypoint "$@"</syntaxhighlight>
Alors : - Le shell du script entrypoint.sh resterait en vie inutilement - Les signaux système ne seraient pas correctement transmis à PHP-FPM - Vous auriez un processus superflu dans votre container
=== En résumé ===
Cette ligne est une bonne pratique Docker qui permet : 1. D’exécuter votre logique personnalisée avant le démarrage 2. De transférer proprement l’exécution au processus principal 3. De garantir une gestion propre des processus et des signaux
C’est particulièrement important pour des services comme PHP-FPM qui doivent être le processus principal du container pour fonctionner correctement.
----
<span id="composer-optionnel"></span>
=== '''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 !
== '''version complète optimisée avec un service Composer dédié''' ==
Voici une version complète optimisée avec '''un service Composer dédié''', tout en gardant la configuration pour vos bundles locaux et l’intégration avec PHPStorm.
=== Structure finale recommandée ===
<pre>~/debian/projet/
├── app/                  # Projet Symfony principal
│  ├── src/
│  ├── vendor/
│  ├── public/
│  └── composer.json
├── Bundles/              # Bundles locaux
│  ├── bundlea/          # Bundle A
│  └── bundleb/          # Bundle B
├── docker/
│  ├── apache/
│  │  └── vhost.conf    # Config Apache
│  ├── php/
│  │  └── php.ini      # Config PHP
│  └── entrypoint.sh    # Script d'initialisation
├── .env                  # Variables d'environnement
├── Dockerfile            # Build PHP-FPM
└── docker-compose.yml    # Configuration Docker</pre>
=== 1. Fichier <code>.env</code> (nouveau) ===
<syntaxhighlight lang="ini"># PostgreSQL
POSTGRES_USER=symfony
POSTGRES_PASSWORD=ChangeMe
POSTGRES_DB=app
# Symfony
APP_ENV=dev
DATABASE_URL="postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}?serverVersion=15&charset=utf8"</syntaxhighlight>
=== 2. Dockerfile (optimisé) ===
<syntaxhighlight lang="dockerfile">FROM php:8.2-fpm
# Dependencies + Extensions PHP
RUN apt-get update && apt-get install -y \
    git \
    libpq-dev \
    libzip-dev \
    libevent-dev \
    && docker-php-ext-install pdo pdo_pgsql zip \
    && pecl install event \
    && docker-php-ext-enable event
# Script d'entrée
COPY docker/entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/entrypoint.sh
WORKDIR /var/www
ENTRYPOINT ["entrypoint.sh"]</syntaxhighlight>
=== 3. docker-compose.yml (complet) ===
<syntaxhighlight lang="yaml">version: '3.8'
services:
  php:
    build: .
    volumes:
      - ./app:/var/www
      - ./Bundles:/var/www/bundles
    env_file:
      - .env
    depends_on:
      - postgres
  apache:
    image: httpd:2.4
    ports:
      - "8080:80"
    volumes:
      - ./app/public:/var/www/html
      - ./docker/apache/vhost.conf:/usr/local/apache2/conf/extra/httpd-vhosts.conf
    depends_on:
      - php
  postgres:
    image: postgres:15
    env_file:
      - .env
    volumes:
      - postgres_data:/var/lib/postgresql/data
  composer:
    image: composer:2
    volumes:
      - ./app:/var/www
      - ./Bundles:/var/www/bundles
      - composer_cache:/tmp
    working_dir: /var/www
    environment:
      - COMPOSER_CACHE_DIR=/tmp
    entrypoint: ["composer"]
volumes:
  postgres_data:
  composer_cache:</syntaxhighlight>
=== 4. docker/apache/vhost.conf ===
<syntaxhighlight lang="apache"><VirtualHost *:80>
    DocumentRoot /var/www/html
    ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://php:9000/var/www/public/$1
   
    <Directory "/var/www/html">
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost></syntaxhighlight>
=== 5. docker/entrypoint.sh (optimisé) ===
<syntaxhighlight lang="bash">#!/bin/bash
set -e
# Attendre que PostgreSQL soit prêt
while ! nc -z postgres 5432; do
  sleep 1
done
# Lancer PHP-FPM
exec php-fpm</syntaxhighlight>
=== 6. Configuration Composer (app/composer.json) ===
<syntaxhighlight lang="json">{
  "repositories": [
    {
      "type": "path",
      "url": "../Bundles/bundlea",
      "options": {
        "symlink": true
      }
    },
    {
      "type": "path",
      "url": "../Bundles/bundleb",
      "options": {
        "symlink": true
      }
    }
  ]
}</syntaxhighlight>
=== 🔧 Workflow recommandé ===
<ol style="list-style-type: decimal;">
<li><p>'''Initialisation''' :</p>
<syntaxhighlight lang="bash">docker-compose build
docker-compose up -d</syntaxhighlight></li>
<li><p>'''Installer les dépendances''' (via le service Composer) :</p>
<syntaxhighlight lang="bash">docker-compose run --rm composer install</syntaxhighlight></li>
<li><p>'''Mettre à jour un bundle local''' :</p>
<syntaxhighlight lang="bash">docker-compose run --rm composer update vendor/bundlea</syntaxhighlight></li>
<li><p>'''Accéder aux logs''' :</p>
<syntaxhighlight lang="bash">docker-compose logs -f php</syntaxhighlight></li>
<li><p>'''Arrêter l’environnement''' :</p>
<syntaxhighlight lang="bash">docker-compose down</syntaxhighlight></li></ol>
=== 🛠 Intégration PHPStorm ===
# '''Configurer les mappings''' :
#* <code>/var/www</code> → <code>./app</code>
#* <code>/var/www/bundles</code> → <code>./Bundles</code>
# '''Interpréteur PHP''' :
#* Utiliser le PHP du container (Settings &gt; PHP)
# '''Server Configuration''' :
#* Nom : Docker Apache
#* Host : localhost
#* Port : 8080
#* Path mappings comme ci-dessus
=== ✅ Points clés de cette configuration ===
* '''Service Composer isolé''' avec cache persistant (<code>composer_cache</code>)
* '''Symlinks des bundles locaux''' fonctionnels grâce au volume partagé
* '''Environnement reproductible''' avec PostgreSQL intégré
* '''Optimisé pour PHPStorm''' avec les bons mappings de chemins
* '''Entrypoint minimaliste''' qui attend juste que la DB soit prête
Cette solution offre un équilibre parfait entre isolation des services et facilité de développement avec les bundles locaux.


[[Catégorie:Symfony]] [[Catégorie:Docker]]
[[Catégorie:Symfony]] [[Catégorie:Docker]]
Récupérée de "https://marmits.com/wiki/Symfony_Docker"