Comparing Mindshare

Let us take a quick look at how each of these alternatives differs from Docker:

• Docker Repository Security and Certificates — Docker runs via a non-networked Unix socket and TLS must be enabled in order to have the Docker client and the daemon communicate securely over HTTPS. This page gathers resources about how to ensure the traffic between the Docker registry and the Docker daemon is encrypted and a properly authenticated using certificate-based client-server authentication.
• Docker Trusted Image Registry — Docker Trusted Registry (DTR) is the enterprise-grade image storage solution from Docker. It is installed behind a firewall so that Docker images can be securely stored and managed. This page gathers resources about the benefits of Docker trusted registry and how to work with it.
• Docker AppArmor Security Profiles — AppArmor (Application Armor) is a Linux security module that protects an operating system and its applications from security threats. To use it, a system administrator associates an AppArmor security profile with each program. Docker expects to find an AppArmor policy loaded and enforced. This page gathers resources about Docker AppArmor security profiles and how to use them to enhance container security.
• Isolating Docker Containers — Docker container technology increases the default security by creating isolation layers between applications and between the application and host and reducing the host surface area which protects both the host and the co-located containers by restricting access to the host.
• Docker CIS Benchmark — The Center for Internet Security (CIS) Docker Benchmark is a reference document that can be used by system administrators, security and audit professionals and other IT roles to establish a secure configuration baseline for Docker containers. This page gather resources about CIS Docker benchmark and how to implement it.

Read more on this wiki: Docker Security Resources

What is Docker Swarm

Docker swarm mode allows you to manage a cluster of Docker Engines, natively within the Docker platform. You can use the Docker CLI to create a swarm, deploy application services to a swarm, and manage swarm behavior.

Docker will shortly support Kubernetes Guide as well as Docker Swarm, and Docker users will be able to use either Kubernetes or Swarm to orchestrate their container workloads.

Swarm can help developers and IT administrators:

• Coordinate between containers and allocate tasks to groups of containers
• Perform health checks and manage lifecycle of individual containers
• Provide redundancy and failover in case nodes experience failure
• Scale the number of containers up and down depending on load
• Perform rolling updates of software across multiple containers

Docker Swarm Concepts

• Swarmkit – a separate project which implements Docker’s orchestration layer and is used directly within Docker to implement Docker swarm mode.
• Swarm – a swarm consists of multiple Docker hosts which run in swarm mode and act as managers and workers.
• Task – the swarm manager distributes a specific number of tasks among the nodes, based on the service scale you specify. A task carries a Docker container and the commands to run inside the container. Once a task is assigned to a node, it cannot move to another node. It can only run on the assigned node or fail.
• Service – a service is the definition of the tasks to execute on the manager or worker nodes. When you create a service, you specify which container image to use and which commands to execute inside running containers. A key difference between services and standalone containers is that you can modify a service’s configuration, including the networks and volumes it is connected to, without manually restarting the service.
• Nodes – a swarm node is an individual Docker Engine participating in the swarm. You can run one or more nodes on a single physical computer or cloud server, but production swarm deployments typically include Docker nodes distributed across multiple machines.
• Manager nodes – dispatches units of work called tasks to worker nodes. Manager nodes also perform orchestration and cluster management functions.
• Leader node – manager nodes elect a single leader to conduct orchestration tasks, using the Raft consensus algorithm.
• Worker nodes – receive and execute tasks dispatched from manager nodes. By default manager nodes also run services as worker nodes. An agent runs on each worker node and reports on the tasks assigned to it to its manager node.
• Load balancing – the swarm manager uses ingress load balancing to expose the services running on the Docker swarm, enabling external access. The swarm manager assigns a configurable PublishedPort for the service. External components, such as cloud load balancers, can access the service on the PublishedPort of any node in the cluster, whether or not the node is currently running the task for the service. All nodes in the swarm route ingress connections to a running task instance. The swarm manager uses internal load balancing to distribute requests among services within the cluster based upon the DNS name of the service.

