Docker: criando e gerenciando containers

Conhecendo o Docker - Apresentação

Olá! Tudo bem? Eu sou o Daniel Artine e serei seu instrutor no curso Docker: criando e gerenciando containers da Alura.

Audiodescrição: Daniel é um homem de pele morena, cabelos pretos, barba preta e olhos pretos. Ele veste uma camisa cinza e está sentado em uma cadeira preta em frente a uma parede branca com iluminação verde.

O que vamos aprender?

Para fazer um breve panorama do que vamos abordar, obviamente, o tema será o Docker, mas também vamos tratar de outros assuntos. Se observarmos rapidamente a página da documentação, percebemos que vamos começar com o básico do Docker em "Get started".

Em seguida, vamos abordar o processo de download e instalação, tanto no Windows quanto no Linux, passando por esses dois ambientes para configuração e outros aspectos. A partir disso, começaremos a explorar a utilização do Docker.

Após configurar e instalar o Docker, vamos entender o que cada comando faz. Temos uma lista de comandos que vamos explorar neste vasto universo do Docker e iremos entender a maioria deles, o que são as flags (bandeiras), como criar um container, o que é um container, como ele é diferente de uma máquina virtual e como funciona, quais são suas características peculiares, e assim por diante.

Todas essas questões serão abordadas neste curso e vamos responder aos poucos: como vamos interagir os containers uns com os outros, como podemos criar nossos próprios containers, usar containers de terceiros, como identificar se um container é original, no contexto de reconhecimento da comunidade.

Muitos assuntos serão estudados no decorrer deste curso. Esperamos que você aproveite. Até o próximo vídeo!

Conhecendo o Docker - Conhecendo o problema

Vamos partir do problema inicial? Os sistemas, atualmente, têm diversas aplicações e ferramentas que interagem entre si para compor seu todo.

É mais ou menos esse caso que vamos visualizar e entender por que os containers podem ser úteis nessas situações. Porém, antes disso, vamos partir do básico da ideia de como chegamos a essa solução.

Conhecendo o problema

Temos uma aplicação Nginx que vai servir como um load balancer (balanceador de carga) do nosso sistema. Além disso, temos uma aplicação Java e uma aplicação C# rodando com o .NET.

Nessa situação, queremos que todas essas aplicações estejam em execução para que o sistema como um todo esteja operacional. Para isso, precisamos de uma máquina para que essas aplicações rodem e o sistema funcione.

A nossa aplicação C# roda na porta 80, isto é, precisa da porta 80 para executar. Da mesma forma, a aplicação Java roda na porta 80, assim como a Nginx. Nesse caso, o C# que utilizamos está na versão 9, o Java na versão 17, e o Nginx na versão 1.17.0.

Quais problemas podem ocorrer nessa situação?

Se observarmos cada uma dessas aplicações e ferramentas, podemos acabar tendo um conflito de portas, porque as 3 aplicações nesse cenário dependem da porta 80 para executar o fluxo necessário.

Além disso, como podemos alterar as versões de maneira prática? Se simplesmente fizéssemos o downgrade ou o upgrade da versão do C#, atualizando o .NET, quebraríamos algo? Precisamos desinstalar para instalar uma nova? O mesmo se aplica ao Java e ao Nginx: conseguiríamos atualizar de maneira prática?

Outra questão é a seguinte: como vamos ter um controle de recursos de memória e de CPU para essas aplicações? Por exemplo: a aplicação C# precisa de 100 millicores de CPU e 200 megabytes de memória para funcionar. Como podemos definir isso de maneira fácil?

O mesmo é válido para as outras aplicações: como podemos fazer essa definição de consumo de recursos do sistema de maneira prática? É uma questão que precisamos levantar.

Por fim, considerando todos esses problemas de uma vez só, como podemos fazer o processo de manutenção dessas aplicações? Como vamos conseguir mudar a versão? Como vamos ter esse controle sobre as portas das aplicações? Como vamos gerenciar os recursos e manter isso a longo prazo?

