The First Docker Book (Revised Edition) - 1.2 Docker Components

Abstract: Docker can help users build and deploy containers. Users only need to package their own applications or services into containers. We just mentioned that the container is started based on the image, and one or more processes can run in the container. We can think of an image as the build or packaging phase of the Docker lifecycle, and a container as the startup or execution phase.

This book is excerpted from Chapter 1, Section 1.2 of the Asynchronous Community "The First Docker Book (Revised Edition)" by James Turnbull (Australia), more chapters You can visit the "Asynchronous Community" official account of Yunqi Community to view

1.2 Docker components
Let 's take a look at the core components of Docker:

Docker client and server, also known as Docker engine;
Docker image;
Registry;
Docker container.
1.2.1 Docker client and server
Docker is a client/server (C/S) architecture program. The Docker client just makes a request to the Docker server or daemon, and the server or daemon will do all the work and return the result. The Docker daemon is also sometimes called the Docker engine. Docker provides a command-line tool, docker, and a set of RESTful APIs [2] to interact with the daemon. Users can run the Docker daemon and client on the same host, or connect from a local Docker client to a remote Docker daemon running on another host. Figure 1-1 depicts the architecture of Docker.

screenshotFigure

1-1 Docker architecture

1.2.2 Docker image
Images are the building blocks of the Docker world. Users run their own containers based on the image. Images are also the "build" part of the Docker lifecycle. The image is a layered structure based on the Union file system, which is constructed step by step by a series of instructions. For example:

add a file;
execute a command;
open a port.
You can also think of an image as the "source code" of a container. Images are small, very "portable" and easy to share, store and update. In this book, we'll learn how to use an existing image, as well as try to build our own.

1.2.3 Registry
Docker uses Registry to store images built by users. Registry is divided into public and private. The public registry operated by Docker is called Docker Hub. Users can register an account[4] in Docker Hub[3], share and save their own images.

According to the latest count, there are more than 10,000 registered users building and sharing images on Docker Hub. Need a Docker image of the Nginx web server [5], or an image of the Asterix open source PABX system [6], or an image of the MySQL database [7]? These images are available on Docker Hub in various versions.

Users can also save their own private images on Docker Hub. For example, images that contain source code or patent information that need to be kept secret, or images that are only visible within a team or organization.

Users can even set up their own private registry. The specific method will be discussed in Chapter 4. Private Registry can be protected by a firewall, keeping images behind the firewall to meet the special needs of some organizations.

1.2.4 Containers
Docker can help users build and deploy containers. Users only need to package their own applications or services into containers. We just mentioned that the container is started based on the image, and one or more processes can run in the container. We can think of an image as the build or packaging phase of the Docker lifecycle, and a container as the startup or execution phase.

To sum up, a Docker container is:

an image format;
a set of standard operations;
an execution environment.
Docker borrows the concept of standard containers. Standard containers ship goods around the world, and Docker applies this model to its own design philosophy, with the only difference: Containers carry goods, and Docker ships software.

Each container contains a software image, which is the "cargo" of the container, and like the real cargo, the software image in the container can perform some operations. For example, images can be created, started, shut down, restarted, and destroyed.

Like containers, Docker doesn't care what's in the container when it performs the above operations, it doesn't matter if it's a web server, a database, or an application server. All containers "load" their content in the same way.

Docker also doesn't care where the user ships the container: users can build the container in their laptop, upload it to the Registry, download it to a physical or virtual server for testing, and deploy the container to a cluster of Amazon EC2 hosts go. Like standard containers, Docker containers are easy to replace, stackable, easy to distribute, and as versatile as possible.

Using Docker, you can quickly build an application server, a message bus, a suite of utilities, a continuous integration (CI) test environment, or any kind of application, service, or tool. A complete test environment can be built locally, or a complex application stack can be quickly replicated for production or development. It can be said that the application scenarios of Docker are quite extensive.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326223306&siteId=291194637