What and Why?

You can’t work in a software company today and not hear about software containers: Docker, Kubernetes, Mesos, and a host of others. But before we dive into any of this, let’s look at what really changed in the world that led to the need for containers.

When you run a program on your machine in a certain environment, and the environment that supports your program on a production machine is not identical, problems arise. You test using a certain version of the programming language, and it runs a different version in production, so something weird happens, owing to the lack of forward or backward compatibility. Alternatively, you rely on a certain version of an SSL library, and a different version is installed in production. The network topology or the security policies might be different. These inconsistencies can cause all sorts of problems. Let’s take a step back. What is a container in the traditional sense of the word, and how can containers solve this problem?

“A container is any receptacle or enclosure for holding a product used in storage, packaging, and shipping,” right? Now let’s apply this to software.

The concept of container technology uses this same paradigm of shipping containers in transportation. The idea is that before shipping containers were invented, manufacturers had to be prepared to ship goods in a wide variety of modes—ships, trains, or trucks—with different sized containers and packaging. By standardizing the shipping container, goods could be seamlessly transferred among shipping methods, without any additional preparation. Before the advent of this standard, shipping anything in bulk was a complicated, laborious process.

The promise behind software containers is essentially the same. Instead of shipping via a full operating system (OS) and your software (and maybe the software that your software depends on), you simply pack your code and its dependencies into an image that can then run anywhere, and because these are usually pretty small, you can pack lots of containers onto a single computer.

Put simply, a container consists of an entire runtime environment: an application, plus all the dependencies, libraries and other binaries, and configuration files needed to run it, bundled into one package. By containerizing the application platform and its dependencies, differences in OS distributions and underlying infrastructure are abstracted away.

By allowing software code to be prepped in ready-made software containers, the code can quickly be moved around to run on servers running the Linux OS or be connected to run a distributed app in the cloud. This approach also has the benefit of speeding up the testing process and building large, scalable cloud applications. While this approach has been around in software development circles for many years, it has recently become more popular with the growth of Linux and cloud computing. Earlier projects taking the container approach have included BSD Jails, Solaris Zones, and Unix V7.

Containers vs. Virtual Machines

Heard the terms virtualization or virtual machine? First, what are virtual machines (VMs)? In the present day and age, when collaborating and working remotely have become commonplace, virtualization is key. Historically, as server processing power and capacity increased, bare metal applications weren’t able to exploit the new abundance in resources. Thus, VMs were born, designed by running software on top of physical servers, to emulate a particular hardware system.

At the heart of it, a VM is an app! Typically called hypervisor, it emulates an OS. Hypervisor is a program that enables you to host several different VMs on a single hardware. Everything in the VM is self-contained, and it typically has all the capabilities of the OS it is imitating.

Sounds like a fake computer, doesn’t it? However, there are some important distinctions. A VM is indeed entirely virtual, in that it doesn’t have any hardware of its own, except for the storage drive it comes from. More modern and complex VMs are supported by server setups.

Virtualization services are usually provided by specific companies, such as VMware, for example.

How do containers compare to VMs, though? Are they the same thing? When do you use what? And what is the key difference, really?

VMs take up a lot of system resources. Each VM runs not just a full copy of an OS but a virtual copy of all the hardware that the OS requires to run. This quickly adds up to a lot of RAM and CPU cycles. In contrast, all that a container requires is enough of an OS, supporting programs and libraries, and system resources to run a specific program.

What this means in practice is that you can put many more applications on a single server with containers than you can with a VM.

OS virtualization has grown in popularity over the last decade, to enable software to run predictably and well when moved from one server environment to another. But containers provide a way to run these isolated systems on a single server or host OS.

Containers sit on top of a physical server and its host OS, for example, Linux or Windows. Each container shares the host OS kernel. Binaries and libraries are the only elements created from scratch. Containers are thus exceptionally “light”—they are only megabytes in size and take just seconds to start, as opposed to gigabytes and minutes for a VM.

Containers also reduce management overhead. Because they share a common OS, only a single OS requires care and feeding for bug fixes, patches, and so on. This concept is similar to what we experience with hypervisor hosts: fewer management points but slightly higher fault domain. In short, containers are lighter weight and more portable than VMs.

VMs and containers differ in several ways, but the primary difference is that containers are isolated processes running on an OS that are implemented using namespaces. With VMs, the hardware is virtualized to run multiple OS instances. Containers’ speed, agility, and portability make them yet another tool to help streamline software development.

Figure 1-1 provides a comparison of containers and VMs.

Pros and Cons of Containerizing Applications

Let us start with understanding how applications are run traditionally. That will help us understand what containerization is not.

Summary

This chapter described the basics of containers, their use in the software industry, and how they differ from VMs. It also described the difference between running an application on a host machine vs. a VM vs. a container. It discussed the advantages and challenges of using containers.

This chapter has put you on a path along which you can start from scratch, if you’re new to the world of virtualization, by comparing the differences between all options available today and the reasons the software industry has moved toward containerization rather than other available options.

History

As new as containerization and Docker might sound to you, the intriguing wrinkle is that they’re really not new. The idea of containers has been around since the early days of Unix, with the chroot command. Rings a bell? Docker software was originally built on Linux containers, which were introduced in 2008.

As you should know from having read Chapter 1, containerized applications share a common operating system (OS) kernel, eliminating the need for each instance to run its own separate system. An application can be deployed in seconds and uses a lot fewer resources than hypervisor-based virtualization. However, because applications rely heavily on a common OS kernel, this approach can work only for applications that share the exact OS version. Docker found a way to address this limitation.

Docker was released as an open source project by dotCloud, Inc., in 2013. dotCloud is a San Francisco–based technology startup founded by the French-born American developer and entrepreneur Solomon Hykes. It relies heavily on namespaces and cgroups to ensure resource isolation and to package an application along with its dependencies, which are mostly Linux kernel features. It is this clustering of dependencies into a package that lets an application run across different platforms and still support a level of portability. This also allows developers to develop in the language of their choice, on a platform of their choice. This flexibility is what attracted a lot of interest in recent years.

Docker became extremely famous in many fast-growing companies that were trying to build test and dev environments for developers that could replicate production systems in many ways. Today, Docker is used by some well-known companies, including PayPal, Spotify, Yelp, and Pinterest, which are finding value in the software.

Let’s look at a time line of Docker milestones, according to the Container Journal. Docker source code was released as an open source software in March 2013. Needless to say, everyone had access to it after that. About a year later, Docker built the libcontainer framework, which it switched to. Around the same time, demand for orchestration tools increased, as Docker kept getting popular. In order for Docker containers to scale, orchestration frameworks are key. In June 2014, Google introduced Kubernetes, which helped Docker scale. Later that year, Amazon’s EC2 container service, which is a cloud-based container as a service, was offered. In June 2015, the open container initiative, which promotes open standards related to containers, was launched. A year later, Docker acquired a small company working on unikernels technology called Unikernels. By June of 2016, Docker had become very popular with the container ecosystem. It included the Swarm orchestrator in its platform, even though it was replaceable. Later that year, Docker started supporting all versions of Microsoft Windows. By 2016, Docker was extremely successful, and major companies began using it extensively for their most important use cases.

Now that we’ve reviewed how Docker became a success in the industry, let’s dive deeper into what Docker is and what use cases it solves.

What Is Docker?

Docker is the name of the company that produces the software called Docker. It is also the open source project that is now called Moby. When someone refers to Docker, he or she can be referring to any of these three things. Let’s try to understand a bit about each of them.

Docker is a software that runs on Linux and Windows. It is a tool designed to make it easier to create, deploy, and run applications, by using containers. The software is developed in the open, as part of the Moby open source project on GitHub.

Docker is a tool that is mainly designed for developers, so that they can focus on developing on their choice of platform, without having to worry about the OS the application will eventually run on. It allows them to run end-to-end workflow without having to get into services they don’t understand. In other words, it helps them to obtain a clearer view of the entire stack fairly easily. Additionally, running Docker containers has no additional memory overhead, so multiple Docker containers running multiple services creates very low overhead.

Understanding the different parts of Docker will help us get a good overview of everything Docker is made of before we dive deeper into any of it. The Docker architecture is explained in detail in Chapter 4.

Why Should You Use Docker?

Docker provides application isolation with little overhead. By saving space with the low memory footprint, it has some powerful advantages.

Primarily, you can benefit from the extra layer of abstraction (in which code and its dependencies are packed together) offered by Docker. Another significant advantage is that you can have many more containers running on a single machine than you can with virtualization alone, owing to Docker’s lightweight nature.

Another significant advantage is that containers can be spun and shut down within seconds. The Docker FAQ has a good overview of what Docker adds to traditional containers.

Let’s look at some of the key uses.

Docker’s Key Use Cases

Here are some of the key use cases that Docker supports that promote consistency of environments.

Summary

In this chapter, you learned how Docker evolved, how it went from being an open source project in 2013 to acquiring unikernels to running natively on Windows. You saw what requirements of the software industry gave rise to the wide adoption of Docker. You also learned some basics of Docker and its components. We’ll dive deeper into this in future chapters.

