Microservices + Docker architecture?

Question

Service Oriented Architecture

There are several microservices. All of them are now written in PHP. There is an environment that is assembled and deployed, it has a separate container with a web server and an interpreter, in fact these are 2 common containers for all microservices, and it turns out that when deploying a leg service, we copy the code to both containers, yes, the code does not rummage with machine host. Among the disadvantages of this approach:
1. Don’t forget to copy everywhere
2. It’s inconvenient to manage rights
3. There is no control over a specific service (for example, deploy a new version or restart the process inside)
4. Changes to one service affect everything inside

Plus: it’s easier to set up a balancer

Why such a question arose, there are a lot of services and some are transferred to a new version of the interpreter, while others do not support it and need custom modules, etc., it is clear that you can raise other nodes and deploy the desired version there, and so far it works, but optimization is needed

There is a 2nd option, but not yet implemented, this is a web server and an interpreter placed in one container, but this is not according to the "docker philosophy", but this approach has a number of advantages

Minus: it is more difficult to set up a balancer
Pros:
1. Fully encapsulated microservice
2. There is control over it (you can redeploy or reboot, stop, another version of puff, custom module, etc.)
3. Does not affect other services during maintenance

Now there is a repository with an env and there are a lot of configs, and when you need to add a new microservice or change it in the deployment, you need to climb into this turnip and first make edits there and run a rebuild or something else passing a specific list of services and shovel everything in the list, although, in fact, only one service is needed

. Now I plan to do this:
1. The turnip with the env will remain, but it will have a common set for building basic images with settings
2. Each service will have a docker folder in the turnip where everything you need to build and launching a specific service

Who will say what, prompt, think?

Answer 1

I don’t know if my experience will help you or not, but I did the following
1. service repo, contains a docker file and a gitlab build script, the service deployment performs the build steps and tagging the container with the required version adds it to the registry (respectively, there are n such services)
2. deployment repo, an ansible that delivers the compose file to the host machine, pulls containers and sets up versions (environments that are hooked in the compose file), I also manage the environments within the services themselves through this repository, the repository branches differ in settings and are responsible for rolling out to different stands.
What I like about this architecture is that the release is rolled out all at once, there is no situation when the first updated service left half an hour ago and everything lies until the last one arrives...
what I don't like is more gestures than usual, for a cluster deployment you need to think out this scheme.

Answer 2

It looks good, but the question is a bit off topic, the point is, as it were, what to do with php + nginx
Put them in one container, which is not feng shui, or separate them like now