Learning Docker - Second Edition

Jeeva S. Chelladhurai, Vinod Singh, Pethuru Raj

• Publisher: Packt Publishing
• Year: 2017
• eBook ISBN: 9781786462015
• Edition: 2
• Topic: Computer Science
• Subtopic: Programming
• Index: Computer Science

Docker lets you create, deploy, and manage your applications anywhere at anytime – flexibility is key so you can deploy stable, secure, and scalable app containers across a wide variety of platforms and delve into microservices architectureAbout This Book• This up-to-date edition shows how to leverage Docker's features to deploy your existing applications• Learn how to package your applications with Docker and build, ship, and scale your containers• Explore real-world examples of securing and managing Docker containersWho This Book Is ForThis book is ideal for developers, operations managers, and IT professionals who would like to learn about Docker and use it to build and deploy container-based apps. No prior knowledge of Docker is expected.What You Will Learn• Develop containerized applications using the Docker version 17.03• Build Docker images from containers and launch them• Develop Docker images and containers leveraging Dockerfiles• Use Docker volumes to share data• Get to know how data is shared between containers• Understand Docker Jenkins integration• Gain the power of container orchestration• Familiarize yourself with the frequently used commands such as docker exec, docker ps, docker top, and docker statsIn DetailDocker is an open source containerization engine that offers a simple and faster way for developing and running software. Docker containers wrap software in a complete filesystem that contains everything it needs to run, enabling any application to be run anywhere – this flexibily and portabily means that you can run apps in the cloud, on virtual machines, or on dedicated servers.This book will give you a tour of the new features of Docker and help you get started with Docker by building and deploying a simple application. It will walk you through the commands required to manage Docker images and containers. You'll be shown how to download new images, run containers, list the containers running on the Docker host, and kill them.You'll learn how to leverage Docker's volumes feature to share data between the Docker host and its containers – this data management feature is also useful for persistent data. This book also covers how to orchestrate containers using Docker compose, debug containers, and secure containers using the AppArmor and SELinux security modules.Style and approachThis step-by-step guide will walk you through the features and use of Docker, from Docker software installation to the impenetrable security of containers.

Orchestrating Containers

In the earlier chapters, we laid down a strong foundation on the need for container networking, how to run a service inside a Docker container, and how to expose this service to the outside world by opening up network ports and other prerequisites. However, recently, there are advanced mechanisms being made available and a few third-party orchestration platforms hitting the market for sagaciously establishing dynamic and decisive linkages between distributed and differently-enabled containers in order to compose powerful containers for comprehensively, yet compactly containing process-centric, multi-tiered, and enterprise-class distributed applications. In the extremely diversified yet connected world, the concept of orchestration cannot be kept away from the deserved prominence for long. This chapter is precisely allocated for explaining the nitty-gritty of container orchestration, and its direct role is in picking up discrete containers to systematically compose sophisticated containers that are more directly aligned with the varying business expectations and expediencies.

In this chapter, we will discuss the following topics in detail:

• Linking containers
• Orchestrating containers
• Orchestrating containers using the docker-compose tool

As mission-critical applications are overwhelmingly being built through loosely coupled, yet highly cohesive components/services destined to run on geographically-distributed IT infrastructures and platforms, the concept of composition is getting a lot of attention and attraction. For sustaining the well-begun containerization journey, the orchestration of containers is being prescribed as one of the most critical and crucial requirements in the ensuing, instant-on, adaptive, and smart IT era. There are a few proven and promising methods and standards-compliant tools for enabling the enigmatic orchestration goals.

Docker inbuilt service discovery

The Docker platform inherently supports the service discovery for the containers that are attached to any user-defined network using an embedded Domain Name Service (DNS). This functionality has been added to Docker since the version 1.10. The embedded DNS feature enables the Docker containers to discover each other using their names or aliases within the user-defined network. In other words, the name resolution request from the container is first sent to the embedded DNS. The user-defined network then uses a special 127.0.0.11 IP address for the embedded DNS, which is also listed in /etc/resolv.conf.

The following example will help to gain a better understanding of Docker's built-in service discovery capability:

1. Let's begin by creating a user-defined bridge network, mybridge, using the following command:

 $ sudo docker network create mybridge 

2. Inspect the newly created network to understand the subnet range and gateway IP:

  $ sudo docker network inspect mybridge
 [
 {
 "Name": "mybridge",
 "Id": "36e5e088543895f6d335eb92299ee8e118cd0610e0d023f7c42e6e603b935e17",
 "Created": 
 "2017-02-12T14:56:48.553408611Z",
 "Scope": "local",
 "Driver": "bridge",
 "EnableIPv6": false,
 "IPAM": {
 "Driver": "default",
 "Options": {},
 "Config": [
 {
 "Subnet": "172.18.0.0/16",
 "Gateway": "172.18.0.1"
 }
 ]
 },
 "Internal": false,
 "Attachable": false,
 "Containers": {},
 "Options": {},
 "Labels": {}
 }
 ] 