Running Docker Swarm

The Docker engine runs with swarm mode disabled by default. To run Docker container in swarm mode, you can either create a new swarm or have the container join an existing swarm.

To create a swarm, run the docker swarm init command, which creates a single-node swarm on the current Docker engine. The current node becomes the manager node for the newly created swarm.

The output for the docker swarm init command tells you which command you need to run on other Docker containers to allow them to join your swarm as worker nodes.

Other nodes can access the SwarmKit API using the manager node’s advertised IP address. SwarmKit is a toolkit for orchestrating distributed systems, including node discovery, task scheduling, and more.

Each node requires a secret token to join a swarm. The token for worker nodes is different from the token for manager nodes, and the token is only used at the time a container joins the swarm.

Manager tokens should be strongly protected, because any access to the manager token grants control over an entire swarm.

For more details, see the Swarm documentation: Run Docker in Swarm mode

Common Docker Swarm Operations

In this section you will learn:

• How to create a swarm
• How to add and manage nodes in a swarm
• How to deploy services to a swarm
• Swarm admin commands

Creating and Joining a Swarm

The Docker engine runs with swarm mode disabled by default. To run Docker in swarm mode, you can either create a new swarm or have the container join an existing swarm.

To create a swarm – run the docker swarm init command, which creates a single-node swarm on the current Docker engine. The current node becomes the manager node for the newly created swarm.

To join a swarm – the output for the docker swarm init command tells you which command you need to run on other Docker containers to allow them to join your swarm as worker nodes, including a “join token”. For example, to add a worker to this swarm, run the following command:

docker swarm join \
--token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \
192.168.99.100:2377

There is a different join token for worker nodes and manager nodes. The token is only used at the time a container joins the swarm. Manager tokens should be strongly protected, because any access to the manager token grants control over an entire swarm.

You can run swarm join-token --rotate at any time to invalidate the older token and generate a new one, for security purposes.

Accessing management functionality – swarm nodes can access the SwarmKit API (providing operations like node discovery and task scheduling) and overlay networking, using an “advertise address” you specify for the manager node. If you don’t specify an address, and there is a single IP for the system, Docker listens by default on port 2377. SwarmKit is a toolkit for orchestrating distributed systems, including node discovery and task scheduling.

For more details, see the Swarm documentation: Create a Swarm

Manage Nodes in a Swarm

To get visibility into the nodes on your swarm, list them using the docker node ls command on a manager node.

The listed nodes display an availability status that identifies whether the scheduler can assign tasks to the node.

• A manager status value identifies whether the node participates in swarm management.
• A blank value indicates that the node is a worker node. 
• A Leader value identifies the primary manager node that makes all swarm management and orchestration decisions for the swarm. 
• A Reachable value identifies nodes that are manager nodes and are candidates to become leader nodes in the event that a leader node is unavailable.
• An Unavailable value signifies a manager node that cannot communicate with other managers. Such nodes should be replaced by promoting worker nodes or adding a new manager node.

For more details, see the Swarm Documentation: Manage Nodes in a Swarm Read more on this wiki: Docker Swarm 101

What is Docker Networking

For Docker containers to communicate with each other and the outside world via the host machine, there has to be a layer of networking involved. Docker supports different types of networks, each fit for certain use cases.

For example, building an application which runs on a single Docker container will have a different network setup as compared to a web application with a cluster with database, application and load balancers which span multiple containers that need to communicate with each other. Additionally, clients from the outside world will need to access the web application container.

See Docker Documentation: Network containers

Docker Default Networking (docker0)

When Docker is installed, a default bridge network named  docker0 is created. Each new Docker container is automatically attached to this network, unless a custom network is specified.

Besides docker0 , two other networks get created automatically by Docker: host (no isolation between host and containers on this network, to the outside world they are on the same network) and none (attached containers run on container-specific network stack).

See Docker Documentation: Default networks

Network Types

Docker comes with network drivers geared towards different use cases. The most common network types being: bridge , overlay , and macvlan .

