Como uma máquina física vira várias máquinas isoladas — e por que, no fim das contas, o mercado trocou VMs inteiras por containers sempre que dá.
Uma das 4 arquiteturas: um hipervisor finge, pra cada SO convidado, que ele tem hardware inteiro só pra si.
docker run --rm alpineE cronometraram: container sobe em milissegundos, VM leva segundos. Mas ainda não vimos por dentro de nenhum dos dois.
Hoje a gente para de espiar de longe: vira o assunto principal da aula, com Docker de verdade — imagem, Dockerfile, comandos que vocês vão usar centenas de vezes no curso e na profissão.
Ela não pode comprar 50 computadores físicos — caro, e a maioria ficaria ocioso a maior parte do tempo. Como isolar 50 ambientes diferentes dentro de poucas máquinas físicas?
É exatamente o problema que a virtualização resolve — e é o motivo dela ter nascido décadas antes do Docker existir.
Um programa especial — o monitor de máquina virtual, ou hipervisor — cria, sobre um único computador físico, várias máquinas virtuais independentes. Cada uma roda seu próprio SO convidado, sem saber que está compartilhando hardware com outras.
Consolidar servidores caros e subutilizados, isolar ambientes de clientes diferentes, e testar vários sistemas operacionais sem comprar uma máquina pra cada um.
Cada VM carrega um núcleo inteiro — memória, disco e tempo de boot multiplicados por quantas VMs existirem na máquina física.
Reconhece essa ideia? É o mesmo VirtualBox que vocês instalaram na Semana 0 — só que rodando numa escala de data center, não no notebook de vocês.
Não existe um "SO anfitrião" por baixo — o próprio hipervisor é a camada mais baixa. Usado em data centers: VMware ESXi, Microsoft Hyper-V, Xen.
Existe um SO anfitrião normal (o Windows do laboratório, por exemplo) e o hipervisor roda como mais um aplicativo dentro dele. É o caso do VirtualBox que vocês usam.
Na prática do mercado: tipo 1 pra servidores de produção que precisam de desempenho máximo; tipo 2 pra desenvolvimento e testes no computador de cada pessoa.
Quando você aluga um servidor na AWS, Azure ou Google Cloud, o que você recebe de verdade é uma máquina virtual rodando dentro do data center de outra empresa — provisionada em segundos por um hipervisor tipo 1.
Não vamos aprofundar nuvem neste curso — é só pra vocês reconhecerem o vocabulário quando ele aparecer numa vaga de emprego ou numa reunião.
Vocês já sentiram isso na pele no Encontro 3: um container Docker sobe em milissegundos, uma VM leva segundos ou minutos. A razão não é o container ser "uma VM otimizada" — é que ele resolve o isolamento de um jeito completamente diferente.
| Máquina virtual | Container | |
|---|---|---|
| Kernel | Um núcleo completo por VM | Compartilha o núcleo do host |
| Isolamento | Hipervisor emula hardware | namespaces + cgroups do próprio kernel |
| Peso | GBs de disco, minutos de boot | MBs de disco, milissegundos de boot |
| Isolamento entre "vizinhos" | Total — núcleos nem se enxergam | Parcial — todos usam o mesmo núcleo por baixo |
É a mesma lição do jigsaw: menos isolamento arquitetural custa menos recurso — o segredo é saber quando cada um vale o preço.
Uma imagem é um pacote read-only com tudo que uma aplicação precisa: sistema de arquivos mínimo, bibliotecas, o binário da aplicação, e instruções de como rodar. Um container é uma instância em execução dessa imagem — como um objeto é uma instância de uma classe.
Você pode rodar vários containers da mesma imagem ao mesmo tempo — cada um isolado, cada um achando que é o único processo na máquina.
Assim como vocês baixaram a imagem alpine no Encontro 3 sem construir nada, existe um repositório público — o Docker Hub — cheio de imagens prontas: nginx, postgres, python, node, e milhares de outras.
docker pull <imagem> baixa uma imagem do Hub pro seu computador, sem rodar nada ainda.docker run <imagem> baixa (se precisar) e já sobe um container a partir dela.Um Dockerfile é um roteiro simples, linha por linha, de como montar uma imagem a partir de uma imagem-base.
Reparem a diferença entre RUN (acontece uma vez, na hora de construir a imagem) e CMD (acontece toda vez que um container novo nasce dessa imagem).
| Comando | O que faz |
|---|---|
docker pull <img> | Baixa uma imagem do Docker Hub |
docker images | Lista as imagens já baixadas/construídas localmente |
docker build -t nome . | Constrói uma imagem a partir de um Dockerfile na pasta atual |
docker run | Cria e inicia um container a partir de uma imagem |
docker ps / docker ps -a | Lista containers rodando / todos (incluindo parados) |
docker logs <id> | Mostra a saída que o container produziu |
docker stop / docker rm | Para um container / remove um container parado |
Uma sequência real: confirmar o Docker, baixar uma imagem, construir a própria, e rodar.
Cada uma dessas linhas vira um passo do roteiro de laboratório de hoje — vocês vão rodar isso de verdade, na própria VM.
docker pull, docker images, docker run com uma imagem pronta do Hub.
Escrever um Dockerfile mínimo, rodar docker build, e subir um container a partir dele.
O roteiro de laboratório detalha os dois passo a passo, com dicas se algo travar. Todas as observações vão pro instrumento semanal (quiz) no fim.
Por que existem, tipos e estratégias de virtualização — a base teórica de hoje. p. 70–77
O vocabulário que o mercado usa todo dia, direto da fonte. p. 329–330 e 342–344
Pra quem quer se aprofundar além do que cai no quiz. p. 327–357
O quiz da semana verifica essa leitura e recolhe suas observações da prática — tudo no mesmo instrumento.