Author: Lao Duan studio
Transferred from: http://www.rhce.cc/2868.html
When we use docker to create containers, docker finally completes container management through runc.
[root@vms101 c1]# docker info Client: ...Mass output... Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc Default Runtime: runc ...Mass output... [root@vms101 c1]#
From here, we can see that docker uses runc as runtime by default. So what is runtime?
The so-called runtime is simply something that can manage containers, which is called runtime. docker is runtime, runc is runtime, podman is runtime, and lxc is runtime.
But just now, what does it mean that docker uses runc as the default runtime by default? Two concepts are involved here: low level runtime and high level runtime.
The so-called low-level runtime refers to a single management container without the ability to manage storage and image. For example, runc, lxc, gVisor, kata, etc. all belong to low-level runtime.
High level runtime can manage not only containers, but also storage, images, etc. When managing containers, you need to call low-level runtime to realize container management. For example, docker, podman and containerd all belong to high-level runtime.
docker uses runc as the runtime by default. If you want to use other low-level runtime, you need to add -- runtime when creating the container to specify which low-level runtime to use (provided that the corresponding runtime is installed), as shown in the following figure:
This section demonstrates how runc manages containers.
Because runc does not have the ability of image management, first download the busybox image with docker.
Step 1: download the image busybox
[root@vms101 ~]# docker pull busybox Using default tag: latest latest: Pulling from library/busybox e5d9363303dd: Pull complete Digest: sha256:c5439d7d...1d7596d2126dfb5b02bfd1f Status: Downloaded newer image for busybox:latest docker.io/library/busybox:latest [root@vms101 ~]#
Step 2: create a container with docker
[root@vms101 ~]# docker run -dit --name=c1 busybox c769a24823abb2271f78...552176d21f44e02397df0 [root@vms101 ~]#
Step 3: export the container to C1 tar
[root@vms101 ~]# docker export c1 > c1.tar [root@vms101 ~]# ls anaconda-ks.cfg c1.tar [root@vms101 ~]
This file C1 Tar contains all the data needed to run a container. With this data, runc can create a container.
Step 4: create a directory / c1/rootfs
[root@vms101 ~]# mkdir -p /c1/rootfs [root@vms101 ~]#
Note that the / c1 name here can be named at will. Rootfs is the default name. If rootfs is any other name, it needs to be generated in the subsequent config Specified in JSON.
Step 5: put C1 Unpack tar into / c1/rootfs
[root@vms101 ~]# tar xf c1.tar -C /c1/rootfs [root@vms101 ~]# ls /c1/rootfs bin dev etc home proc root sys tmp usr var [root@vms101 ~]#
For testing convenience, create AA in / c1/rootfs / txt
[root@vms101 ~]# touch /c1/rootfs/aa.txt [root@vms101 ~]# ls /c1/rootfs/ aa.txt bin dev etc home proc root sys tmp usr var [root@vms101 ~]#
Step 6: generate config. For the runc creation file JSON file
[root@vms101 ~]# cd /c1/ [root@vms101 c1]# ls rootfs [root@vms101 c1]# runc spec [root@vms101 c1]# ls config.json rootfs [root@vms101 c1]#
Modify config JSON content
1 { 2 "ociVersion": "1.0.2-dev", 3 "process": { 4 "terminal": false, 5 "user": { 6 "uid": 0, 7 "gid": 0 8 },
Change line 4 from terminal: true to terminal: false.
53 "root": { 54 "path": "rootfs", 55 "readonly": true
The path in line 53 sets rootfs, and the name of rootfs in / c1/rootfs created earlier is defined here.
Step 7: create a container using runc
[root@vms101 c1]# runc create c1 [root@vms101 c1]# runc list ID PID STATUS BUNDLE CREATED OWNER c1 2741 created /c1 2021-02-13T03:13:32.724746332Z root [root@vms101 c1]#
Step 8: enter the container
[root@vms101 c1]# runc exec -t c1 /bin/sh / # / # ls / aa.txt bin dev etc home proc root sys tmp usr var / # exit [root@vms101 c1]#
Step 9: delete container
[root@vms101 c1]# runc delete c1 [root@vms101 c1]# runc list ID PID STATUS BUNDLE CREATED OWNER [root@vms101 c1]#