Bridge Networks

Bridge networking is the most common network type. It is limited to containers within a single host running the Docker engine. Bridge networks are easy to create, manage and troubleshoot.

For the containers on bridge network to communicate or be reachable from the outside world, port mapping needs to be configured. As an example, consider you can have a Docker container running a web service on port  80. Because this container is attached to the bridge network on a private subnet, a port on the host system like 8000 needs to be mapped to port  80 on the container for outside traffic to reach the web service.

To create a bridge network named my-bridge-net , pass the argument bridge to the -d (driver) parameter as shown below:

$ docker network create -d bridge my-bridge-net

See Docker Documentation: Bridge networks

Overlay Networks

An overlay network uses software virtualization to create additional layers of network abstraction running on top of a physical network. In Docker, an overlay network driver is used for multi-host network communication. This driver utilizes Virtual Extensible LAN (VXLAN) technology which provide portability between cloud, on-premise and virtual environments. VXLAN solves common portability limitations by extending layer 2 subnets across layer 3 network boundaries, hence containers can run on foreign IP subnets.

To create an overlay network named my-overlay-net, you’ll also need the --subnet parameter to specify the network block that Docker will use to assign IP addresses to the containers:

$ docker network create -d overlay --subnet=192.168.10.0/24 my-overlay-net

See Docker Documentation: An overlay network without swarm mode

Macvlan Networks

The macvlan driver is used to connect Docker containers directly to the host network interfaces through layer 2 segmentation. No use of port mapping or network address translation (NAT) is needed and containers can be assigned a public IP address which is accessible from the outside world. Latency in macvlan networks is low since packets are routed directly from Docker host network interface controller (NIC) to the containers.

Note that macvlan has to be configured per host, and has support for physical NIC, sub-interface, network bonded interfaces and even teamed interfaces. Traffic is explicitly filtered by the host kernel modules for isolation and security. To create a macvlan network named macvlan-net, you’ll need to provide a --gateway parameter to specify the IP address of the gateway for the subnet, and a -o parameter to set driver specific options. In this example, the parent interface is set to eth0 interface on the host:

$ docker network create -d macvlan \
  --subnet=192.168.40.0/24 \
  --gateway=192.168.40.1 \
  -o parent=eth0 my-macvlan-net

See Docker Documentation: Get started with Macvlan network driver

How Containers Communicate with Each Other

Different networks provide different communication patterns (for example by IP address only, or by container name) between containers depending on network type and whether it’s a Docker default or a user-defined network.

Container discovery on docker0 network (DNS resolution)

Docker will assign a name and hostname to each container created on the default docker0 network, unless a different name/hostname is specified by the user. Docker then keeps a mapping of each name/hostname against the container’s IP address. This mapping allows pinging each container by name as opposed to IP address.

Furthermore, consider the following example which starts a Docker container with a custom name, hostname and DNS server:

$ docker run --name test-container -it \
--hostname=test-con.example.com \
--dns=8.8.8.8 \
ubuntu /bin/bash

In this example, processes running inside test-container, when confronted with a hostname not in /etc/hosts, will connect to address 8.8.8.8 on port 53 expecting a DNS service.

See Docker Documentation: Embedded DNS server in user-defined networks

Directly linking containers

It is possible to directly link one container to another using the --link option when starting a container. This allow containers to discover each other and securely transfer information about one container to another container. However, Docker has deprecated this feature and recommends creating user-defined networks instead.

As an example, imagine you have a mydb container running a database service. We can then create an application container named myweb and directly link it to mydb:

$ docker run --name myweb --link mydb:mydb -d -P myapp python app.py

For further reading see Docker Documentation: Legacy container links

How Containers Communicate with the Outside World

There are different ways in which Docker containers can communicate with the outside world, as detailed below.

Exposing Ports and Forwarding Traffic

