Docker in Depth

What is Docker?

Docker is an open platform for developing, shipping, and running applications. Docker is designed to deliver your applications faster. With Docker you can separate your applications from your infrastructure and treat your infrastructure like a managed application. Docker helps you ship code faster, test faster, deploy faster, and shorten the cycle between writing code and running code.

Docker does this by combining kernel containerization features with workflows and tooling that help you manage and deploy your applications.

At its core, Docker provides a way to run almost any application securely isolated in a container. The isolation and security allow you to run many containers simultaneously on your host. The lightweight nature of containers, which run without the extra load of a hypervisor, means you can get more out of your hardware.

Surrounding the container is tooling and a platform which can help you in several ways:

  • getting your applications (and supporting components) into Docker containers
  • distributing and shipping those containers to your teams for further development and testing
  • deploying those applications to your production environment, whether it is in a local data center or the Cloud.

Docker’s architecture:

Docker uses client-server architecture. The Docker client talks to the Docker daemon, which does the heavy lifting of building, running, and distributing your Docker containers. Both the Docker client and the daemon can run on the same system, or you can connect a Docker client to a remote Docker daemon. The Docker client and daemon communicate via sockets or through a RESTful API.



The Docker daemon

As shown in the diagram above, the Docker daemon runs on a host machine. The user does not directly interact with the daemon, but instead through the Docker client.

The Docker client

The Docker client, in the form of the docker binary, is the primary user interface to Docker. It accepts commands from the user and communicates back and forth with a Docker daemon.

Inside Docker

To understand Docker’s internals, you need to know about three components:

  • Docker images.
  • Docker registries.
  • Docker containers.

Docker images

A Docker image is a read-only template. For example, an image could contain an Ubuntu operating system with Apache and your web application installed. Images are used to create Docker containers. Docker provides a simple way to build new images or update existing images, or you can download Docker images that other people have already created. Docker images are the build component of Docker.

Docker registries

Docker registries hold images. These are public or private stores from which you upload or download images. The public Docker registry is provided with the Docker Hub. It serves a huge collection of existing images for your use. These can be images you create yourself or you can use images that others have previously created. Docker registries are the distribution component of Docker.

Docker containers

Docker containers are similar to a directory. A Docker container holds everything that is needed for an application to run. Each container is created from a Docker image. Docker containers can be run, started, stopped, moved, and deleted. Each container is an isolated and secure application platform. Docker containers are the run component of Docker.

So far, we’ve learned that:

  1. You can build Docker images that hold your applications.
  2. You can create Docker containers from those Docker images to run your applications.
  3. You can share those Docker images via Docker Hub or your own registry.


About Docker Networking

The Docker networking features allow you to create secure networks of web applications that can communicate while running in separate containers. By default, Docker configures two types of network (as displayed by the docker network ls command):


If you specify the –net=host option to the docker create or docker run commands, Docker uses the host’s network stack for the container. The network configuration of the container is the same as that of the host and the container shares the service ports that are available to the host. This configuration does not provide any network isolation for a container.


By default, Docker attaches containers to a bridge network named bridge. When you run a command such as ip link show on the host, the bridge is visible as the docker0 network interface. You can use the bridge network to connect separate application containers. The docker network inspect bridge command allows you to examine the network configuration of the bridge, which is displayed in JSON format. Docker sets up a default subnet address, network mask, and gateway for the bridge network and automatically assigns subnet addresses to containers that you add to the bridge network.

A container can communicate with other containers on a bridge network but not with other networks unless you also attach it to those networks. To define the networks that a container should use, specify a –net=bridge-network-name option for each network to the docker create or docker run commands. To attach a running container to a network, you can use the docker network connect network-name container-name command.

You can use the docker network create –driver bridge bridge-network-name command to create user-defined bridge networks that expose container network ports that can be accessed by external networks and other containers. You specify –net=bridge-network-name to docker create or docker run to attach the container to this network. User-defined bridge networks do not support linking by using the docker run –link command.

Link example:

# docker run -d –name db -p 3306:3306 centos/mysql:v1

 # docker run -d –name web -p 80:80 –link db:db centos/httpd:v3


Communicating Between Docker Containers

