Hands-On Docker for Microservices with Python

上QQ阅读APP看书，第一时间看更新

Docker containers

The microservice architecture is pretty agnostic about the platform that supports it. It can be deployed on old physical boxes in a dedicated data center, in a public cloud, or in containerized form.

There's a tendency, though, to use containers to deploy microservices. Containers are a packetized bundle of software that encapsulates everything that is required to run, including all dependencies. It only requires a compatible OS kernel to run autonomously.

Docker is the lead actor in containers for web applications. It has an extremely vibrant community supporting it as well as great tooling to work on all kinds of operations. We will learn how to work and operate using Docker.

The first time that I worked with Docker containers, they looked like a sort of light virtual machine to me; a small operative system that didn't require simulating the hardware to run. But after a while, I realized that's not the correct approach.

The best way to describe a container is to think of a process that's surrounded by its own filesystem. You run one process (or a few related ones), and they see a whole filesystem, not shared by anyone.

This makes containers extremely portable, as they are detached from the underlying hardware and the platform that runs them; they are very lightweight, as a minimal amount of data needs to be included, and they are secure, as the exposed attack surface of a container is extremely small. You don't need applications to manage them in the same way you do on a traditional server, such as an sshd server, or a configuration tool such as Puppet. They are specialized and designed to be small and single-purpose.

In particular, try to keep your containers small and single-purpose. If you end up adding several daemons and a lot of configuration, it's likely that you are trying to include too much; maybe you need to split it into several containers.

Working with Docker containers has two steps. First, we build the container, executing layer after layer of changes on the filesystem, such as adding the software and configuration files that will be executed. Then, we execute it, launching its main command. We will see exactly how to do this in Chapter 3, Dockerizing the Service.

The microservices architecture aligns very well with some of the characteristics of Docker containers—small, single-purpose elements that communicate through HTTP calls. That's why, even though it's not a hard requirement, they're typically presented together these days.

The Twelve-Factor App principles (https://12factor.net/), which are a collection of practices that have been proven successful in developing web applications, are also very aligned with Docker containers and with the microservice architecture. Some of the principles are extremely easy to follow with Docker, and we will comment on them in depth later in the book.

An important factor for dealing with containers is that containers should be stateless (Factor VI— https://12factor.net/processes). Any state needs to be stored in a database and each container stores no persistent data. This is one of the key elements for scalable web servers that, when dealing with a couple of servers, may not be done. Be sure to keep it in mind.

Another advantage of Docker is the availability of a lot of ready-to-use containers. Docker Hub (https://hub.docker.com/) is a public registry full of interesting containers to inherit or to use directly, either in development or production. This helps you to have examples for your own services, and to quickly create small services that require little configuration.