Finally, you learned some of the key use cases of Docker, ranging from code pipeline management to faster deployments to increasing developer productivity. These are just some of the use cases of Docker that are widely applied across the software industry.

In the next chapter, you will learn about the differences between monoliths and microservices and when and why you use one vs. the other. You will see how to use Docker with microservices, as well.

Evolution of Microservices

Before we go into learning how microservices evolved, let’s first look into challenges presented by monoliths, because that is what contributed to the need for microservices architecture.

A monolith application is a single, self-contained software application in which all components of the application, including the user interface and the data access code, are all tightly coupled into a single program.

To mitigate all of these potential pitfalls, microservices architecture was born.

A microservices architecture is one in which a monolith is split into multiple smaller services that operate independently of each other but are interconnected. Each microservice is an independent service or an independent application. Different microservices in an application can be built on different software stacks and implement their own architecture. What’s more, in a microservices architecture, each microservice can additionally implement its own database schema, as required, instead of sharing a single database schema. It can also use a database that best suits its need. As a matter of fact, microservices should use their own databases and database schema; otherwise, the dependency on shared databases and schemas doesn’t really allow the services to be independent. Figure 3-1 shows two services using MySQL but different instances of it. The monolith is broken down into multiple services, each of which uses its own database.

Microservices have many advantages over monoliths. A microservice architecture deals with the complexity issue of a monolith, for which it helps in dividing a single application into multiple components. This makes understanding as well as maintaining the code base a lot easier. Because the services operate independently, they can be developed using a framework that best suits the need. This gives developers a lot of flexibility, as they are free to choose what works best. Different modules can be deployed independently of one another. Services can also be scaled, as required. Testing independent services becomes easier as well, owing to the modularity that comes with a microservices architecture.

Comparing Monoliths and Microservices

Challenges with Microservices

While microservices address many issues with monoliths, they introduce many other kinds of problems that present a challenge. With a microservices architecture, you are dealing with all challenges that come with a distributed system. For example, because services in a microservices architecture are interconnected, inter-service communication must occur, and for that, a single, reliable, and consistent communication channel must be established, for example, using HTTP.

Multiple services mean more management of those services. All of these must be independently managed for their health and maintenance. These services have to be frequently updated and upgraded to meet the newest versions of the dependencies they use.

Microservices might have their own logging mechanisms. This might result in lots of unstructured and potentially unmanaged data. Retrieving logs can become confusing with gigabytes of available logging data.

Finding the root cause of a failure in a certain workflow might be very tedious to debug. In order to debug an entire workflow, you might have to get multiple services up and running and then test them end to end, in order to know where the bug exists, because the logic is distributed, as is the data. There could also be cyclic dependencies between services, which can be very difficult to deal with while debugging the root cause of a failure.

Last, the most significant issues are those related to versioning. When more than one service depends on certain libraries or packages, but only different versions of those libraries, it becomes tricky to get these services up and running. How can you have two versions of the same dependency on your machine? If you can’t have that, how can you manage getting these services up and running, either in a production system or in your debugging environment?

For example, imagine a spellchecker application with three different microservices: service A, service B, and service C. When the user enters a word to check the spelling of, the request is sent to service A, which depends on JavaScript version 1.8.5, Python version 2.7, and Flask version 0.12.4. Service B takes the request from service A, checks the spelling against a dictionary, and sends it to service C. In order to get service B up and running, you need Flask version 0.10.3. Service C takes this spelling and writes it to a database for records. Service C depends on Python version 2.1.

As you see, getting service A and service B running on the same machine is practically impossible, because they both require a different version of Flask. Similarly, getting service A and service C running successfully on a single machine is also impossible, owing to the different versions of Python.

This is one of the most prevalent and widely seen problems in the software industry. A common solution might be to update your services to use the same version of a certain dependency. But in a complex application with thousands of microservices, this becomes extremely difficult to keep track of. So, what is a good solution here? Docker.

In the preceding example, if you isolate service A, service B, and service C in their own environment and let them run independently and, at the same time, enable inter-process communication between them, they would not conflict with one another. Docker enables exactly this!

In the next few chapters, I will delve into how exactly this problem can be solved with the help of Docker, in addition to the many other advantages of using Docker to solve related problems.

Summary

In this chapter, you saw how the microservices architecture was born and how it evolved. The many challenges that came with monolith services were solved by the microservices architecture.

You also saw the differences between a monolith and a microservices architecture. You saw how as an application grows in size and complexity, a monolith poses many problems, such as difficulties with continuous deployments, testing, scalability, startup, etc. These are elegantly solved by a microservices architecture.

Last, you saw that with a microservices architecture come all the challenges of a distributed system. You saw how getting multiple services up and running can be quite challenging, if they rely on different versions of the same dependencies. Application isolation comes in very handy here. And Docker can help us with that.

In the next chapter, I will get into the basics of Docker and explain the nitty-gritties, including related terminologies, its architecture, how to install Docker, and some basic commands to use to get started.

Terminology

Architecture

Before mastering Docker, let’s get into how it all works behind the scenes, to get a solid understanding of how it really works and how its different components interact with one another.

As you have seen in the previous chapters, some of the advantages of Docker are process- and application-level isolation, portability, and ease of deployment and testing. Many different components come into play to support these scenarios. So, let’s delve into the components one at a time.

Docker Engine

The Docker Engine is a client-server application. It consists of the following three parts, as shown in Figure 4-1.

1. 1.

   A server process, also known as a daemon process. This is a background process that is continuously running and constantly listening to the REST API interface for any commands to process.

    
2. 2.

   A REST API interface that programs can talk to, in order to communicate with the Docker daemon. This can be accessed by an HTTP client.

    
3. 3.

   A client that is a command-line interface (CLI).

    

The way to get anything done using Docker is through the Docker client, via the CLI or a script composed of commands. The client then communicates these commands, via the REST API, to the Docker daemon, which is the server. The Docker daemon then gets the job done. It creates such Docker objects as images, containers, volumes, etc.

Let’s look more extensively into Docker’s client-server architecture.

Docker Architecture

The Docker system mainly consists of the Docker client, daemon, and registry (Figure 4-2).

Docker Client

The Docker Client is the primary way in which most users interact with Docker. When you run commands using the CLI, these commands are then sent to the Docker daemon, using the Docker API interface. The Docker daemon or the dockerd then executes these commands and creates relevant Docker objects. The Docker client has the ability to communicate with multiple Docker daemons.

Docker Daemon

The Docker daemon is a server process that is persistent in nature and runs in the background. It continuously listens to the REST API interface and looks for any incoming requests to process commands. The daemon can listen to the API interface using different socket types, such as Unix, TCP (transmission control protocol), and FD (file descriptor) .

Docker Registries

The images created by the Docker daemon must be stored at a certain location, for ease of access. The Docker registry is this location. There are public registries, such as the Docker Hub, that can be used by anyone. By default, Docker looks for images on the Docker Hub, but this can be configured to use your private registry as well.

Commands such as Docker pull retrieve the required images from your configured registry and Docker push pushes the image to this same configured registry.

From a Docker store, you can buy, sell, or distribute images for free. You can then use these images to deploy an application in your test or production environment.

Let’s move forward a bit and look at the different objects of Docker that have been referenced multiple times in this book so far.

Installing Docker

For the purposes of this book, let’s look at how to install the Docker CE.

Docker CE is available for both the Mac and Windows OSs. It is also available to Amazon Web Services and Microsoft Azure.

Let’s look at how to install Docker CE on the Mac OS platform. There are some system requirements to meet before you can install Docker on your machine. You will need a Mac machine model that is at least from 2010 or later. In addition, you will need at least 4GB of RAM.

1. 1.
   Go to the Docker store at https://store.docker.com/editions/community/docker-ce-desktop-mac and click Get Docker, from the right-side pane, as seen in Figure 4-3.

   

    
2. 2.
   Once you have the dmg file on your machine, double-click it and drag Moby the whale to the Applications folder, as shown in Figure 4-4.

   

    
3. 3.

   In the Applications folder, double-click the Docker app, as seen in Figure 4-5.

    

Authorize Docker.app with your system password, after you launch it. You will need admin access to launch the different Docker components.

1. 4.
   The Moby whale on the status bar on the top, as shown in Figure 4-6, indicates that Docker is now running.

   

    
2. 5.

   If you have successfully installed the app, you will also see a pop-up with a success message, next steps, and tips, as shown in Figure 4-7.

    

To dismiss this pop-up, click the whale on the top status bar.

Now that we have Docker installed and running on our machines, let’s take a look at some basic Docker commands, so that you can play around and experiment with them.

Basic Docker Commands

Following are some basic Docker commands that you can start playing with.

Summary

In this chapter, we looked in detail at the Docker terminology that has been commonly used in the previous chapters of this book and that will continue to be used in future chapters.

