CODEWITHSUNDEEP
dockerdocker-composecontainers
José Victor
José Victor

Reputation: 335

What is the difference between network_mode and networks using Docker

I was trying to use the network "bridge" to join services from different "docker-compose.yml" and I was getting the following error:

Network-scoped alias is supported only for containers in user defined networks

Searching a bit, I came to this reference link:: https://github.com/docker/compose/issues/3012

I read and re-read everything several times, but I couldn't understand the real reason for using one or the other.

Can someone explain to me what the difference is in practice?

Why when you use network_mode and run docker network inspect bridge all containers correctly linked appear?

Before:

services:
  local-db:
    image: mysql

networks:
  default:
    external:
      name: bridge

After:

local-db:
  image: mysql
  network_mode: bridge

Upvotes: 7

Views: 10995

Answers (1)

BMitch
BMitch

Reputation: 263666

The top level networks section creates networks in compose (or specifies external user created networks) that can be used by various services. Each service then defines a networks section to identify one or more user created networks to join. That service gets automatically configured with a network alias for DNS based service discovery. This is the preferred method to setup networking with services, and by default each of these networks is a bridge network.

To skip that entire process, you can use a network_mode that changes from the compose managed networking to switch to host, bridge, none, service:$name, or container:$name. Each of these has unique properties.

  • host has no network namespacing at all, similar to starting a process outside of a container.
  • bridge is the legacy bridge network docker always creates, but disables some features like DNS based service discovery.
  • none is no networking at all, only the loopback interface is defined.
  • service:$name and container:$name are special ways of connecting multiple containers into the same network namespace. The same thing is done by pods in kubernetes, and it can be useful for network troubleshooting or when creating sidecars that require access to localhost. This should only be used as a last resort when building microservices since it breaks the ability to independently scale and deploy the containers.

Upvotes: 5

Related Questions