Two approaches to Docker image construction

About the main concepts in Docker

Here is an inappropriate analogy to illustrate.

I'm sure you've installed an ghost system. The image is like an ghost file, and the container is like an ghost system. You can install the system from someone else's ghost file (run the container with a mirror) or build your own ghost file (build the mirror from the container). Dockerfile is like a script (mirror build script) that generates ghost files, specifying where to download which version of window system, which software to download and install, which configuration files to modify, and so on. This article focuses on how to build images from containers (making ghost files from existing systems) and how to build images using Dockerfile (generating ghost files using scripts).

There are two main steps to building an image:

1. Build image from container (hereinafter referred to as container image)
Create 1 container, such as an ES26en-ES27en container using the tomcat:latest image
Modify the file system of the ES29en-ES30en container, such as changing the default port in tomcat's ES32en. xml file
Commit the image using the commit command

2. Use Dockerfile to build image (hereinafter referred to as Dockerfile image)
Write the Dockerfile file
Build the image using the build command

Differences between the two construction methods:

1. The builder of the container image can modify the file system of the container and publish it at will. Such modification is not transparent to the mirror user, and every step of the modification to the container file system will not be recorded in the document for the reference of the mirror user.

2. Container images cannot (or more precisely, are not recommended) be modified to generate new container images.
Running the container from the mirror actually adds a writable layer to the top of the mirror, where all changes to the container file system are made without affecting the existing layer. For example, delete a 1G file in the container. From the user's point of view, the file is no longer in the container, but from the file system point of view, the file is still there, but it is marked as deleted at the top level, and of course the file marked as deleted takes up mirror space. Building an image from a container actually solidifies the top layer of the container into the image.
In other words, after modifying the container image, a new container image will be generated, with an additional layer, and the volume will only increase, not decrease. Over time, the mirror image will get fatter and fatter. The export and import commands provided by Docker can handle this to some extent, but they are not without drawbacks.

3. The container image must be rebuilt when the dependent parent image changes. There is no value in having to reinvent the container's file system and build it manually without writing an automated build script.

4. Dockerfile image is completely transparent, and all instructions used to build the image can be seen through Dockerfile. You can even recursively find the build instructions for any parent image of this mirror. In other words, you can fully understand how a mirror is built from scratch using the 1 point instruction.

5. When Dockerfile image needs to be modified, it can be rebuilt and generated by modifying the instructions in Dockerfile without any problems.

6, Dockerfile can be hosted on GitHub and other source management websites, DockerHub automatically associated source code for building. When your Dockerfile changes, or the dependent parent image changes, it triggers the automatic build of the image, which is very convenient.
Both officially and personally, I recommend the second method of building images.

As for the detailed instructions in Dockerfile, it is not listed here in 11, you can refer to the official documents, or pay attention to my later articles, of course, the Internet is also 1 search 1 pile.