We also examined the different components of the Docker architecture, including the Docker Engine, Docker Hub, Docker clients, Docker hosts, and Docker registries. We also saw how different Docker objects are created by the Docker daemon. We saw how Docker Hub can be used to pull existing Docker images and buy, sell, or distribute images for free.

Additionally, you saw how to install Docker on the Mac OS platform in detail.

We looked at some basic Docker commands, with sample usage and examples of each command, so that you can explore them further. We then walked through a simple end-to-end example of pulling the existing Hello World image and running it.

In the next chapter, I’ll go more into detail on how to build an image from a Dockerfile and run it inside a container.

Docker Images

As mentioned previously, Docker images are read-only and immutable and created with the docker image build command . They are stored inside a Docker registry and run inside a container. Images can become quite large very quickly. Therefore, they are designed to be composed of layers of other images, allowing a minimal amount of data to be sent when transferring images over a network. So, you can build your own customized image on top of an existing image. When you modify that image, new layers are added that contain your changes.

As for Docker containers, you’ll learn about them in more detail later in this chapter, but to summarize with a programming metaphor, if an image is a class, then a container is an instance of a class, that is, a runtime object. While images are lightweight and portable encapsulations of an environment, containers are the running instances of images.

Furthermore, a Docker image is created using a Dockerfile. Let’s see what a Dockerfile is. Later on, you’ll learn how to build a Docker image from a Dockerfile.

Dockerfile

Everything Docker begins with a Dockerfile. The Dockerfile is the instruction set on how to build an image. It the basis on which your entire Docker container is built. It specifies all the configuration settings environment variables, volumes to be mounted, the base image to build on top of, the list of dependencies, etc. All this is then bundled into an image that then runs inside the container.

A Dockerfile must be built to create the Docker image of an application. The image is just the “compiled version” of the source code that lives inside the Dockerfile. The Dockerfile is a text file that contains a set of instructions or commands that are then assembled into an image.

Creating a Sample Dockerfile

This command is set in such a way that whenever you run the image, the ENTRYPOINT command will be executed every time.

You can also pass arguments here, but they are optional. You can pass them when you run the image with something such as docker run <image-name>.

Save this file, and in the next section, you’ll see how to build an image from this Dockerfile.

Building Images with Dockerfile

As you’ve learned so far, Docker images are immutable, read-only file systems. Images can be based on other existing images that can be pulled from Dockerfile. This makes modifying them a lot easier, because the only thing that changes is the layer that gets modified. This also prevents images from becoming extremely large in size.

In the previous section, we created a Dockerfile called Dockerfile with some basic instructions and saved it in a directory called docker.

Let’s continue to build an image from the Dockerfile created in the previous section. From the docker directory, run the command docker image build. The . builds the Dockerfile within the directory.

When you run this command for the first time, you’ll see a long list of packages being pulled, because we’re building our image on top of the Ubuntu image.

I am going to divide the output in multiple sections, to make it easier to read. You should be able to see this entire output, if your image is built successfully.

In the next section, let’s run this image inside a container.

Docker Containers

Now that we have built a Docker image successfully, let’s look into what a Docker container is and run this image inside a container.

As we’ve seen before, Docker containers provide a different form of isolation than virtual machines (VMs). They are lightweight platforms to package your entire microservices application and have it running inside the container.

Let’s run inside a container the image we built successfully. There are multiple ways to run a Docker image inside a container.

You could use either or both to run the image inside a container.

Now let’s look inside the container. Your container has the ID 1c3e3baace92.

When inside the container, you can view logs, volumes that have been mounted, etc. Getting inside the Docker container very much comes in handy when debugging errors.

Attaching and Detaching from a Docker Container

Attaching to the Docker container means attaching the local standard input/output to the Docker container. Detaching means detaching your local input/output from the Docker container. Now you’ll learn how to attach to and detach from a Docker container.

In order to attach to the Docker container, first run the Docker image, and give it a name, say, “testdemo.”

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container run -d –-name testdemo ubuntu /usr/bin/tap -b easjhf7ejbadgsvkaid888sagdhabgfks555

kinnaryjangla@dev-abv:~/code/demo/docker$

Next, let’s attach our local terminal standard input/output to the container using docker container attach, as shown in Figure 5-1.

You should see that your terminal is now attached to the container’s input/output.

Let’s do another quick example, in which you can see the exit code of your container in your local terminal output.

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container run –name test -d -it ubuntu

easjhf7ejbadgsvkaid888sagdhabgfks555

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container attach test

root@ksjhdf6t3uqe: /# exit 13

exit

kinnaryjangla@dev-abc:~/code/demo/docker$ echo $?

13

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container ls -a | grep test

ksjhdf6t3uqe   ubuntu    "/bin/bash"    28 seconds ago    Exited(13) 15 seconds ago

In this example, we run the image inside a container and call it test. We then attach the container to the local standard input/output. From inside the container, we set an exit code of 13, which exits the container. On your local terminal, when you echo, you see 13 as the output. In your list of containers, you see that the container exited, owing due to the exit code 13.

You can also create a new container over a certain image. This is useful when you want to set up a container configuration beforehand.

To create a container over our Ubuntu image, let’s use docker container create -t -I ubuntu bash.

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container create -t -I ubuntu bash cee13y299o1hkjasd462e4jhdasi7673242hbd76gdewu

Then start this container, using the first few letters of the container ID that was created previously.

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container start -a -i cee13y299

root@ cee13y299: /#

This lands you inside the newly created container.

You can do various things when you create a container, such as initializing volumes and even removing them using the -v option.

Now that we’ve looked at how to create Dockerfiles, how to build images with Dockerfiles, and how to run these images inside a container, in the next chapter, let’s look at how to link multiple containers,in order to get an entire microservices application up and running on Docker.

Summary

In this chapter, we looked at what a Dockerfile is and created a basic Dockerfile step by step. You learned that a Dockerfile is the first step to anything Docker.

Later, we built an image using this Dockerfile. We looked at how to list all the images on your host machine.

Later, we ran this image inside a container and looked at how to attach the container to our local terminal input/output. We executed a few examples and attached and detached the container to our local terminal. You also learned how to list all the containers that are up and running on your machine.

In the next chapter, we’ll look at how to link multiple containers, hence multiple services to each other, and create a real-world microservices application, using Docker.

What Is Docker Compose

In the previous chapters, you saw the advantages of running services on Docker containers. Some of the advantages are consistent environment variables, isolation of dependencies, and enabling continuous deployment of these services.

Today, most software applications are made of multiple services that talk to each other. In order to make such applications operational, you have to link several Docker containers to one another and have them all running simultaneously on Docker in production. Let’s see how we can link multiple Docker containers.

Docker Compose is the tool for running multi-container Docker applications. It’s essentially a YAML file that can be thought of as a composition of multiple Dockerfile containers running commands into a single file. This Docker compose YAML file contains configurations of multiple services. Then, using a single command, you can get all the services up and running simultaneously inside Docker containers.

You can also configure these services in such a way that they talk to each other.

Docker Compose can be used to create this microservices architecture and link the containers between them, or it can be used for a single service. In addition, Docker Compose can build images, scale containers, and rerun stopped containers. All this functionality is a part of Docker. docker-compose is just a higher-level abstraction of container run commands. You can do everything you can in a compose file with plain Docker commands, except that this requires more memory and takes extra effort to run all the extra commands, attaching to the network, etc. docker-compose helps to simplify this process.

In this example, the Docker Compose YAML file has configurations for two services, namely, myApp and Redis, wherein myApp is an application service and Redis is a database. Let’s look at what some of the fields in the YAML file represent. First, the Docker Compose YAML file tells Docker to build the images for the services—myApp and Redis. The build instruction asks to look for the file Dockerfile-dev in the folder myApp.

Instead of using the build key, you could specify the image. If you use image, specify the image name. This pulls up the specific image.

Next, the ports instruction indicates to map port 5001 on the host to the service1 docker containers port 8887.

The command instruction specifies the first command to run, in order to get the service up and running.

container_name is intuitive. It specifies the name of the Docker container in which myApp will run. This is used to identify which services run inside which Docker container. However, most compose files do not define the container name. Names must be unique. Once you specify a name, you have removed the ability to scale the number of replicas used for a service. When the docker-compose tool starts the container without a specified name, the generated name helps to identify the service.

The volumes instructions let you map certain files and folders on the host machine to the Docker container. For example, /home/{{USER}}/code/services/service1:/var/src/myApp says to map the folder code/services/service1 to the folder var/src/myApp on the Docker container. This command is very useful when debugging inside the Docker container, so that you can use the files that exist on the host machine.

The environment instruction basically configures the environment variables for the services.

The networks key lets you define a network that each service wants to connect to. You can also specify a default network that can be used for the entire app. If there is an existing network that you want the containers to join, you can employ the external option.

In addition to the instructions in the preceding sample Docker Compose YAML file, you could use deploy to specify the deployment specifications, such as the number of replicas, resources, CPU, and memory limits on these resources, restart policies, etc. The deploy key only applies when deploying to a Swarm. We’ll look at that in more detail in later chapters.

