Hello, I have a problem or misunderstanding with docker-compose and accessibility in the respective networks and hope you can explain the behavior to me because it doesn’t make sense to me at first.
I work locally on several projects, many projects are dependent on other projects. But my stack is pretty much identical. (php-fpm, nginx, MariaDb) For easy handling I use Traefik, which works very well and is stable!
Each project is in a network called “local”, which is only used for communication within a docker-compose file.
In addition, individual containers are located in the network “intern” and can be reached via Traefik. This also works as desired.
Now I’ve noticed that sometimes projects exhibit strange behavior. Until I noticed that the wrong php-fpm container was responding! The nginx from one project suddenly talks to the php-fpm container from another project. Totally random.
According to my understanding of Docker-Compose, this shouldn’t actually happen because the containers are unique! But it does!
This also happens with the database sometimes…
I then dug deeper and investigated the whole thing and found out that the container name is stored as a DNS alias in both networks!
Why is this done? I don’t understand it!
I can fix the behavior by setting a link from NGINX as an example. ( links: -php-fpm )
But that doesn’t explain to me why the container name appears as an alias in the external network!
Docker version 26.1.1
Windows 11
Docker Windows 4.30.0
That is just how user defined networks work. You can use the container names as domain names. In case of compose, you can also use the compose service name as domain name.
So the solution is that the php-fpm service should not be connected to the network of the reverse proxy. That way you can make sure that the nginx container will not see other services called “php” (or whatever name you chose). Only the nginx in front of PHP FPM should be connected to the reverse proxy network in addition to the local.
Thanks for the explanation, but I can’t really get my head around it.
What is the benefit of storing the service name as a DNS alias in an external network?
As soon as you have multiple applications, there can be overlaps that are not immediately apparent. Sometimes it works and sometimes it doesn’t. For example, it depends on the order in which the applications were started.
NGINX → PHP-FPM is just an example. I also had this behavior with a database. The wrong DB server was used again and again.
Unfortunately, I don’t have any implementations in front of me that aren’t so nice, where a project has to access the database of another project directly. I have to allow that, e.g. via a unique alias.
I just want to understand it. And I could imagine that a warning should also be issued if multiple projects want to store the same alias in the same network.
It works with all user defined networks. External just means that compose willl not create a new network but connects to an existing network. The benefit is exactly that you don’t need to know container IP addresses which can change every time you recreate the container. If you want two containers to communicate where one is outside the compose project, you also have to make sure containers that don’t have to see eachother don’t see eachother. When you create virtual machines or configure physical mahcines you also need to choose different hostnames. You can have the same hostname in separate networks, but in the same network, if your router detects the hostname and provides DNS resolution, you won’t know which machine you will access eventually.
The fact that compose adds compose service names as network alias can help when you run multiple replicas so nginx could load balance between the replicas.
