Por Thiago Marques
O pai ta on!!
Até agora entendemos o que é um container, como o Docker funciona sob esse modelo e como utilizar o Docker Compose para auxiliar a criação de várias máquinas. Mas conforme vamos nos aprofundando surgem novas dúvidas, como:
• Beleza, mas como tudo isso funciona?
• Como o Docker controla e gerencia os containers?
• Existe licenciamento para utilizar?
Nesse post iremos detalhar um pouco mais sobre o conceito da plataforma para entender tudo isso.
A Arquitetura Docker
Docker Client / Remote API
Quando estamos logados em um terminal e executamos comandos como docker ps, docker images e etc, utilizamos o command line interface (CLI) do docker, de forma que, nessas condições, podemos dizer que nosso terminal é um docker client.
Assim conseguimos interagir com o daemon que está no host para nos trazer informações dos containers, das imagens e etc. Além do cliente, é possível interagir também via remote API. Quanto utilizamos o docker em uma máquina diferente do Jenkins, por exemplo, precisamos efetuar a configuração de um remote API para o deploy de um build funcionar.
Note que para instalação do cliente/server em uma instância Amazon Linux 2, é necessário instalar via amazon-linux-extras. A AWS já possui uma excelente documentação de como fazer isso basta acessar o link: How-to-install-docker-Amazon-Linux
Docker daemon / runtimes
Depois da versão 1.11 do Docker (que até então era um grande monolítico), ele passou a segmentar em daemons as operações, sendo:
• dockerd ficou responsável por receber e interpretar os comandos e APIs do cliente;
• containerd ficou com o trabalho mais ‘pesado’ de controlar as imagens e containers, e executar os processos do runC;
• runC que é quem de fato lida com o gerenciamento dos containers.
Note que com a segmentação e a disponibilização dos códigos, podem existir outros runtimes para essas funções, como é o caso do CRI-O, que é uma alternativa ao containerd, ou o CRUN e o RAILCAR que são alternativas ao runC.
NaAWS os runtimes utilizados pelo Fargate são o containerd e o runC.
Fonte: Docker
Docker Registry
Finalizando a parte de arquitetura temos os Registries, que são os repositórios de onde é possível realizar o download/upload dos docker images.
Veja na imagem inicial desse post que quando fazemos o primeiro pull (docker pull
Nesse caso (apenas o pull) o containerd se registra no repositório, procura a imagem, e faz seu download para o repositório local. O runC não entra no processo ainda, pois não estamos de fato criando um container, apenas baixando a imagem.
A vantagem de ter um repositório central, além de te poupar espaço, é que ele pode garantir outras características como:
• Ter um repositório privado;
• Possibilidade de utilizar SSO e colaboração;
• Acesso a imagens oficiais;
• Scan de vulnerabilidades para as imagens;
• Integração com CI/CDs.
Atualmente o Docker Hub, é o repositório mais utilizado, no qual você pode realizar o push (enviar) ou o pull (receber) as imagens, e possui a versão paga e gratuita. Obviamente na versão gratuita você tem alguns limites, como o bloqueio de 100 pulls por 6horas (veja os limites aqui)
A AWS possui a sua própria solução de registry chamada ECR, o que se mostra ser eficiente para integração de serviços como o ECS e o Fargate. Contudo soluções como o Harbor, para IaaS também pode ser uma saída interessante caso você utiliza pull de forma constante.
That’s all folks! Be Happy!!!
Veja os outros artigos sobre Docker!
Entendendo Docker
Docker Compose