Next let’s see how to install Docker Compose on your machine.

Installing Docker Compose

Docker Compose relies on the Docker Engine, so before you install Compose, make sure you have Docker installed on your machine.

The Docker Desktop tool includes the docker-compose tool.

In order to get Docker for a Mac system, refer to the “Installing Docker” section in Chapter 4. For older machines, you can get the Docker Toolbox. Docker Toolbox helps you quickly set up and install the Docker environment on your Mac or Windows machine. Docker Toolbox includes docker-machine, docker, docker-compose, Docker GUIs, and Docker CLIs.

You can uninstall Docker Compose in two ways, unless you’ve installed the Docker Compose tool with Docker Desktop. In this case, you’ll have to uninstall Docker Desktop.

Usage

Let’s look at some basic Docker Compose commands.

Behind the Scenes and an Example

In the previous chapters, you saw how a single Dockerfile can be built into a single Docker image. Similar to that, a single Docker Compose YAML file can be built into a stack of images. This stack is also called a distributed application bundle (DAB).

Docker stacks and Docker bundles are features in Docker and Docker Compose.

The simplest way to create a Docker bundle is via Docker Compose. Using docker-compose bundle builds all the images of the services in the YAML file and creates a bundle. In order to deploy this bundle, you have to create a Docker stack. This can be done using docker deploy. You can manage this stack using the docker stack command.

Further, let’s work through a simple docker-compose example in which we will link two services.

In this example, redis refers to the Redis Docker container, and we use 6379, which is the default port for Redis.

Let’s look at what the instructions in this Dockerfile mean. The FROM instruction pulls the alpine image from the Docker registry and builds the image. Next, the ADD instruction says to add the current directory . into the /code directory in the image. The WORKDIR command sets the working directory in the container to /code. The RUN instruction installs the Python dependencies, namely, Flask and Redis, as defined in the requirements.txt file. The CMD instruction then sets the default command for the Docker container to python myapp.py.

So now that we have the Dockerfile for our service created, let’s start a Redis service that our app can talk to that pulls an existing Redis image from the Docker registry. In practice, this could be replaced by another similar service to that we created previously.

This is made up of two services, one of which is defined by us, called myapp, that is built by the Dockerfile in the current project directory. This configuration maps the port 5000 on the host machine to the port 5000 on the Docker container running this service. The other service is Redis, which pulls an existing Redis image from the default Docker Hub registry.

From your project directory, now run docker-compose up .

As you see from the preceding code, both services have started and are running.

Next, look at our browser. On your browser, navigate to http://0.0.0.0:5000/, to see your application running, as shown in Figure 6-1. The web app should now be listening to the port 5000 on your Docker daemon.

If you refresh the page, you should see the count increase from 1 to 2, as shown in Figure 6-2.

Now that you’ve seen a running example of docker-compose, let’s conclude this section.

Summary

In this chapter, we looked at Docker Compose and its uses. We saw that Docker containers running different services can be linked to one another using docker-compose.

You saw how to install and uninstall the docker-compose tool and different uses for docker-compose. Next, you saw how docker-compose creates container images and spins them. I walked you through a real-world example of Docker Compose. We created a Dockerfile for a service and a docker-compose file that links that service to a Redis image that we pulled from the Docker Hub registry. We went through how to build it and run the entire application. We looked at the browser, to see the application in action and then viewed the Docker containers running the two services that the application is composed of.

In the next chapter, I’ll go through a real-world example of how to debug a real-world application composed of microservices, using Docker.

Distributed Environments

What exactly is a distributed system? In the simplest terms, it is a group of individual computers working together and appearing to the external user as one system. These computers have shared state, concurrency behaviors, and failure handing properties, if implemented correctly.

Some of the obvious advantages of a distributed system are sharing, collaboration, scalability, reliability, and availability. The World Wide Web is a fantastic example of a distributed system.

Advantages of Distributed Systems

Challenges of Distributed Systems

Let’s look at some of the major challenges you’ll face with distributed systems.

Debugging

Given that a distributed system has multiple services linked to one another, handling of failures as those mentioned previously can get tricky. Debugging these failures can get even trickier. In order to debug, you would have to get all the services up and running first. Consider multiple services dependent of different versions of a library. Getting these services running on a single machine would be pretty difficult, maybe even impossible, without the use of some kind of virtualization.

Sample Real-World End-to-End Use Case

Some of the challenges of a distributed environment can be addressed with Docker. Let’s look at how to specifically debug an end-to-end application whose service runs using Docker Compose.

Consider a web site that takes a list of interests as user input and renders images in the user’s feed, based on these interests. This can get extremely complex, if you take user signals into account. That would include learning from user signals and rendering images from the categories or interests that the user is known to click most and rendering fewer images from categories or interests that the user has not clicked very often. This can become complicated very quickly. For the purpose of maintaining simplicity, I will not take user signals into account in this example.

So, let’s look at what our application does. Our application basically contains a table from which user ID is mapped to a list of interests and an inverted index of interests to images in a MySQL database. When the user logs into his or her account, an HTTP request is made to a service, in order to retrieve the user’s list of interests. This list is then sent to another service, which in turn looks at the database and gets five images per interest from the interest list. Once this data is returned, this service then sorts this image list according to those most recently created and sends it back to the client in the HTTP response.

I will not go into detail about how each service does its job or the schema of the database. For the purposes of this example, we’ll look at the Dockerfiles of each service, the Docker Compose file that will get all these services up and running at the same time, and, finally, we’ll make an HTTP request to our service and look at the response received and the images rendered.

Let’s begin. We’ll call our application FunFeed. Figure 7-1 shows how it will look.

Now let’s take a closer look at the Client service.

As mentioned, this service logs the user in and sends the user ID to the DB service (Figure 7-2).

Put succinctly, the Client service Dockerfile sets the base image that the rest of the instructions can sit on, sets some environment variables for the client container, sets a working directory and copies some files, and, finally, sets up the command for the image run.

Now that we have looked at the individual Dockerfiles of all three services, let’s take a look at some of the dependencies of those services.

As you can see in the preceding code snippet, the Client service depends upon the Puppycrawl tool version 7.5.1, in addition to the JUnit and Twitter dependencies.

We already have versioning conflicts for JUnit and com.twitter.common libraries, because both of these are used by both Client and DB services, except that these services use different versions of these libraries. If you were to run these services on a single machine on the same application server, you would have to make these compatible with the same version of JUnit and Twitter. Imagine doing this for 50 dependencies, which could very well be the case for huge services. Then imagine adding a new service that depends on the latest version of JUnit, in which case, you would have to make all the previous services use the latest version of JUnit. In addition, JUnit is a test-scoped dependency, so it isn’t even included in the final artifact. If a previous service was using a feature that is potentially not supported in the latest version of JUnit, that would break your service, and you would have to rewrite some of it to use the latest version of JUnit. Nightmare! Isn’t it?

Even though the Api service does not need JUnit or Twitter to execute, it is dependent on the Apache Maven plug-ins and the Puppycrawl tool plug-in, both of which are different versions than those of the Client service, as you can see in the code snippet.

Even though there are conflicts in the dependencies of all these three services, Docker can handle this gracefully, using one of its properties of application isolation. That means that running these services individually inside Docker containers will not cause these services to conflict with one another. Instead, they can operate in their own isolated environment and run simultaneously.

Alright, now that we have established why we are going to run these services in Docker containers (to enable them running in their isolated environments, to avoid conflict dependencies), let’s look at how can we get them all running together, so we can run the application end to end all at once.

As you can see in preceding code snippet, the docker-compose file of the FunFeed application contains the configuration of all three services Client, DB, and Api.

Now that we’ve looked at our docker-compose file, let’s go ahead and run this and see what it looks like.

As you can see, so far, we have Api and Client services running successfully. Next, let’s verify whether Api, DB, and Client Docker containers are running.

Now that we have all the Docker containers for all the services of our application up and running, as you can see in the preceding code snippet, let’s see how we can look at the logs and how to look inside these Docker containers.

Note, as you can see, the Dockerfile of the Api service sets the working directory to be /opt/api, which is why the container starts in that directory.

Now that we’ve looked at how to get inside the Docker containers, let’s go ahead and query the entire FunFeed application.

The FunFeed application services talk to one another over a common network that could be defined in the docker-compose file. The Client service talks to the DB service, and the DB service talks to the Api service. This means that any incoming request from the Client service to the DB service will not go to the DB production service anymore. Instead, the request will be processed by the DB service running inside the Docker container named db. Similarly, any incoming request from the DB service to the Api service will go to the Api service running inside the Docker container named api.

Now that we’re clear on how the request is going to get processed, it’s time for the finale! Let’s query our FunFeed application and see what we get back.

In order to query our application, make sure that you are inside the FunFeed ➤ client directory. Remember: client is our Client service, which will accept this request, authenticate the user, and send the user ID to the DB service, to get a list of interests for that user and then send it to the Api service, to get the list of images in the response.

Let’s look at what the preceding request means.

