Docker Community Forums

Share and learn in the Docker community.

Shared network namespaces using --net=container:


(Lee Calcote) #1

Docker networking question… regarding --net=container:<some_container> - what are the use cases for one container sharing the network namespace of another container? (sharing the same IP and MAC). Why would someone choose to use this container-mode networking vs creating a new bridge (or other)?


(Jonostilla) #2

It depends if you mean exposed IP or not. Kubernetes pods have had this idea since the beginning. They believe that some applications belong together completely, and are separated by containers for pragmatic reasons. For a better explanation see the link above under section Alternatives considered.

E.g.

you have a log rotation tool, and a web app server, both containers. The log rotation tool is build for one app to tag logs and send them elsewhere on the net. The app and log rotation tool have no logical boundary between them. When you scale one you scale them both. When one (at least the main one) dies, the other should be shut down. SkyDNS is an example. It’s for ip addressing with containers.

When you have n web app containers, you no longer have to deal with n log rotation tools each with independant ip addresses, clogging up your namespace. The reality is there are often more than one ‘helper’ service for many apps. This is an ideal time for this sort of behaviour. :slight_smile:

Could anyone correct me on any part of that? I’m open to feedback :smiley:


(Lee Calcote) #3

Jonostilla, I completely agree with your example, moreover, with the power of the pod concept.

My specific inquiry aims to identify when the --net:container:some_container mode of Docker networking is useful. Here’s a quote from the docker documentation - https://docs.docker.com/v1.8/articles/networking/:

–net=container:NAME_or_ID — Tells Docker to put this container’s processes inside of the network stack that has already been created inside of another container. The new container’s processes will be confined to their own filesystem and process list and resource limits, but will share the same IP address and port numbers as the first container, and processes on the two containers will be able to connect to each other over the loopback interface.