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:

• reconhecer o problema que os contêineres resolvem, o famoso “na minha máquina funciona”;
• explicar o que é um contêiner e diferenciá-lo de uma máquina virtual, retomando 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;
• diferenciar imagem, contêiner, Dockerfile e registry, e reconhecer os componentes internos do Docker;
• interpretar um Dockerfile simples e os comandos básicos do ciclo de vida de um contêiner;
• explicar por que aplicações reais usam vários 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

Todo mundo que desenvolve para a web já passou por isso, ou vai passar. O site funciona perfeitamente no seu computador. Você manda para um colega, ou coloca no servidor, e ele quebra. A versão do Node.js é outra, falta uma biblioteca, uma configuração ficou para trás. A frase “na minha máquina funciona” virou piada entre desenvolvedores justamente porque é muito comum.

Repare que o problema quase nunca é o código. É o ambiente onde o código roda: o sistema operacional, as versões das dependências, as configurações. Se desse para levar o ambiente junto com o código, o problema desapareceria. Essa é a ideia central dos contêineres.

Até aqui percorremos um caminho em que cada aula resolveu um problema da anterior. Nas Aulas 01 e 02, instalamos e configuramos um servidor manualmente. Na Aula 03, a virtualização permitiu que um único servidor físico executasse várias máquinas virtuais, cada uma com seu próprio sistema operacional completo. Na Aula 04, vimos esse modelo oferecido sob demanda, em escala, pelos provedores de nuvem.

Ainda na Aula 01 (seção 1.5), mencionamos 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 custo e ao problema do ambiente. Nesta aula vamos entender 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.

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

O nome não é por acaso. Pense num contêiner de navio. O navio, o guindaste do porto e o caminhão não precisam saber o que há dentro dele. Como a caixa tem tamanho e encaixes padronizados, qualquer porto do mundo consegue carregá-la, empilhá-la e transportá-la da mesma maneira.

Um contêiner de software segue o mesmo princípio. É uma unidade padronizada que empacota uma aplicação com tudo o que ela precisa para rodar: código, bibliotecas, dependências e configurações. A diferença para uma máquina virtual é que o contêiner não inclui um sistema operacional completo. Todos os contêineres de um mesmo host compartilham o kernel do sistema operacional hospedeiro. O que fica isolado é o ambiente de execução de cada aplicação (arquivos, processos e rede), não o kernel.

Uma analogia ajuda a visualizar a diferença. Máquinas virtuais são como casas: cada uma tem fundação, encanamento e rede elétrica próprios, ou seja, seu próprio sistema operacional. O isolamento é forte, mas cada casa é cara e demorada de construir. Contêineres são como apartamentos de um prédio: todos dividem a mesma estrutura (o kernel), mas cada um tem sua porta, sua chave e seus móveis. São muito mais leves e ficam prontos rapidamente. Em contrapartida, um problema na estrutura do prédio afeta todos os apartamentos, e por isso o isolamento do contêiner é considerado mais fraco que o da máquina virtual.

Essa diferença de arquitetura explica as principais vantagens práticas dos contêineres: inicialização em segundos (não há sistema operacional para iniciar), consumo de recursos muito menor e imagens bem menores que as de uma máquina virtual.

Importante: virtualização e contêineres não são tecnologias concorrentes. Elas são frequentemente combinadas. É comum 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. Isso acontece inclusive no seu computador: no Windows, o Docker Desktop usa o WSL 2 (Subsistema do Windows para Linux) para executar um kernel Linux, e é sobre esse kernel que os contêineres Linux rodam.

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

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

Namespaces: o que cada contêiner enxerga

Voltando ao prédio: cada morador vê a sua porta, os seus móveis e o seu interfone, e não enxerga o que acontece no apartamento vizinho. Um namespace faz algo parecido. Ele dá a um grupo de processos a sua própria visão de um recurso do sistema, isolada da visão dos 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: quanto cada contêiner pode consumir

Os cgroups (control groups) funcionam como a franquia de dados de um plano de celular. Eles limitam e contabilizam o uso de CPU, memória, E/S de disco e rede por processo ou grupo de processos. É esse mecanismo que impede um único contêiner “guloso” de consumir todos os recursos do servidor e prejudicar os demais.

5.3 Arquitetura do Docker

Imagem, contêiner e registry

Três conceitos organizam o modelo Docker, e a confusão entre os dois primeiros é a mais comum entre iniciantes. Uma analogia de cozinha ajuda: a imagem é a receita, e o contêiner é o bolo.

