What is overlay network and how does DNS resolution work?

I cannot connect to external mongodb server from my docker swarm cluster.

As I understand this is because of cluster uses overlay network driver. Am I right?

  • Run `rails db:setup` in Docker with schema in structure.sql
  • Can't connect to docker published port for tftp
  • Docker download Google's TensorFlow issue
  • What is the proper command to restart a Dokku app from SSH?
  • how to link docker container to each other with docker-compose
  • Why “https://get.docker.com/ubuntu” is a apt repository?
  • If not, how does docker overlay driver works and how can I connect to external mongodb server from cluster?

  • Is there Jenkins or other open-source CI for a distributed system?
  • App running in Docker on EB refuses connecting to self
  • Dockerized .net core app doesn't load on Azure
  • How can I specify an Alternate Exposed Port for Redis / RethinkDB (using Docker Compose)?
  • kubernetes : Containers not starting using private registry
  • Union mounts into Docker containers
  • One Solution collect form web for “What is overlay network and how does DNS resolution work?”

    Q. How does docker overlay driver works?

    I would recommend this good reference for understanding docker swarm network overlay, and more globally, how docker is architectured.

    This states that:

    Docker uses embedded DNS to provide service discovery for containers running on a single Docker Engine and tasks running in a Docker Swarm. Docker Engine has an internal DNS server that provides name resolution to all of the containers on the host in user-defined bridge, overlay, and MACVLAN networks.

    Each Docker container ( or task in Swarm mode) has a DNS resolver that forwards DNS queries to Docker Engine, which acts as a DNS server.

    So, in multi-host docker swarm mode, with this exemple setup :

    architecture

    In this example there is a service of two containers called myservice. A second service (client) exists on the same network. The client executes two curl operations for docker.com and myservice.

    These are the resulting actions:

    • DNS queries are initiated by client for docker.com and myservice.
    • The container’s built-in resolver intercepts the DNS queries on 127.0.0.11:53 and sends them to Docker Engine’s DNS server.
    • myservice resolves to the Virtual IP (VIP) of that service which is internally load balanced to the individual task IP addresses. Container names resolve as well, albeit directly to their IP addresses.
    • docker.com does not exist as a service name in the mynet network and so the request is forwarded to the configured default DNS server.

    Back to your question:

    How can I connect to external mongodb server form cluster?

    For your external mongodb (let’s say you have a DNS for that mongodb.mydomain.com), you are in the same situation as the client in above architecture, wanting to connect to docker.com, except that you certainly don’t wan’t to expose that mongodb.mydomain.com to the entire web, so you may have declared it in your internal cluster DNS server.

    Then, how to tell docker engine to use this internal DNS server to resolve mongodb.mydomain.com?

    You have to indicate in your docker service task that you want to use an internal DNS server, like so:

    docker service create \
    --name myservice \
    --network my-overlay-network \
    --dns=10.0.0.2 \
    myservice:latest
    

    The important thing here is --dns=10.0.0.2. This will tell docker engine to use DNS server at 10.0.0.2:53 as default if it can not resolve the DNS name in the VIP.

    Finally, when you say :

    I cannot connect to external mongodb server from my docker swarm cluster. As I understand this is because of cluster uses overlay network driver. Am I right?

    I would say no, as there is a built in method in docker engine to forward unknown DNS name coming from overlay network to the DNS server you want.

    Hope this helps!

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.