Pourquoi utiliser les builds multi-stage ?
Les builds multi-stage permettent de séparer l'environnement de compilation de l'environnement d'exécution. Résultat : des images plus légères et plus sécurisées.
Le problème des images monolithiques
Une image PHP classique avec toutes les dépendances de développement peut facilement dépasser 1 Go. En production, vous n'avez besoin ni de Composer, ni des outils de test, ni des fichiers source non compilés.
Exemple de Dockerfile multi-stage
# Stage 1 : Build
FROM composer:2 AS builder
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader
COPY . .
# Stage 2 : Production
FROM php:8.3-fpm-alpine
COPY --from=builder /app /var/www/html
RUN docker-php-ext-install pdo pdo_mysql opcache
EXPOSE 9000
CMD ["php-fpm"]Avantages concrets
- Taille réduite : passage de 800 Mo à moins de 150 Mo
- Sécurité : pas d'outils de développement en production
- Cache Docker : chaque stage est mis en cache indépendamment
- Reproductibilité : même résultat sur tous les environnements
Bonnes pratiques
Utilisez Alpine comme image de base pour minimiser la surface d'attaque. Installez uniquement les extensions PHP nécessaires. Configurez OPcache pour la production avec les paramètres optimaux.
RUN echo "opcache.memory_consumption=256" >> /usr/local/etc/php/conf.d/opcache.ini \
&& echo "opcache.max_accelerated_files=20000" >> /usr/local/etc/php/conf.d/opcache.ini \
&& echo "opcache.validate_timestamps=0" >> /usr/local/etc/php/conf.d/opcache.iniCette approche est utilisée avec succès sur des plateformes comme Keytchens pour déployer des applications Symfony avec des temps de build réduits de 60%.