How to configure supervisor in docker correctly

According to official documentation:

There can only be one CMD instruction in a Dockerfile. If you list more than one CMD then only the last CMD will take effect.

And your Dockerfile has two CMD commands so the command php-fpm will override

/usr/bin/supervisord

So that you can execute PHP commands but can't find supervisor's socket created in the container.

You can fix your issue by deleting the last CMD command related to PHP-FPM as you already configured supervisor to start it and your Dockerfile should have one CMD command:

CMD ["/usr/bin/supervisord"]

The idea here is to eliminate the supervisor and instead run whatever the supervisor used to run in several different containers. You can easily orchestrate this with docker-compose, for example, all running the same container with different CMD overrides, or the same container with a different CMD layer at the end to split it out. The trouble here is the supervisor won't be able to communicate the status of the processes it manages to Docker. It will always be "alive" even if all of its processes are completely trashed. Exposing those directly means you get to see they crashed.

What's best is to break out each of these services into separate containers. Since there's official pre-built ones for MySQL and so on there's really no reason to build one yourself. What you want to do is translate that supervisord config to docker-compose format.

With separate containers you can do things like docker ps to see if your services are running correctly, they'll all be listed individually. If you need to upgrade one then you can do that easily, you just work with that one container, instead of having to pull down the whole thing.

The way you're attacking it here is treating Docker like a fancy VM, which it really isn't. What it is instead is a process manager, where these processes just so happen to have pre-built disk images and a security layer around them.

Compose your environment out of single-process containers and your life will be way easier both from a maintenance perspective, and a monitoring one.

If you can express this configuration as something docker-compose can deal with then you're one step closer to moving to a more sophisticated management layer like Kubernetes which might be the logical conclusion of this particular migration.