Selon la documentation officielle :
Il ne peut y avoir qu'un seul
CMDinstruction dans un Dockerfile . Si vous citez plus d'unCMDpuis seulement le dernierCMDprendra effet.
Et votre Dockerfile a deux commandes CMD donc la commande php-fpm remplacera
/usr/bin/supervisord
Pour que vous puissiez exécuter des commandes PHP mais que vous ne trouviez pas le socket du superviseur créé dans le conteneur.
Vous pouvez résoudre votre problème en supprimant le dernier CMD commande liée à PHP-FPM comme vous avez déjà configuré superviseur pour le démarrer et votre Dockerfile devrait avoir un CMD commande :
CMD ["/usr/bin/supervisord"]
L'idée ici est d'éliminer le superviseur et d'exécuter à la place tout ce que le superviseur avait l'habitude d'exécuter dans plusieurs conteneurs différents. Vous pouvez facilement orchestrer cela avec docker-compose , par exemple, exécutant tous le même conteneur avec différents CMD remplace, ou le même conteneur avec un CMD différent couche à la fin pour le diviser. Le problème ici est que le superviseur ne pourra pas communiquer l'état des processus qu'il gère à Docker. Il sera toujours "vivant" même si tous ses processus sont complètement détruits. Les exposer directement signifie que vous pouvez voir qu'ils se sont écrasés.
Le mieux est de répartir chacun de ces services dans des conteneurs distincts. Puisqu'il existe des pré-construits officiels pour MySQL et ainsi de suite, il n'y a vraiment aucune raison d'en créer un vous-même. Ce que vous voulez faire est de traduire ce supervisord config à docker-compose formater.
Avec des conteneurs séparés, vous pouvez faire des choses comme docker ps pour voir si vos services fonctionnent correctement, ils seront tous répertoriés individuellement. Si vous avez besoin d'en mettre à niveau un, vous pouvez le faire facilement, vous travaillez simplement avec ce conteneur, au lieu d'avoir à tout supprimer.
La façon dont vous l'attaquez ici traite Docker comme une machine virtuelle sophistiquée, ce qui n'est vraiment pas le cas. Il s'agit plutôt d'un gestionnaire de processus , où il se trouve que ces processus ont des images de disque prédéfinies et une couche de sécurité autour d'eux.
Composez votre environnement à partir de conteneurs à processus unique et votre vie sera beaucoup plus facile, tant du point de vue de la maintenance que de la surveillance.
Si vous pouvez exprimer cette configuration comme quelque chose docker-compose pouvez gérer, vous êtes sur le point de passer à une couche de gestion plus sophistiquée comme Kubernetes, ce qui pourrait être la conclusion logique de cette migration particulière.