The server/local_test_serversh is the script that starts the server for the Client service, such that it gets ready to accept the incoming requests. The user_id is the parameter that is being passed to this script as an input. "--" before user_id is just how the script recognizes what the input parameters are. num_results is a parameter that accepts the number of results.

Now let’s look back at the preceding snippets. Observe that all three services are ready to accept incoming requests.

Now that we’ve made the request, let’s go back and look at our web browser, because we have all our services hooked up to the correct ports (Figure 7-3).

Furthermore, if you see in your terminal where the client Docker container is running, running the docker container logs command should show you everything that’s happening inside each container. You should be able to see all the post and get requests being made and all data received. Remember: What you see in the logs is because of what your service and script logs on the output terminal. So, if you want more verbosity, make sure your script of your service logs the requests or the data that you would like to see in the logs. That also makes it easier to debug, if something is failing in any of these services.

Debugging

Now that we’ve looked at how an end-to-end application runs successfully on Docker, let’s take a look at how you would debug if something failed here and what could be potential hurdles as you develop.

Last, docker-compose in theory is a very powerful and extremely straightforward tool to run multi-container applications. It’s super convenient to get an application that is composed of multiple microservices up and running for development purposes and also in production environments.

Today, many companies, such as Pinterest, Lyft, Yelp, etc., run their services on Docker containers. In order for Docker containers to run at scale (to compute the resources needed to run containers), options such as Amazon Web Services (AWS) or any other public clouds come in very handy. AWS lets you deploy containers pretty quickly.

In addition, in order to get services running at scale in such large companies, automation of deployment of these services, also known as orchestration, requires different solutions. We’ll look at that a little more in detail in the next and final chapter.

Summary

Phew, that was a lot! In this chapter, we looked at distributed environments and their advantages and challenges. You saw in depth that heterogeneity, concurrency, scalability, transparency, and failure handling are just a few of the issues related to distributed environments.

Later, we saw how an end-to-end application composed of microservices runs, using the Docker Compose tool. We walked through each service, its responsibility, individual Dockerfiles, the docker-compose file that runs the entire application, and, finally, we made a request to the entire end-to-end application, once all Docker containers were up and running. We saw the output of that request in a web browser. Last, we looked at some of the hurdles that you can encounter while running a full application on Docker.

In the next chapter, we’ll look at how Docker works in production environments, how to scale Docker containers, and how all this ultimately helps us accelerate the development for software engineers.

Docker in Production Environments

Now that we’ve got our application built and even running on Docker from our local machines, it might be time to ship it. Let’s deploy it in our production environment, so that the world can start using it.

But wait, is our application really ready to be shipped? The answer is, not so fast!

There are many critical decisions to be made before we decide to ship our application. Let’s look at some of them.

Orchestration Using Docker

What is container orchestration, after all? Put simply, a container orchestration is the process of deploying multi-container applications on multiple machines. Or, even more essentially, it’s the process of transitioning individual containers on a single host to multi-container applications on multiple machines.

Needless to say, in order to achieve this, one would require a distributed platform that can stay online through the entire lifetime of an application, surviving hardware and software failures and upgrades.

In order to enable orchestration, Docker came up with a solution known as “Docker in swarm mode.”

Basically, it consists of a group of Docker Engines on which applications can be deployed using the Docker API . API objects such as Service and Node can be used to do this.

There are multiple tools that can be used for orchestration, for example, Kubernetes. One way to orchestrate Docker is with Docker! Docker orchestration is built in as part of the core Docker Engine, and it relies on some fundamental principles, such as simplicity, reliability, security, and backward compatibility.

Modern distributed applications that serve heavy traffic are mostly all going to run on multiple hosts and multiple machines and, therefore, will require orchestration as a critical element. More often than not, a new tool comes on the market, and developers must ramp up on it quickly. Before you know it, some other tool supersedes it, and it’s time to ramp up on that.

Simplicity of tools makes it easier for developers to start using them more quickly. At the same time, making these tools more powerful allows developers to use them for longer periods of time, thus providing more flexibility. Docker in swarm mode takes advantage of this fundamental principle. And it’s built with simplicity in mind, yet it’s one of the most powerful tools. It focuses on resilience in addition to simplicity. Computers fail all the time, and systems should expect that and be able to adapt to potential failures effortlessly.

Needless to say, applications built on distributed systems must be highly secure. Security should be an assumed principle. Continuous upgrades of certificates, privacy updates, network tapping, etc., are effortlessly incorporated in the swarm mode.

Docker has had multiple versions and millions of users using these different versions. For this reason, maintaining backwards compatibility is essential for Docker, and that’s exactly what Docker in swarm mode provides.

Advanced Use Cases

Tips and Tricks

Summary

In this chapter, I reviewed the decisions that you’ll have to make, in order to take your Docker application to production. You saw how network access and security, deployment of multiple Docker containers and multiple Docker hosts, etc., can be quite challenging.

You then saw how Docker has a swarm mode to help with orchestration, which is managing complex multi-container applications on multiple machines. You also learned some tips and tricks that can be very useful when building applications with Docker.

This concludes this book. All the knowledge you’ve gained, if put into practice, can tremendously increase the velocity of your software engineering.

What and Why?

You can’t work in a software company today and not hear about software containers: Docker, Kubernetes, Mesos, and a host of others. But before we dive into any of this, let’s look at what really changed in the world that led to the need for containers.

When you run a program on your machine in a certain environment, and the environment that supports your program on a production machine is not identical, problems arise. You test using a certain version of the programming language, and it runs a different version in production, so something weird happens, owing to the lack of forward or backward compatibility. Alternatively, you rely on a certain version of an SSL library, and a different version is installed in production. The network topology or the security policies might be different. These inconsistencies can cause all sorts of problems. Let’s take a step back. What is a container in the traditional sense of the word, and how can containers solve this problem?

“A container is any receptacle or enclosure for holding a product used in storage, packaging, and shipping,” right? Now let’s apply this to software.

The concept of container technology uses this same paradigm of shipping containers in transportation. The idea is that before shipping containers were invented, manufacturers had to be prepared to ship goods in a wide variety of modes—ships, trains, or trucks—with different sized containers and packaging. By standardizing the shipping container, goods could be seamlessly transferred among shipping methods, without any additional preparation. Before the advent of this standard, shipping anything in bulk was a complicated, laborious process.

The promise behind software containers is essentially the same. Instead of shipping via a full operating system (OS) and your software (and maybe the software that your software depends on), you simply pack your code and its dependencies into an image that can then run anywhere, and because these are usually pretty small, you can pack lots of containers onto a single computer.

Put simply, a container consists of an entire runtime environment: an application, plus all the dependencies, libraries and other binaries, and configuration files needed to run it, bundled into one package. By containerizing the application platform and its dependencies, differences in OS distributions and underlying infrastructure are abstracted away.

By allowing software code to be prepped in ready-made software containers, the code can quickly be moved around to run on servers running the Linux OS or be connected to run a distributed app in the cloud. This approach also has the benefit of speeding up the testing process and building large, scalable cloud applications. While this approach has been around in software development circles for many years, it has recently become more popular with the growth of Linux and cloud computing. Earlier projects taking the container approach have included BSD Jails, Solaris Zones, and Unix V7.

Containers vs. Virtual Machines

Heard the terms virtualization or virtual machine? First, what are virtual machines (VMs)? In the present day and age, when collaborating and working remotely have become commonplace, virtualization is key. Historically, as server processing power and capacity increased, bare metal applications weren’t able to exploit the new abundance in resources. Thus, VMs were born, designed by running software on top of physical servers, to emulate a particular hardware system.

At the heart of it, a VM is an app! Typically called hypervisor, it emulates an OS. Hypervisor is a program that enables you to host several different VMs on a single hardware. Everything in the VM is self-contained, and it typically has all the capabilities of the OS it is imitating.

Sounds like a fake computer, doesn’t it? However, there are some important distinctions. A VM is indeed entirely virtual, in that it doesn’t have any hardware of its own, except for the storage drive it comes from. More modern and complex VMs are supported by server setups.

Virtualization services are usually provided by specific companies, such as VMware, for example.

How do containers compare to VMs, though? Are they the same thing? When do you use what? And what is the key difference, really?

VMs take up a lot of system resources. Each VM runs not just a full copy of an OS but a virtual copy of all the hardware that the OS requires to run. This quickly adds up to a lot of RAM and CPU cycles. In contrast, all that a container requires is enough of an OS, supporting programs and libraries, and system resources to run a specific program.

What this means in practice is that you can put many more applications on a single server with containers than you can with a VM.

OS virtualization has grown in popularity over the last decade, to enable software to run predictably and well when moved from one server environment to another. But containers provide a way to run these isolated systems on a single server or host OS.

Containers sit on top of a physical server and its host OS, for example, Linux or Windows. Each container shares the host OS kernel. Binaries and libraries are the only elements created from scratch. Containers are thus exceptionally “light”—they are only megabytes in size and take just seconds to start, as opposed to gigabytes and minutes for a VM.

