Sexta-feira, ambiente de produção. O alerta do sistema de monitoramento dispara com a delicadeza de uma sirene de ataque aéreo: um dos serviços centrais da infraestrutura parou de responder, a réplica caiu sumariamente com status de falha e o orquestrador subiu um contêiner substituto no lugar para estancar a sangria.

Na primeira parte desta série, a gente abriu o capô do kernel Linux e viu que contêineres não são máquinas virtuais: são processos comuns isolados por namespaces, limitados em hardware por cgroups v2 e servidos por camadas montadas via OverlayFS. Chegamos a empacotar tudo isso num script em shell de cinquenta linhas capaz de rodar um ambiente funcional do zero.

Uma VM AlmaLinux recém-saída do vagrant up é um ótimo servidor genérico: quieta, previsível e configurada para aplicações comuns. Ela não repassa pacotes entre interfaces, não deixa o firewall inspecionar o tráfego das pontes de rede, convive com swap sem remorso e nem sequer conhece os nomes das outras máquinas do laboratório. Para quem vai virar nó de Kubernetes, cada uma dessas características é um problema que precisa ser resolvido.

Você já rodou docker run centenas de vezes. Digita o comando, aperta enter, um punhado de letrinhas corre pelo terminal e, em questão de meio segundo, você tem uma aplicação inteira rodando em um ambiente isolado com rede, disco e variáveis próprias. Mas se eu te perguntar exatamente o que o kernel Linux fez naquele exato instante de meio segundo, você sabe responder?

Existe uma ilusão vendida pelas interfaces gráficas modernas de que transformar o computador em ponto de acesso sem fio é um clique e pronto. Você abre o painel da distribuição, clica em "Criar Hotspot", inventa uma senha qualquer e espera que funcione. Na melhor das hipóteses, sobe uma rede WPA2 capenga; na pior, a interface congela, o NetworkManager se perde sozinho e você não faz ideia do que deu errado.