A B C Docker – Capítulo 1

Tudo o que você queria saber, mas…

Olá, visitante, e obrigado pela sua presença aqui. Decidi criar a série de posts “A B C Docker” para aprender, junto com você, este maravilhoso mundo de containers e suas aplicações. Neste primeiro artigo, você verá  uma introdução geral sobre arquitetura de containers.  Nos próximos episódios, mostrarei mais sobre o funcionamento, comunicação em rede, gerenciamento, apresentar algumas dúvidas comuns e executar exemplos práticos!  Vamos ao que interessa.

Se quiser conferir diretamente os outros capítulos:

• Capítulo 2:  Componentes do Docker;
• Capítulo 3:  Armazenamento no Docker;
• Capítulo 4:  Redes no Docker.

 

Por que escrever sobre containers?

Tenho navegado pela Internet e visto bons artigos sobre como usar Docker em algumas situações e com outras ferramentas relevantes, como aquelas dedicadas ao gerenciamento da plataforma.  A documentação oficial da implementação mais famosa (o Docker) é bem completa e abrangente, mas primariamente escrita em Inglês. Alguns vídeos são intuitivos e facilitam o aprendizado, mas, novamente, em Inglês.

Em Português, é fácil encontrar blogs tratando do conceito, mas geralmente orientados a desenvolvedores.  Assim, decidi escrever algo mais dedicado aos administradores de sistemas (como fui por muito tempo), sem esquecer, é claro que o conceito facilita bastante a vida dos programadores.

Além disto, tenho concentrado algumas pesquisas sobre o relacionamento entre Containers, DevOps (acrônimo que corresponde à facilitação da interação entre desenvolvedores e administradores de sistemas) e Cloud Security. Isto vai gerar um material que pretendo publicar em breve.

 

O que são containers?

Containers são estruturas que servem para proteger e isolar cargas. Materiais dentro de um container não devem vazar e ter contato com materiais de outros containers. Além disto, eles são projetados para facilitar o transporte e manuseio, com um mínimo de esforço.  Ainda sobre transporte, uma forma eficiente de movimentar grandes quantidades deles é através de navios, onde, mesmo completamente encostados uns nos outros, os containers compartilham o mesmo barco sem qualquer impacto.  Isto tem tudo a ver com o que explicarei.

Na Tecnologia da Informação, containers correspondem a porções de código que são executadas em um espaço reservado de memória e que compartilham (veja a analogia com o navio) o kernel do sistema operacional de um host. Lembra virtualização de servidores, certo?  Calma!  Vamos por partes.

Em 2008, foi criado o projeto Linux Containers para dar início à implementação do conceito no Linux.  O Linux Containers, capitaneado pelo projeto principal LXC, se baseia em componentes deste sistema operacional. Alguns deles:

• Kernel namespaces:  capacidade de executar uma aplicação em um espaço de memória isolado e controlado;
• CGroups:  controle e alocação de recursos (tempo de CPU, rede, memória do sistema) a tarefas definidas pelo usuário;
• ChRoot:  capacidade de entregar a um processo um ambiente que o faz pensar ser o root (/) do sistema. Programas rodando sob este ambiente não podem acessar qualquer área em disco fora do mesmo.

Deste projeto, nasceram algumas implementações:  LXD (Canonical), rkt (CoreOS) e Docker (Docker Inc), sendo que vamos nos focar nesta última, a mais conhecida.  Inicialmente para funcionar em Linux, o Docker foi posteriormente reescrito para ser executado em Windows e macOS.

 

Arquitetura – Parte 1

Você já sabe que uma das características do container é compartilhar o kernel do sistema operacional e isso remete à virtualização de servidores.  Vamos ver a diferença entre os dois conceitos na forma visual.

Na figura 1, a imagem da esquerda mostra um servidor que possui um sistema operacional próprio (como Windows Linux, macOS), representado pelo “Host OS” e um hypervisor do tipo 2, representado por “Hypervisor”.  Para entender a diferença entre hypervisor tipo 1 e tipo 2, veja este link.  Em cima do hypervisor, podem-se ver diversos “Guest OS”, que correspondem a máquinas virtuais (ou VMs, para encurtar), cada um com seu sistema operacional.  Em cada VM, existem bibliotecas, comandos e aplicações em execução.  Ainda do lado esquerdo, é possível ver duas VMs com MySQL, e uma com uma aplicação proprietária (App).

