O que é container e qual a diferença para uma máquina virtual

Você clona o projeto de um colega, roda npm install, sobe a aplicação e recebe um erro que ele nunca viu. A versão do Node é outra, o banco local está numa versão antiga e falta uma biblioteca do sistema operacional. Meia tarde perdida para descobrir que o código estava certo e a máquina, não.

É exatamente esse problema que o container resolve. Ele empacota a aplicação junto com tudo de que ela precisa para rodar (runtime, bibliotecas, arquivos de configuração) e garante que o pacote se comporte igual no seu notebook, no do colega e no servidor.

Na prática: um container é um processo isolado que leva a aplicação e suas dependências, mas usa o kernel do sistema hospedeiro. Uma máquina virtual simula um computador inteiro, com sistema operacional próprio. Por isso o container sobe em segundos e ocupa megabytes; a VM leva mais tempo e ocupa gigabytes, mas isola mais.

Imagem e container não são a mesma coisa

Essa é a confusão de vocabulário mais comum entre iniciantes. A imagem é o molde, somente leitura, montado em camadas. O container é a imagem em execução, com uma camada gravável por cima. Da mesma imagem você pode subir dez containers.

A imagem nasce de um arquivo de receita, o Dockerfile. Um exemplo mínimo para uma API em Node:

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

Com docker build -t minha-api . você gera a imagem; com docker run -p 3000:3000 minha-api sobe um container a partir dela. A visão geral oficial do Docker explica bem a relação entre cliente, daemon, imagens e registros como o Docker Hub.

Repare na ordem do Dockerfile: o package.json é copiado antes do resto do código. Cada linha vira uma camada em cache, então, se só o código mudou, o Docker reaproveita a camada do npm ci e o build cai de minutos para segundos. É um ajuste pequeno que pouca gente explica a quem está começando.

Container e máquina virtual lado a lado, critério por critério

A diferença técnica mais importante está numa camada só: quem fornece o kernel. Numa VM, um hypervisor (VirtualBox, KVM, Hyper-V, VMware) cria um hardware virtual e, em cima dele, roda um sistema operacional completo. No container, o sistema operacional do hospedeiro é compartilhado, e o isolamento vem de recursos do próprio kernel Linux, como namespaces (cada container enxerga seus próprios processos, rede e arquivos) e cgroups (limites de CPU e memória).

Um detalhe que confunde quem usa Docker no Windows ou no Mac: lá, o Docker Desktop roda uma pequena VM Linux escondida, e os containers vivem dentro dela. Ou seja, no seu notebook os dois conceitos muitas vezes estão empilhados.

Quando o container é a escolha certa

Na prática, container virou o padrão para empacotar aplicações web e APIs. Ele encaixa melhor quando:

• você quer o mesmo ambiente em desenvolvimento, testes e produção;
• a aplicação é dividida em serviços (API, fila, worker) que sobem e caem de forma independente;
• precisa subir um banco ou um Redis só para testar, sem instalar nada na máquina;
• o pipeline de CI precisa de ambientes limpos a cada execução;
• a carga varia e você quer criar e destruir cópias rápido.

Um caso do dia a dia de júnior: em vez de instalar PostgreSQL no Windows, roda-se docker run -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16 e em poucos segundos há um banco limpo. Terminou o projeto, apaga o container e a máquina volta a ficar como estava.

Onde a máquina virtual ainda ganha

Container não aposentou a VM. Ela continua sendo a resposta certa em situações bem concretas:

• Outro sistema operacional: testar um software de Windows num servidor Linux, ou rodar uma distribuição antiga que um sistema legado exige.
• Isolamento forte entre clientes: provedores de nuvem colocam containers de clientes diferentes dentro de VMs separadas justamente por isso.
• Mexer no kernel: módulos, drivers, configurações de rede de baixo nível.
• Sistemas legados que esperam um servidor inteiro, com serviços de sistema rodando, e não um processo único.

A combinação mais comum em produção nem é uma ou outra: são containers rodando dentro de VMs na nuvem. A VM dá o isolamento e o kernel; o container dá a padronização da aplicação. Se você quiser ir além do Docker e da VirtualBox, o buildbase já tratou das alternativas open source de virtualização que ganharam espaço nas empresas.

Kubernetes entra quando os containers viram dezenas

Rodar três containers na mão com Docker Compose é tranquilo. Rodar cento e vinte, espalhados por dez servidores, reiniciando o que cai e distribuindo tráfego, não é. É aí que entra o orquestrador, e o mais usado é o Kubernetes (também chamado de K8s).

Ele cuida de tarefas que você faria manualmente:

1. decidir em qual servidor cada container vai rodar;
2. reiniciar automaticamente o que falhar;
3. aumentar ou diminuir o número de cópias conforme a carga;
4. trocar a versão da aplicação aos poucos, sem derrubar o serviço;
5. distribuir as requisições entre as cópias.

A documentação do Kubernetes em português descreve justamente essa evolução: da era dos servidores físicos para a das VMs e, depois, para a dos containers.

Uma opinião honesta para quem está começando: não comece pelo Kubernetes. Aprenda Docker, escreva Dockerfiles, use Compose para subir dois ou três serviços juntos. Kubernetes tem uma curva de aprendizado alta e só se paga quando o volume de serviços justifica. Muita empresa pequena roda muito bem com containers num serviço gerenciado, sem nunca tocar num cluster.

Container é seguro o bastante?

É seguro quando bem configurado, e é aí que o compartilhamento do kernel pesa. A Red Hat, que mantém boa parte do ecossistema, resume em seu material sobre containers Linux que o isolamento acontece no nível do processo, não do hardware. Três cuidados resolvem a maior parte dos riscos:

• não rodar o processo como root dentro do container (use a instrução USER no Dockerfile);
• partir de imagens oficiais e enxutas, como as variantes alpine ou slim, e atualizá-las;
• nunca colocar senhas e tokens dentro da imagem; passe por variáveis de ambiente ou por um cofre de segredos.

O terceiro ponto é o deslize mais frequente: alguém faz COPY . . com o arquivo .env na pasta, publica a imagem num registro público e a senha do banco vai junto. Um arquivo .dockerignore com .env listado evita o problema.

Mão na massa: containerize um projeto seu

Escolha um projeto seu que já funcione, escreva o Dockerfile dele e faça subir com um comando só. Depois, adicione o banco num docker-compose.yml. Esses dois passos ensinam mais do que qualquer curso sobre orquestração, e o termo deixa de ser jargão para virar ferramenta. Se aparecerem outras palavras pelo caminho, como imagem, registro ou orquestrador, o glossário de programação traz cada termo explicado em linguagem de iniciante.