Étant donné que podman est installé sur un système linux et une unité systemd nommée baz.service:
# /etc/systemd/system/baz.service
[Service]
ExecStart=/usr/bin/podman run --rm --tty --name baz alpine sh -c 'while true; do date; sleep 1; done'
ExecStop=/usr/bin/podman stop baz
Et le baz.service a commencé:
# systemctl daemon-reload
# systemctl start baz.service
Ensuite, lorsque je vérifie l'état de l'unité, je ne vois pas le processus sh
ou sleep
dans le groupe de contrôle /system.slice/baz.service
# systemctl status baz
● baz.service
Loaded: loaded (/etc/systemd/system/baz.service; static; vendor preset: enabl
Active: active (running) since Sat 2019-08-10 05:50:18 UTC; 14s ago
Main PID: 16910 (podman)
Tasks: 9
Memory: 7.3M
CPU: 68ms
CGroup: /system.slice/baz.service
└─16910 /usr/bin/podman run --rm --tty --name baz alpine sh -c while
# ...
Je m'attendais à voir le sh
et les sleep
enfants dans mon statut baz.service parce que j'ai entendu des gens de redhat dire que podman utilise un modèle traditionnel de fork-exec.
Si podman a fait fork et exec, alors mon processus sh
et ne seraient-ils pas des sleep
enfants de podman et seraient-ils dans le même groupe de contrôle que le processus podman d'origine?
Je m'attendais à pouvoir utiliser systemd et podman pour pouvoir gérer mes conteneurs sans que les enfants partent vers un parent différent et s'échappent de mon unité baz.service ssystemd.
En regardant la sortie de ps
je peux voir cela sh
et sleep
sont en fait des enfants d'un processus différent appelé conmon
. Je ne sais pas d'où vient Conmon, ni comment il a été démarré, mais SystemD ne l'a pas capturé.
# ps -Heo user,pid,ppid,comm
# ...
root 17254 1 podman
root 17331 1 conmon
root 17345 17331 sh
root 17380 17345 sleep
D'après la sortie, il est clair que mon unité baz.service ne gère pas la chaîne conmon -> sh -> sleep.
- En quoi podman est-il différent du modèle de serveur client docker?
- En quoi le conmon de podman est-il différent du containerd de docker?
Peut-être sont-ils tous deux des runtimes de conteneurs et le dockerd
démon est ce dont les gens veulent se débarrasser.
Alors peut-être que docker est comme:
- démon dockerd
- docker cli
- exécution du conteneur containerd
Et podman est comme:
- podman cli
- exécution du conteneur conmon
Donc peut-être que podman utilise un modèle traditionnel de fork fork, mais ce n'est pas le podman cli qui forge et exécute, c'est le processus conmon.
Je suis confus.