Swarm and DNS configuration

Hello everyone!

I have a specific use-case to resolve using Swarm and I am curious about your opinion about it. I’m trying to use Swarm to create a “dynamic environment” for my app. What that means that for each Pull Request on Github I’d like to build seperate stack of containers specifically for that git rev-id.

I have everything in place - deploy scripts, docker-compose version 3.2 for docker stack deploy etc

I am using same docker-compose file which has ENV variables attached to the image name, so I just do REVISION=something docker stack deploy and it deploys stack with proper image

What the problem is that all the services inside docker-compose are connected to external overlay network…

(why external overlay? Well… before deploying the stack I want to execute a one-off command, so I’m using a docker-compose command - when non-external network was in the configuration then docker-compose was creating a “local” network and then docker stack was creating an “overlay” network with same name, causing Docker to throw errors)

… and if I deploy multiple different stacks using same docker-compose file I am having multiple references to specific service using its host name (for example dig web@127.0.0.11 gives me multiple IP addresses, because there are multiple “web” services across multiple stacks)

This is not good because one of the services is the database, so for example, having stacks: app1, app2 and app3, from container “app1.web” trying to resolve “database” hostname it gives me multiple ips (because “database” also exists on stack app2 and app3)

What I would like to know is how Swarm internally “configures” DNS names and also do you have any idea on how this can be fixed?

What I have discovered so far I can reference the service by stackname_servicename, for example: app1_database and also specific container name (app1_database.1.k0dcj65250ec6s37kgenmwozs), but I can’t find any more references. Any help will be appreciated

Thanks!

Hi, we’ve just hit exactly the same problem on exactly the same use case!

Did you ever find a solution? We’re thinking of just passing stackname_servicename as the DB hostname environment variable to our backend service as a workaround.