Aula 05 — Contêineres: Conceitos, Docker e Introdução à Orquestração

Instalação e Configuração de Servidores — IFPE Campus Palmares

Objetivos de Aprendizagem

Ao final desta aula, o estudante deverá ser capaz de:

• explicar o que é um contêiner e diferenciá-lo de uma máquina virtual, retomando e aprofundando a Aula 01 (seção 1.5) e a Aula 03 (virtualização);
• descrever, em nível conceitual, os mecanismos do kernel Linux (namespaces e cgroups) que tornam os contêineres possíveis;
• identificar os componentes da arquitetura Docker (imagem, contêiner, Dockerfile, registry) e explicar o papel de cada um;
• interpretar um Dockerfile simples e reconhecer os comandos básicos do ciclo de vida de um contêiner;
• explicar por que aplicações reais costumam envolver múltiplos contêineres e como o Docker Compose organiza esse cenário;
• situar o papel da orquestração de contêineres (Kubernetes) como resposta ao problema de escala, sem aprofundar sua operação.

Introdução

Na Aula 03 estudamos a virtualização: um hipervisor permite que um único servidor físico execute várias máquinas virtuais, cada uma com seu próprio sistema operacional completo. Na Aula 04, vimos como esse modelo é oferecido em escala, sob demanda, pelos provedores de nuvem.

Ainda na Aula 01 (seção 1.5), mencionamos rapidamente que a virtualização tradicional tem um custo: cada máquina virtual carrega um sistema operacional inteiro, o que consome memória, armazenamento e tempo de inicialização. Os contêineres surgiram como resposta a esse problema. Nesta aula vamos aprofundar o que ficou apenas citado naquele momento: o que é um contêiner, como o Docker organiza esse modelo na prática, e por que essa tecnologia se tornou tão presente no desenvolvimento e na operação de aplicações web modernas.

5.1 Contêineres: Conceito e Comparação com Máquinas Virtuais

Um contêiner é uma unidade padronizada de software que empacota uma aplicação junto com tudo o que ela precisa para rodar — código, bibliotecas, dependências e configurações — mas, diferentemente de uma máquina virtual, não inclui um sistema operacional completo. Todos os contêineres em um mesmo host compartilham o kernel do sistema operacional hospedeiro; o que é isolado é o ambiente de execução de cada aplicação (arquivos, processos, rede), não o kernel em si.

Essa diferença de arquitetura explica praticamente todas as vantagens práticas dos contêineres: inicialização em segundos (não é preciso inicializar um sistema operacional), consumo de recursos muito menor, e imagens de poucos megabytes em vez de gigabytes.

Aspecto	Máquina Virtual	Contêiner
O que é virtualizado	O hardware (via hipervisor)	O sistema operacional (via kernel compartilhado)
Sistema operacional	Um SO completo por VM	Nenhum SO adicional; usa o kernel do host
Tempo de inicialização	Minutos	Segundos (ou menos)
Tamanho típico	Gigabytes	Megabytes a poucas dezenas de megabytes
Isolamento	Forte (nível de hardware/hipervisor)	Mais leve (nível de processo/kernel)
Portabilidade entre SOs hospedeiros diferentes	Alta (independe do SO do host)	Depende do kernel do host (contêineres Linux precisam de um kernel Linux)
Ferramentas típicas	VMware, VirtualBox, Hyper-V, KVM	Docker, Podman, containerd

Importante: virtualização e contêineres não são tecnologias concorrentes — são frequentemente combinadas. É comum, inclusive, rodar contêineres dentro de máquinas virtuais na nuvem, unindo o isolamento forte da VM com a leveza e a portabilidade do contêiner.

5.2 Como o Kernel Linux Torna os Contêineres Possíveis

Um contêiner não é uma tecnologia isolada e sim uma combinação de recursos que já existiam no kernel Linux, organizados de forma prática por ferramentas como o Docker. Os dois pilares principais são os namespaces e os cgroups.

Namespaces: isolamento do que cada contêiner enxerga

Um namespace faz um grupo de processos enxergar sua própria visão de um recurso do sistema, isolada da visão de outros processos. O Linux oferece vários tipos, e cada um isola uma dimensão diferente:

