Como Funcionam Containers no Linux: Namespaces, cgroups v2, OverlayFS e runc

Um container no Linux é um processo comum executado com visibilidade restrita e recursos controlados diretamente pelo kernel. Ele combina namespaces para isolar o ambiente, cgroups v2 para impor limites físicos e OverlayFS para compor o sistema de arquivos em camadas.

No imaginário popular da engenharia, consolidou-se o mito de que containers operam como máquinas virtuais compactas. Essa metáfora oculta a mecânica real do sistema operacional e induz a erros graves de segurança e arquitetura em produção.

Diferente de uma máquina virtual tradicional, um container não inicializa nenhum sistema operacional independente. Não existe kernel convidado, emulação de barramentos PCI ou intermediação por hipervisores de hardware.

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

Um container é um processo nativo do host cujo isolamento decorre de recursos internos do kernel do Linux. Uma máquina virtual emula hardware completo através de hipervisores como KVM, exigindo um kernel dedicado para cada instância convidada.

Nas máquinas virtuais, o hipervisor gerencia tabelas de páginas estendidas e placas de rede virtuais. Cada instância precisa carregar seu próprio kernel vmlinuz, processos de inicialização e rotinas de gerenciamento de memória.

Esse modelo de virtualização pesada impõe um custo de inicialização de dezenas de segundos. Além disso, cada máquina virtual consome centenas de megabytes de memória RAM apenas para sustentar o sistema operacional hóspede.

Em contrapartida, o container executa diretamente sobre a CPU física do servidor hospedeiro. O comando executado no container realiza chamadas de sistema repassadas diretamente ao kernel do hospedeiro, alcançando desempenho nativo de bare metal.

A inicialização de um container consome menos de 50 milissegundos na maioria das distribuições modernas. Esse tempo equivale ao intervalo de um simples fork de processo associado à montagem de pontos de arquivos.

A fronteira de segurança, contudo, é compartilhada. Se um processo em container comprometer o kernel através de uma falha de sistema, todo o nó hospedeiro estará vulnerável.

Como os Namespaces do Linux governam a visibilidade dos processos?

Os Namespaces particionam os recursos globais do sistema operacional para restringir o que o processo consegue visualizar. Um processo alocado em namespaces dedicados opera como se fosse a única aplicação ativa em todo o computador.

O kernel Linux provê oito namespaces fundamentais documentados em namespaces(7). Cada um isola uma dimensão do hospedeiro:

• PID Namespace: Isola a tabela de identificadores de processo. O processo principal torna-se o PID 1 interno, mantendo seu PID real no host.
• Mount Namespace (MNT): Isola a árvore de montagem de sistemas de arquivos, impedindo que alterações nos pontos de montagem afetem o hospedeiro.
• Network Namespace (NET): Provê pilhas de rede isoladas com interfaces virtuais veth, tabelas de rotas e regras de firewall independentes.
• IPC Namespace: Isola mecanismos de comunicação interprocessos, como filas de mensagens POSIX e segmentos de memória compartilhada System V.
• UTS Namespace: Permite atribuir nomes de host e domínio exclusivos para cada ambiente sem alterar o nome da máquina física.
• User Namespace: Mapeia identificadores de usuário e grupo (UID/GID), permitindo ser superusuário interno com UID 0 sem deter privilégios reais no host.
• Cgroup Namespace: Mascara a visualização da hierarquia de cgroups, ocultando as restrições globais dos processos filhos.
• Time Namespace: Permite ajustar relógios de tempo do sistema (CLOCK_MONOTONIC) de forma desacoplada do hardware físico.

A criação desses ambientes ocorre através da chamada de sistema clone(2) com flags CLONE_NEW*. Processos ativos podem ingressar em namespaces via setns(2). Para desvincular recursos, utilizam a chamada unshare(2).

# Criando um namespace isolado de PID, Mount e Rede via linha de comando
unshare --pid --mount --net --fork /bin/bash

Como o cgroups v2 controla memória, CPU e I/O sem travar o host?

O cgroups v2 governa a distribuição e os limites máximos de recursos físicos que os grupos de processos podem consumir. Ele impede que processos com vazamentos de memória ou laços infinitos de processamento derrubem servidores em produção.

