Abandonei os contêineres nativos do Docker Desktop e tudo ficou melhor

Eu adoro o Docker e seu ecossistema de contêineres tanto quanto o próximo patch. Com comandos simples, funcionalidade Compose e suporte massivo da comunidade, o Docker é fácil de aprender para iniciantes e confiável o suficiente para atender entusiastas veteranos de construção de projetos. Mas como alguém que começou com o Docker e mudou para outros tempos de execução de contêiner à medida que meu projeto DIY progredia, tenho que admitir que ele tem algumas peculiaridades que tornam um pouco difícil tarefas avançadas de hospedagem de contêiner.

Na verdade, depois de mudar para o Proxmox há alguns anos e experimentar a imensa utilidade do LXC, percebi que minha estação de trabalho Docker Desktop era na verdade uma bagunça não otimizada. Claro, demorou um pouco para se acostumar, mas os contêineres nativos do Linux se tornaram um substituto do Docker para tudo, desde cargas de trabalho auto-hospedadas até experimentos caprichosos em servidores domésticos.

Executar uma configuração do Docker Desktop baseada no Windows é mais problemático do que vale a pena

Não é uma boa ideia executar um tempo de execução de contêiner inchado em um sistema operacional que consome muitos recursos

Por mais que me doa admitir, eu costumava confiar no Docker Desktop quando era um adolescente com medo de Linux para satisfazer minhas travessuras. E, verdade seja dita, não é ruim operar alguns contêineres. Mas quando meus projetos DIY começaram a crescer, não fazia sentido administrar tudo com meu gerente diário. Meus sistemas de arquivos montados estavam espalhados, enquanto meu conjunto essencial de aplicativos auto-hospedados consumia recursos extras durante minhas sessões de jogo.

Mesmo se você deixar essas questões de lado, já é terrível, do ponto de vista da eficiência, executar contêineres dentro de algo tão inchado quanto o Windows. E à medida que me acostumei com o terminal Docker, a interface do desktop começou a parecer desnecessária. Acabei implantando o Proxmox em uma máquina de backup, mas a dependência do Docker ainda me impediu por um tempo.

A mudança para uma configuração Docker baseada em VM no Proxmox foi uma melhoria

Mas ainda não estou aproveitando todo o potencial do meu hardware

Se você já usou o Proxmox, provavelmente sabe que ele oferece suporte apenas a contêineres Linux e máquinas virtuais. No entanto, existem várias maneiras de criar e executar contêineres Docker em uma plataforma de virtualização. Seguir a rota Docker-in-LXC não parece terrível no papel, mas com o LXC e seu ambiente Docker aninhado compartilhando um núcleo de host, basta um contêiner não autorizado para comprometer a segurança do nó. Sem mencionar que os mapeamentos UID em um ambiente aninhado se tornam muito complexos, assim como as configurações de rede para esses contêineres nativos e privilegiados. E não, executar contêineres privilegiados nunca foi uma opção porque introduziriam mais vulnerabilidades de segurança.

Mudar para uma máquina virtual – sem GUI – e contar com uma versão não desktop do Docker parecia um compromisso sólido e, honestamente, me deu o melhor dos dois mundos. Foi assim que usei o Docker em meu primeiro ano como usuário do Proxmox e, contanto que eu tivesse RAM e recursos de CPU suficientes no host, não me importava de executar uma máquina virtual completa apenas no Docker. Mas assim que comecei a converter laptops dinossauros, mini PCs antigos e SBCs x86 com poucos recursos em meu laboratório doméstico Proxmox, a sobrecarga de uma máquina virtual tornou essa configuração muito menos pragmática. Se eu tivesse ficado com minha instância do Docker baseada em VM, provavelmente teria declarado meu laptop Lenovo de dez anos como lixo eletrônico e jogado fora um pouco, em vez de usá-lo como parte do meu cluster de “tecnologia ressuscitada” como faço hoje em dia.

Eventualmente mudei para LXC

Rapidamente percebi que eles são muito mais fáceis de usar do que eu esperava

Como um novo usuário do LXC, executar modelos TurnKey no Proxmox parecia muito complicado. Afinal, o LXC fornece um ambiente Linux completo como uma máquina virtual normal, que parecia muito mais complexa do que aplicativos Docker simples (especialmente aqueles implantados usando arquivos YAML do Compose). Mas agora que os uso há algum tempo, realmente aprecio como eles são personalizáveis. Um modelo TurnKey Debian é tudo que preciso para configurar tudo, desde o servidor llama.cpp até o roteador de sub-rede Tailscale, sem me preocupar com a tendência de gastar demais os recursos da máquina virtual.

Graças à talentosa comunidade Proxmox, eles são igualmente fáceis de instalar e operar. O repositório da comunidade Proxmox VE-Helper Scripts é uma mina de ouro para entusiastas de software livre que desejam trabalhar com ferramentas de qualidade de vida sem a complexidade adicional de gerenciar tudo manualmente. Inclui centenas de comandos de instalação de uma linha que podem configurar todos os aspectos de um aplicativo auto-hospedado em minutos. Caramba, eu ainda confio nesses scripts quando estou cansado demais para configurar um serviço manualmente, e a maior parte da minha pilha de contêineres é construída usando scripts PVE-Helper.

Docker não é de forma alguma terrível, só que confio mais no LXC

Embora eu possa parecer muito duro com o Docker, estou realmente grato por esse tempo de execução do contêiner. Docker foi o que me levou ao ecossistema de auto-hospedagem, e os serviços de armazenamento que implantei em meu nó TrueNAS são baseados neste tempo de execução amigável para iniciantes. Além disso, se construir um aplicativo FOSS obscuro do zero parecer muito problemático, eu provavelmente o implantaria em um ambiente Docker. Mas para a maioria das minhas necessidades de auto-hospedagem, o LXC fornece utilidade suficiente para substituir seus equivalentes do Docker.