Which approach is correct in docker-compose description?

Question

Docker

Knowledge in containerization is close to zero. Docker docks are 30% explored and understood.
I read various, like experienced commentators on habré, and questions arose that, as they say, lead to a bunch of problems in the future: 1.

It is advised not to explicitly set networks, they say that docker itself does this for all services
one node = one application instance and layering cannot be
3. In a Laravel container. It is advised to mount only storage, store all other code inside the container
4. Relative paths in volumes are evil

I ask knowledgeable people to comment on these "facts" and, if possible, explain whether commentators are mistaken or 99% of articles on this topic?

Answer 1

1. It is always better to do it explicitly than implicitly. This will make it easier for others and for yourself when six months have passed.
2. It is at least convenient. The container is always named the same, instead of stupid automatic names. Again, half a year will pass, you yourself read the compose config and see the container, don’t understand the name, you will have to guess that the name has not been assigned. Why complicate?
3. According to the situation, there is no correct answer
4. Relative paths are true. But absolute evil. With relative paths, you just need to transfer the directory to the new server and everything will start. Absolute will have to be corrected, and this is a complication.

Answer 2

1. According to the situation. Sometimes this is more than justified. I would not raise it to absolute
2. Again - according to the situation. Sometimes required.
3. Question with updating this very code. If it lies on volume, then updating is not a problem (including from inside the container). If it is in a container, then you will need to rebuild the container.
4. I did not understand this question.

Answer 3

1. Very much depends on the task. Of course, if you don’t understand exactly why you need it, then it makes sense to entrust the network setup to docker. But if it is necessary that instead of bridge there is a macvlan with a strictly defined network and a specific parent interface, then the docker itself will not provide us with this, unless it is prompted.
2. The problem here is that the names are long. But if you clearly know your infrastructure and run predictable containers within a given host - why not? After all, container naming can also be part of an infrastructure decision. The main thing is not to launch two projects with intersecting names - it will turn out oh and oh with the re-creation of the live container.
3. This is an attempt to fight against a rather typical approach of docker beginners who manage with a "universal" container that executes any php code from an external directory. Of course, for quick experiments “I’ll just pile it up and run it for testing” this is not even a very bad solution, but with the widespread use of this approach, the meaning of docker essentially disappears: instead of an application ready for deployment, we have a container that can’t do anything and that has to do it on its own sawing a separate delivery system for the code itself. Instead, it’s better to immediately learn and debug how to prepare a full-fledged image. In the end, you can make all applications descendants of this super-image with php, which will make their assembly quite fast.
4. Relative paths - this is just very convenient for many tasks. We have a directory with a project, in which docker-compose.yml and all the necessary data. The placement of the data is predictable, you can see exactly who is using it, what size it is, and all that. It is convenient in case of something to transfer between servers along with the data: just extinguished, rsync, launched. On the contrary, storing data in anonymous volumes in /var/lib/docker with obscure names is often an anti-pattern whereby valuable space in /var is filled with something obscure that is not really identifiable. And the use of names can lead to the same problem as container_name - in different compose projects, the names will intersect, and you will know this only when it already breaks.