docker basics 3 - making images (based on containers)

1. Basic understanding

• The image can be understood as the container of the application, and 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 the image is used to create and start the container.

1.1 Mirror structure

1. The docker image adopts a layered construction mechanism, with bootfs at the bottom and rootfs above it.
   • bootfs: The file system used for system boot, including bootloader and kernel. After the container is started, it will be uninstalled to save memory resources.
   • rootfs: Located above bootfs, it appears as the root file system of the docker container.
2. In traditional mode, when the system starts, the kernel mounts rootfs and first mounts it in "read-only" mode. After the integrity self-check is completed, it remounts it in read-write mode.
3. In docker, rootfs is mounted in "read-only" mode by the kernel, and then an additional "writable" layer is mounted through "joint mounting" technology.
4. When a container is deleted, the container's own "writable" layer will be deleted together.
   

docker image layer:

• The image located at the lower level is called the parent image (parent image), and the bottom image is called the base image (base image).
• The top layer is the "read-write" layer, and everything below it is the "read-only" layer.
  

1.2 docker storage driver

• Docker provides a variety of storage drivers to store images in different ways, such as AUFS, OverlayFS, Devicemapper, Btrfs, and VFS.
• OverlayFS is file-level storage, and Device mapper is block-level storage. Block-level storage directly accesses logical disks and is suitable for IO-intensive scenarios. For scenarios with complex internal programs and large concurrency but low IO, Overlay's performance is relatively stronger.

1.2.1 EDITION

1. AUFS (AnotherUnionFS) is a Union FS, a file-level storage driver, a layered file system that can transparently cover one or more existing file systems, and merges multiple layers into a single-layer representation of the file system.
2. This kind of file system can superimpose and modify files layer by layer. Only the uppermost file system can be written, and the lower layers are all read-only.
3. When a file needs to be modified, AUFS creates a copy of the file, CoW copies the file from the read-only layer to the writable layer for modification, and the results are also saved in the writable layer.
4. In Docker, the underlying read-only layer is image and the writable layer is Container.
5. It has been basically eliminated.

1.2.2 OverlayFS

1. Overlay is supported by the Linux kernel after 3.18 and is also a Union FS. Different from the multi-layer AUFS, Overlay has only two layers: an upper file system and a lower file system, representing Docker's image layer and container layer respectively.
2. When a file needs to be modified, CoW copies the file from the read-only lower to the writable upper for modification, and the result is also saved in the upper layer.
3. In Docker, the read-only layer underneath is image, the writable layer is Container, and the latest OverlayFS is Overlay2.

1.2.3 DeviceMapper

1. Device mapper is supported by the Linux kernel after 2.6.9. It provides a mapping framework mechanism from logical devices to physical devices. It is block-level storage. All operations are performed directly on blocks, not files.
2. 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 this basic device, and containers are snapshots of the image. Therefore, the file system seen in the container is a snapshot of the file system of the basic device on the resource pool, and no space is allocated for the container.
3. When a new file is written, new blocks are allocated for it in the container's image and data is written. This is called on-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 the new block in the container snapshot, and then modify it.

1.3 Mirror warehouse

1. When starting a container, the docker daemon process will try to obtain the relevant image locally from the server. If the local image does not exist, it will download the image from the Registry and save it locally.
2. Registry is used to save docker images, including the image hierarchy and metadata. Users can build their own Registry or use the official Docker Hub.
   

docker registry classification:

1. Sponsor Registry: A third-party registry for use by customers and the Docker community.
2. Mirror Registry: A third-party Registry that is only used by customers.
3. Vendor Registry: A registry provided by the vendor that publishes docker images.
4. Private Registry: A registry provided through a private entity with firewalls and additional layers of security

Docker registry consists of:

1. Repository：
   • A mirror warehouse composed of all iterative versions of a specific docker image.
   • Multiple Repositories can exist in a Registry.
   • Repository can be divided into "top-level warehouse" and "user warehouse". The top-level warehouse is based on each official release and is recommended to be used.
   • The format of the user warehouse name is "user name/warehouse name".
   • Each warehouse can contain multiple tags, and each tag corresponds to an image.
2. Index：
   • Maintain user accounts, image verification, and public namespace information.
   • It is equivalent to providing a retrieval interface for the Registry to complete user authentication and other functions.

2. Mirror production

How to generate the image:

1. Dockerfile。
2. Made based on containers.
3. Docker Hub automated builds
   

Production of docker image:

1. In most cases, the mirroring we make is based on a certain basic image that others already have. We call it a base image. For example, a pure version of minimized centos, ubuntu or debian.
2. Pull image command, image warehouse address + warehouse name + image name + image version

   docker pull <registry>[:<port>]/[<namespace>/]<name>:<tag>
   

2.1 Making images based on containers

• The docker commit command is to modify an existing image to generate a new image.
• Command format:

  docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]
  

parameter	Definition
-a	The submitted mirror author.
-c	Use Dockerfile instructions to create images.
-m	Description text when submitting.
-p	When committing, pause the container.

1. Pull a system image as the base image and create a temporary running container qingjun.

docker run --name qingjun -it --rm busybox /bin/sh

2. Save the container qingjun as a new image and specify the new image repository name + version.

docker commit -p qingjun  baimu:v1

3. Create a repository in the remote warehouse, and the name needs to be consistent with the name of the new image.


4. Log in to the docker remote warehouse locally. It can be the official docker hub warehouse, or it can be a private warehouse built by yourself.

5. Push the image.

//给镜像打标签，标签需要与远程仓库对应。
docker tag baimu:v1 baimuqingjun/baimu:v1

//推送镜像。
docker push baimuqingjun/baimu:v1

6. Check the push results in the docker hub warehouse.

7. Delete the original local image, pull the image just pushed, and create a temporary container to make a second image.

//删除本地v1镜像。
docker rmi baimuqingjun/baimu:v1


//拉取v1镜像启动容器。
docker run --name qingjun -it --rm baimuqingjun/baimu:v1 /bin/sh
/ # cd /data/
/data # rm -f text 
/data # echo 'haha' > index.html


//使用dockerfile命令制作v2镜像。
//-c指定运行httpd服务，-f前台运行，-h指定网站目录。
docker commit  -c 'CMD ["/bin/httpd","-f","-h","/data"]' -p qingjun baimuqingjun:v2
docker tag baimuqingjun:v2 baimuqingjun/baimu:v2 
docker push baimuqingjun/baimu:v2

8. Run the container using the v2 image and obtain the container IP.

//-d指定容器后台运行，需要有个前台进程，这里指定睡眠时间。
docker run --name qingjun  baimuqingjun/baimu:v2 

3. Image import and export

1. Package the image on the first machine and transfer the image package to the second machine.

docker save -o baimu_v2.image.gz baimuqingjun/baimu:v2

2. Import the image package on the second machine.

docker load -i baimu_v2.image.gz