Containers also reduce management overhead. Because they share a common OS, only a single OS requires care and feeding for bug fixes, patches, and so on. This concept is similar to what we experience with hypervisor hosts: fewer management points but slightly higher fault domain. In short, containers are lighter weight and more portable than VMs.

VMs and containers differ in several ways, but the primary difference is that containers are isolated processes running on an OS that are implemented using namespaces. With VMs, the hardware is virtualized to run multiple OS instances. Containers’ speed, agility, and portability make them yet another tool to help streamline software development.

Figure 1-1 provides a comparison of containers and VMs.

Pros and Cons of Containerizing Applications

Let us start with understanding how applications are run traditionally. That will help us understand what containerization is not.

Summary

This chapter described the basics of containers, their use in the software industry, and how they differ from VMs. It also described the difference between running an application on a host machine vs. a VM vs. a container. It discussed the advantages and challenges of using containers.

This chapter has put you on a path along which you can start from scratch, if you’re new to the world of virtualization, by comparing the differences between all options available today and the reasons the software industry has moved toward containerization rather than other available options.

History

As new as containerization and Docker might sound to you, the intriguing wrinkle is that they’re really not new. The idea of containers has been around since the early days of Unix, with the chroot command. Rings a bell? Docker software was originally built on Linux containers, which were introduced in 2008.

As you should know from having read Chapter 1, containerized applications share a common operating system (OS) kernel, eliminating the need for each instance to run its own separate system. An application can be deployed in seconds and uses a lot fewer resources than hypervisor-based virtualization. However, because applications rely heavily on a common OS kernel, this approach can work only for applications that share the exact OS version. Docker found a way to address this limitation.

Docker was released as an open source project by dotCloud, Inc., in 2013. dotCloud is a San Francisco–based technology startup founded by the French-born American developer and entrepreneur Solomon Hykes. It relies heavily on namespaces and cgroups to ensure resource isolation and to package an application along with its dependencies, which are mostly Linux kernel features. It is this clustering of dependencies into a package that lets an application run across different platforms and still support a level of portability. This also allows developers to develop in the language of their choice, on a platform of their choice. This flexibility is what attracted a lot of interest in recent years.

Docker became extremely famous in many fast-growing companies that were trying to build test and dev environments for developers that could replicate production systems in many ways. Today, Docker is used by some well-known companies, including PayPal, Spotify, Yelp, and Pinterest, which are finding value in the software.

Let’s look at a time line of Docker milestones, according to the Container Journal. Docker source code was released as an open source software in March 2013. Needless to say, everyone had access to it after that. About a year later, Docker built the libcontainer framework, which it switched to. Around the same time, demand for orchestration tools increased, as Docker kept getting popular. In order for Docker containers to scale, orchestration frameworks are key. In June 2014, Google introduced Kubernetes, which helped Docker scale. Later that year, Amazon’s EC2 container service, which is a cloud-based container as a service, was offered. In June 2015, the open container initiative, which promotes open standards related to containers, was launched. A year later, Docker acquired a small company working on unikernels technology called Unikernels. By June of 2016, Docker had become very popular with the container ecosystem. It included the Swarm orchestrator in its platform, even though it was replaceable. Later that year, Docker started supporting all versions of Microsoft Windows. By 2016, Docker was extremely successful, and major companies began using it extensively for their most important use cases.

Now that we’ve reviewed how Docker became a success in the industry, let’s dive deeper into what Docker is and what use cases it solves.

What Is Docker?

Docker is the name of the company that produces the software called Docker. It is also the open source project that is now called Moby. When someone refers to Docker, he or she can be referring to any of these three things. Let’s try to understand a bit about each of them.

Docker is a software that runs on Linux and Windows. It is a tool designed to make it easier to create, deploy, and run applications, by using containers. The software is developed in the open, as part of the Moby open source project on GitHub.

Docker is a tool that is mainly designed for developers, so that they can focus on developing on their choice of platform, without having to worry about the OS the application will eventually run on. It allows them to run end-to-end workflow without having to get into services they don’t understand. In other words, it helps them to obtain a clearer view of the entire stack fairly easily. Additionally, running Docker containers has no additional memory overhead, so multiple Docker containers running multiple services creates very low overhead.

Understanding the different parts of Docker will help us get a good overview of everything Docker is made of before we dive deeper into any of it. The Docker architecture is explained in detail in Chapter 4.

Why Should You Use Docker?

Docker provides application isolation with little overhead. By saving space with the low memory footprint, it has some powerful advantages.

Primarily, you can benefit from the extra layer of abstraction (in which code and its dependencies are packed together) offered by Docker. Another significant advantage is that you can have many more containers running on a single machine than you can with virtualization alone, owing to Docker’s lightweight nature.

Another significant advantage is that containers can be spun and shut down within seconds. The Docker FAQ has a good overview of what Docker adds to traditional containers.

Let’s look at some of the key uses.

Docker’s Key Use Cases

Here are some of the key use cases that Docker supports that promote consistency of environments.

Summary

In this chapter, you learned how Docker evolved, how it went from being an open source project in 2013 to acquiring unikernels to running natively on Windows. You saw what requirements of the software industry gave rise to the wide adoption of Docker. You also learned some basics of Docker and its components. We’ll dive deeper into this in future chapters.

Finally, you learned some of the key use cases of Docker, ranging from code pipeline management to faster deployments to increasing developer productivity. These are just some of the use cases of Docker that are widely applied across the software industry.

In the next chapter, you will learn about the differences between monoliths and microservices and when and why you use one vs. the other. You will see how to use Docker with microservices, as well.

Evolution of Microservices

Before we go into learning how microservices evolved, let’s first look into challenges presented by monoliths, because that is what contributed to the need for microservices architecture.

A monolith application is a single, self-contained software application in which all components of the application, including the user interface and the data access code, are all tightly coupled into a single program.

To mitigate all of these potential pitfalls, microservices architecture was born.

A microservices architecture is one in which a monolith is split into multiple smaller services that operate independently of each other but are interconnected. Each microservice is an independent service or an independent application. Different microservices in an application can be built on different software stacks and implement their own architecture. What’s more, in a microservices architecture, each microservice can additionally implement its own database schema, as required, instead of sharing a single database schema. It can also use a database that best suits its need. As a matter of fact, microservices should use their own databases and database schema; otherwise, the dependency on shared databases and schemas doesn’t really allow the services to be independent. Figure 3-1 shows two services using MySQL but different instances of it. The monolith is broken down into multiple services, each of which uses its own database.

Microservices have many advantages over monoliths. A microservice architecture deals with the complexity issue of a monolith, for which it helps in dividing a single application into multiple components. This makes understanding as well as maintaining the code base a lot easier. Because the services operate independently, they can be developed using a framework that best suits the need. This gives developers a lot of flexibility, as they are free to choose what works best. Different modules can be deployed independently of one another. Services can also be scaled, as required. Testing independent services becomes easier as well, owing to the modularity that comes with a microservices architecture.

Comparing Monoliths and Microservices

Challenges with Microservices

While microservices address many issues with monoliths, they introduce many other kinds of problems that present a challenge. With a microservices architecture, you are dealing with all challenges that come with a distributed system. For example, because services in a microservices architecture are interconnected, inter-service communication must occur, and for that, a single, reliable, and consistent communication channel must be established, for example, using HTTP.

Multiple services mean more management of those services. All of these must be independently managed for their health and maintenance. These services have to be frequently updated and upgraded to meet the newest versions of the dependencies they use.

Microservices might have their own logging mechanisms. This might result in lots of unstructured and potentially unmanaged data. Retrieving logs can become confusing with gigabytes of available logging data.

Finding the root cause of a failure in a certain workflow might be very tedious to debug. In order to debug an entire workflow, you might have to get multiple services up and running and then test them end to end, in order to know where the bug exists, because the logic is distributed, as is the data. There could also be cyclic dependencies between services, which can be very difficult to deal with while debugging the root cause of a failure.

Last, the most significant issues are those related to versioning. When more than one service depends on certain libraries or packages, but only different versions of those libraries, it becomes tricky to get these services up and running. How can you have two versions of the same dependency on your machine? If you can’t have that, how can you manage getting these services up and running, either in a production system or in your debugging environment?

For example, imagine a spellchecker application with three different microservices: service A, service B, and service C. When the user enters a word to check the spelling of, the request is sent to service A, which depends on JavaScript version 1.8.5, Python version 2.7, and Flask version 0.12.4. Service B takes the request from service A, checks the spelling against a dictionary, and sends it to service C. In order to get service B up and running, you need Flask version 0.10.3. Service C takes this spelling and writes it to a database for records. Service C depends on Python version 2.1.

As you see, getting service A and service B running on the same machine is practically impossible, because they both require a different version of Flask. Similarly, getting service A and service C running successfully on a single machine is also impossible, owing to the different versions of Python.

This is one of the most prevalent and widely seen problems in the software industry. A common solution might be to update your services to use the same version of a certain dependency. But in a complex application with thousands of microservices, this becomes extremely difficult to keep track of. So, what is a good solution here? Docker.

