Salve, Daz, beleza? Continuamos a saga aqui no nosso módulo de Docker. Nós vamos falar agora sobre a arquitetura do Docker. Nós vamos entender as ferramentas que estão por trás desse projeto, conhecendo ali o que cada ferramenta faz e como o Docker funciona debaixo dos panos. Então, bora para o VS Code. Então, o Docker é composto por três componentes. Nós temos o Docker Engine, que é o motor do Docker. Lá atrás, quando o Docker foi criado, foi criado com esse nome. Então, inclusive, o Docker inicialmente nem tinha disponibilidade para Windows. Hoje tem aí por conta de várias coisas que já foram feitas. Então, é esse cara que você acaba instalando dentro do seu Linux. E quando você instala ele na sua máquina, ele vai instalar o Docker Daemon, lembra lá do Container D? o Docker daemon, lembra lá do container D? Então, ele que vai ser o serviço que vai gerenciar a criação de containers, quais imagens disponíveis que você tem na sua máquina, os metadados dessas informações, as redes, os volumes e tudo mais. Aí a gente vai ter uma API nesse daemon e o CLI, que é o comando docker que a gente fica executando o tempo inteiro ali. Então, o docker engine funciona dessa forma. É uma arquitetura cliente-servidor no final das contas, que eu tenho os comandos sendo executados, que bate lá no daemon pedindo alguma informação, pedindo para ele poder fazer alguma coisa. Tem o docker hub que nós vimos na aula anterior, que é o repositório de imagens, e o Docker Desktop, que não é uma ferramenta nova, mas também não é velha. É uma ferramenta visual Docker, para você poder gerenciar os seus containers de forma visual e não ficar necessariamente usando o CLI dele. Então, a gente poderia resumir bem grosseiramente o Docker dessa forma. Então, agora vamos olhar um pouquinho mais para o Docker Engine. Ele é composto, como a gente já falou, do Docker Daemon. Olhando aqui para essa imagem, está vendo que nós temos o servidor do Dock, vamos chamar o Docker da irmã de servidor do Dock rodando aí na sua máquina. Inclusive, a gente consegue a seguinte situação, olha que legal. Eu posso ter um servidor do Docker rodando numa outra máquina que está na minha rede ou num outro lugar, em qualquer parte do mundo, e o meu CLI se conecta através de uma API. A gente consegue se conectar para poder pedir coisas lá para o Docker através até de uma API HTTP. Mas você não tem que ficar fazendo nenhuma chamada. Tudo isso funciona ali por debaixo dos panos. Então, tem o host do Docker que vai gerenciando as imagens, os containers, as outras coisas. E quando esse demon precisar... Ah, tem uma imagem... Ele baixa a imagem para a máquina ali, que ele está. Vamos supor que ele tem... O client pediu para poder criar um container baseado em uma SQL. Aí ele olha para cá, tem MySQL aqui. Então, ele vai lá no Docker Hub e puxa. Ou eu posso pedir para ele não puxar necessariamente do Docker Hub, eu posso pedir para ele puxar de um outro lugar. Não sou obrigado necessariamente a usar o Docker Hub. Então, a gente tem esse cenário. Esse cenário é bem esclarecedor. Então, aqui a gente tem sempre uma API que está funcionando, uma API HTTP, que é uma das formas, não é a única. Eu posso acessar a API na porta 2375. Inclusive, dá para fazer isso na própria máquina ali. Tem algumas coisinhas que poderiam ajudar. Então, esse aqui é o nosso cenário. Agora, vendo um pouco mais profundamente, então, tem nós como usuários aqui, ou pode ser até uma outra aplicação que é o usuário do Docker Client, que são ali os comandos. Então, vai se comunicando ali via API ou via socket, que eu posso ter um ponto SOC ali no Linux. Quando eles estão na mesma máquina, não tem necessidade de usar API, inclusive acaba sendo mais rápido. O SOC é uma forma de processos se comunicarem sem ter que usar a rede. Então, tem esse daemon aqui que vai fazendo o gerenciamento para mim. E embaixo dele, a gente acaba tendo o container D, que se comunica com o shim e usa o runc para poder fazer a criação dos containers. Então, o daemon está como se fosse um serviço que a Docker está provendo ali para poder abstrair essa complexidade daqui para baixo. Então, é por isso que é bom ter um padrão, porque como a gente está aqui com o container D, se eu quiser trocar o run C para outro aqui, ou se eu quiser trocar o serviço aqui do Scheme que vai organizar a criação dos containers e os gerenciamentos, eu posso fazer a troca sem que isso afete a minha infraestrutura. Eu até tirei essa imagem desse link aqui que você pode ver mais detalhes. Então, é basicamente isso. Nós temos o Arquitur cliente-servidor que está fazendo ali as chamadas e o Run-C está rodando lá para poder fazer a criação dos containers, pessoal. Então, a gente fecha esse capítulo aqui mais esclarecido sobre o Docker e também sobre containers e o próximoítulo, a gente vai fazer o quê? Já meter a mão na massa e rodar o Docker para valer. Então, vamos seguir na nossa saga. É isso aí. E até a próxima.