Estoy buscando implementar una aplicación Symfony en Docker usando Docker-Compose. Tendré al menos los siguientes contenedores:
Actualmente también tenemos un entorno de desarrollo que utiliza la configuración anterior.
La aplicación Symfony se almacena localmente (host) y luego se usa un volumen en el contenedor PHP-FPM para que pueda leer la aplicación; esto funciona bien. bash el contenedor php-fpm para ejecutar los comandos composer/app/console.
También ejecutamos manualmente los consumidores (comandos de Symfony) que consumen mensajes del servidor rabbitmq.
¿Cuáles son mis opciones en producción?
1) ¿Puedo crear un solo contenedor que ejecute la aplicación y luego permitir que otros contenedores lo usen? Veo que el contenedor php-fpm necesita acceso al código de la aplicación, pero también me gustaría crear un contenedor para ejecutar un consumidor, pasando el nombre del servicio para ejecutar el contenedor, lo que significa que puedo tener una sola imagen que se puede iniciar de forma flexible para procesar mensajes de cualquier cola. ¿Qué sucede con los registros/caché en esta opción?
2) ¿Tiene la aplicación almacenada dentro de cada imagen que la necesita? esta es mi opción menos favorita ya que para actualizar la aplicación necesito construir cada imagen
3) ¿Algo que aún no he explorado?
Me gustaría permitir actualizaciones sencillas de la aplicación, quizás algo programado, pero también me gustaría minimizar el tiempo de inactividad. Puedo hacerlo usando haproxy o algo similar. ¿Alguien más ha tenido alguna experiencia con la ejecución de una aplicación Symfony de varios contenedores en producción?
Ejecuto un contenedor para cada servicio. Recuerde que uno de los principios de Docker es la "separación de intereses".
Sin embargo, es posible que tenga Nginx + PHP-FPM en el mismo contenedor.
Para iniciar todos los servicios (en un entorno de desarrollo o producción), puede usar docker-compose y la variable de entorno mágica "SYMFONY_ENV=dev" para iniciar todo. Sugiero lanzar los consumidores en un contenedor separado, pero posiblemente con diferentes rutas de proyecto/registro/caché. Tenga en cuenta que los consumidores, en producción, pueden afectar el rendimiento en línea si se ejecutan con CPU/memoria/disco compartidos.
Actualmente estoy investigando alternativas para implementar/postimplementar la aplicación web, la solución subóptima ahora es un script bash de punto de entrada simple (que se pasa a "docker run -d myimage php_entrypoint.sh" que:
Da como resultado algo como esto:
#$OPTIMIZE is an ENV-propagated or a calulated variable su -c "php composer.phar install $OPTIMIZE" webmgr cp -f web/HTACCESS_${SYMFONY_ENV} web/.htaccess /usr/bin/supervisord -c /etc/supervisord/supervisord.confLa razón por la que estoy usando supervisord es que tengo que copiar/montar las secciones [program:] que necesito ejecutar, manteniendo así una sola imagen de php que es buena tanto para php-fpm como para CLI/trabajo de consumidor. También puedo reiniciar el servidor de aplicaciones php sin eliminar el contenedor. Además, supervisord es bastante inteligente en la gestión de procesos "demonizados".
ACTUALIZADO
La aplicación web está montada como un volumen y docker-compose.yml está en el directorio raíz del proyecto, que contiene las configuraciones de imágenes de docker y el proyecto Symfony. Este es un extracto de docker-compose.yml
webapp_fpm: image: ... volumes: - ./symfony:/var/www/html - ./docker-conf/supervisord:/etc/supervisord - /var/log/appname/symfony:/var/log/symfony entrypoint: "/bin/bash php_entrypoint.sh"