• PID: isola a árvore de processos — dentro do contêiner, o primeiro processo pode ter PID 1, mesmo havendo centenas de processos rodando no host.
• NET: isola interfaces de rede, tabelas de roteamento e portas — cada contêiner tem sua própria pilha de rede.
• MNT: isola o sistema de arquivos montado — o contêiner enxerga seu próprio sistema de arquivos raiz.
• UTS: isola o nome do host (hostname) e o nome de domínio.
• IPC: isola mecanismos de comunicação entre processos, como memória compartilhada e filas de mensagens.
• USER: isola identificadores de usuário e grupo — um processo pode ser “root” dentro do contêiner sem ter privilégios de root no host.

Cgroups: controle de recursos

Enquanto os namespaces controlam o que um contêiner enxerga, os cgroups (control groups) controlam quanto ele pode consumir: limitam e contabilizam o uso de CPU, memória, I/O de disco e rede por processo ou grupo de processos. É o mecanismo que impede que um único contêiner consuma todos os recursos do servidor e prejudique os demais.

Você sabia? A ideia de isolar o sistema de arquivos que um processo enxerga não nasceu com o Docker. O comando chroot, que restringe um processo a um subdiretório específico, existe desde a Version 7 do Unix (1979) e foi incorporado ao BSD no início dos anos 1980. Os namespaces e cgroups do Linux, décadas depois, generalizaram essa ideia para muito além do sistema de arquivos — e o Docker, lançado em 2013, foi quem tornou esses recursos do kernel fáceis de usar através de uma interface de linha de comando simples e de um formato padronizado de empacotamento (a imagem).

5.3 Arquitetura do Docker

O Docker não é uma peça única de software: é um conjunto de componentes que trabalham em camadas.

• dockerd (Docker Engine/daemon): processo que recebe os comandos do usuário (via CLI ou API) e coordena a criação de imagens e contêineres.

• containerd: gerencia o ciclo de vida dos contêineres (criar, iniciar, parar, remover) e a transferência de imagens.

• runc: componente de baixo nível que efetivamente cria o contêiner, aplicando namespaces e cgroups conforme a especificação técnica da OCI (Open Container Initiative) — um padrão aberto adotado pela indústria para que diferentes ferramentas de contêiner sejam interoperáveis.

Além do motor de execução, três conceitos organizam o modelo Docker:

• Imagem: um modelo somente leitura, montado em camadas (layers) sobrepostas por um sistema de arquivos union — o driver mais usado atualmente é o overlay2. Cada instrução de um Dockerfile normalmente gera uma nova camada, e camadas iguais entre imagens diferentes podem ser reaproveitadas, economizando espaço.

• Contêiner: uma instância em execução de uma imagem, com uma camada adicional gravável por cima das camadas somente leitura da imagem.

• Registry: um repositório de imagens. O Docker Hub é o registry público mais usado; organizações também mantêm registries privados para suas próprias imagens.

5.4 Do Dockerfile ao Contêiner em Execução

Um Dockerfile é um arquivo de texto com instruções sequenciais que descrevem como construir uma imagem. Um exemplo simples, para uma aplicação Node.js:

FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm install COPY . . EXPOSE 3000 CMD [“node”, “server.js”]

Cada linha corresponde a uma instrução: FROM define a imagem-base; WORKDIR define o diretório de trabalho dentro do contêiner; COPY leva arquivos do host para a imagem; RUN executa um comando durante a construção da imagem (aqui, instalar dependências); EXPOSE documenta a porta usada pela aplicação; CMD define o comando executado quando o contêiner é iniciado.

Depois de escrito o Dockerfile, o ciclo de vida básico de um contêiner passa por um pequeno conjunto de comandos:

Comando	O que faz
docker build -t nome-da-imagem .	Constrói uma imagem a partir do Dockerfile no diretório atual
docker images	Lista as imagens disponíveis localmente
docker run -p 3000:3000 nome-da-imagem	Cria e inicia um contêiner a partir de uma imagem
docker ps	Lista os contêineres em execução
docker logs nome-do-contêiner	Exibe a saída (logs) de um contêiner
docker stop / docker rm	Para e, em seguida, remove um contêiner

5.5 Aplicações com Múltiplos Contêineres: Docker Compose

