Virtualização com containers
Revisão: Máquinas Virtuais
Antes de entender containers, é essencial revisar VMs, pois as diferenças entre as duas tecnologias derivam de um único ponto arquitetural.
Em um servidor sem virtualização, todas as aplicações compartilham o mesmo sistema operacional — um problema em um app pode afetar os demais. VMs resolvem isso permitindo que múltiplos sistemas operacionais rodem em um único hardware físico, isolando cada aplicação em seu próprio ambiente.
Um hypervisor gerencia e aloca os recursos de hardware entre as VMs. Existem dois tipos:
| Tipo | Nome alternativo | Onde roda | Uso típico |
|---|---|---|---|
| Tipo 1 | Bare metal / nativo | Diretamente no hardware | Data centers corporativos |
| Tipo 2 | Hosted | Sobre um SO host (Windows, Linux, macOS) | Dispositivos pessoais, labs |
> Exemplo: Cisco Modeling Labs (CML) roda como VM sobre VMware Workstation (Type 2) instalado no Windows.
Cada VM possui seu próprio SO guest, além de binários e bibliotecas necessários às aplicações. Isso garante isolamento completo — um problema em uma VM não afeta as demais.
Containers
Containers são pacotes de software que contêm uma aplicação e todas as suas dependências, mas sem um SO próprio. Essa é a diferença fundamental em relação às VMs.
Arquitetura
Hardware
└── SO Host (geralmente Linux)
└── Container Engine (ex: Docker)
├── Container A (App + libs)
├── Container B (App + libs)
└── Container C (App + libs)Todos os containers compartilham o mesmo SO host. O Docker Engine é o container engine mais popular do mercado.
Orquestradores de containers
Em ambientes de pequena escala, containers podem ser gerenciados manualmente. Em sistemas grandes — especialmente com microsserviços — isso se torna inviável. Um orquestrador automatiza implantação, escalonamento e gerenciamento.
Principais orquestradores:
- Kubernetes — o mais utilizado no mercado
- Docker Swarm — solução nativa do Docker
Microsserviços
Arquitetura de microsserviços divide uma aplicação monolítica em partes menores e independentes, cada uma rodando em seu próprio container. Sistemas corporativos podem exigir milhares de containers rodando simultaneamente — daí a necessidade de orquestração.
VMs vs. Containers: comparativo
A diferença central — VMs têm SO próprio, containers não — gera todos os impactos abaixo:
| Critério | VMs | Containers |
|---|---|---|
| Tempo de boot | Minutos | Milissegundos |
| Uso de disco | Dezenas de GB | Dezenas de MB |
| Consumo de CPU/RAM | Maior | Menor |
| Portabilidade | Alta (mesmo hypervisor) | Muito alta (qualquer container service) |
| Isolamento | Total (SO independente) | Parcial (SO compartilhado) |
| Segurança | Maior isolamento | Menor isolamento |
Ponto crítico para o exame: se o SO host de um ambiente com containers falhar, todos os containers são afetados. Em VMs, uma falha no SO guest de uma VM não impacta as demais.
O que cai no CCNA
Para o exame CCNA 200-301, garanta que você sabe:
- Diferença entre Type 1 e Type 2 hypervisors
- Definição de container e container engine (Docker)
- Que containers não possuem SO próprio — compartilham o SO host
- Que Kubernetes é o orquestrador de containers mais popular
- Vantagens dos containers: boot rápido, leveza, portabilidade
- Desvantagem dos containers: menor isolamento comparado a VMs
VMs e containers coexistem nos ambientes corporativos modernos. Containers dominam cenários de DevOps e microsserviços; VMs seguem essenciais em data centers tradicionais.