Como são os processos dentro de um contêiner do Docker?

Recentemente, ouvi confusão surgir várias vezes sobre o que é um contêiner do Docker e, mais especificamente, o que está acontecendo lá dentro, com relação aos comandos e processos que invoco enquanto estou dentro de um contêiner do Docker.

Alguém pode fornecer uma visão geral de alto nível do que está acontecendo?

O Docker é jogado no balde de virtualização, porque as pessoas assumem que de alguma forma está virtualizando o hardware por baixo. Esse é um nome impróprio que permeia a terminologia que o Docker utiliza, principalmente o termo contêiner.

No entanto, o Docker não está fazendo nada de mágico em relação à virtualização do hardware de um sistema. Em vez disso, está usando a capacidade do Kernel do Linux de construir "cercas" em torno dos principais recursos, o que permite que um processo interaja com recursos como rede, sistema de arquivos e permissões (entre outras coisas) para dar a ilusão de que você está interagindo com um sistema totalmente funcional.

Aqui está um exemplo que ilustra o que está acontecendo quando iniciamos um contêiner do Docker e o inserimos pela chamada de /bin/bash.

$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#

Agora, de dentro deste contêiner, se executarmos ps -eaf:

Mudando para outra guia do terminal em que estamos conectados ao sistema host que hospeda o contêiner Docker, podemos ver o espaço do processo que o contêiner "está realmente" ocupando:

Agora, se voltarmos à guia Docker e iniciarmos vários processos dentro dela e colocarmos todos em segundo plano, podemos ver que agora temos vários processos filhos em execução no processo Bash principal, que iniciamos originalmente como parte do lançamento do contêiner Docker.

NOTA: Os processos são 4 sleep 1000comandos que estão sendo armazenados em segundo plano.

Observe como, dentro do contêiner do Docker, os processos recebem IDs de processo (PIDs) de 48 a 51. Veja-os na ps -eafsaída também:

No entanto, com esta próxima imagem, grande parte da "mágica" que o Docker está realizando é revelada.

Veja como os 4 sleep 1000processos são na verdade apenas processos filhos do nosso processo Bash original? Observe também que nosso contêiner Docker original também /bin/bashé um processo filho do daemon Docker.

Agora, se esperarmos mais de 1000 segundos para que os sleep 1000comandos originais sejam concluídos, execute mais 4 novos e inicie outro contêiner do Docker da seguinte maneira:

$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#

A saída do computador host ps -eafseria assim:

E outros contêineres do Docker, todos aparecerão como processos no daemon do Docker.

Como você vê, o Docker realmente não está virtualizando ( no sentido tradicional ), está construindo "cercas" em torno dos vários recursos do Kernel e limitando a visibilidade deles para um determinado processo + filhos.

Dentro do contêiner, seus processos devem ser isolados (em quarentena). Na verdade, você não deve ver nenhum processo, exceto aqueles que você especificar (pelo menos um shell). Não é para testes de "sociabilidade". A única semelhança com o chroot é que o kernel do host é usado. O Docker é ótimo se você precisar isolar alguma coisa ou usar versões diferentes do software de arquitetura de plataforma do que aquela em execução no host. (versões muito antigas do Java ou uma bifurcação diferente do Python dizem). Esteja ciente de que as pastas e binários com os quais você está lidando podem não ser os mesmos do host. Não é a mesma pasta / bin etc.

EDIT: semelhança com chroot em vez de VMs.