Uma aplicação web raramente é um único processo isolado: normalmente há, no mínimo, a aplicação e um banco de dados, e frequentemente também um cache, uma fila de mensagens ou um servidor proxy. A prática recomendada é manter cada responsabilidade em um contêiner separado — um princípio às vezes chamado de “um processo principal por contêiner” — em vez de empacotar tudo junto em um contêiner só.

Gerenciar vários contêineres relacionados manualmente, um comando docker run de cada vez, torna-se rapidamente inviável. O Docker Compose resolve esse problema descrevendo, em um único arquivo YAML, todos os serviços de uma aplicação e como eles se relacionam:

version: “3.9” services: app: build: . ports: – “3000:3000” depends_on: – db db: image: postgres:16 environment: POSTGRES_PASSWORD: exemplo volumes: – db-data:/var/lib/postgresql/data volumes: db-data:

Com esse arquivo, o comando docker compose up sobe todos os serviços descritos, na ordem correta de dependência, conectados por uma rede interna criada automaticamente — sem que seja preciso configurar manualmente cada contêiner ou a comunicação entre eles.

Estudo de caso Uma escola decide colocar no ar um pequeno sistema de matrícula online, com uma aplicação web e um banco de dados. Sem containerização, seria preciso instalar e configurar manualmente o ambiente de execução da aplicação e o banco de dados no servidor, cuidando para que as versões de cada dependência sejam compatíveis com o que foi usado durante o desenvolvimento — um cenário clássico do problema “na minha máquina funciona”. Com Docker Compose, o time de desenvolvimento descreve a aplicação e o banco de dados como dois serviços em um único arquivo docker-compose.yml. Esse arquivo é versionado junto com o código-fonte e pode ser executado de forma idêntica no notebook de um desenvolvedor, em um servidor de testes ou em produção — o ambiente de execução deixa de depender de configuração manual e passa a ser parte do próprio projeto.

5.6 Além de um Único Host: a Necessidade de Orquestração

Tudo o que vimos até aqui — Dockerfile, imagem, contêiner, Compose — funciona muito bem em um único servidor. Mas o que acontece quando uma aplicação precisa rodar em dezenas ou centenas de contêineres, distribuídos em vários servidores, com exigência de que continuem no ar mesmo se um servidor falhar, e que sejam escalados automaticamente conforme a demanda (lembrando o auto scaling visto na Aula 04)?

Esse é o problema que ferramentas de orquestração de contêineres resolvem. A mais difundida atualmente é o Kubernetes, que automatiza o agendamento de contêineres entre servidores disponíveis, reinicia contêineres que falham, distribui carga entre réplicas e permite atualizações sem interrupção do serviço.

Não vamos aprofundar o funcionamento do Kubernetes nesta aula — ele tem complexidade própria suficiente para ser tratado com mais profundidade, como aliás já está previsto na bibliografia complementar da disciplina (Burns, Kubernetes Básico) e será retomado com mais detalhe em conteúdos de DevOps mais avançados. O que importa reter aqui é o porquê: orquestração existe porque, em escala, gerenciar contêineres manualmente deixa de ser viável — o mesmo tipo de raciocínio que, na Aula 04, justificou o dimensionamento automático em nuvem.

5.7 Uma Nota Sobre Segurança em Contêineres

Assim como fizemos na Aula 04 em relação à nuvem, vamos apenas situar o tema aqui, sem aprofundá-lo — segurança da informação, incluindo técnicas de ataque e defesa, é o assunto do próximo módulo da disciplina.

Um erro comum de quem está começando é assumir que, por serem mais leves que máquinas virtuais, os contêineres são automaticamente seguros. Alguns cuidados básicos, amplamente recomendados pela comunidade Docker, incluem: evitar executar o processo principal do contêiner como usuário root quando não houver necessidade real; usar imagens-base oficiais ou de fontes confiáveis, já que uma imagem é, na prática, um pacote de software de terceiros; e manter imagens atualizadas, reduzindo a janela de exposição a vulnerabilidades já corrigidas em versões mais novas.

Recursos Gratuitos para Ilustração da Aula

Lista de sites com documentação, tutoriais e ambientes de prática gratuitos, verificados na data de elaboração deste material:

• docs.docker.com/get-started/ — documentação oficial do Docker, gratuita e sem necessidade de login. Útil para as seções 5.3 e 5.4.
• docs.docker.com/get-started/resources/ — página oficial de recursos educacionais adicionais do Docker.
• docker-curriculum.com — tutorial independente e gratuito (Prakhar Srivastav), sem login, cobrindo praticamente a mesma sequência desta aula (imagens e contêineres, Dockerfile, Docker Compose).
• kubernetes.io/docs/tutorials/kubernetes-basics/ — documentação oficial do Kubernetes, gratuita e sem login. Importante: até 2022 essa página incluía um terminal interativo embutido (via Katacoda); a Katacoda foi descontinuada em 2023 e esse recurso foi removido — hoje o conteúdo é textual, com diagramas, útil para a seção 5.6.
• killercoda.com (playgrounds de Docker e Kubernetes) — ambiente de terminal interativo no navegador, sucessor não-oficial da Katacoda. Vários cenários abrem sem login; sessões mais longas podem pedir um cadastro gratuito.
• hub.docker.com — registry público oficial do Docker; útil para mostrar, ao vivo, como imagens reais são publicadas e versionadas.

O Play with Docker (labs.play-with-docker.com), por ser comumente citado em outros materiais sobre o tema, foi verificado e deliberadamente excluído desta lista: ele exige login com conta Docker Hub, GitHub ou Google para abrir uma instância, fora do critério de acesso livre e sem cadastro adotado nas aulas anteriores.

Resumo

Nesta aula vimos o que é um contêiner e em que ele se diferencia de uma máquina virtual, os mecanismos do kernel Linux que tornam isso possível (namespaces e cgroups), a arquitetura do Docker (dockerd, containerd, runc, imagens em camadas, registries), o ciclo básico de construção e execução de um contêiner a partir de um Dockerfile, o papel do Docker Compose na organização de aplicações com múltiplos contêineres, e uma introdução conceitual — sem aprofundamento — à necessidade de orquestração em escala e aos cuidados básicos de segurança em contêineres.

Encerramento da Aula 05

Percorremos o caminho da Aula 01 até aqui: de uma instalação manual em um único servidor (Aulas 01 e 02), passando pela virtualização de múltiplas máquinas em um mesmo hardware (Aula 03), pela entrega desses recursos sob demanda em escala global (Aula 04), até chegar a uma forma mais leve e portátil de empacotar e distribuir aplicações (Aula 05). Essas tecnologias não competem entre si — na prática, coexistem: é comum um contêiner Docker rodar dentro de uma máquina virtual, hospedada em um provedor de nuvem, com dimensionamento automático.

No próximo módulo da disciplina trataremos dos Princípios da Segurança da Informação, incluindo técnicas e tipos de ataque e de defesa, e segurança em protocolos e serviços — retomando, com mais profundidade, os pontos de segurança que fomos apenas sinalizando ao longo das Aulas 04 e 05.

Referências Bibliográficas

• MATTHIAS, Karl; KANE, Sean P. Primeiros Passos com Docker. São Paulo: Novatec, 2015.
• SILVA, Wellington F. da. Aprendendo Docker. São Paulo: Novatec, 2016.
• MOUAT, Adrian. Using Docker: Developing and Deploying Software with Containers. Sebastopol: O’Reilly Media, 2015.
• MIELL, Ian; HOBSON SAYERS, Aidan. Docker in Practice. Shelter Island: Manning Publications, 2016.
• BURNS, Brendan. Kubernetes Básico: Mergulhe no Futuro da Infraestrutura. São Paulo: Novatec, 2020.
• DOCKER INC. Get Started. Documentação oficial. Disponível em: https://docs.docker.com/get-started/.
• DOCKER INC. Educational resources. Documentação oficial. Disponível em: https://docs.docker.com/get-started/resources/.
• SRIVASTAV, Prakhar. Docker Curriculum. Disponível em: https://docker-curriculum.com/.
• THE KUBERNETES AUTHORS. Learn Kubernetes Basics. Documentação oficial. Disponível em: https://kubernetes.io/docs/tutorials/kubernetes-basics/.
• OPEN CONTAINER INITIATIVE. About the OCI. Disponível em: https://opencontainers.org/.

 

Material livre para distribuição e cópia.

 

Fim da Aula 05