As aplicações recorrem ao kernel do Guest OS (o sistema operacional da VM) para ter acesso aos recursos do hardware.  Por sua vez, o Guest OS recorre ao hypervisor para acessar o hardware (disco, CPU, rede, …).  Por último, o Hypervisor repassa as requisições ao sistema operacional do host.

Ainda na mesma figura, do lado direito, vemos a arquitetura do Container.  Sobre o hardware, continuamos precisando de um Host OS.  Em cima desse sistema operacional, aparece o “Container Engine” (ou Docker Engine, no caso desta solução), e é justamente este componente que faz a “mágica” do compartilhamento de kernel entre os containers. Este compartilhamento expõe as bibliotecas e o kernel do sistema operacional para qualquer container que rode neste sistema.  Assim, torna-se visível uma das principais vantagens dos containers:  você não precisa de uma VM para cada aplicação que necessitar executar.  Um container também pode ter acesso aos binários contidos na imagem de onde ele foi instanciado, mas isso é uma discussão para um outro capítulo

Mas, lembre-se de algo importante:  como estamos executando tudo no mesmo sistema operacional, as aplicações dos containers precisam ser construídas para rodarem no mesmo sistema.  No caso da figura 1, por exemplo, tanto o MySQL quanto a “App” foram escritas para rodar sobre o mesmo “Host OS”.  Então, obviamente, se o  “Host OS” for Linux, tudo o que executar sobre ele (inclusive o Container Engine e qualquer container) também terá que funcionar sobre Linux.

Correto?  Não exatamente.  Na seção anterior, expliquei que o Docker foi reescrito para executar em Windows e macOS.  Então, como não posso ter mais de um tipo de sistema ao mesmo tempo.  Veremos isso com detalhe no próximo capítulo! 😉

 

Arquitetura – Parte 2

Já sabemos que container e máquina virtual não são a mesma coisa.  Pela figura 1, você percebe que o Container Engine pode executar diretamente sobre o sistema operacional de um host, como Linux ou Windows Server.  Ou seja, o Docker roda diretamente num sistema bare-metal, inclusive no seu computador de mesa ou laptop.  Na verdade, até foi realizado um estudo segundo o qual o desempenho da plataforma em bare-metal chega a ser melhor do que em ambiente virtualizado.  Para ler o relatório do estudo, acesse aqui.  Há outro estudo análogo a este, e bem completo, disponível aqui.

Ok, e se o sistema operacional do host for, na verdade, um hypervisor tipo 1 (já viu a diferença entre tipo 1 e tipo 2?)?  Um excelente exemplo de hypervisor tipo 1 é o VMware ESXi.  Como já sabemos, este tipo de hypervisor dispensa a execução de qualquer sistema operacional de host, porque ele mesmo se ocupa dessa tarefa.  Só que, para executar qualquer aplicação num ambiente assim, ela precisa ser implementada na forma de máquina virtual.  Então, se seu servidor tem um hypervisor deste tipo (outro exemplo é o XenServer), você precisará criar uma máquina virtual para, só então, poder implementar o Docker Engine sobre ela.

Veja a próxima figura.

Vamos percorrer a figura 2 da esquerda para a direita.  Observe o servidor 1.  Ele representa um hypervisor tipo 2 funcionando sobre um Host OS e possuindo duas VM, cada uma com seu Guest OS.  O servidor 2 também representa um hypervisor tipo 2 com duas VMs, mas a da direita possui o Docker Engine funcionando.  O servidor 3, por sua vez, está instalado diretamente sobre o hardware e o Host OS está executando a Docker Engine.  É uma situação de implementação em bare-metal.  Por fim, o servidor 4 representa um hypervisor tipo 1 com duas VMs, sendo que uma delas possui a Docker Engine instalada.  É exatamente a situação explicada no parágrafo anterior.

 

Cenas do próximo capítulo

No próximo post, saberemos como o Docker, tendo sido criado primariamente para Linux, consegue funcionar em Windows e macOS e, além disso, permite executar containers de sistemas operacionais diferentes. Também vamos ver o relacionamento entre os componentes do Docker.

Aguardo você no próximo post. 😉