O Que É um Container? Isolamento Sem uma VM Completa
Um container é um processo isolado: sua aplicação mais suas dependências, compartilhando o kernel do host, mas com seu próprio filesystem, rede e limites de recursos.
Containers resolvem o problema do "funciona na minha máquina" ao empacotar o código e tudo de que ele precisa em uma única unidade portátil. Ao contrário de uma máquina virtual, um container não carrega um sistema operacional inteiro - ele toma emprestado o kernel do host e isola apenas o que precisa. Isso torna os containers pequenos, rápidos para iniciar e ideais para os ambientes descartáveis dos quais o CI depende.
O que isolamento realmente significa
No Linux, um container é apenas um processo normal que o kernel cercou usando namespaces (sua própria visão do filesystem, árvore de processos, rede e usuários) e cgroups (limites de CPU, memória e I/O). Por dentro, o processo acredita ter a máquina só para si; por fora, ele é apenas um processo entre muitos.
Containers vs máquinas virtuais
Uma VM virtualiza o hardware e roda um sistema operacional convidado completo com seu próprio kernel, por isso é pesada e leva de segundos a minutos para iniciar. Um container compartilha o kernel do host, por isso é leve e inicia em milissegundos. O trade-off: VMs oferecem isolamento mais forte; containers oferecem densidade e velocidade.
O que vai dentro de um container
- O binário da sua aplicação ou o código interpretado.
- O runtime e as bibliotecas de sistema às quais ele se vincula.
- Arquivos de configuração e padrões de ambiente embutidos na image.
- Nada mais - sem kernel, e idealmente sem shell ou gerenciador de pacotes de que você não precise.
Por que o CI adora containers
Todo job de CI quer um ambiente limpo e idêntico. Um container te dá exatamente isso: a mesma image roda da mesma forma em um laptop, em um runner e em produção. Os builds se tornam reproduzíveis, e um job não pode deixar estado para trás que envenene o próximo.
Um exemplo rápido
Rodar docker run --rm -it python:3.12 python -c "print(1+1)" baixa uma image Python, inicia um container, imprime 2 e remove o container - tudo sem tocar no Python do seu host. A flag --rm o torna efêmero, exatamente a propriedade que o CI deseja.
Containers no CI
Os provedores de CI rodam cada job em um container ou VM novo e o destroem depois, e é por isso que seu pipeline começa limpo toda vez. Fazer o build dessas container images pode ser lento em runners frios; runners gerenciados (como o Latchkey) aceleram os builds de image com caches de camadas aquecidos e refazem automaticamente falhas transitórias de registry.
Principais conclusões
- Um container é um processo isolado que compartilha o kernel do host, não uma mini-VM.
- Namespaces fornecem o isolamento; cgroups fornecem os limites de recursos.
- Containers iniciam rápido e são reproduzíveis, e é por isso que o CI depende deles.