In the preceding example, if you isolate service A, service B, and service C in their own environment and let them run independently and, at the same time, enable inter-process communication between them, they would not conflict with one another. Docker enables exactly this!

In the next few chapters, I will delve into how exactly this problem can be solved with the help of Docker, in addition to the many other advantages of using Docker to solve related problems.

Summary

In this chapter, you saw how the microservices architecture was born and how it evolved. The many challenges that came with monolith services were solved by the microservices architecture.

You also saw the differences between a monolith and a microservices architecture. You saw how as an application grows in size and complexity, a monolith poses many problems, such as difficulties with continuous deployments, testing, scalability, startup, etc. These are elegantly solved by a microservices architecture.

Last, you saw that with a microservices architecture come all the challenges of a distributed system. You saw how getting multiple services up and running can be quite challenging, if they rely on different versions of the same dependencies. Application isolation comes in very handy here. And Docker can help us with that.

In the next chapter, I will get into the basics of Docker and explain the nitty-gritties, including related terminologies, its architecture, how to install Docker, and some basic commands to use to get started.

Terminology

Architecture

Before mastering Docker, let’s get into how it all works behind the scenes, to get a solid understanding of how it really works and how its different components interact with one another.

As you have seen in the previous chapters, some of the advantages of Docker are process- and application-level isolation, portability, and ease of deployment and testing. Many different components come into play to support these scenarios. So, let’s delve into the components one at a time.

Docker Engine

The Docker Engine is a client-server application. It consists of the following three parts, as shown in Figure 4-1.

1. 1.

   A server process, also known as a daemon process. This is a background process that is continuously running and constantly listening to the REST API interface for any commands to process.

    
2. 2.

   A REST API interface that programs can talk to, in order to communicate with the Docker daemon. This can be accessed by an HTTP client.

    
3. 3.

   A client that is a command-line interface (CLI).

    

The way to get anything done using Docker is through the Docker client, via the CLI or a script composed of commands. The client then communicates these commands, via the REST API, to the Docker daemon, which is the server. The Docker daemon then gets the job done. It creates such Docker objects as images, containers, volumes, etc.

Let’s look more extensively into Docker’s client-server architecture.

Docker Architecture

The Docker system mainly consists of the Docker client, daemon, and registry (Figure 4-2).

Docker Client

The Docker Client is the primary way in which most users interact with Docker. When you run commands using the CLI, these commands are then sent to the Docker daemon, using the Docker API interface. The Docker daemon or the dockerd then executes these commands and creates relevant Docker objects. The Docker client has the ability to communicate with multiple Docker daemons.

Docker Daemon

The Docker daemon is a server process that is persistent in nature and runs in the background. It continuously listens to the REST API interface and looks for any incoming requests to process commands. The daemon can listen to the API interface using different socket types, such as Unix, TCP (transmission control protocol), and FD (file descriptor) .

Docker Registries

The images created by the Docker daemon must be stored at a certain location, for ease of access. The Docker registry is this location. There are public registries, such as the Docker Hub, that can be used by anyone. By default, Docker looks for images on the Docker Hub, but this can be configured to use your private registry as well.

Commands such as Docker pull retrieve the required images from your configured registry and Docker push pushes the image to this same configured registry.

From a Docker store, you can buy, sell, or distribute images for free. You can then use these images to deploy an application in your test or production environment.

Let’s move forward a bit and look at the different objects of Docker that have been referenced multiple times in this book so far.

Installing Docker

For the purposes of this book, let’s look at how to install the Docker CE.

Docker CE is available for both the Mac and Windows OSs. It is also available to Amazon Web Services and Microsoft Azure.

Let’s look at how to install Docker CE on the Mac OS platform. There are some system requirements to meet before you can install Docker on your machine. You will need a Mac machine model that is at least from 2010 or later. In addition, you will need at least 4GB of RAM.

1. 1.
   Go to the Docker store at https://store.docker.com/editions/community/docker-ce-desktop-mac and click Get Docker, from the right-side pane, as seen in Figure 4-3.

   

    
2. 2.
   Once you have the dmg file on your machine, double-click it and drag Moby the whale to the Applications folder, as shown in Figure 4-4.

   

    
3. 3.

   In the Applications folder, double-click the Docker app, as seen in Figure 4-5.

    

Authorize Docker.app with your system password, after you launch it. You will need admin access to launch the different Docker components.

1. 4.
   The Moby whale on the status bar on the top, as shown in Figure 4-6, indicates that Docker is now running.

   

    
2. 5.

   If you have successfully installed the app, you will also see a pop-up with a success message, next steps, and tips, as shown in Figure 4-7.

    

To dismiss this pop-up, click the whale on the top status bar.

Now that we have Docker installed and running on our machines, let’s take a look at some basic Docker commands, so that you can play around and experiment with them.

Basic Docker Commands

Following are some basic Docker commands that you can start playing with.

Summary

In this chapter, we looked in detail at the Docker terminology that has been commonly used in the previous chapters of this book and that will continue to be used in future chapters.

We also examined the different components of the Docker architecture, including the Docker Engine, Docker Hub, Docker clients, Docker hosts, and Docker registries. We also saw how different Docker objects are created by the Docker daemon. We saw how Docker Hub can be used to pull existing Docker images and buy, sell, or distribute images for free.

Additionally, you saw how to install Docker on the Mac OS platform in detail.

We looked at some basic Docker commands, with sample usage and examples of each command, so that you can explore them further. We then walked through a simple end-to-end example of pulling the existing Hello World image and running it.

In the next chapter, I’ll go more into detail on how to build an image from a Dockerfile and run it inside a container.

Docker Images

As mentioned previously, Docker images are read-only and immutable and created with the docker image build command . They are stored inside a Docker registry and run inside a container. Images can become quite large very quickly. Therefore, they are designed to be composed of layers of other images, allowing a minimal amount of data to be sent when transferring images over a network. So, you can build your own customized image on top of an existing image. When you modify that image, new layers are added that contain your changes.

As for Docker containers, you’ll learn about them in more detail later in this chapter, but to summarize with a programming metaphor, if an image is a class, then a container is an instance of a class, that is, a runtime object. While images are lightweight and portable encapsulations of an environment, containers are the running instances of images.

Furthermore, a Docker image is created using a Dockerfile. Let’s see what a Dockerfile is. Later on, you’ll learn how to build a Docker image from a Dockerfile.

Dockerfile

Everything Docker begins with a Dockerfile. The Dockerfile is the instruction set on how to build an image. It the basis on which your entire Docker container is built. It specifies all the configuration settings environment variables, volumes to be mounted, the base image to build on top of, the list of dependencies, etc. All this is then bundled into an image that then runs inside the container.

A Dockerfile must be built to create the Docker image of an application. The image is just the “compiled version” of the source code that lives inside the Dockerfile. The Dockerfile is a text file that contains a set of instructions or commands that are then assembled into an image.

Creating a Sample Dockerfile

This command is set in such a way that whenever you run the image, the ENTRYPOINT command will be executed every time.

You can also pass arguments here, but they are optional. You can pass them when you run the image with something such as docker run <image-name>.

Save this file, and in the next section, you’ll see how to build an image from this Dockerfile.

Building Images with Dockerfile

As you’ve learned so far, Docker images are immutable, read-only file systems. Images can be based on other existing images that can be pulled from Dockerfile. This makes modifying them a lot easier, because the only thing that changes is the layer that gets modified. This also prevents images from becoming extremely large in size.

In the previous section, we created a Dockerfile called Dockerfile with some basic instructions and saved it in a directory called docker.

Let’s continue to build an image from the Dockerfile created in the previous section. From the docker directory, run the command docker image build. The . builds the Dockerfile within the directory.

When you run this command for the first time, you’ll see a long list of packages being pulled, because we’re building our image on top of the Ubuntu image.

I am going to divide the output in multiple sections, to make it easier to read. You should be able to see this entire output, if your image is built successfully.

In the next section, let’s run this image inside a container.

Docker Containers

Now that we have built a Docker image successfully, let’s look into what a Docker container is and run this image inside a container.

As we’ve seen before, Docker containers provide a different form of isolation than virtual machines (VMs). They are lightweight platforms to package your entire microservices application and have it running inside the container.

Let’s run inside a container the image we built successfully. There are multiple ways to run a Docker image inside a container.

You could use either or both to run the image inside a container.

Now let’s look inside the container. Your container has the ID 1c3e3baace92.

When inside the container, you can view logs, volumes that have been mounted, etc. Getting inside the Docker container very much comes in handy when debugging errors.

Attaching and Detaching from a Docker Container

Attaching to the Docker container means attaching the local standard input/output to the Docker container. Detaching means detaching your local input/output from the Docker container. Now you’ll learn how to attach to and detach from a Docker container.

In order to attach to the Docker container, first run the Docker image, and give it a name, say, “testdemo.”

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container run -d –-name testdemo ubuntu /usr/bin/tap -b easjhf7ejbadgsvkaid888sagdhabgfks555

