Arch Linux propose un paquet pour Docker. Après avoir fait quelques essais, je l'ai désinstallé, et voici le log de la réinstallation :
[root@kameha ~]# pacman -S docker resolving dependencies... looking for conflicting packages... Packages (4) bridge-utils-1.7.1-1 containerd-1.7.0-1 runc-1.1.5-1 docker-1:23.0.3-1 Total Installed Size: 233.36 MiB :: Proceed with installation? [Y/n] (4/4) checking keys in keyring [#################] 100% (4/4) checking package integrity [#################] 100% (4/4) loading package files [#################] 100% (4/4) checking for file conflicts [#################] 100% (4/4) checking available disk space [#################] 100% :: Processing package changes... (1/4) installing bridge-utils [#################] 100% (2/4) installing runc [#################] 100% Optional dependencies for runc criu: checkpoint support (3/4) installing containerd [#################] 100% (4/4) installing docker [#################] 100% Optional dependencies for docker btrfs-progs: btrfs backend support [installed] pigz: parallel gzip compressor support [installed] docker-scan: vulnerability scanner docker-buildx: extended build capabilities :: Running post-transaction hooks... (1/4) Creating system user accounts... (2/4) Reloading system manager configuration... (3/4) Reloading device manager configuration... (4/4) Arming ConditionNeedsUpdate...
La commande docker info
donne :
Client: Context: default Debug Mode: false Plugins: compose: Docker Compose (Docker Inc.) Version: 2.17.2 Path: /usr/lib/docker/cli-plugins/docker-compose Server: Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 0 Server Version: 23.0.3 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Using metacopy: true Native Overlay Diff: false userxattr: false Logging Driver: json-file Cgroup Driver: systemd Cgroup Version: 2 Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: io.containerd.runc.v2 runc Default Runtime: runc Init Binary: docker-init containerd version: 1fbd70374134b891f97ce19c70b6e50c7b9f4e0d.m runc version: init version: de40ad0 Security Options: seccomp Profile: builtin cgroupns Kernel Version: 6.1.23-1-lts Operating System: Arch Linux OSType: linux Architecture: x86_64 CPUs: 4 Total Memory: 15.62GiB Name: kameha ID: YIVP:IZSS:ZFSE:FYNX:6KNV:2AGU:FXVO:LPH5:42I5:FMO4:I4DP:FNG4 Docker Root Dir: /var/lib/docker Debug Mode: false Registry: https://index.docker.io/v1/ Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false
Le répertoire de données contient après installation :
[root@kameha ~]# du -ks /var/lib/docker/* 92 /var/lib/docker/buildkit 184 /var/lib/docker/containerd 4 /var/lib/docker/containers 4 /var/lib/docker/engine-id 132 /var/lib/docker/image 56 /var/lib/docker/network 8 /var/lib/docker/overlay2 16 /var/lib/docker/plugins 4 /var/lib/docker/runtimes 4 /var/lib/docker/swarm 4 /var/lib/docker/tmp 4 /var/lib/docker/trust 28 /var/lib/docker/volumes
Et il n'y a ni image ni conteneur :
[root@kameha ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE [root@kameha ~]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Je lance le test proposé par Arch Linux, un hello world dans une image Arch Linux :
[root@kameha ~]# docker run -it --rm archlinux bash -c "echo hello world" Unable to find image 'archlinux:latest' locally latest: Pulling from library/archlinux b99db29ebf06: Pull complete ee476ebdd029: Pull complete Digest: sha256:6199cf75da82918db13bbbeef7463e52f1f92b0533187f07632d3676276a64a0 Status: Downloaded newer image for archlinux:latest hello world
Ce qui donne ensuite :
[root@kameha ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE archlinux latest 1633d31b65fd 6 hours ago 420MB [root@kameha ~]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES [root@kameha ~]# du -ks /var/lib/docker/* 92 /var/lib/docker/buildkit 184 /var/lib/docker/containerd 4 /var/lib/docker/containers 4 /var/lib/docker/engine-id 992 /var/lib/docker/image 56 /var/lib/docker/network 441040 /var/lib/docker/overlay2 16 /var/lib/docker/plugins 4 /var/lib/docker/runtimes 4 /var/lib/docker/swarm 4 /var/lib/docker/tmp 4 /var/lib/docker/trust 28 /var/lib/docker/volumes
docker run
Note : La commande docker run
est succintement décrite par
docker help run
, et plus en détail par
Docker run reference | Docker Documentation.
Bien sûr, si je relance la commande
docker run -it --rm archlinux bash -c "echo hello world"
,
elle s'exécute en affichant uniquement le hello world
et l'occupation de la mémoire de masse n'augmente pas.
En lançant une commande qui prend plus de temps, comme
docker run -it --rm archlinux bash -c "echo Hello, world; sleep 60"
, je peux observer l'excécution
avec docker ps
:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6e6059ff52cc archlinux "bash -c 'echo Hello…" 4 seconds ago Up 2 seconds boring_cerf
et avec ps auxf
:
... root 35869 0.0 0.3 1353908 56096 ? Ssl avr11 0:05 /usr/bin/containerd root 35880 0.1 0.5 1538132 89252 ? Ssl avr11 0:15 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock root 44066 0.0 0.0 722440 13504 ? Sl 02:43 0:00 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 6e6059ff52cc5cf3ac97ea74f02721f8a7881e88481f70a8cf723d4a2030e659 -address /run/containerd/containerd.sock root 44086 0.0 0.0 3028 1708 pts/0 Ss+ 02:43 0:00 \_ sleep 60
13 jour plus tard, l'image est toujours présente et je peux relancer l'image directement :
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE archlinux latest 1633d31b65fd 13 days ago 420MB $ docker run -it --rm archlinux bash -c "echo hello world" hello world $
Dans les options utilisées, -it
est un classique qui signifie
--interactive --tty
. Comme je n'interagis pas avec le shell, ça
ne me semble pas utile, et la commande
docker run --rm archlinux bash -c "echo Hello, world"
donne le même résultat.
L'option --rm
m'apparaît plus mystérieuse :
elle provoque la suppression du système de fichier du conteneur à la fin de
son exécution. Voyons déjà ce système de fichier :
$ mount|grep docker overlay on /var/lib/docker/overlay2/c70a60a0db0c02083f314a4acc39bd48a93968a28c6059e86c974e3457a98706/merged type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/T5OW7MSDPVJAE3BBJZ2ZPEPYA4:/var/lib/docker/overlay2/l/7LKH7W3VRKJQ5F4JKRNG7NJ542:/var/lib/docker/overlay2/l/VI6EQUWABKRJEKDJTGZ4VJ34XR,upperdir=/var/lib/docker/overlay2/c70a60a0db0c02083f314a4acc39bd48a93968a28c6059e86c974e3457a98706/diff,workdir=/var/lib/docker/overlay2/c70a60a0db0c02083f314a4acc39bd48a93968a28c6059e86c974e3457a98706/work,index=off) nsfs on /run/docker/netns/fff997882f87 type nsfs (rw)
Il y a 2 systèmes de fichiers : overlay
et nsfs
.
Cependant, avec ou sans --rm
, ces systèmes de fichiers
disparaissent à la fin de la commande. Mauvaise piste... En revanche, la commande
docker ps -a
voit qqch :
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 9dc629ecbfb8 archlinux "bash -c 'echo hello…" 3 minutes ago Exited (0) 2 minutes ago sweet_noether ebe44c67eada archlinux "bash -c 'echo hello…" 3 minutes ago Exited (0) 3 minutes ago quirky_brown $
Même terminé, il reste possible de lire les logs d'un conteneur avec :
$ docker logs 9dc629ecbfb8 hello world $
Il est aussi possible d'inspecter le conteneur terminé, ce qui donne notamment des noms de fichiers :
$ docker inspect 9dc629ecbfb8 [ { "Id": "9dc629ecbfb81face3293b1b50ef00b49b88a2b5b2f51574e5b3c35ecbe5f23a", ... "Path": "bash", "Args": [ "-c", "echo hello world;sleep 10" ], ... "Image": "sha256:1633d31b65fd7cc20e3990a721222f2e32ac50a3f618c4f941de1682d23b23cf", "ResolvConfPath": "/var/lib/docker/containers/9dc629ecbfb81face3293b1b50ef00b49b88a2b5b2f51574e5b3c35ecbe5f23a/resolv.conf", "HostnamePath": "/var/lib/docker/containers/9dc629ecbfb81face3293b1b50ef00b49b88a2b5b2f51574e5b3c35ecbe5f23a/hostname", "HostsPath": "/var/lib/docker/containers/9dc629ecbfb81face3293b1b50ef00b49b88a2b5b2f51574e5b3c35ecbe5f23a/hosts", "LogPath": "/var/lib/docker/containers/9dc629ecbfb81face3293b1b50ef00b49b88a2b5b2f51574e5b3c35ecbe5f23a/9dc629ecbfb81face3293b1b50ef00b49b88a2b5b2f51574e5b3c35ecbe5f23a-json.log", ... "GraphDriver": { "Data": { "LowerDir": "/var/lib/docker/overlay2/82b6123af7e0f7fcc6d7883e140f88688c85dbd8843c136f9a7609dd2d79774a-init/diff:/var/lib/docker/overlay2/4c14d5a004ee9bdf3e4bef4519e06e93dbd42240118d14493f3e57edbcf0e581/diff:/var/lib/docker/overlay2/66dbfb22b14325f8e462a56aec99be16bf4b67e4e285035ea72224620d8bb8b7/diff", "MergedDir": "/var/lib/docker/overlay2/82b6123af7e0f7fcc6d7883e140f88688c85dbd8843c136f9a7609dd2d79774a/merged", "UpperDir": "/var/lib/docker/overlay2/82b6123af7e0f7fcc6d7883e140f88688c85dbd8843c136f9a7609dd2d79774a/diff", "WorkDir": "/var/lib/docker/overlay2/82b6123af7e0f7fcc6d7883e140f88688c85dbd8843c136f9a7609dd2d79774a/work" }, "Name": "overlay2" }, ...
Et je trouve des traces de tout cela dans le système de fichoer hôte :
$ du -hs /var/lib/docker/containers/* 40K /var/lib/docker/containers/9dc629ecbfb81face3293b1b50ef00b49b88a2b5b2f51574e5b3c35ecbe5f23a 40K /var/lib/docker/containers/ebe44c67eada2b758666eb5ec3ba92250482bb1bbb1cdef733620bb0a318a420 $ du -hs /var/lib/docker/overlay2/* 84K /var/lib/docker/overlay2/4c14d5a004ee9bdf3e4bef4519e06e93dbd42240118d14493f3e57edbcf0e581 431M /var/lib/docker/overlay2/66dbfb22b14325f8e462a56aec99be16bf4b67e4e285035ea72224620d8bb8b7 24K /var/lib/docker/overlay2/82b6123af7e0f7fcc6d7883e140f88688c85dbd8843c136f9a7609dd2d79774a 48K /var/lib/docker/overlay2/82b6123af7e0f7fcc6d7883e140f88688c85dbd8843c136f9a7609dd2d79774a-init 24K /var/lib/docker/overlay2/e3f902faa6a8a7d49f0f6845a7f04c4b46cae3399a8e738925f14f93c29100a9 48K /var/lib/docker/overlay2/e3f902faa6a8a7d49f0f6845a7f04c4b46cae3399a8e738925f14f93c29100a9-init 28K /var/lib/docker/overlay2/l $ ls -ltr /var/lib/docker/overlay2/ total 28 drwx--x--- 3 root root 4096 12 avr 00:53 66dbfb22b14325f8e462a56aec99be16bf4b67e4e285035ea72224620d8bb8b7 drwx--x--- 4 root root 4096 12 avr 00:53 4c14d5a004ee9bdf3e4bef4519e06e93dbd42240118d14493f3e57edbcf0e581 drwx--x--- 4 root root 4096 25 avr 02:50 e3f902faa6a8a7d49f0f6845a7f04c4b46cae3399a8e738925f14f93c29100a9-init drwx--x--- 4 root root 4096 25 avr 02:51 e3f902faa6a8a7d49f0f6845a7f04c4b46cae3399a8e738925f14f93c29100a9 drwx------ 2 root root 4096 25 avr 02:51 l drwx--x--- 4 root root 4096 25 avr 02:51 82b6123af7e0f7fcc6d7883e140f88688c85dbd8843c136f9a7609dd2d79774a-init drwx--x--- 4 root root 4096 25 avr 02:51 82b6123af7e0f7fcc6d7883e140f88688c85dbd8843c136f9a7609dd2d79774a $
© 2023 Marc Mongenet
Ce document est disponible selon les termes de la
Creative Commons Attribution 2.5 License.
Dernière mise à jour et
validation le 25 avril 2023.