Uma solução que poderíamos pensar inicialmente que seria bem simples, mas ao mesmo tempo problemática, seria simplesmente comprar uma máquina para cada aplicação. Dessa forma, teríamos uma máquina para a aplicação .NET, outra máquina para a aplicação Java, e outra para a aplicação Nginx.

Assim, resolveríamos o problema de conflito de portas, já que cada máquina teria a sua respectiva porta 80; conseguiríamos controlar os recursos de maneira mais fácil, pois não teríamos essa dependência das aplicações entre si; e o controle de versionamento também ficaria mais fácil, pois não teríamos diversas aplicações no mesmo sistema.

Porém, qual o problema disso? O nosso dinheiro vai embora, porque se tivéssemos uma máquina para cada aplicação, pensando em sistemas que têm milhares ou milhões de aplicações em execução simultaneamente, precisaríamos de milhares ou milhões de máquinas para que o sistema esteja operante.

Máquinas virtuais

Existe uma solução já bem difundida, que não é recente e ajuda a resolver esses problemas: as máquinas virtuais, onde teríamos o hardware bem definido; o sistema operacional, seja ele Windows, Linux, Mac ou outro; e uma camada de hypervisor, que fará um meio de campo para virtualizar um novo sistema operacional.

Esse sistema pode ser um Windows, um Linux, um Mac, rodando dentro de outro sistema, mas graças a essa camada de hypervisor, teríamos uma camada de isolamento desse sistema operacional original. Assim, conseguiríamos instalar as nossas dependências e aplicações de maneira isolada, porque cada uma delas tem o seu respectivo sistema operacional.

Essa solução resolve esses problemas iniciais, mas a pergunta que fica nesse momento é a seguinte: é realmente necessário fazer isso?

Queremos executar as nossas aplicações, como vimos, de maneira isolada, ter um controle de recursos, e ter um controle de versionamento bem definido. Então, essa camada de hypervisor é realmente necessária? Nessas situações, precisamos sempre virtualizar um sistema operacional? Pode ser que sim, pode ser que não, mas no caso que vamos abordar durante este curso, é a utilização de containers.

No caso do uso de containers, não temos a camada de sistema operacional virtualizado, nem a de hypervisor, mas sim a camada diretamente do container rodando o sistema operacional, e mesmo assim, de forma isolada. Cada aplicação está isolada entre si e também isolada do sistema operacional original.

É isso que vamos entender a partir de agora: por que os containers são mais leves? Como eles vão garantir esse isolamento? E como eles vão funcionar sem instalar um sistema operacional?

No caso da máquina virtual, a aplicação C# terá um sistema operacional para ela, bem como a aplicação Java. Já no ambiente de containers, a aplicação C# está diretamente dentro do container. Nesse caso, qual sistema operacional ela vai usar? Windows? Linux? Precisamos instalar um sistema?

Precisamos responder essas perguntas. De onde vêm essas informações? Por último, temos a seguinte pergunta: como ficará a divisão de recursos entre as aplicações que estarão, a partir de agora, containerizadas?

Conclusão

No próximo vídeo, vamos entender como essas situações ocorrem. Como o container vai garantir ser mais leve em questão de consumo de recursos? Como vai garantir isolamento? Como funciona sem instalar um sistema operacional?

Agora que já sabemos como os containers nos ajudam e o que eles fazem, vamos entender os diferenciais de como o container opera dentro do nosso sistema. Abordaremos isso na sequência. Até mais!

Conhecendo o Docker - Como containers funcionam

Neste vídeo, vamos responder às seguintes perguntas:

• Por que os containers são mais leves em relação a uma máquina virtual?
• Como eles garantem o isolamento?
• Como funcionam sem instalar um sistema operacional?
• Como fica a divisão de recursos do sistema?

Como containers funcionam?

O container funciona da seguinte maneira: dentro de um sistema operacional, temos vários containers, isto é, diversas aplicações sendo executadas. No entanto, eles funcionarão diretamente como processos dentro do nosso sistema.

