A cada poucos meses eu me convenço de que outra camada de complexidade tornará meu laboratório doméstico mais gerenciável. Testarei outro método de implantação, automatizarei outra tarefa de manutenção ou moverei o serviço porque o novo arranjo parece mais limpo no papel. Às vezes isso realmente ajuda. Outras vezes eu olho para o simples container Linux Proxmox e me pergunto por que passei uma tarde tentando melhorar algo que já estava funcionando sem reclamar. Os contêineres LXC não são a parte mais nova ou interessante da minha configuração, mas continuam ganhando porque posso descobri-los rapidamente, corrigi-los sem passar por várias camadas e nunca mais pensar neles.
Recipientes simples tornam os serviços comuns agradavelmente comuns
A maioria dos serviços de laboratório doméstico não exige orquestração complexa
Muitos serviços têm um trabalho no meu laboratório doméstico e não têm interesse em se tornar um projeto maior. O Pi-hole filtra as solicitações de DNS, enquanto o Uptime Kuma verifica se o resto da rede ainda está ativo. Eles ficam sentados lá, fazendo seu trabalho e geralmente só chamam minha atenção quando uma atualização está disponível ou algo deu errado. Esses serviços não exigem um processo de implantação complexo. Eles precisam de um sistema operacional estável, uma conexão de rede, armazenamento suficiente e uma maneira confiável de reiniciar após uma reinicialização.
O contêiner LXC me dá isso sem me forçar a converter a configuração para uma mentalidade diferente. Criei um contêiner no Proxmox, instalei o software, configurei a rede e agi como uma pequena máquina Linux. As peças importantes estão onde eu as espero. Não preciso lembrar se o arquivo de configuração está no aplicativo, em um diretório mapeado ou em algum outro arquivo que informe ao aplicativo onde está o diretório mapeado.
É mais importante depois de alguns meses. Posso lembrar por que instalei um serviço, mas nem sempre me lembro de todas as decisões que tomei ao configurá-lo. Com o LXC, posso abrir o shell e começar a procurar sem precisar reconstruir a implantação primeiro. Aprendi que isso geralmente é mais útil do que uma configuração bonita e reutilizável para um serviço que talvez nunca reconstrua do zero.
Os contêineres LXC não são automaticamente a melhor escolha para todas as aplicações. Eles são mais adequados quando o serviço requer apenas um ambiente Linux leve, acesso direto à rede e fácil manutenção. Os aplicativos criados com base em imagens oficiais do Docker ou em vários serviços relacionados ainda podem ser mais gerenciáveis com o Docker Compose.
LXC se encaixa naturalmente em como eu gerencio o Proxmox
A interface Proxmox oferece manutenção diária em um só lugar
A maior vantagem do LXC na minha configuração não é a economia de memória, embora isso seja bem-vindo. É que os contêineres ficam na mesma interface Proxmox que já uso para VMs, backups, armazenamento e o restante do cluster. Posso ver se o serviço está em execução, verificar quanta memória está usando e abrir o console sem precisar ir para outro painel. Isso parece trivial até que o laboratório tenha serviços suficientes para que cada interface adicional se torne outro local para esquecer de verificar.
Meu laboratório doméstico funciona melhor quando não transformo cada serviço em um projeto de infraestrutura.
A solução de problemas também é mais direta. Se um contêiner parar de responder após uma atualização, sei por onde começar porque o contêiner em si fica próximo a todo o resto. Posso verificar seus recursos, confirmar a configuração da rede, reiniciá-la ou abrir o console e testar o serviço de dentro do convidado. Gasta-se menos tempo perguntando qual camada realmente é a responsável pelo problema.
Os backups seguem o mesmo padrão. O Proxmox pode incluir o contêiner LXC nos trabalhos agendados dos quais já confio, portanto, não preciso de uma rotina de backup separada para cada pequeno serviço. Ainda preciso saber onde estão os dados importantes, e um backup que nunca verifiquei é apenas um consolo no papel. No entanto, capturar todo o contêiner me fornece um caminho de recuperação fácil de encontrar e explicar posteriormente.
Docker ainda lida com algumas cargas de trabalho de maneira mais limpa
As pilhas de aplicativos se beneficiam da embalagem fornecida pelos contêineres
Docker conquista seu lugar em meu laboratório doméstico. Muitos projetos publicam imagens oficiais, fornecem exemplos do Compose e esperam claramente que os usuários implantem o software dessa forma. Ignorá-los pode transformar uma simples instalação em um trabalho manual desnecessário. Quando os desenvolvedores do aplicativo já empacotaram as dependências e documentaram os caminhos esperados, prefiro usar esse trabalho do que provar que posso montar as mesmas partes sozinho.
Meus serviços de mídia são o exemplo mais óbvio. Jellyfin e minhas diversas ferramentas de gerenciamento de biblioteca de mídia fazem sentido como contêineres Docker porque suas portas, caminhos de armazenamento e dependências podem ser definidos em um só lugar. Atualizar uma imagem geralmente é mais limpo do que modificar uma instalação manual e depois descobrir que um pacote de suporte abaixo foi alterado. Escrever também me dá uma visão geral útil quando vários serviços pertencem ao mesmo conjunto mais amplo.
Docker também é útil para testes curtos. Posso lançar algo, apontar para um armazenamento temporário, decidir se é útil e removê-lo sem deixar muito para trás. Um novo contêiner LXC pode fazer o mesmo trabalho, mas requer mais configuração e fico com outro convidado para nomear, configurar e, eventualmente, limpar. Para experimentos e aplicativos descartáveis que já são construídos em torno de imagens de contêiner, o Docker geralmente é uma escolha razoável.
Mais abstração pode criar mais espaço para solução de problemas
A conveniência desaparece quando o armazenamento e a rede se tornam confusos
Os problemas começam quando uso o Docker só porque a imagem está disponível. Um serviço principal pode incluir subitamente ligações, caminhos internos, redes de ponte, portas encaminhadas e variáveis de ambiente distribuídas por meio de um arquivo Compose. Nada disso é particularmente difícil quando estou familiarizado com a implantação. A irritação começa quando volto meses depois e tenho que lembrar como o aplicativo vê o host, como o host vê o aplicativo e qual caminho é o correto.
O armazenamento é a parte que provavelmente desperdiçaria meu tempo. O Docker pode fazer com que os arquivos de um aplicativo pareçam ocultos porque o caminho exibido no contêiner pode ter pouca semelhança com o caminho no host. Se o aplicativo não conseguir ler o diretório ou gravar no arquivo de configuração, terei que rastrear o mapeamento nas duas direções antes mesmo de chegar ao problema de permissões. Esse isolamento pode ser útil, mas não é gratuito.
A rede pode ser igualmente indireta. Um contêiner LXC pode ter seu próprio endereço na minha rede, facilitando sua identificação e acesso. Um serviço Docker pode compartilhar um endereço de host, expor uma das várias portas ou ser executado em uma rede interna na qual não pensei desde o dia em que foi criado. Essas escolhas são poderosas, mas dão a um pequeno bug mais espaço para se esconder quando algo para de responder.
Uma infraestrutura mais simples me permite lembrar menos coisas
A manutenção previsível é mais importante do que métodos de implantação impressionantes
Portanto, continuo transferindo certas cargas de trabalho de volta para contêineres LXC regulares. Não estou tentando eliminar o Docker, as máquinas virtuais ou qualquer coisa mais recente que surja. Tento parar de usar ferramentas específicas onde elas não resolvem um problema real. Se o serviço requer apenas um ambiente Linux modesto e um local de rede estável, o LXC geralmente me leva até lá com menos coisas para lembrar.
Essa diferença se torna mais aparente à medida que o laboratório cresce. Cada método de implantação adiciona seus próprios comandos, hábitos de atualização, layout de armazenamento e modos de falha. Posso documentar tudo isso, mas a documentação não desaparece devido à complexidade. Isso apenas me dá uma chance melhor de encontrar o caminho mais tarde.
O LXC também me deixa menos hesitante em fazer manutenção de rotina. Sinto-me mais confortável atualizando um contêiner se souber que posso shellá-lo, verificar seus pacotes e voltar para um backup do Proxmox se isso falhar. Com configurações que raramente toco, é provável que adie a atualização porque não quero mexer com a cadeia de montagens, variáveis e seleção de rede que as mantém unidas. Essa não é uma boa troca por um serviço que deveria ser chato.
Um bom laboratório doméstico não precisa de uma plataforma perfeita
Não creio que todos os serviços em um laboratório doméstico devam seguir a mesma filosofia de implantação. O Docker é ótimo para aplicativos empacotados e pilhas relacionadas, enquanto as VMs ainda fazem sentido se eu precisar de um isolamento mais forte ou de um sistema operacional diferente. Os contêineres LXC simples cobrem o amplo meio onde muitos serviços pequenos realmente pertencem. Eles são fáceis, fáceis de duplicar e familiares o suficiente para que eu possa eliminá-los sem me lembrar de quão inteligente eu estava tentando ser.
Voltar ao LXC não significa rejeitar outras ferramentas. É uma decisão de gastar a complexidade onde ela é conquistada. Meu laboratório doméstico funciona melhor quando não transformo cada serviço em um projeto de infraestrutura. Para sistemas silenciosos que precisam apenas ser executados, fazer backup e entender, um contêiner simples geralmente é suficiente.
