The concept of image

• The image can be understood as the container of the application, and the docker is used to load and unload the container.
• The docker image contains the file system and its contents required to start the container, so it is used to create and start the container.
• The docker image adopts a layered construction mechanism. The bottom layer is bootfs and the top layer is rootfs
• bootfs: the file system used for system boot, including bootloader and kernel. After the container is started, it will be unloaded to save memory resources
• rootfs: located above bootfs and represented as the root file system of the docker container
• In the traditional mode, when the system starts, the kernel will mount rootfs to the "read-only" mode first, and then re mount it to the read-write mode after the integrity self-test is completed
• In docker, rootfs is mounted in the "read-only" mode by the kernel, and then an additional "writable" layer is mounted through the "joint mount" technology
  Note: when a container is deleted, its own "writable" layers will be deleted together
  

docker mirror layer

• The image at the lower level is called a parent image, and the image at the lowest level is called a base image; The top layer is the "read-write" layer, and the lower layer is the "read-only" layer

docker storage driver

docker provides a variety of storage drivers to store images in different ways. The following are common storage drivers:

• AUFS
• OverlayFS
• Devicemapper
• Btrfs
• VFS

AUFS
AUFS (another Union FS) is a Union FS, which is a file level storage driver. AUFS is a layered file system that can transparently cover one or more existing file systems, merging multiple layers into a single-layer representation of the file system. Simply put, it supports mounting different directories to the file system under the same virtual file system. This file system can overlay and modify files layer by layer. No matter how many layers below are read-only, only the top file system is writable. When a file needs to be modified, AUFS creates a copy of the file, uses CoW to copy the file from the read-only layer to the writable layer for modification, and the results are also saved in the writable layer. In Docker, the lower read-only layer is image, and the writable layer is Container.

It is said that the AUFS file system has 3W lines of code, while the ext4 file system has only about 4000-5000 lines of code. These codes are to be integrated into the kernel. Later, when the AUFS application is to be incorporated into the kernel code, linuz thought the code is too bloated, so he refused. Therefore, the AUFS file system has not been the file system of the linux kernel for a long time. If you want to use the AUFS file system, you must patch the kernel and compile and use it. However, the redhat series operating system has always been known for its stability and will not do such extraordinary things. Therefore, it is impossible to use AUFS in the redhat series operating system. The docker on ubuntu uses AUFS by default.

OverlayFS
Overlay is supported by Linux kernel after 3.18. It is also a kind of Union FS. Unlike AUFS, overlay has only two layers: an upper file system and a lower file system, representing the image layer and Container layer of Docker respectively. When a file needs to be modified, use CoW to copy the file from the read-only lower to the writable upper for modification, and the results are also saved in the upper layer. In Docker, the lower read-only layer is image, and the writable layer is Container. At present, the latest overlay FS is overlay 2.

Both AUFS and Overlay are federated file systems, but AUFS has multiple layers, while Overlay has only two layers. Therefore, when copying on write, if the file is large and there are lower layers, AUSF will be slower. Moreover, Overlay is incorporated into the linux kernel mainline, but AUFS does not. At present, AUFS has been basically eliminated.

DeviceMapper
Device mapper is supported by Linux kernel after 2.6.9. It provides a mapping framework mechanism from logical devices to physical devices. Under this mechanism, users can easily formulate and implement storage resource management strategies according to their own needs. Both AUFS and OverlayFS are file level storage, while device mapper is block level storage. All operations are direct operations on blocks, not files. The device mapper driver will first create a resource pool on the block device, and then create a basic device with a file system on the resource pool. All images are snapshots of the basic device, and the container is a snapshot of the image. Therefore, the file system in the container is a snapshot of the file system of the basic device in the resource pool, and no space is allocated for the container. When a new file is to be written, a new block is allocated in the container's image and data is written. This is called time allocation. When you want to modify an existing file, use CoW to allocate block space for the container snapshot, copy the data to be modified to a new block in the container snapshot, and then modify it.

