Después de mucho trabajar ya dimos con la contestación de esta dificultad que muchos los usuarios de nuestro sitio web han presentado. Si deseas aportar alguna información puedes dejar tu comentario.
Solución:
Según la documentación oficial:
Solo puede haber uno
CMDinstrucción en un Dockerfile. Si enumeras más de unoCMDentonces solo el ultimoCMDentrará en vigor.
Y su Dockerfile tiene dos comandos CMD, por lo que el comando php-fpm anulará
/usr/bin/supervisord
Para que pueda ejecutar comandos PHP pero no puede encontrar el socket del supervisor creado en el contenedor.
Puede solucionar su problema eliminando el último CMD comando relacionado con PHP-FPM como ya lo configuraste supervisor para iniciarlo y su Dockerfile debería tener uno CMD dominio:
CMD ["/usr/bin/supervisord"]
La idea aquí es eliminar al supervisor y, en su lugar, ejecutar lo que el supervisor solía ejecutar en varios contenedores diferentes. Puede orquestar esto fácilmente con docker-composepor ejemplo, todos ejecutando el mismo contenedor con diferentes CMD overrides, o el mismo contenedor con un diferente CMD capa al final para dividirlo. El problema aquí es que el supervisor no podrá comunicar el estado de los procesos que administra a Docker. Siempre estará “vivo”, incluso si todos sus procesos están completamente destrozados. Exponerlos directamente significa que puedes ver que se estrellaron.
Lo mejor es dividir cada uno de estos servicios en contenedores separados. Dado que hay oficiales preconstruidos para MySQL, etc., realmente no hay razón para construir uno usted mismo. Lo que quieres hacer es traducir eso. supervisord configurar para docker-compose formato.
Con contenedores separados puede hacer cosas como docker ps para ver si sus servicios se ejecutan correctamente, todos se enumerarán individualmente. Si necesita actualizar uno, puede hacerlo fácilmente, solo trabaja con ese contenedor, en lugar de tener que desmontarlo todo.
La forma en que lo está atacando aquí es tratar a Docker como una máquina virtual elegante, que en realidad no lo es. Lo que es en cambio es un gestor de procesosdonde estos procesos tienen imágenes de disco preconstruidas y una capa de seguridad a su alrededor.
Componga su entorno a partir de contenedores de un solo proceso y su vida será mucho más fácil tanto desde una perspectiva de mantenimiento como de supervisión.
Si puede expresar esta configuración como algo docker-compose puede manejar, entonces está un paso más cerca de pasar a una capa de administración más sofisticada como Kubernetes, que podría ser la conclusión lógica de esta migración en particular.
Si piensas que te ha resultado de provecho este artículo, te agradeceríamos que lo compartas con más juniors así contrubuyes a difundir esta información.