Book Review: Docker Deep Dive

作者：Nigel Poulton
出版社：Amazon
发行时间：February 2018
来源：下载的 mobi 版本
Goodreads：4.46 (46 Ratings)
豆瓣：无

For a long time, the big web-scale players like Google have been using container technologies to address these shortcomings of the VM model.
In the container model the container is roughly analogous to the VM. The major difference through, is that every container does not require a full-blown OS. In fact, all containers on a single host share a single OS. This frees up huge amounts of system resources such as CPU, RAM, and storage. It also reduces potential licensing costs and reduces the overhead of OS patching and other maintenance. This results in savings on the cap-ex and op-ex fronts.

Modern containers started in the Linux world and are the product of an immense amount of work from a wide variety of people over a long period of time. Just as one example, Google Inc. has contributed many container-related technologies to the Linux kernel. Without these, and other contributions, we wouldn’t have modern containers today.

Interestingly, Docker, Inc. started its life as a platform as a service (PaaS) provider called dotCloud. Behind the scenes, the dotCloud platform leveraged Linux containers. To help them create and manage these containers they built an internal tool that they nick-named “Docker”. And that’s how Docker was born!
In 2013 the dotCloud PaaS business was struggling and the company needed a new lease of life. To help with this they hired Ben Golub as new CEO, rebranded the company as “Docker, Inc.”, got rid of the dotCloud PaaS platform, and started a new journey with a mission to bring Docker and containers to the world.

Most of the project and its tools are written in Golang - the relatively new system-level programming language from Google also known as Go. If you code in Go you’re in a great position to contribute to the project!

Despite this, the container ecosystem is flourishing with a healthy balance of co-operation and competition. You’ll often hear people use terms like co-opetition (a balance of co-operation and competition) and frenemy (a mix of a friend and an enemy) when talking about the container ecosystem. This is great! Healthy competition is the mother of innovation!

Images are made up of multiple layers that get stacked on top of each other and represented as a single object. Inside of the image is a cut-down operating system (OS) and all of the files and dependencies required to run an application. Because containers are intended to be fast and lightweight, images tend to be small.

Images are usually small
The whole purpose of a container is to run an application or service. This means that the image a container is created from must contain all OS and application files required to run the app/service. However, containers are all about being fast and lightweight. This means that the images they’re built from are usually small and stripped of all non-essential parts.
For example, Docker images do not ship with 6 different shells for you to choose from - they usually ship with a single minimalist shell, or no shell at all. They also don’t contain a kernel - all containers running on a Docker host share access to the host’s kernel. For these reasons, we sometimes say images contain just enough operating system (usually just OS-related files and filesystem objects).

The official Alpine Linux Docker image is about 4MB in size and is an extreme example of how small Docker images can be. That’s not a typo! It really is about 4 megabytes! However, a more typical example might be something like the official Ubuntu Docker image which is currently about 120MB. These are clearly stripped of most non-essential parts!

If you want to pull images from 3rd party registries (not Docker Hub), you need to prepend the repository name with the DNS name of the registry. For example, if the image in the example above was in the Google Container Registry (GCR) you’d need to add gcr.io before the repository name as follows - docker pull gcr.io/nigelpoulton/tu-demo:v2 (no such repository and image exists).

Sharing image layers
Multiple images can, and do, share layers. This leads to efficiencies in space and performance.manifest

If you look closely you’ll see that your shell prompt has changed and you’re now inside of the container. In the example above the shell prompt has changed to root@3027eb644874:/#. The long number after the @ is the first 12 characters of the container’s unique ID.