• Imagem: o modelo somente leitura, a receita. É montada em camadas (layers) sobrepostas por um sistema de arquivos do tipo 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 são reaproveitadas, economizando espaço.
• Contêiner: uma instância em execução de uma imagem, o bolo pronto. Com uma única receita dá para fazer vários bolos, e com uma única imagem dá para subir vários contêineres. Cada contêiner recebe uma camada fina gravável por cima das camadas somente leitura da imagem.
• Registry: um repositório de imagens, parecido com o que o npm é para pacotes JavaScript ou o GitHub é para código. O Docker Hub é o registry público mais usado; organizações também mantêm registries privados. Baixar uma imagem é fazer um pull, e publicar é fazer um push.

Duas consequências práticas dessa separação. Se você apagar um contêiner, a imagem continua disponível, assim como a receita continua existindo depois que o bolo acaba. Já o que foi gravado dentro do contêiner, na camada gravável, é descartado junto com ele. É por isso que dados que precisam sobreviver, como os de um banco de dados, ficam em volumes, que veremos na seção 5.5.

Os componentes do motor Docker

O Docker não é uma peça única de software. É um conjunto de componentes que trabalham em camadas, como numa cozinha de restaurante:

• dockerd (Docker Engine/daemon), o garçom: recebe os comandos do usuário (via linha de comando ou API) e coordena a criação de imagens e contêineres.
• containerd, o gerente da cozinha: gerencia o ciclo de vida dos contêineres (criar, iniciar, parar, remover) e a transferência de imagens.
• runc, o cozinheiro: o componente de baixo nível que efetivamente cria o contêiner, aplicando namespaces e cgroups conforme a especificação da OCI (Open Container Initiative). A OCI é um padrão aberto adotado pela indústria para que diferentes ferramentas de contêiner sejam interoperáveis. Por isso uma imagem criada com o Docker também pode ser executada, por exemplo, com o Podman.

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

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

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

Cada linha corresponde a uma instrução:

A ordem das instruções tem um motivo. Primeiro copiamos apenas o package.json e instalamos as dependências; só depois copiamos o restante do código. Como cada instrução gera uma camada, e o Docker reaproveita camadas que não mudaram, uma alteração apenas no código não obriga a reinstalar todas as dependências a cada nova construção da imagem. Se o COPY . . viesse antes do RUN npm install, a imagem funcionaria do mesmo jeito, mas cada build seria bem mais lento.

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

docker cp index.html meusite:/usr/share/nginx/html/

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 com frequência 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 num contêiner só. Assim, cada parte pode ser atualizada, reiniciada e escalada de forma independente.

Gerenciar vários contêineres relacionados manualmente, com um 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:


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:


Nesse arquivo, o serviço app é construído a partir do Dockerfile da seção anterior (build: .) e publica a porta 3000. O serviço db usa a imagem oficial do PostgreSQL, e seus dados ficam no volume db-data, que sobrevive mesmo que o contêiner seja removido. No YAML a indentação é feita com espaços, nunca com tabulação, e faz parte da sintaxe.

Com esse arquivo, o comando docker compose up sobe todos os serviços descritos, conectados por uma rede interna criada automaticamente, sem que seja preciso configurar cada contêiner ou a comunicação entre eles. A opção depends_on garante que o banco seja iniciado antes da aplicação. Ela controla a ordem de inicialização, mas não espera o banco estar pronto para aceitar conexões; para isso existem as verificações de saúde (healthcheck), um recurso mais avançado.

Observação

Tutoriais mais antigos costumam começar o arquivo com uma linha version: “3.x”. Esse campo está obsoleto: segundo a documentação oficial, o Compose o ignora e apenas exibe um aviso. Arquivos atuais começam direto por services.

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 as que foram usadas durante o desenvolvimento. É o cenário clássico do “na minha máquina funciona”.

Com o Docker Compose, a equipe de desenvolvimento descreve a aplicação e o banco de dados como dois serviços num ú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, num servidor de testes ou em produção. O ambiente de execução deixa de depender de configuração manual e passa a fazer 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, que precisam continuar no ar mesmo se um servidor falhar e ser escalados automaticamente conforme a demanda, como no auto scaling visto na Aula 04?

Esse é o problema que as ferramentas de orquestração de contêineres resolvem. A mais difundida atualmente é o Kubernetes, que automatiza o agendamento de contêineres entre os servidores disponíveis, reinicia contêineres que falham, distribui a 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 já está previsto na bibliografia complementar da disciplina (Burns, Beda e Hightower, Kubernetes Básico), e será retomado em conteúdos de DevOps mais avançados. O que importa reter aqui é o porquê: a orquestração existe porque, em escala, gerenciar contêineres manualmente deixa de ser viável. É o mesmo raciocínio que, na Aula 04, justificou o dimensionamento automático na 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. A 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. Lembre-se da analogia do prédio: como todos os contêineres compartilham o mesmo kernel, o isolamento é mais fraco que o de uma VM. Alguns cuidados básicos, amplamente recomendados pela comunidade Docker:

• 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;
• manter as imagens atualizadas, reduzindo a janela de exposição a vulnerabilidades já corrigidas em versões mais novas. Isso vale também para a própria imagem-base: por isso o exemplo desta aula usa o Node.js 24, versão com suporte de longo prazo (LTS), e não o Node.js 20, cujo suporte já foi encerrado.

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, que cobre praticamente a mesma sequência desta aula (imagens e contêineres, Dockerfile, Docker Compose).
• hub.docker.com — registry público oficial do Docker. Útil para ver como imagens reais são publicadas e versionadas; a página da imagem oficial do nginx, por exemplo, documenta o uso mostrado no quadro “Experimente”.
• kubernetes.io/docs/tutorials/kubernetes-basics/ — documentação oficial do Kubernetes, gratuita e sem login. Até março de 2023 essa página incluía um terminal interativo (via Katacoda), removido após a descontinuação da plataforma pela O’Reilly. 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. O uso gratuito tem sessões de duração limitada e pode exigir um cadastro gratuito.

O Play with Docker (labs.play-with-docker.com), 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, o que foge do critério de acesso livre e sem cadastro adotado nas aulas anteriores.

Resumo

Nesta aula vimos que o problema do “na minha máquina funciona” está no ambiente, e não no código, e que os contêineres resolvem esse problema levando o ambiente junto com a aplicação. Comparamos contêineres e máquinas virtuais (apartamentos e casas) e vimos os mecanismos do kernel Linux que tornam isso possível: namespaces, que controlam o que o contêiner enxerga, e cgroups, que controlam quanto ele consome. Estudamos a arquitetura do Docker, com imagem, contêiner e registry (receita, bolo e loja) e os componentes dockerd, containerd e runc, e o ciclo de construção e execução de um contêiner a partir de um Dockerfile. Vimos também o papel do Docker Compose na organização de aplicações com vários contêineres e, sem aprofundamento, a necessidade de orquestração em escala e os 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 várias máquinas no mesmo hardware (Aula 03) e 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 da segurança em protocolos e serviços. Nele retomaremos, com mais profundidade, os pontos de segurança que foram apenas sinalizados nas Aulas 04 e 05.

Referências Bibliográficas

• BURNS, Brendan; BEDA, Joe; HIGHTOWER, Kelsey. Kubernetes básico: mergulhe no futuro da infraestrutura. São Paulo: Novatec, 2020.
• DOCKER INC. Docker Desktop WSL 2 backend on Windows. Documentação oficial. Disponível em: https://docs.docker.com/desktop/features/wsl/. Acesso em: 26 set. 2026.
• DOCKER INC. Educational resources. Documentação oficial. Disponível em: https://docs.docker.com/get-started/resources/. Acesso em: 26 set. 2026.
• DOCKER INC. Get started. Documentação oficial. Disponível em: https://docs.docker.com/get-started/. Acesso em: 26 set. 2026.
• DOCKER INC. Nginx: Docker Official Image. Docker Hub. Disponível em: https://hub.docker.com/_/nginx. Acesso em: 26 set. 2026.
• DOCKER INC. Version and name top-level elements. Documentação oficial. Disponível em: https://docs.docker.com/reference/compose-file/version-and-name/. Acesso em: 26 set. 2026.
• MATTHIAS, Karl; KANE, Sean P. Primeiros passos com Docker: uso de contêineres em produção. São Paulo: Novatec, 2015.
• MIELL, Ian; HOBSON SAYERS, Aidan. Docker in practice. Shelter Island: Manning Publications, 2016.
• MOUAT, Adrian. Using Docker: developing and deploying software with containers. Sebastopol: O’Reilly Media, 2015.
• NODE.JS. Node.js releases. Disponível em: https://nodejs.org/en/about/previous-releases. Acesso em: 26 set. 2026.
• OPEN CONTAINER INITIATIVE. About the OCI. Disponível em: https://opencontainers.org/. Acesso em: 26 set. 2026.
• PORT HOUSTON. Ideal X. Disponível em: https://porthouston.com/ideal-x/. Acesso em: 26 set. 2026.
• SILVA, Wellington Figueira da. Aprendendo Docker: do básico à orquestração de contêineres. São Paulo: Novatec, 2016.
• SRIVASTAV, Prakhar. Docker curriculum. Disponível em: https://docker-curriculum.com/. Acesso em: 26 set. 2026.
• THE KUBERNETES AUTHORS. Learn Kubernetes basics. Documentação oficial. Disponível em: https://kubernetes.io/docs/tutorials/kubernetes-basics/. Acesso em: 26 set. 2026.

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

Fim da Aula 05