Enquanto os namespaces determinam o que uma aplicação pode enxergar, os Control Groups regulam o que ela pode efetivamente gastar. A versão legacy cgroups v1 permitia múltiplas árvores desconexas por subsistema, causando inconsistências graves na contabilização de memória e I/O.

A especificação cgroup v2 unificou a topologia do Linux. Todos os controladores operam sob /sys/fs/cgroup. Nessa arquitetura, um processo pertence a um único nó folha da árvore de controle.

O arquivo memory.max estabelece o teto rígido de consumo de memória física. Quando o container atinge esse limite, o kernel tenta recuperar páginas de cache ativas antes de disparar o terminador de processos.

Se a recuperação de memória falhar, o Out-Of-Memory Killer (OOM Killer) atua de maneira cirúrgica. Ele encerra exclusivamente os processos daquele cgroup específico, preservando a estabilidade operacional dos demais containers e do host.

A medição de saturação apoia-se no Pressure Stall Information (PSI). Esse subsistema do kernel monitora ciclos de CPU perdidos à espera de memória ou disco antes que ocorra a pane total.

# Configurando restricoes em cgroups v2 diretamente pelo pseudo-filesystem
mkdir /sys/fs/cgroup/meu-container
echo "200000 100000" > /sys/fs/cgroup/meu-container/cpu.max     # Limita a 2 nucleos
echo "536870912" > /sys/fs/cgroup/meu-container/memory.max        # Limita a 512 MB
echo $ > /sys/fs/cgroup/meu-container/cgroup.procs               # Associa o processo

Como o OverlayFS cria o sistema de arquivos em camadas com Copy-on-Write?

O OverlayFS compõe uma visualização unificada de múltiplos diretórios sobrepostos através de camadas de leitura e escrita. Ele viabiliza o compartilhamento de imagens base imutáveis entre dezenas de containers sem duplicação de dados em disco.

A documentação técnica do Linux Kernel Overlay Filesystem estrutura essa montagem em quatro diretórios principais:

• lowerdir: Uma ou mais camadas inferiores contendo a imagem base do container. Esses diretórios são estritamente somente-leitura.
• upperdir: A camada superior de leitura e escrita associada individualmente a cada container em execução.
• workdir: Diretório de trabalho intermediário reservado pelo kernel para garantir operações atômicas de escrita e renomeação.
• merged: O ponto de montagem resultante exibido como o diretório raiz para os processos do container.

Quando um container lê um arquivo inalterado da imagem base, o kernel atende a requisição diretamente das camadas inferiores (lowerdir). Nenhum byte é copiado ou realocado para a memória durante essa operação.

No instante em que o processo executa uma modificação no arquivo, o mecanismo Copy-on-Write (CoW) entra em ação. O kernel duplica o arquivo original para o upperdir antes de aplicar as gravações solicitadas.

Se um arquivo do lowerdir for excluído pelo container, o arquivo físico original não é alterado na imagem base. O kernel cria um nó especial chamado whiteout no upperdir que bloqueia a visibilidade do item na montagem final.

Esse modelo reduz o consumo de armazenamento secundário de servidores modernos. Centenas de instâncias de uma mesma imagem compartilham gigabytes de binários utilizando apenas megabytes de gravações diferenciais.

Qual o papel do runc e do pivot_root no ciclo de vida do container?

O runc é o runtime de baixo nível de referência da Open Container Initiative (OCI). Ele recebe um diretório descompactado de sistema de arquivos e um arquivo config.json para materializar o container no kernel.

O fluxo de trabalho de plataformas como Docker e Podman divide-se em camadas bem delimitadas. Motores de alto nível gerenciam downloads de imagens, redes virtuais e volumes de armazenamento antes de invocar o runtime de execução.

Na inicialização, o runc invoca clone(2) com os sinalizadores necessários. Ele define interfaces de rede e monta subsistemas.

Em seguida, o runtime altera a raiz de montagem via pivot_root(2). Essa chamada substitui o diretório raiz do sistema de arquivos.

// Sequencia simplificada de isolamento com pivot_root em C
chdir("/novo_rootfs");
pivot_root(".", "./antigo_host");
umount2("./antigo_host", MNT_DETACH);

Após o desmonte do diretório raiz antigo, torna-se computacionalmente impossível escapar do confinamento através de caminhos relativos como ../../. O container perde qualquer referência topológica aos diretórios do servidor hospedeiro.

