Início / unix / Perguntas / 534843
Accepted
mbigras
Asked: 2019-08-10 22:23:21 +0800 CST

Por que o comum está em um cgroup diferente quando o podman é iniciado com o systemd?

  • 772

Dado que o podman está instalado em um sistema linux e uma unidade systemd chamada 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

E o baz.service começou:

# systemctl daemon-reload
# systemctl start baz.service

Então, quando eu verifico o status da unidade, não vejo o shou sleepprocesso no cgroup /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
# ...

Eu esperava ver o shand sleepchildren no meu status baz.service porque ouvi pessoas da redhat dizerem que o podman usa um modelo tradicional de fork-exec.

Se podman fizesse fork e exec, então my she sleepprocess não seriam filhos de podman e estariam no mesmo cgroup que o processo podman original?

Eu esperava poder usar o systemd e o podman para poder gerenciar meus contêineres sem que os filhos fossem para um pai diferente e escapassem da minha unidade ssystemd baz.service.

Olhando para a saída de pseu posso ver isso she sleepna verdade são filhos de um processo diferente chamado conmon. Não tenho certeza de onde veio o conmon ou como foi iniciado, mas o systemd não o capturou.

# ps -Heo user,pid,ppid,comm
# ...
root     17254     1   podman
root     17331     1   conmon
root     17345 17331     sh
root     17380 17345       sleep

A partir da saída, fica claro que minha unidade baz.service não está gerenciando a cadeia conmon -> sh -> sleep.

  • Como o podman é diferente do modelo de servidor cliente do docker?
  • Como o conmon do podman é diferente do containerd do docker?

Talvez ambos sejam tempos de execução de contêiner e o dockerddaemon seja o que as pessoas querem se livrar.

Então, talvez o docker seja como:

  • daemon dockerd
  • docker cli
  • tempo de execução do contêiner containerd

E o podman é como:

  • podman cli
  • tempo de execução do contêiner comum

Então, talvez o podman use um modelo tradicional de fork exec, mas não é o podman cli que é bifurcação e exec, é o processo comum.

Eu me sinto confuso.

systemd docker

2 respostas

  1. Best Answer

    A ideia por trás disso podmané sair da arquitetura centralizada com o superpoderoso supervisor (por exemplo dockerd, ), onde o daemon centralizado é um ponto único de falha. Existe até uma hashtag sobre isso - " #nobigfatdaemons ".

    Como evitar o gerenciamento centralizado de contêineres? Você remove o daemon principal único (novamente, dockerd) e inicia os contêineres de forma independente (no final do dia, os contêineres são apenas processos, então você não precisa do daemon para gerá-los).

    No entanto, você ainda precisa do caminho para

    • recolher os logs do container - alguém tem que segurar stdoute stderrdo container;
    • coletar o código de saída do container - alguém precisa wait(2)no PID 1 do container;

    Para isso, cada contêiner podman ainda é supervisionado por um pequeno daemon, chamado conmon(de "monitor de contêiner"). A diferença com o daemon do Docker é que esse daemon é o menor possível (verifique o tamanho do código-fonte ) e é gerado por contêiner. Se conmonum contêiner travar, o restante do sistema não será afetado.

    Em seguida, como o contêiner é gerado?

    Considerando que o usuário pode querer executar o container em background, como no Docker, o podman runprocesso bifurca duas vezes e só então executa conmon:

    $ strace -fe trace=fork,vfork,clone,execve -qq podman run alpine
execve("/usr/bin/podman", ["podman", "run", "alpine"], 0x7ffeceb01518 /* 30 vars */) = 0
...
[pid  8480] clone(child_stack=0x7fac6bffeef0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[8484], tls=0x7fac6bfff700, child_tidptr=0x7fac6bfff9d0) = 8484
...
[pid  8484] clone(child_stack=NULL, flags=CLONE_VM|CLONE_VFORK|SIGCHLD <unfinished ...>
[pid  8491] execve("/usr/bin/conmon", ... <unfinished ...>
[pid  8484] <... clone resumed>)        = 8491

    O processo intermediário entre podman rune conmon(ou seja, o pai direto de conmon- no exemplo acima é o PID 8484) sairá e conmonserá reparentado por init, tornando-se assim um daemon autogerenciado. Depois disso, conmontambém bifurca o runtime (eg runc) e, finalmente, o runtime executa o entrypoint do container (eg /bin/sh).

    Quando o container está rodando, podman runnão é mais necessário e pode sair, mas no seu caso ele fica online, pois você não pediu para desanexar do container.

    Em seguida, podmanfaz uso de cgroups para limitar os contêineres. Isso significa que ele cria novos cgroups para novos contêineres e move os processos para lá . Pelas regras do cgroups, o processo pode ser membro de apenas um cgroup por vez, e adicionar o processo a algum cgroup o remove de outro cgroup (onde estava anteriormente) dentro da mesma hierarquia. Assim, quando o container é iniciado, o layout final dos cgroups se parece com o seguinte: podman runpermanece em cgroups do baz.service, criado por systemd, o conmonprocesso é colocado em seus próprios cgroups, e os processos em container são colocados em seus próprios cgroups:

    $ ps axf
<...>
 1660 ?        Ssl    0:01 /usr/bin/podman run --rm --tty --name baz alpine sh -c while true; do date; sleep 1; done
 1741 ?        Ssl    0:00 /usr/bin/conmon -s -c 2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6 <...>
 1753 pts/0    Ss+    0:02  \_ sh -c while true; do date; sleep 1; done
13043 pts/0    S+     0:00      \_ sleep 1
<...>

$ cd /sys/fs/cgroup/memory/machine.slice
$ ls -d1 libpod*
libpod-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope
libpod-conmon-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope

$ cat libpod-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope/cgroup.procs 
1753
13075

$ cat libpod-conmon-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope/cgroup.procs 
1741

    Nota: O PID 13075 acima é na verdade um sleep 1processo, gerado após a morte do PID 13043.

    Espero que isto ajude.

    • 12

  2. podman com --cgroups splitcriará os cgroups de uma maneira mais amigável ao sistema. (Semelhante a como o systemd-nspawn faria isso, com um cgroup de "serviço" e sub-cgroups para processos de supervisor e contêiner)

    Exemplo - meu contêiner rwhod:

     CGroup: /machine.slice/rwhod.service
         ├─container
         │ ├─ 998 /dev/init -- /container/tool/run
         │ ├─1040 /usr/bin/python3 -u /container/tool/run
         │ └─1706 /usr/sbin/rwhod -i mgmt0 -S -D
         └─supervisor
           └─995 /opt/podman/libexec/podman/conmon --api-version 1 -c ddf3e27960378fd57b2ebd15d7beb7474506f612e7329acb014c5f89cd652562 >

    Eu fiz parte da adição desse método ao podman especificamente para esse propósito, como parte desta discussão de log. https://github.com/containers/podman/issues/6400

    • 0

relate perguntas