No último artigo vimos o que é uma Distro Linux, e a divisão entre User space e Kernel space. Nesse artigo vamos ver o porque é importante essa definição ser clara para entender alguns fatos sobre os containers Docker.
O conteúdo desse artigo também está no formato de vídeo no nosso canal do YouTube:
Docker Containers Não São SOs
No uso de containers essa divisão entre os dois “spaces” tem que ficar muito clara. Um container não é um SO! Um SO é o conjunto do user space e kernel space. E quando nós vamos lá no Docker e fazemos o seguinte:
o Docker vai baixar uma imagem que tem o que chamamos de rootfs do Debian, que é o sistema de arquivos principal do user space aonde estão armazenados os arquivos dos programas e bibliotecas utilitárias. Não tem Kernel nessa imagem! Por que? Porque o Docker, que está rodando no user space, usa funcionalidades do Kernel Linux, cgroups e namespaces, para criar um novo “User Space isolado”, processos e network isolados baseados nos arquivos do rootfs de uma distro Linux.
Lembra do teste que fizemos no último artigo? Tivemos que reinicializar a Rasbperry Pi para dizer ao Kernel carregar o Ubuntu ao invés do Raspbian. Com Docker containers isso não é necessários porque na verdade o Docker runtime, que é um programa que está rodando no user space, monta um isolamento e inicializa os processos de uma certa distro Linux em um namespace isolado. Assim através das ferramentas do Docker podemos ter vários “User spaces” com configurações diferentes gerenciados pelo Docker.
Sendo assim podemos rodar qualquer rootfs, user space, de qualquer distro Linux dentro de um container e esses “user spaces” vão compartilhar do mesmo e único Kernel space!
Docker Containers Não São Virtualizações
Agora já sabemos o que é Kernel space e User space. E com essa definição fica claro também o porque de um Docker container não ser uma virtualização:
Na imagem acima temos lado a lado como é a definição do sistema para Docker container e para uma máquina virtual. Para montar uma máquina virtual precisamos virtualizar todo o stack: o hardare, rede, disco e etc, o Kernel que vai rodar em cima desse hardware virtual e por tabela o User space que o Kernel vai inicializar. Note bem como no caso de um Container, como já sabemos, ele só precisa do rootfs da distro Linux para rodar em um espaço isolado utilizando o mesmo Kernel e hardware nativos, não há virtualização! Por isso é muito leve e vantajoso utilizar Docker containers ao invés de VMs.
Mas uma coisa tem de ser dita, nem tudo são flores. Já que os Containers compartilham do mesmo Kernel deve-se tomar cuidado ao privilegio de ações que você executa dentro de um container ao utilizar funcionalidades do Kernel. Você pode causar um Kernel Panic! Isso causaria o termino de execução de todos os outros containers e serviços rodando em cima desse Kernel.
Agora pensando que cada VM tem seu próprio Kernel virtual, no caso de um Kernel Panic, apenas a VM que causou o erro seria parada.
Conclusão
Desde quando eu conheci o Docker eu vivo in love ❤ com essa ferramenta! Me facilita muito muitas tarefas, inclusive para sistemas embarcados que é o que com eu mais trabalho atualmente. Eu geralmente preciso testar um dado programa que roda apenas com uma certa versão de biblioteca, ou nesse meio tempo preciso rodar outro programa que depende de outra configuração, eu apenas monto imagens Docker e com a mesma imagem eu consigo testar em diferentes placas com sistemas diferentes, mas com o comum de terem o Docker runtime.
Como vimos nem tudo são flores, e precisamos verificar se containers Docker são a melhor solução para o seu problema. Talvez para você, seja lá qual for seu problema, o Docker por utilizar um Kernel space compartilhado não se encaixe. Mas ainda há a opção de rodar em uma VM. É sempre bom conhecer todas as opções, prós e contras de cada para poder tomar a melhor decisão. Nunca sabemos quando vamos precisar.