You can use the –link option with docker run to make network connection information about a server container available to a client container. The client container uses a private networking interface to access the exposed port in the server container. Docker sets environment variables about the server container in the client container that describe the interface and the ports that are available.

Create a client container named client1 that runs the bash shell and is linked to the http_server container:

       [root@host httpd]# docker run -t -i –name client1 –link http_server:server \

                                                oraclelinux:6.6 /bin/bash

        [root@client1 ~]#

The argument http_server:server to the –link option aliases the name http_server as server. Docker converts the alias to uppercase (SERVER) and uses this string when setting up the names of the environment variables on the client.

You can now view the environment variables in the client1 container. You can also use ping to detect the server container by name or IP address, and use curl to access the web server running on the server.

 Limiting CPU Usage by Containers

To control a container’s CPU usage, you can use the –cpu-period and –cpu-quota options with the docker create and docker run commands from version 1.7.0 of Docker onward.

The –cpu-quota option specifies the number of microseconds that a container has access to CPU resources during a period specified by –cpu-period. As the default value of –cpu-period is 100000, setting the value of –cpu-quota to 25000 limits a container to 25% of the CPU resources. By default, a container can use all available CPU resources, which corresponds to a –cpu-quota value of -1.

 Limiting The Memory Usage For Containers

In order to limit the amount of memory a docker container process can use, simply set the -m [memory amount] flag with the limit.

To run a container with memory limited to 256 MBs:

# Example: docker run -name [name] -m [Memory (int)][memory unit (b, k, m or g)] -d (to run not to attach) -p (to set access and expose ports) [image ID]

$docker run -m 64m -d -p 8082:80 tutum/wordpress

To confirm the memory limit, you can inspect the container:

# Example: docker inspect [container ID] | grep Memory

$docker inspect 9a7562a361122706 | grep Memory

Making a Container Use the Host’s UTS Namespace

By default, a container runs with a UTS namespace (which defines the system name and domain) that is different from the UTS namespace of the host. To make a container use the same UTS namespace as the host, you can use the –uts=host option with the docker create and docker run commands from version 1.7.0 of Docker onward. This setting allows the container to track the UTS namespace of the host or to set the host name and domain from the container.

Setting ulimit Values on Containers

The –ulimit option to docker run allows you to specify ulimit values for a container, for example:

$ docker run -i -t --ulimit nofile=128:256 --ulimit nproc=32:64

This example sets a soft limit of 128 open files and 32 child processes and a hard limit of 256 open files and 64 child processes on the container.

From version 1.6.0 of Docker, you can set default ulimit values for all containers by specifying –default-ulimit options to the Docker daemon. For example, you can add the options to OPTIONS in /etc/sysconfig/docker:

OPTIONS="--ulimit nofile=1280:2560 --ulimit nproc=256:512"

Any ulimit values that you specify for a container override the default values that you set for the daemon.

What happens when you run a container?

Either by using the docker binary or via the API, the Docker client tells the Docker daemon to run a container.

$ docker run -i -t ubuntu /bin/bash

Let’s break down this command. The Docker client is launched using the docker binary with the run option telling it to launch a new container. The bare minimum the Docker client needs to tell the Docker daemon to run the container is:

  • What Docker image to build the container from, here ubuntu, a base Ubuntu image;
  • The command you want to run inside the container when it is launched, here/bin/bash, to start the Bash shell inside the new container.

So what happens under the hood when we run this command?

In order, Docker does the following:

  • Pulls the ubuntu image: Docker checks for the presence of the Ubuntu image and, if it doesn’t exist locally on the host, then Docker downloads it from Docker Hub. If the image already exists, then Docker uses it for the new container.
  • Creates a new container: Once Docker has the image, it uses it to create a container.
  • Allocates a filesystem and mounts a read-write layer: The container is created in the file system and a read-write layer is added to the image.
  • Allocates a network / bridge interface: Creates a network interface that allows the Docker container to talk to the local host.
  • Sets up an IP address: Finds and attaches an available IP address from a pool.
  • Executes a process that you specify: Runs your application, and;
  • Captures and provides application output: Connects and logs standard input, outputs and errors for you to see how your application is running.

You now have a running container! From here you can manage your container, interact with your application and then, when finished, stop and remove your container.