Here, the subnet assigned to the mybridge network is 172.18.0.0/16 and the gateway is 172.18.0.1.

3. Now, let's create a container by attaching it to the mybridge network, as shown here:

 $ sudo docker container run \
 -itd --net mybridge --name testdns ubuntu 

4. Continue to list the IP address assigned to the container, as illustrated here:

  $ sudo docker container inspect --format \
 '{{.NetworkSettings.Networks.mybridge.IPAddress}}' \
 testdns 
 172.18.0.2 

Evidently, the testdns container is assigned a 172.18.0.2 IP address. The 172.18.0.2 IP address is from the subnet of the mybridge network (that is, 172.18.0.0/16).

5. Having got the IP address of the container, let's look into the content of the /etc/resolv.conf file of the container using the docker container exec subcommand, as shown here:

  $ sudo docker container exec testdns \
 cat /etc/resolv.conf 
 nameserver 127.0.0.11
 options ndots:0 

Here the nameserver is configured as 127.0.0.11, which is the IP address of the embedded DNS.

6. As a final step, let's ping the testdns container using the busybox image. We picked the busybox image here because the ubuntu image is shipped without the ping command:

  $ sudo docker container run --rm --net mybridge \ 
 busybox ping -c 2 testdns
 PING testdns (172.18.0.2): 56 data bytes
 64 bytes from 172.18.0.2: seq=0 ttl=64 
 time=0.085 ms
 64 bytes from 172.18.0.2: seq=1 ttl=64 
 time=0.133 ms

 --- testdns ping statistics ---
 2 packets transmitted, 2 packets received, 
 0% packet loss
 round-trip min/avg/max = 0.085/0.109/0.133 ms 

Awesome, isn't it! The folks behind Docker have made it so simple that with no effort we are able to discover the containers in the same network.

Linking containers

Before the introduction of the concept of the user-defined network, container linking was predominantly used for inter-container discovery and communication. That is, cooperating containers can be linked together to offer complex and business-aware services. The linked containers have a kind of source-recipient relationship, wherein the source container gets linked to the recipient container, and the recipient securely receives a variety of information from the source container. However, the source container will know nothing about the recipients to which it is linked. Another noteworthy feature of linking containers in a secured setup is that the linked containers can communicate using secure tunnels without exposing the ports used for the setup to the external world. Though you will find lots of deployments that use container-linking techniques, they are cumbersome and time-consuming to configure. Also, they are error-prone. So the new method of embedded DNS is highly preferred over the traditional container-linking techniques.

The Docker Engine provides the --link option in the docker run subcommand to link a source container to a recipient container.

The format of the --link option is as follows:

 --link <container>:<alias> 

Here, <container> is the name of the source container and <alias> is the name seen by the recipient container. The name of the container must be unique in a Docker host, whereas alias is very specific and local to the recipient container, and hence, the alias need not be unique in the Docker host. This gives a lot of flexibility to implement and incorporate functionalities with a fixed source alias name inside the recipient container.

When two containers are linked together, the Docker Engine automatically exports a few environment variables to the recipient container. These environment variables have a well-defined naming convention, where the variables are always prefixed with the capitalized form of the alias name. For instance, if src is the alias name given to the source container, then the exported environment variables will begin with SRC_. Docker exports three categories of environment variables, as enumerated here:

• NAME: This is the first category of environment variables. These variables take the form of <ALIAS>_NAME, and they carry the recipient container's hierarchical name as their value. For instance, if the source container's alias is src and the recipient container's name is rec, then the environment variable and its value will be SRC_NAME=/rec/src.
• ENV: This is the second category of environment variables used to export the environment variables configured in the source container by the -e option of the docker run subcommand or the ENV instruction of the Dockerfile. This type of an environment variable takes the form of <ALIAS>_ENV_<VAR_NAME>. For instance, if the source container's alias is src and the variable name is SAMPLE, then the environment variable will be SRC_ENV_SAMPLE.
• PORT: This is the final and third category of environment variables that is used to export the connectivity details of the source container to the recipient. Docker creates a bunch of variables for each port exposed by the source container through the -p option of the docke...

Table of contents

• Title Page
• Copyright
• Credits
• About the Authors
• About the Reviewer
• www.PacktPub.com
• Customer Feedback
• Preface
• Getting Started with Docker
• Handling Docker Containers
• Building Images
• Publishing Images
• Running Your Private Docker Infrastructure
• Running Services in a Container
• Sharing Data with Containers
• Orchestrating Containers
• Testing with Docker
• Debugging Containers
• Securing Docker Containers
• The Docker Platform – Distinct Capabilities and Use Cases