Some problems encountered in the installation of docker by rpm and their solutions

Posted by EY on Fri, 08 May 2020 15:22:13 +0200

Today, I installed the docker environment for my colleagues in the R & D department on the domestic winning Kirin 7.4 operating system. Because of its special environment, I couldn't use the Internet repo source, so I only used the rpm package for the installation. Because it is the first time to use the rpm package for the installation of docker, so I leave a record here

1. Download docker and the dependent packages required for installation (because the successful source downloads too slowly and some packages do not exist, here I directly configure Alibaba yum source on centos7 to download)

#Download only the installation package without installation, and specify the download directory as / root/soft
yum install --downloadonly --downloaddir=/root/soft docker
 
#The version of docker in the yum source is older, so download the latest stable version from the official website, and delete the docker installation package and dockerclient downloaded from yum
https://mirrors.aliyun.com/docker-ce/linux/centos/7/x86_64/stable/Packages/
 
docker-ce-18.09.6-3.el7.x86_64.rpm ,containerd.io-1.2.5-3.1.el7.x86_64.rpm ,docker-ce-cli-18.09.6-3.el7.x86_64.rpm 

2. Dependency package required for rpm to install docker

atomic-registries-1.22.1-26.gitb507039.el7.centos.x86_64.rpm  
oci-register-machine-0-6.git2b44233.el7.x86_64.rpm
containerd.io-1.2.0-3.el7.x86_64.rpm                         
oci-systemd-hook-0.1.18-3.git8787307.el7_6.x86_64.rpm
containers-common-0.1.35-2.git404c5bd.el7.centos.x86_64.rpm   oci-umount-2.3.4-2.git87f9237.el7.x86_64.rpm
container-selinux-2.95-2.el7_6.noarch.rpm                     policycoreutils-2.5-29.el7_6.1.x86_64.rpm
container-storage-setup-0.11.0-2.git5eaf76c.el7.noarch.rpm    policycoreutils-python-2.5-29.el7_6.1.x86_64.rpm
docker-ce-18.09.0-3.el7.x86_64.rpm                            python-backports-1.0-8.el7.x86_64.rpm
docker-ce-cli-18.09.0-3.el7.x86_64.rpm                        python-backports-ssl_match_hostname-3.4.0.2-4.el7.noarch.rpm
libselinux-2.5-14.1.el7.x86_64.rpm                            python-pytoml-0.1.14-1.git7dea353.el7.noarch.rpm
libselinux-python-2.5-14.1.el7.x86_64.rpm                     python-setuptools-0.9.8-7.el7.noarch.rpm
libselinux-utils-2.5-14.1.el7.x86_64.rpm                      PyYAML-3.10-11.ns7.se.1.x86_64.rpm
libsemanage-2.5-14.el7.x86_64.rpm                             selinux-policy-3.13.1-229.el7_6.12.noarch.rpm
libsemanage-python-2.5-14.el7.x86_64.rpm                      selinux-policy-targeted-3.13.1-229.el7_6.12.noarch.rpm
libsepol-2.5-10.el7.x86_64.rpm                                setools-libs-3.3.8-4.el7.x86_64.rpm
libyaml-0.1.4-11.ns7.se.1.x86_64.rpm                          subscription-manager-rhsm-certificates-1.21.10-3.el7.centos.x86_64.rpm

3. After resolving the dependency package, use RPM - ivuh -- nodes *. Rpm for installation, which will not be covered here;

4. After the installation is completed, rpm -qa |grep docker queries the rpm package of docker that has been installed, but it is thrown incorrectly during startup and cannot be started. Use systemctl status docker -l to view the complete startup record and find the following errors:

5 15 / 16:12:50 db1 dockerd-current[25067]: time="2019-05-15T16:12:50.371094918+08:00" level=warning msg="overlay2: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior. Reformat the filesystem with ftype=1 to enable d_type support. Running without d_type support will no longer be supported in Docker 1.16."

The reason for the error is that the xfs file system does not support d Φ U type. The solution is to reformat the system to make ftype=1. The specific effect of D Φ U type on docker can be seen as follows:

The overlay storage driver of Docker uses many OverlayFS features to build and manage the disk structure of image and container. Since Docker 1.12, Docker also supports the overlay 2 storage driver. Compared with overlay, overlay 2 is more efficient in inode optimization. But the overlay 2 driver is only compatible with Linux kernel 4.0 and above.
Note: since overlayfs joined the kernel mainline, its name in the kernel module has been changed from overlayfs to overlay.
 
OverlayFS uses two directories, one on top of the other, and provides a single unified perspective to the outside world. These two directories are usually called layers, and this layered technology is called union mount. Technically, the lower directory is called lowerdir, and the upper directory is called upperdir. The unified view on display is called merged.
The following figure shows how the Docker image and Docker container are layered. The image layer is lowerdir, and the container layer is upperdir. The exposed unified view is called merged.
 
    When docker runs on the overlay/overlay2 storage driver, it needs the support of the d'u type feature to work normally. Docker 1.13 added this check later. You can run the docker info command to check whether the file system supports the d'u type feature.
 
   For details, please refer to: https://www.sudops.com/docker-xfs-filesystem-without-d'u type-support.html

5. Check whether the current file system supports d'u type

6, Modify the ftype value of the operating system to 1

Backup data; unload file system, rebuild system format; re mount, recover data;
 
umount /dev/mapper/nlas-root
 
mkfs.xfs -n ftype=1 /dev/mapper/nlas-root
 
mount /dev/mapper/nlas-root 
 
xfs_info  /

7. Just restart docker

Topics: Programming RPM Docker Python yum