Neste post explico por que escolhi LXC para quase tudo, quando uma VM ainda faz sentido e o que muda na prática.

A diferença em uma frase #

Uma VM simula um computador inteiro, com kernel próprio. Um container LXC compartilha o kernel do host e isola só os processos, a rede e o sistema de arquivos.

Essa diferença decide quase tudo:

Por que quase tudo aqui é LXC #

Num servidor com 24 GB de RAM, cada gigabyte conta. Um container com um serviço web simples consome a memória do serviço e pouco mais. A mesma aplicação numa VM carrega junto um sistema operacional inteiro.

O que eu hospedo é, em sua maioria, serviço Linux leve:

• cofre de senhas;
• DNS interno;
• o conector do Cloudflare Tunnel;
• monitoria da internet;
• minhas próprias aplicações;
• este blog.

Nada disso precisa de kernel próprio. Para esse tipo de carga, LXC é mais leve para tudo, e é essa a razão principal da minha escolha.

Outro ganho é a agilidade. Container liga em segundos, o backup é pequeno e criar um container novo para testar algo é rápido o suficiente para eu não ter preguiça de separar cada serviço no seu próprio container. Separar serviços facilita muito na hora de restaurar só uma coisa.

A minha única VM: o jump server #

A exceção é a porta de entrada do homelab, o meu jump server. É por ele que eu chego por SSH quando estou fora de casa, e é nele que fica a monitoria dos acessos SSH.

Ele começou como um Debian completo, com ambiente gráfico. Com o tempo, enxuguei para modo texto e menos pacotes. Hoje, olhando com calma, ele poderia muito bem ser um container LXC. Mantive como VM, e existe um argumento a favor disso: numa máquina que fica exposta como ponto de entrada, o kernel próprio da VM adiciona uma camada de isolamento a mais entre quem tenta entrar e o host.

Se eu estivesse começando hoje, eu pensaria assim: VM para o que é exposto, precisa de outro kernel ou exige isolamento forte; LXC para o resto.

Quando uma VM é a escolha certa #

Mesmo sendo fã de LXC, eu usaria VM nestes casos:

• Outro sistema operacional: Windows, BSD ou qualquer coisa que não rode no kernel Linux do host.
• Módulos de kernel próprios: alguns softwares de VPN, de armazenamento ou de virtualização exigem carregar módulos, o que um container não pode fazer.
• Isolamento forte: serviços expostos à internet ou softwares em que você confia pouco.
• Appliances prontos: sistemas distribuídos como imagem completa, por exemplo alguns firewalls e sistemas de NAS.

Cuidados com LXC #

Container não é VM pequena. Três detalhes que vale saber:

1. Prefira containers não privilegiados. No Proxmox, o padrão ao criar pela interface é o container não privilegiado. Nele, o root do container não é o root do host, o que reduz bastante o estrago de uma invasão.
2. Docker dentro de LXC precisa de ajuste. É preciso ligar o recurso de nesting no container:

pct set <vmid> --features nesting=1

3. O kernel é do host. Uma atualização do Proxmox atualiza o kernel de todos os containers de uma vez. Isso é bom para manutenção, mas significa que um problema de kernel afeta todos juntos.

Para ver o que está rodando no nó, os dois comandos básicos são:

pct list   # containers LXC
qm list    # máquinas virtuais

Como isso escala num nó só #

Ter um único nó tem um limite óbvio: se a máquina para, tudo para. Para mim isso é aceitável hoje, porque a energia está coberta por uma bateria (contei no post sobre a EcoFlow como UPS) e os backups estão em dia.

O próximo passo que eu quero dar é uma segunda máquina para montar um cluster, o que traz outros cuidados, como quórum. Mas a lógica de LXC para quase tudo continua valendo: quanto mais leve cada serviço, mais coisa cabe em cada nó.

Resumindo #

• LXC para serviços Linux leves: menos memória, liga em segundos e tem backup pequeno.
• VM para outro sistema operacional, módulos de kernel, appliances e o que fica mais exposto.
• Comece não privilegiado e ligue o nesting só onde precisar de Docker.
• Um serviço por container facilita backup, restauração e limites.

Num ThinkCentre de 24 GB, essa escolha é o que permite rodar todos os meus serviços com folga e ainda sobrar espaço para testar coisas novas.