In most cases, Docker networks use subnets without access from the outside world. To allow requests from the Internet to reach the container, you’ll need to map container ports to ports on the container’s host. For example, a request to hostname:8000 will be forwarded to whatever service is running inside the container on port 80, if a mapping from host port 8000 to container port 80 to was previously defined.

See Docker Documentation: Exposing and publishing ports

Containers Connected to Multiple Networks

Fine-grained network policies for connectivity and isolation can be achieved by joining containers to multiple networks. By default each container will be attached to a single network. More networks can be attached to a container by creating it first with docker create (instead of docker run) and then running the command docker network connect. For example:

$ docker network create net1 # creates bridge network name net1
$ docker network create net2 # creates bridge network name net2
$ docker create -it --net net1 --name cont1 busybox sh # creates container named cont1 attached to network net1
$ docker network connect net2 cont1 # further attaches container cont1 to network net2

The container is now connected to two distinct networks simultaneously.

See Docker Documentation: User-defined networks

How IPv6 Works on Docker

By default, Docker configures the container networks for IPv4 only. To enable IPv4/IPv6 dual stack the --ipv6 flag needs to be applied when starting the Docker daemon. Then the docker0 bridge will get an IPv6 link-local address fe80::1. To assign globally routable IPv6 addresses to your containers, use the flag --fixed-cidr-v6 followed by ipv6 address.

See Docker Documentation: IPv6 with Docker

Common Operations

Some common operations with Docker networking include:

• Inspect a network: To see a specific network’s configuration details like subnet information, network name, IPAM driver, network ID, network driver, or connected containers, use the docker network inspect command.
• List all networks: Run docker network ls to display all networks (along with their type and scope) present on the current host.
• Create a new network: To create a new network, use the docker network create command and specify if it’s of type bridge (default), overlay or macvlan.
• Run or connect a container to a specific network: Note first of all, the network must exist already on the host. Either specify the network at container creation/startup time (docker create or docker run) with the --net option; or attach an existing container by using the docker network connect command. For example: docker network connect my-network my-container
• Disconnect a container from a network: The container must be running to disconnect it from the network using the docker network disconnect command.
• Remove an existing network: A network can only be removed using the command docker network rm if there are no containers attached to it. When a network is removed, the associated bridge will be removed as well.

Docker Networking with Multiple Hosts

When working with multi-host, there is a need to use higher-level Docker orchestration tools to ease management of networking between a cluster of machines. Popular orchestration tools today include Docker Swarm, Kubernetes, and Apache Mesos.

Docker Swarm

Docker Swarm is a Docker Inc. native tool used to orchestrate Docker containers. It enables you to manage a cluster of hosts as a single resource pool.

Docker Swarm makes use of overlay networks for inter-host communication. The swarm manager service is responsible for automatically assigning IP addresses to the containers.

For service discovery, each service in the swarm gets assigned a unique DNS name. Additionally, Docker Swarm has an embedded DNS server. You can query every container running in the swarm through this embedded DNS server.

See Docker Documentation: Manage swarm service networks

Kubernetes

Kubernetes Guide is a system used for automating deployment, scaling, and management of containerized applications, either on a single host or across a cluster of hosts.

Kubernetes approaches networking in a different way as compared to Docker, using native concepts like services and pods. Each pod has an IP address and no linking of pods is required, neither do you need to explicitly map container ports to host ports. There are DNS-based service discovery plugins which can be used for service discovery.

Apache Mesos

Apache Mesos is an open-source project used to manage a cluster of containers, providing efficient resource sharing and isolation across distributed applications.

Mesos uses IP address management (IPAM) server and client to manage containers networking. The role of the IPAM server is to assign IP addresses on demand while the IPAM client acts as a bridge between a network isolator module and the IPAM server. A network isolator module is a lightweight module that’s loaded into the Mesos agent. It looks at scheduler task requirements and uses IPAM and network isolator services to provide IP addresses to the containers.

Mesos-dns is a DNS-based service discovery for Mesos. It allows applications and services running on Mesos to find each other through the DNS service.

Read more on this wiki: Docker Networking 101