Starting with Docker 1.12, Docker has added features to the core Docker Engine to make multi-host and multi-container orchestration simple to use and accessible to everyone. Docker 1.12 Networking plays a key role in enabling these orchestration features.
In this online meetup, we learned all the new and exciting networking features introduced in Docker 1.12:
- Swarm-mode networking
- Routing Mesh
- Ingress and Internal Load-Balancing
- Service Discovery
- Encrypted Network Control-Plane and Data-Plane
- Multi-host networking without external KV-Store
- MACVLAN Driver
The number of questions Madhu got at the end of the online meetup was amazing and because he did not have time to answer all of them, we’ve added the rest of the Q&A below:
Q: Will you address the DNS configuration in Docker? We have two apps created with docker compose and would like to enable communication and DNS resolution from containers in one of the apps to containers in the other app.
Q: What mechanism is used to register the different docker instances with each other so that they recognize a shared network between hosts, please?
Docker swarm-mode uses Raft and GRPC to communicate between docker instances. That’s how the nodes in the cluster exchange data and recognize shared network. At the data-plane, overlay driver uses VXLAN tunnels to provide per-network multi-host connectivity and isolation.
Q: Does it work with NSX?
This question is related to network plugins and the community has developed OVS & OVN plugins. We are not sure if NSX integration is feasible through that. Typically vendor plugin are created and maintained by the vendor directly.
Q: Is there a way to see all records registered in Docker internal DNS? Is it exposed via API so it can be queried?
The Internal DNS is not exposed but network inspect and service inspect APIs can be used to gather this information.
Q: Has swarm mode created dependency of docker-engine on iptables?
Docker Engines has been using iptables since 1.0 for the bridge driver. Swarm mode merely makes use of iptables to provide functionality like the routing mesh.
Q: Can I have only 2 nodes in swarm and both are managers and node themselves as well?
Docker recommends an odd number of manager nodes as the Raft consensus requires majority consensus and to take full advantage of the fault tolerance features of swarm mode. Please read through https://docs.docker.com/engine/swarm/raft/ for more information.
Q: Wil making ports into a cluster wide resources limit the number of total services whereas using public VIPs is expandable?
Yes. Docker does not control public VIP so it needs to be managed external to the docker cluster. However, only front-end services require port-publishing & only those services that requires port-publishing will be participating in the Routing Mesh. Back-end services do not reserve cluster-wide ports.
Q: Can I plumb more than one IP per container while only using one network?
At the moment, libnetwork supports one routable IP per endpoint (per network). But users can configure many more link-local ip-addresses to the same endpoint. If you are interested in discussing this capability further, please open an enhancement request in docker/docker.
Q: Can you insert records into DNS to cause static IPs to be used?
Docker doesn’t expose embedded DNS APIs externally. Users can provide external DNS using the
--dns option and one can insert custom name-lookup entries in the external DNS server which will be used by the containers.
Q: Can you talk more about automatic key rotation for secure networks? How often does it occur and is the interval configurable? What process(es) are responsible for key rotation? How are the keys circulated throughout the cluster?
Please read the Overlay Security Model on the Docker Docs. Currently this is not configurable, but we are working on the configurability of this and other swarm mode features. Key-rotation is entirely handled by manager node process (swarmkit) and is distributed in the secured grpc channel established between the manager and workers.
Q: Regarding front end ports, is there a limitation on the number of port 80’s you can listen on?
Yes. The best way to mitigate that is to run a global nginx or haproxy or other reverse-proxy service and back the backend services by the host-header.
Want to learn more about Docker 1.12 and networking? Check out these resources:
- Docker 1.12 Networking Model Overview by Docker Captain Ajeet Singh Raina
- Docker Docs: Understand Docker container network
- Docker 1.12 Release Notes
- Docker Blog: Docker 1.12: Now With Built-In Orchestration!
- Scale a real microservice with Docker 1.12 Swarm Mode by Docker Captain Alex Ellis
- Docker 1.12 orchestration built-in by Docker Captain Gianluca Arbezzano