kinnaryjangla@dev-abv:~/code/demo/docker$

Next, let’s attach our local terminal standard input/output to the container using docker container attach, as shown in Figure 5-1.

You should see that your terminal is now attached to the container’s input/output.

Let’s do another quick example, in which you can see the exit code of your container in your local terminal output.

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container run –name test -d -it ubuntu

easjhf7ejbadgsvkaid888sagdhabgfks555

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container attach test

root@ksjhdf6t3uqe: /# exit 13

exit

kinnaryjangla@dev-abc:~/code/demo/docker$ echo $?

13

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container ls -a | grep test

ksjhdf6t3uqe   ubuntu    "/bin/bash"    28 seconds ago    Exited(13) 15 seconds ago

In this example, we run the image inside a container and call it test. We then attach the container to the local standard input/output. From inside the container, we set an exit code of 13, which exits the container. On your local terminal, when you echo, you see 13 as the output. In your list of containers, you see that the container exited, owing due to the exit code 13.

You can also create a new container over a certain image. This is useful when you want to set up a container configuration beforehand.

To create a container over our Ubuntu image, let’s use docker container create -t -I ubuntu bash.

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container create -t -I ubuntu bash cee13y299o1hkjasd462e4jhdasi7673242hbd76gdewu

Then start this container, using the first few letters of the container ID that was created previously.

kinnaryjangla@dev-abc:~/code/demo/docker$ docker container start -a -i cee13y299

root@ cee13y299: /#

This lands you inside the newly created container.

You can do various things when you create a container, such as initializing volumes and even removing them using the -v option.

Now that we’ve looked at how to create Dockerfiles, how to build images with Dockerfiles, and how to run these images inside a container, in the next chapter, let’s look at how to link multiple containers,in order to get an entire microservices application up and running on Docker.

Summary

In this chapter, we looked at what a Dockerfile is and created a basic Dockerfile step by step. You learned that a Dockerfile is the first step to anything Docker.

Later, we built an image using this Dockerfile. We looked at how to list all the images on your host machine.

Later, we ran this image inside a container and looked at how to attach the container to our local terminal input/output. We executed a few examples and attached and detached the container to our local terminal. You also learned how to list all the containers that are up and running on your machine.

In the next chapter, we’ll look at how to link multiple containers, hence multiple services to each other, and create a real-world microservices application, using Docker.

What Is Docker Compose

In the previous chapters, you saw the advantages of running services on Docker containers. Some of the advantages are consistent environment variables, isolation of dependencies, and enabling continuous deployment of these services.

Today, most software applications are made of multiple services that talk to each other. In order to make such applications operational, you have to link several Docker containers to one another and have them all running simultaneously on Docker in production. Let’s see how we can link multiple Docker containers.

Docker Compose is the tool for running multi-container Docker applications. It’s essentially a YAML file that can be thought of as a composition of multiple Dockerfile containers running commands into a single file. This Docker compose YAML file contains configurations of multiple services. Then, using a single command, you can get all the services up and running simultaneously inside Docker containers.

You can also configure these services in such a way that they talk to each other.

Docker Compose can be used to create this microservices architecture and link the containers between them, or it can be used for a single service. In addition, Docker Compose can build images, scale containers, and rerun stopped containers. All this functionality is a part of Docker. docker-compose is just a higher-level abstraction of container run commands. You can do everything you can in a compose file with plain Docker commands, except that this requires more memory and takes extra effort to run all the extra commands, attaching to the network, etc. docker-compose helps to simplify this process.

In this example, the Docker Compose YAML file has configurations for two services, namely, myApp and Redis, wherein myApp is an application service and Redis is a database. Let’s look at what some of the fields in the YAML file represent. First, the Docker Compose YAML file tells Docker to build the images for the services—myApp and Redis. The build instruction asks to look for the file Dockerfile-dev in the folder myApp.

Instead of using the build key, you could specify the image. If you use image, specify the image name. This pulls up the specific image.

Next, the ports instruction indicates to map port 5001 on the host to the service1 docker containers port 8887.

The command instruction specifies the first command to run, in order to get the service up and running.

container_name is intuitive. It specifies the name of the Docker container in which myApp will run. This is used to identify which services run inside which Docker container. However, most compose files do not define the container name. Names must be unique. Once you specify a name, you have removed the ability to scale the number of replicas used for a service. When the docker-compose tool starts the container without a specified name, the generated name helps to identify the service.

The volumes instructions let you map certain files and folders on the host machine to the Docker container. For example, /home/{{USER}}/code/services/service1:/var/src/myApp says to map the folder code/services/service1 to the folder var/src/myApp on the Docker container. This command is very useful when debugging inside the Docker container, so that you can use the files that exist on the host machine.

The environment instruction basically configures the environment variables for the services.

The networks key lets you define a network that each service wants to connect to. You can also specify a default network that can be used for the entire app. If there is an existing network that you want the containers to join, you can employ the external option.

In addition to the instructions in the preceding sample Docker Compose YAML file, you could use deploy to specify the deployment specifications, such as the number of replicas, resources, CPU, and memory limits on these resources, restart policies, etc. The deploy key only applies when deploying to a Swarm. We’ll look at that in more detail in later chapters.

Next let’s see how to install Docker Compose on your machine.

Installing Docker Compose

Docker Compose relies on the Docker Engine, so before you install Compose, make sure you have Docker installed on your machine.

The Docker Desktop tool includes the docker-compose tool.

In order to get Docker for a Mac system, refer to the “Installing Docker” section in Chapter 4. For older machines, you can get the Docker Toolbox. Docker Toolbox helps you quickly set up and install the Docker environment on your Mac or Windows machine. Docker Toolbox includes docker-machine, docker, docker-compose, Docker GUIs, and Docker CLIs.

You can uninstall Docker Compose in two ways, unless you’ve installed the Docker Compose tool with Docker Desktop. In this case, you’ll have to uninstall Docker Desktop.

Usage

Let’s look at some basic Docker Compose commands.

Behind the Scenes and an Example

In the previous chapters, you saw how a single Dockerfile can be built into a single Docker image. Similar to that, a single Docker Compose YAML file can be built into a stack of images. This stack is also called a distributed application bundle (DAB).

Docker stacks and Docker bundles are features in Docker and Docker Compose.

The simplest way to create a Docker bundle is via Docker Compose. Using docker-compose bundle builds all the images of the services in the YAML file and creates a bundle. In order to deploy this bundle, you have to create a Docker stack. This can be done using docker deploy. You can manage this stack using the docker stack command.

Further, let’s work through a simple docker-compose example in which we will link two services.

In this example, redis refers to the Redis Docker container, and we use 6379, which is the default port for Redis.

Let’s look at what the instructions in this Dockerfile mean. The FROM instruction pulls the alpine image from the Docker registry and builds the image. Next, the ADD instruction says to add the current directory . into the /code directory in the image. The WORKDIR command sets the working directory in the container to /code. The RUN instruction installs the Python dependencies, namely, Flask and Redis, as defined in the requirements.txt file. The CMD instruction then sets the default command for the Docker container to python myapp.py.

So now that we have the Dockerfile for our service created, let’s start a Redis service that our app can talk to that pulls an existing Redis image from the Docker registry. In practice, this could be replaced by another similar service to that we created previously.

This is made up of two services, one of which is defined by us, called myapp, that is built by the Dockerfile in the current project directory. This configuration maps the port 5000 on the host machine to the port 5000 on the Docker container running this service. The other service is Redis, which pulls an existing Redis image from the default Docker Hub registry.

From your project directory, now run docker-compose up .

As you see from the preceding code, both services have started and are running.

Next, look at our browser. On your browser, navigate to http://0.0.0.0:5000/, to see your application running, as shown in Figure 6-1. The web app should now be listening to the port 5000 on your Docker daemon.

If you refresh the page, you should see the count increase from 1 to 2, as shown in Figure 6-2.

Now that you’ve seen a running example of docker-compose, let’s conclude this section.

Summary

In this chapter, we looked at Docker Compose and its uses. We saw that Docker containers running different services can be linked to one another using docker-compose.

You saw how to install and uninstall the docker-compose tool and different uses for docker-compose. Next, you saw how docker-compose creates container images and spins them. I walked you through a real-world example of Docker Compose. We created a Dockerfile for a service and a docker-compose file that links that service to a Redis image that we pulled from the Docker Hub registry. We went through how to build it and run the entire application. We looked at the browser, to see the application in action and then viewed the Docker containers running the two services that the application is composed of.

In the next chapter, I’ll go through a real-world example of how to debug a real-world application composed of microservices, using Docker.

Distributed Environments

What exactly is a distributed system? In the simplest terms, it is a group of individual computers working together and appearing to the external user as one system. These computers have shared state, concurrency behaviors, and failure handing properties, if implemented correctly.

Some of the obvious advantages of a distributed system are sharing, collaboration, scalability, reliability, and availability. The World Wide Web is a fantastic example of a distributed system.

Advantages of Distributed Systems