Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what is the relationship between Dockerfile, Docker images and containers". In daily operations, I believe many people have doubts about the relationship between Dockerfile, Docker images and containers. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts about "what is the relationship between Dockerfile, Docker images and containers". Next, please follow the editor to study!

The relationship between Dockerfile, Docker images, and Docker containers

Dockerfile is the raw material of the software, the Docker image is the deliverable of the software, and the Docker container can be thought of as the running state of the software. From the perspective of application software, Dockerfile, Docker image and Docker container represent three different stages of software respectively. Dockerfile is oriented to development, Docker image becomes the delivery standard, and Docker container involves deployment and operation and maintenance, all of which are indispensable and work together as the cornerstone of Docker system.

To put it simply, Dockerfile builds a Docker image and runs the Docker container through the Docker image.

We can deduce the relationship between the three from the perspective of Docker container. First of all, take a look at the following picture:

Let's assume that the image of this container is built from the following Dockerfile:

FROM ubuntu:14.04 ADD run.sh / VOLUME / data CMD [". / run.sh"] 1 Dockerfile and Docker images

First of all, let's take a look at the relationship between Dockerfile and Docker images in conjunction with the figure above.

FROM ubuntu:14.04: set the basic image. All the mirror layers of the basic image ubuntu:14.04 will be used. For simplicity, it is shown as a whole in the figure.

ADD run.sh /: add the file run.sh of the directory where the Dockerfile resides to the root directory of the image. In this case, the image of the new layer has only one item, that is, the run.sh under the root directory.

VOLUME / data: set the VOLUME of the image. The path of this VOLUME inside the container is / data. It is important to note that no file is added to the image of the new layer at this time, that is, the file in the constructed magnetosphere image is empty, but the mirrored json file is updated to obtain this information when the container is started through this image.

CMD [. / run.sh "]: sets the default execution entry of the image. This command also does not add any files to the new image, but only updates the json file of the new image based on the json file of the previous image.

Therefore, through the above analysis, the above Dockerfile can build a new image, including four mirror layers, each command will correspond to a mirror layer, and there will be a parent-child relationship between the images. These relationships are clearly shown in the picture.

2 the relationship between Docker image and Docker container

Docker image is the basis of Docker container operation. Without Docker image, there can be no Docker container, which is also one of the design principles of Docker.

It is understandable that the Docker image is a mirror image and belongs to static content, while the Docker container is different. The container belongs to dynamic content. Dynamic content, it is easy to think of processes, memory, CPU and so on. Indeed, Docker containers contain these as dynamic content.

In order to make it easier to understand, we can understand the Docker container as one or more running processes, and these running processes will occupy the corresponding memory, corresponding CPU computing resources, corresponding virtual network devices and corresponding file system resources. The file system resources occupied by the Docker container are provided by the mirror layer files mirrored by Docker.

So as a static mirror, how can it be transformed into a dynamic Docker container? At this point, we can imagine: first, what is the basis of the transformation; second, who will perform the transformation operation.

In fact, the conversion is based on the json file of each image. Docker can parse the json file of the Docker image to know what kind of process should run on this image and what kind of environment variables should be configured for the process. At this time, the transformation from static to dynamic is realized.

Who will carry out the transformation work? The answer is the Docker daemon. Perhaps you have long understood the saying that a Docker container is essentially one or more processes, and the parent process of the container is the Docker daemon. In this way, the implementation of the conversion work is not difficult to understand: the Docker daemon holds the json file of the Docker image, configures the corresponding environment for the container, and actually runs the process specified by the Docker image to complete the real creation of the Docker container.

After the Docker container is running, the Docker mirrored json file has no effect. At this time, most of the function of Docker image is to provide a file system perspective for the Docker container for processes inside the container to access file resources.

Going back to the image above, let's take a look at some special relationships between containers and images. First of all, it has been mentioned earlier that Docker images are managed hierarchically, and when managing Docker containers, Docker images are still managed hierarchically. Because the process already exists in the dynamic container, the process will read and write to the file from the perspective of the file system, so a question is involved: will the container tamper with the contents of the Docker image?

The answer is, of course, no. Generally speaking, as shown in the above figure, all Docker mirror layers are read-only to the container, and the container's write to the file will never act on the image.

In that case, the principle of implementation is very important: the Docker daemon will add a read / write layer on top of the Docker image, and all writes from the container will be applied to this layer. If the Docker container needs to write a file in the underlying Docker image, then a mechanism called Copy-on-Write is involved, that is, a federated file system such as aufs ensures that the file is first copied from the Docker image layer to the uppermost read-write layer, and then the container process manipulates the copy in the read-write layer. For the container process, it can only see the top-level files.

Finally, let's talk about: from the file system perspective of the Docker container, is there something that is not stored in the Docker image?

The answer this time is still yes.

Once again, static files are stored in the Docker image. In principle, these files should be completely decoupled from container specific information and host information. Then the contents of the Docker image that does not exist in the Docker container mainly include the following:

Contents of virtual file systems such as 1./proc and / sys

two。 Container hosts files, hostname files and resolv.conf files, which are environment-specific information, should not, in principle, be mirrored.

3. The Volume path of the container, which is viewed from the path mounted from the host machine to the inside of the container

4. Partial device files

At this point, the study on "what is the relationship between Dockerfile, Docker images and containers" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.