Fala pessoal, tudo certo?
Hoje, vamos falar um pouco do "problema" que os containers vieram para resolver.
Vou colocar "problema" entre aspas, por que realmente algumas coisas dependem muito do ponto de vista, do cenário como um todo, da preferência, etc.
Mas sim... De forma geral os containers resolvem um problema =]
O Mundo Antes dos Containers
Você é o cara de infraestrutura que o time de desenvolvimento procura quando tem uma nova aplicação pronta para subir e entrar em produção.
O time te procura e fala o seguinte:
"É simples! Só precisa do Python 2.7, a biblioteca X na versão 1.2.3, a biblioteca Y na versão 2.0 e a variável de ambiente Z configurada."
Por um momento parece tranquilo.
Você já tem um servidor em produção. Mas o servidor de produção já tem Python 2.6 instalado porque outra aplicação depende especificamente dessa versão. Se você atualizar para 2.7, a outra aplicação quebra. Se não atualizar, a nova não funciona.
Isso era chamado de dependency hell. O inferno das dependências.
As soluções que existiam e seus problemas:
1 - Colocar cada aplicação em um servidor físico dedicado. Funcionava, mas era caro, lento para provisionar e desperdiçava muito recurso - uma aplicação usando 10% da CPU enquanto o servidor ficava ocioso 90% do tempo.
2 - Máquinas Virtuais. Uma VM emula um computador inteiro, tem seu próprio sistema operacional, kernel, drivers, tudo. Você poderia ter várias VMs num servidor físico, cada uma com suas dependências isoladas. Muito melhor! Mas o problema é que cada VM carregava um sistema operacional completo, 1GB, 2GB, às vezes mais. Subir uma VM levava minutos. Rodar 50 VMs num servidor significava 50 sistemas operacionais rodando em paralelo, consumindo memória e CPU só para existir.
Mas aí meus amigos, existem os containers...
A ideia dos Containers
A principal pergunta que os engenheiros de infraestrutura fizeram, foi:
"Precisamos mesmo de um sistema operacional inteiro para cada aplicação? Ou só precisamos de isolamento?"
A resposta foi: só precisamos de isolamento.
Um container não é uma VM. Ele não emula hardware. Ele não tem um kernel próprio. Todos os containers num servidor compartilham o mesmo kernel Linux do host, mas cada um enxerga apenas o seu próprio universo isolado.
Pense assim: uma VM é como construir casas separadas para cada família. Um container é como um prédio de apartamentos. Cada família tem seu espaço isolado, com sua própria porta, mas todos compartilham a mesma fundação, encanamento e estrutura.
O resultado prático é que um container:
- Sobe em milissegundos em vez de minutos
- Ocupa megabytes em vez de gigabytes
- Consome recursos apenas para a aplicação, não para um SO inteiro
- Pode rodar dezenas ou centenas no mesmo servidor
Mas o que torna os containers possível?
Existem 3 tecnologias do linux que tornam isso possível: Namespaces - O Isolamento, Cgroups - O Controle de Recursos e Union Filesystems - As Camadas.
Vamos falar um pouco sobre cada uma delas.
Namespaces (Isolamento)
Um namespace cria uma visão isolada de um recurso do sistema. Existem vários tipos e cada um isola uma coisa diferente.
PID Namespace isola os processos. Dentro de um container, o primeiro processo tem PID 1, mesmo que no host ele tenha PID 4382. O container enxerga apenas seus próprios processos, nunca os do host ou de outros containers.
bash
# No host você vê todos os processos
ps aux # mostra tudo — nginx, postgres, sua aplicação, tudo
# Dentro de um container
ps aux # mostra APENAS os processos daquele container
Network Namespace isola a rede. Cada container tem sua própria interface de rede, seu próprio endereço IP, suas próprias tabelas de roteamento. É como se cada container tivesse sua própria placa de rede virtual.
Mount Namespace isola o sistema de arquivos. O container enxerga apenas os diretórios e arquivos que foram montados para ele. Ele não tem acesso ao sistema de arquivos do host.
UTS Namespace isola o hostname. Cada container pode ter seu próprio nome de host, independente do servidor onde roda.
User Namespace isola usuários. O usuário root dentro de um container pode ser um usuário sem privilégios no host, uma camada importante de segurança.
Cgroups (Controle de Recursos)
Namespace resolve o isolamento, mas não resolve o consumo de recursos. Sem controle, um container poderia consumir toda a CPU e memória do servidor, afetando todos os outros.
Cgroups - Control Groups - é o mecanismo do Linux para limitar e monitorar o uso de recursos por grupos de processos.
Com cgroups você define que um container pode usar no máximo 2 CPUs e 512MB de memória. Se a aplicação tentar usar mais, o kernel intervém. Throttling de CPU ou OOM Kill de memória.
bash
# Você pode ver os cgroups de um container rodando
cat /sys/fs/cgroup/memory/docker/<container-id>/memory.limit_in_bytes
Quando você escreve isso num Deployment do Kubernetes. Você limita o quanto o container pode usar:
resources:
limits:
cpu: "2"
memory: "512Mi"
Union Filesystems (Camadas)
Esta é a tecnologia que torna imagens de container tão eficientes.
Uma imagem de container é composta de camadas sobrepostas. Cada instrução no Dockerfile cria uma nova camada. Essas camadas são somente leitura e podem ser compartilhadas entre múltiplas imagens.
Imagine três aplicações que todas usam Ubuntu como base. Sem camadas, cada imagem teria sua própria cópia do Ubuntu, 3 cópias de 80MB cada. Com Union Filesystem, a camada do Ubuntu existe uma única vez no disco e as três imagens apontam para ela.
Quando você roda um container, uma camada extra de escrita é adicionada no topo. É onde as mudanças acontecem durante a execução. Quando o container para, essa camada some. A imagem original nunca é modificada.O que você aprendeu hoje é fundamental e para quem usa Kubernetes saber explicar:
Containers existem para resolver o problema de isolamento de dependências sem o overhead de máquinas virtuais. Eles funcionam usando três recursos do kernel Linux — Namespaces para isolamento, Cgroups para controle de recursos e Union Filesystems para imagens eficientes em camadas.
Um container não é uma VM, não tem kernel próprio e não emula hardware - ele é um processo isolado rodando diretamente no kernel do host.
Por hoje é isso.
Abs e até a próxima.
:wq!
