Quando comecei a construir meu ambiente Proxmox, criar uma máquina virtual completa para cada serviço parecia uma aposta segura. Cada aplicativo possui seu próprio sistema operacional, disco virtual, alocação de memória e localização claramente definida no servidor. Parecia organizado e, mais importante, parecia devidamente isolado. Porém, depois de um tempo eu tive várias instalações Linux quase idênticas para suportar pequenos serviços que mal utilizavam os recursos que eu havia alocado para eles. Mover a maioria das cargas de trabalho para contêineres Linux, ou LXCs, tornou o lixo muito mais difícil de ignorar porque o mesmo hardware de repente parecia mais rápido, menos confuso e muito mais fácil de manter.
Os contêineres Linux pararam de desperdiçar recursos em sistemas operacionais duplicados
A maioria dos serviços nunca precisou de uma máquina virtual completa
Uma máquina virtual completa faz sentido se a carga de trabalho precisar de seu próprio kernel, de um sistema operacional diferente ou de uma margem de segurança mais forte. A maioria dos serviços do meu laboratório doméstico não precisa de nada disso. Pi-hole, Uptime Kuma, Homarr, RustDesk e outros pequenos utilitários em que confio são aplicativos Linux que exigem ambiente estável, armazenamento e conectividade de rede. Atribuí VMs completas a eles principalmente porque era um método de implantação com o qual já estava familiarizado.
Essa escolha não pareceu particularmente um desperdício quando eu estava olhando para uma máquina virtual por vez. Um pouco de memória para um sistema operacional convidado aqui e espaço em disco ali não pareciam muito. O problema ficou mais claro quando vários deles estavam em execução, cada um com seus próprios serviços em segundo plano, cache de pacotes, syslogs e processo de atualização. Reservei uma quantidade significativa de hardware para o próprio Linux antes que o aplicativo que realmente me interessasse tivesse feito o trabalho.
O LXC elimina grande parte dessa duplicação compartilhando o núcleo do host Proxmox enquanto mantém os serviços em ambientes isolados do espaço do usuário. Ainda recebo diferentes sistemas de arquivos, endereços IP, contas de usuário, limites de recursos e tarefas de backup. O que não faço mais é inicializar um kernel diferente e um sistema operacional completo para cada painel ou ferramenta de monitoramento. Quando vi quão pouco esses contêineres precisavam para funcionar confortavelmente, as alocações que atribuí às VMs antigas começaram a parecer ridículas.
Os LXCs Proxmox compartilham o kernel Linux do host, portanto, usam menos recursos do que máquinas virtuais completas. Eles ainda mantêm cada serviço em seu próprio ambiente de espaço de usuário isolado, com sistemas de arquivos, processos, rede e restrições de recursos separados. Os contentores não atribuídos são um padrão mais seguro para a maioria dos serviços de laboratório doméstico, a menos que a carga de trabalho exija especificamente acesso elevado.
O tempo de inicialização mais rápido mudou a maneira como gerenciei todo o cluster
Os contêineres se regeneram com rapidez suficiente para que a manutenção pareça quase rotineira
A primeira diferença que notei não estava oculta no gráfico de recursos. Os contêineres começaram muito mais rápido. A VM teve que concluir verificações de hardware virtual, inicialização do kernel e inicialização do sistema operacional antes que o serviço fosse disponibilizado. O LXC geralmente voltava antes que eu tivesse tempo de pensar se deveria abrir o console e verificar.
Essa velocidade mudou meus hábitos de manutenção mais do que eu esperava. Com as VMs antigas, às vezes eu atrasava a reinicialização ou a alteração da configuração porque sabia que esperaria que vários convidados desligassem e voltassem por sua vez. Não foi um grande atraso, mas foi atrito suficiente para me fazer adiar o trabalho que precisava fazer. Com o LXC, interromper um serviço, alterar algo e reiniciá-lo parece uma tarefa normal, e não um pequeno evento de manutenção.
Isso também é importante se eu trabalhar com mais de um nó Proxmox. Uma reinicialização no host ainda interrompe tudo que está sendo executado nele, e a velocidade de armazenamento ainda afeta os tempos de migração e backup, de modo que os contêineres não fazem tudo de uma vez. O que eles removem é o longo processo de inicialização do convidado no final. Se vários serviços leves precisarem retornar após o retorno de um nó, essa diferença será sempre óbvia.
Os contêineres reduzem a manutenção ao não esconder de mim todos os serviços
Menos sistemas operacionais significam menos atualizações e verificações repetidas
O menor consumo de recursos foi o benefício mais aparente, mas a redução na manutenção foi o que fez o LXC aderir. Cada máquina virtual tinha seus próprios pacotes de sistema operacional, repositórios, atualizações de segurança e serviços em segundo plano. Mesmo quando vários convidados usavam a mesma distribuição Linux, ainda era necessário atualizar cada instalação separadamente. Depois de fazer a mesma manutenção de pacotes algumas vezes em máquinas quase idênticas, a separação exata começou a parecer mais repetitiva do que útil.
LXC é meu padrão para a maioria dos serviços Linux porque eles atendem melhor a essas cargas de trabalho.
Os contêineres não eliminam completamente esse trabalho. Cada um ainda tem seu próprio espaço de usuário, pacotes de aplicativos e configuração, então não acho que sejam autossustentáveis. Eles são simplesmente ambientes menores que executam menos software não relacionado. As atualizações são concluídas mais rapidamente, os backups têm menos dados para mover e geralmente há menos ruído para lidar quando verifico por que o serviço está agindo de forma estranha.
Também não tive que abrir mão da visibilidade que me atraiu para convidados individuais. Cada contêiner ainda tem sua própria entrada no Proxmox, junto com gráficos de recursos, acesso ao console, logs, armazenamento, rede e configurações de backup. Posso ver quando o Pi-hole está usando mais armazenamento do que o esperado ou quando algum outro serviço está consumindo memória sem explorar o host compartilhado. A fronteira ainda existe; simplesmente não é necessário fingir que cada aplicativo possui o computador inteiro.
Máquinas virtuais completas ainda fornecem isolamento mais forte e extenso
Compartilhar o núcleo de um host cria limitações que as máquinas virtuais evitam
Há uma razão pela qual o Proxmox oferece suporte a LXC e máquinas virtuais completas. Os contêineres compartilham o kernel host, portanto, não podem executar um sistema operacional completamente diferente ou substituir livremente os componentes do kernel. O Windows pertence à máquina virtual e algumas cargas de trabalho do Linux também exigem mais controle do kernel do que o LXC pode fornecer confortavelmente. Esses casos não se tornam menos reais só porque os contêineres são mais eficientes para todo o resto.
A margem de segurança também é diferente. Uma máquina virtual isola o convidado do host por trás de um hipervisor e fornece a ele seu próprio kernel, enquanto o LXC depende de namespaces, permissões e outros mecanismos de isolamento do Linux. Eu uso contêineres não alocados sempre que possível porque eles são um padrão mais seguro para os serviços que executo. Mesmo assim, eu não as descreveria como idênticas às máquinas virtuais do ponto de vista da segurança, porque não são.
O acesso ao hardware e ao armazenamento também pode se tornar inconveniente. Transferir dispositivos, adicionar armazenamento compartilhado ou organizar permissões entre host e contêiner pode exigir configuração manual e uma melhor compreensão de como os IDs de usuário do Linux são mapeados além da fronteira. Uma máquina virtual muitas vezes esconde mais dessa complexidade por trás do hardware virtual. Já tive momentos em que a opção mais pesada teria sido mais rápida de configurar, mesmo que depois usasse mais recursos.
Essas restrições são menos importantes para os serviços que realmente executo
A escolha dos hóspedes com base na carga de trabalho mantém as compensações sob controle
O argumento mais forte do LXC não é que suas limitações não importem. Acontece que a maioria dos meus serviços Proxmox nunca entra em contato com eles. Minhas ferramentas de DNS, monitoramento, painel e acesso remoto não precisam de seus próprios kernels. Atribuir uma máquina virtual a cada um deles resolveu os problemas de isolamento que eu não tinha quando adicionei a manutenção que definitivamente tinha.
Também não tentei forçar todos os aplicativos ao LXC apenas para fazer o ambiente parecer consistente. Jellyfin e meus serviços de gerenciamento de biblioteca de mídia ainda funcionam em um Docker NAS, próximo ao armazenamento que eles usam todos os dias. Esse acordo já está em vigor, e mover esses aplicativos para o Proxmox exigiria a adição de montagens de rede, permissões e outras dependências entre o NAS e o cluster. Eu mudaria uma configuração razoável para fazer o gráfico parecer mais limpo.
Isso é importante porque mantém a decisão prática. LXC é meu padrão para a maioria dos serviços Linux porque eles se adaptam melhor a essas cargas de trabalho, não porque eu ache que toda implantação de VM ou Docker esteja errada. Se algo exigir um núcleo separado, um sistema operacional diferente, um isolamento mais forte ou uma passagem de hardware mais fácil, usarei uma máquina virtual. Se pertencer ao NAS ao lado dos dados que gerencia, deixo lá.
Meu hardware Proxmox agora passa mais tempo fornecendo serviços úteis
A maior mudança é que não considero mais uma máquina virtual como ponto de partida automático para cada nova implantação. Começo com o serviço e trabalho de trás para frente a partir do que ele realmente precisa. Para a maioria das ferramentas executadas no Proxmox, isso significa LXC com um sistema de arquivos pequeno, memória limitada e apenas os pacotes necessários para o trabalho. Os nós parecem menos confusos agora, embora eu esteja pedindo que executem mais serviços do que antes.
As máquinas virtuais ainda desempenham um papel importante no meu laboratório doméstico, mas se tornaram a exceção e não o padrão. Os LXCs me proporcionaram reinicializações mais rápidas, menos uso de recursos básicos, menos backups e menos manutenção do sistema operacional. Jellyfin e meus serviços de gerenciamento de biblioteca de mídia permanecem no Docker NAS porque esse ainda é o lugar para eles, enquanto praticamente todo o resto funciona convenientemente em contêineres. Depois de usar ambas as abordagens por tempo suficiente, a diferença não é mais teórica; Percebo isso toda vez que atualizo um serviço, reinicio um nó ou vejo quanto hardware não estou mais desperdiçando.
