Dynamic Discovery Docker Compose - docker

Question

I am using docker compose to bring up and dynamically scale a database.The containers all live within the same network, and there are a few different images that run, some which can scale and some which cant. Is there a way from within the other dockers to "see" all containers of type "x" on a certain network, so that I can load balance/etc effectively between them?

Answer 1

If you happen to know their names, you can use the docker DNS resolver to discover them. This is actually likely to be the thing you want to do with a load balancer anyway. Think of Nginx upstream directive, or HAProxy backends.
services:
app:
image: nginx
deploy:
replicas: 2
networks:
default:
name: sample
If you deploy this, you can query the docker DNS resolver from the same network to ask for the IP addresses of the individual app containers.
$ docker compose up -d
$ docker run --network sample --rm tutum/dnsutils dig +short app
172.22.0.3
172.22.0.2
You can actually tell load balancers like nginx or HAProxy to use the docker resolver for service discovery.
This doesn't tell you what capabilities the app containers have, but I think it also doesn't really matter. Unless I misunderstand your question and there is more to it.
Compose already adds these replicas under the same alias to the network. That's also why I could just query for app although the container names are actually project_app_1 and project_app_2.
$ docker run --network sample --rm tutum/dnsutils dig +short sample_app_1
172.22.0.3
So, you are essentially getting DNS round-robin as the built-in solution offered by compose.
You can even take this a step further, if you want to load balancer across separate services as one entity. Say type x or type y.
services:
app:
image: nginx
deploy:
replicas: 2
networks:
default:
aliases:
- nginx
other:
image: nginx
deploy:
replicas: 2
networks:
default:
aliases:
- nginx
networks:
default:
name: sample
docker run --network sample --rm tutum/dnsutils dig +short nginx
172.22.0.2
172.22.0.4
172.22.0.5
172.22.0.3
You could pair this as described above with a loadbalancer. I.E. haproxy.
For example, you could have a config file like this.
resolvers docker
nameserver dns1 127.0.0.11:53
resolve_retries 3
timeout resolve 1s
timeout retry 1s
hold other 10s
hold refused 10s
hold nx 10s
hold timeout 10s
hold valid 10s
hold obsolete 10s
global
log fd#2 local2
stats timeout 2m
spread-checks 15
defaults
log global
mode http
option httplog
timeout connect 5s
timeout check 5s
timeout client 2m
timeout server 2m
listen stats
bind *:4450
stats enable
stats uri /
stats refresh 15s
stats show-legends
stats show-node
frontend default
bind *:8080
default_backend nginx
backend nginx
balance leastconn
option httpchk GET /
server-template nginx- 10 nginx:80 resolvers docker init-addr libc,none check inter 30s
If you bake this into a HAProxy image or mount the file for simplicity, you get proper load balancer instead of DNS round-robin. You can have different load balancing algorithms and session affinity / persistence.
services:
app:
&nginx
image: nginx
deploy:
replicas: 2
networks:
default:
aliases:
- nginx
other: *nginx
lb:
image: haproxy:2.5-alpine3.15
ports:
- 8000:8080
- 4450:4450
volumes:
- ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg
Now we can see on the stats' page on port 4450 the 4 instances with nginx alias.
You can also check out this answer, which contains related information and shows some other strategies next to HAProxy. How does service discovery work with modern docker/docker-compose?.
This answer showcases aliases with the docker CLI, so you may understand what compose is doing there. how are compose services implemented?
In Kubernetes, you would pretty much get the same things to work with. Kubernetes has also its own DNS resolver and service abstractions to get VIP or DNS round-robin behaviour. The rest has to come from an external implementation, such as an ingress controller.