Enquanto uma máquina virtual terá toda aquela etapa de virtualização dos sistemas operacionais dentro do sistema original, os containers funcionarão diretamente como processos dentro do sistema.

Portanto, no que diz respeito ao consumo, podemos visualizar que ele será um pouco menor. O consumo de recursos, a carga para que ele possa ser executado, é um pouco menor, porque eles serão processos, e não uma virtualização completa.

As próximas perguntas são as seguintes:

• Como um processo garantirá o isolamento?
• Como ele funcionará sem instalar um sistema operacional?
• Como vamos conseguir resolver e responder essas perguntas?

A questão é que, quando containers estiverem em execução no nosso sistema operacional, para garantir o isolamento entre cada um deles e o sistema operacional original, existe um conceito chamado namespaces, que garantirá que cada um desses containers tenha capacidade de se isolar em determinados níveis.

O que são namespaces?

Teremos os principais namespaces: primeiramente, o PID, que garante o isolamento a nível de processo dentro de cada um dos containers. Portanto, um processo dentro de um container, que, consequentemente, é um processo dentro do sistema operacional, estará isolado de todos os outros do nosso host, isto é, da nossa máquina original.

Teremos também o NET, o namespace de rede, que garantirá o isolamento entre uma interface de rede de cada um dos containers e também do nosso sistema operacional original.

O namespace IPC será de intercomunicação entre cada um dos processos da nossa máquina. O MNT, que é a parte de file system (sistema de arquivos), montagem, volumes e afins, também estará devidamente isolado. Por fim, o UTS faz um compartilhamento e um isolamento ao mesmo tempo do host, isto é, do kernel, da máquina que executa o container.

Este último namespace específico, UTS, ajuda a responder à próxima pergunta:

• Como o container dentro do sistema operacional funcionará sem um sistema operacional?

Na verdade, graças ao namespace UTS, se executarmos nossos containers em uma máquina com kernel Linux, cada um dos containers, a princípio, também terá um pedaço desse kernel, mas devidamente isolado.

Assim, conseguimos responder à pergunta: não precisamos necessariamente instalar um sistema operacional dentro de um container, porque ele já terá, graças ao namespace UTS, acesso ao kernel do sistema original, mas isoladamente.

Cgroups

Por fim, na parte de gerenciamento de recursos, suponha que queiramos definir, conforme levantado em um problema anteriormente, o consumo máximo de memória, de CPU e afins para cada um dos containers.

Existe outro conceito chamado Cgroups, que garantirá que podemos definir, tanto de maneira automática, quanto de maneira manual, como os consumos serão feitos para cada um desses processos, isto é, para cada um desses containers dentro do sistema operacional.

De volta às perguntas originais, graças aos namespaces e aos Cgroups, conseguimos garantir o isolamento, garantir que o nosso container funciona sem instalar um sistema operacional dentro dele, e também conseguir ter um controle de gerenciamento de recursos como memória e CPU.

Quanto à questão de por que eles são mais leves, entendemos que eles funcionarão como processos diretamente do sistema operacional, mas ao longo deste curso, entenderemos ainda mais por que eles conseguem ser tão mais práticos em relação a uma máquina virtual em termos de consumo de recursos e de tamanho de armazenamento também no nosso sistema operacional.

Conclusão

Respondemos às principais perguntas de quem está começando agora no mundo de containers: como garantir o isolamento, como ele funciona sem instalar um sistema operacional, e assim por diante.

Agora que entendemos como um container se diferencia de uma máquina virtual tradicional, aprenderemos a instalar o Docker, inicialmente no Windows e depois no Linux, onde vamos abordar as principais utilizações do Docker.

Nos encontramos no próximo vídeo. Até mais!

Sobre o curso Docker: criando e gerenciando containers

O curso Docker: criando e gerenciando containers possui 204 minutos de vídeos, em um total de 58 atividades. Gostou? Conheça nossos outros cursos de Containers em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Conhecendo o Docker
• Os primeiros comandos
• Criando e compreendendo imagens
• Persistindo dados
• Comunicação através de redes
• Coordenando containers