Por fim, o runc restringe privilégios com capabilities(7). Ele ativa filtros de chamadas via seccomp e executa a aplicação via execve(2).

Tabela comparativa: Container vs Máquina Virtual vs MicroVM vs Bare Metal

A escolha da arquitetura de isolamento exige balancear densidade de instâncias, latência de inicialização e nível de garantia de segurança. A tabela abaixo compara os quatro modelos operacionais predominantes na computação em nuvem moderna:

O container atinge o ápice de eficiência computacional ao dispensar duplicações de subsistemas operacionais. MicroVMs modernas como o Firecracker combinam o tempo de arranque do container com a barreira de hardware das máquinas virtuais.

Sistemas que processam código não confiável de múltiplos locatários costumam alocar containers dentro de MicroVMs dedicadas. Essa estratégia conjuga o empacotamento ágil do OCI com defesas sólidas contra explorações de vulnerabilidades de kernel.

Como o MaxVision Code utiliza primitivas de container para execução agêntica segura?

O runtime do MaxVision Code utiliza sandboxes de isolamento baseadas em namespaces e cgroups para executar ferramentas e código arbitrário gerado por IA. Isso impede que comandos automatizados danifiquem o host ou exponham credenciais corporativas.

Sistemas agênticos que compilam software ou manipulam terminais virtuais precisam de execução rápida e estritamente confinada. Criar máquinas virtuais completas para cada invocação de script geraria gargalos de segundos inaceitáveis para desenvolvedores.

O orquestrador do MaxVision Code emprega primitivas equivalentes ao utilitário bwrap (Bubblewrap) sobre User Namespaces. Cada ferramenta executada pelo modelo de linguagem inicializa em um ambiente temporário descartável com as seguintes restrições:

• Isolamento de Filesystem Read-Only: Os binários vitais do sistema hospedeiro são montados com sinalizadores estritos de leitura (MS_RDONLY), impedindo modificações em bibliotecas globais.
• Áreas Efêmeras em Memória (tmpfs): Gravações ocorrem em pontos tmpfs voláteis alocados em RAM, que são instantaneamente descartados no término da execução.
• Blackhole de Rede Sob Demanda: Ferramentas sem necessidade externa rodam em namespaces sem interfaces de rede, eliminando exfiltração de dados confidenciais.
• Limites Físicos via cgroups: Processos agênticos em laços infinitos são interrompidos por limites estritos de CPU e cotas de memória.

Essa arquitetura garante que a autonomia dos agentes de inteligência artificial opere com proteções corporativas rigorosas. O desenvolvedor usufrui de velocidade imediata de execução sem colocar em risco a integridade do ambiente produtivo.

Perguntas Frequentes sobre Containers no Linux

Container é mais seguro que máquina virtual?

Não, máquinas virtuais possuem isolamento mais robusto por utilizarem hipervisores de hardware e kernels segregados. Containers compartilham a mesma superfície de chamadas de sistema do kernel hospedeiro, o que pode permitir explorações caso ocorra uma falha de segurança no núcleo do Linux.

O que acontece quando um container atinge o limite de memória?

O kernel tenta recuperar páginas de memória cache ativas e libera alocações temporárias. Se o consumo persistir acima do valor definido em memory.max do cgroups v2, o Out-Of-Memory Killer encerra o processo causador para preservar o hospedeiro e os demais serviços.

É possível rodar containers sem Docker ou privilégios de root?

Sim, ferramentas modernas como Podman e runc utilizam User Namespaces para executar containers em modo Rootless. Nesse cenário, o processo atua como superusuário com UID 0 dentro do container, mantendo um identificador comum sem privilégios administrativos no sistema operacional hospedeiro.

Qual a diferença entre chroot e pivot_root?

O comando chroot apenas altera a referência do diretório raiz para o processo atual, permitindo eventuais fugas de confinamento através de ponteiros de diretórios abertos. O comando pivot_root desmonta o sistema de arquivos anterior e substitui a raiz de montagem, impedindo qualquer acesso ao host.

Por que o cgroups v2 substituiu o cgroups v1 nos servidores modernos?

O cgroups v1 operava com hierarquias separadas para CPU, memória e I/O, gerando inconsistências graves na contabilização de recursos combinados. O cgroups v2 unificou todos os subsistemas em uma árvore hierárquica única, aprimorando o controle do OOM Killer e introduzindo métricas de pressão com o PSI.