OverlayFS is a file level storage and device mapper is a block level storage. When a file is very large and the modified content is very small, Overlay will copy the whole file regardless of the modified content size. Obviously, modifying a large file takes more time than a small file, while block level only copies the blocks that need to be modified, not the whole file, In this scenario, device mapper is obviously faster. Because the block level directly accesses the logical disk, it is suitable for IO intensive scenarios. The performance of Overlay is relatively stronger in the scenario of complex internal program, large concurrency but less io.

docker registry
When the container is started, the docker daemon will attempt to obtain the relevant image locally. When the local image does not exist, it will download the image from the Registry and save it locally.

Registry is used to save the docker image, including the hierarchy and metadata of the image. Users can create their own registry or use the official Docker Hub.

Classification of docker registry:

Sponsor Registry: a third-party Registry for customers and Docker communities
Mirror Registry: a third-party Registry for customers only
Vendor Registry: the registry provided by the vendor that publishes the docker image
Private Registry: a registry provided by private entities with firewalls and additional security layers
Composition of docker registry:

Repository
An image repository consisting of all iterative versions of a particular docker image
Multiple repositories can exist in a Registry
Repository can be divided into "top-level warehouse" and "user warehouse"
The format of user warehouse name is "user name / warehouse name"
Each warehouse can contain multiple tags, and each tag corresponds to a mirror image
Index
Maintain user accounts, verification of images, and public namespace information
It is equivalent to providing a retrieval interface for Registry to complete user authentication and other functions
Images in Docker Registry are usually created by developers, and then pushed to "public" or "private" Registry for saving for other people's use, such as "deployment" to production environment.

Making docker image

• Download centos system image for modification

[root@docker ~]# docker pull centos

Start the container using the image and enter the container
[root@docker ~]# docker run -it --name centos.nginx centos /bin/bash

install epel Source and nginx
[root@24dead280154 /]# yum install epel-release -y
[root@24dead280154 /]# yum install nginx -y

• Configure nginx as foreground startup mode

[root@24dead280154 /]# vi /etc/nginx/nginx.conf
 write in:
daemon off;
Save exit

• Make image

[root@docker ~]# docker commit -p centos.nginx
sha256:88e857ac741716e8f8a7ac2cd55f8fbeb2cb4b4eb910339350b317ee31db2c15

View container:
[root@docker ~]# docker ps -a
CONTAINER ID   IMAGE     COMMAND              CREATED          STATUS                         PORTS     NAMES
24dead280154   centos    "/bin/bash"          9 minutes ago    Up 9 minutes                             centos.nginx
5f95cb8e5ee2   centos    "/bin/bash"          11 minutes ago   Exited (0) 11 minutes ago                centos
6f1881da8c86   httpd     "httpd-foreground"   6 hours ago      Exited (0) About an hour ago             httpd

[root@docker ~]# docker images
REPOSITORY   TAG       IMAGE ID       CREATED              SIZE
<none>       <none>    88e857ac7417   About a minute ago   345MB
httpd        latest    73b8cfec1155   6 days ago           138MB
centos       latest    300e315adb2f   7 months ago         209MB
[root@docker ~]# docker tag 88e857ac7417 xialuo/nginx:v0.1
[root@docker ~]# docker images
REPOSITORY     TAG       IMAGE ID       CREATED              SIZE
xialuo/nginx   v0.1      88e857ac7417   About a minute ago   345MB
httpd          latest    73b8cfec1155   6 days ago           138MB
centos         latest    300e315adb2f   7 months ago         209MB

Upload warehouse
[root@docker ~]# docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: xialuo
Password: 
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
[root@docker ~]# docker push xialuo/nginx:v0.1
The push refers to repository [docker.io/xialuo/nginx]
44fba6e4cc73: Pushed 
2653d992f4ef: Mounted from library/centos 
v0.1: digest: sha256:5d9d1d227776b23458c5f3a4c01bd373ebd38a6a31c96f6daae30c83d83ebebb size: 741