Hi @doejohn
I'm the author of that GitHub repo, so I thought I'd help you out and answer your questions here, in the order you asked them:
-
You are correct, only one image will be built since both of those services use the same image (php.dockerfile). This container image will be used to spin up two separate containers when you run docker compose up.
-
You are correct again, both containers will contain the composer library. So, why have a separate instance for composer? The reason is separation of concerns. The PHP container is designed to spin up and stay running, running the php-fpm process in the background. However, the composer container is designed to be spun up and only run briefly to run composer commands (e.g. installing packages). This goes with the Docker way of thinking, which is that only one service should be performing an action at the same time. We could have the PHP container running composer commands by using
docker compose exec php composer require ...but it makes more sense to separate it out as its own service. -
Correct, on spin-up without a command the container will just end with no real output. This is because this particular service is meant to be used with docker compose run. Example:
docker compose run composer update. The entrypoint provides the docker container additional arguments after the container name. So in this case, theupdatewe used in that command gets tacked on aftercomposer --ignore-platform-reqs. -
The WORKDIR line sets the current working directory to where our code lies, so when composer commands are ran, they take place at the project root. The dialout group is removed because of some MacOS issue I ran into in the past (that I don't remember), and the laravel user is added in because the main PHP config file uses it instead of the default
wwwuser due to some weird permissions issues.
I hope these are all succinct answers and if you have any more questions, I'd be happy to help out further!
