VM vs LXC vs Docker: que fronteira se adequa a serviços fiáveis, privilegiados e expostos à Internet?

Utilize o Docker para aplicações de confiança e bem empacotadas; utilize o LXC para ambientes de sistema Linux leves; utilize uma VM quando o serviço precisar de um kernel independente ou de uma fronteira de confiança mais forte.

Não são três invólucros intercambiáveis. O Docker empacota aplicações, o LXC funciona mais como um sistema Linux compacto e uma VM virtualiza o hardware para um kernel convidado separado. A escolha certa muda quando um serviço está exposto à Internet, precisa de privilégios amplos, utiliza uma GPU ou um dispositivo USB, ou tem de ser restaurado sem confiar no estado do anfitrião.

Classifique o nível de confiança e defina a fronteira do kernel

Comece por classificar cada serviço como interno de confiança, infraestrutura privilegiada ou exposto à Internet e potencialmente hostil. Depois, registe quem fornece a imagem ou os pacotes, a que dados pode aceder e se uma intrusão pode chegar às redes de gestão, de cópias de segurança ou dos ficheiros da família.

Um serviço não é de baixo risco apenas por ser pequeno. Um painel público sem montagens do anfitrião pode ser mais seguro do que uma ferramenta interna de automatização com credenciais de rede, acesso ao socket do Docker e permissões de escrita em todas as partilhas.

Este primeiro critério pode pôr fim à comparação. Se a carga de trabalho não puder partilhar o kernel do anfitrião, o Docker e o LXC ficam excluídos, independentemente do menor consumo de memória; se for uma aplicação de finalidade única e de confiança, com montagens limitadas, uma VM pode acrescentar tarefas de administração sem alterar o risco prático de forma significativa.

O Docker e o LXC isolam processos enquanto utilizam o kernel do anfitrião; uma VM executa um kernel convidado por trás de uma fronteira imposta pelo hipervisor. Uma comparação independente da partilha do kernel e do isolamento de VMs explica por que motivo a diferença de segurança é arquitetural, e não uma afirmação de que todos os contentores são inseguros.

O Docker costuma restringir a unidade a uma aplicação e às respetivas dependências. O LXC oferece um ambiente de utilizador mais completo, com init, pacotes, contas e serviços do sistema. Isso torna o LXC prático para um ambiente Linux pequeno, mas não o transforma numa VM.

Escolha a VM quando forem importantes a diversidade de kernels, a execução de código não fidedigno ou um limite claro para a firewall e as atualizações ao nível do sistema convidado. Continue a considerar o Docker ou o LXC quando o kernel do anfitrião for uma dependência partilhada aceitável e a simplicidade operacional for mais importante do que ter um sistema operativo convidado separado.

Deixe que os privilégios e o acesso ao hardware alterem a opção predefinida

Um serviço Docker de confiança é eficiente até precisar de rede do anfitrião, capacidades alargadas, montagens de sistema com escrita ou acesso ao socket de gestão de contentores. Cada exceção enfraquece o limite restrito da aplicação e aumenta as vantagens de transferir o serviço para uma VM própria ou reformular o caminho de acesso.

O LXC pode ser uma solução intermédia prática para um serviço Linux que precisa de um gestor de pacotes normal, um nome de anfitrião estável e acesso a dispositivos selecionados. No entanto, o LXC privilegiado, as montagens bind extensas e o Docker aninhado aumentam o acoplamento, pelo que a poupança de recursos deve ser ponderada face a atualizações e recuperação mais difíceis.

Para uma GPU, HBA, coordenador USB ou placa de rede especial, teste o comportamento de reposição, as permissões e a persistência após o reinício. O acesso direto ao dispositivo pode ser mais simples no anfitrião, mas uma VM com passagem direta do dispositivo pode definir com maior clareza os limites de propriedade, quando o hardware e a configuração de IOMMU o permitem.

Trate a exposição à Internet como uma decisão de rede e identidade

Coloque os serviços públicos por trás de um único proxy inverso controlado ou de um acesso VPN, mantenha as interfaces de gestão privadas e limite as credenciais dos serviços aos menores conjuntos de dados necessários. O isolamento do ambiente de execução não compensa um painel de administração público, segredos reutilizados ou acesso irrestrito ao armazenamento e às cópias de segurança.

Uma discussão da comunidade sobre a forma como os operadores distribuem as cargas de trabalho entre Docker, LXC e VMs mostra que as implementações reais recorrem muitas vezes a uma solução híbrida: uma VM estabelece o limite de confiança e, em seguida, o Docker dentro dela permite empacotar aplicações. Esta é uma terceira arquitetura, não uma admissão de que uma das opções falhou.

Para um serviço público com consequências graves, prefira uma VM ou um anfitrião dedicado, mesmo que o Docker o execute a um custo inferior. Para uma aplicação de baixo risco com implementação imutável, montagens limitadas e controlos de rede rigorosos, o Docker pode continuar a ser a solução mais simples.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Compare a Unidade que Vai Atualizar, Salvaguardar e Restaurar

É mais fácil recriar um contentor Docker quando os ficheiros Compose, os segredos, as versões e os volumes persistentes estão claramente separados. Um contentor LXC pode ser restaurado como uma unidade de sistema, mas as alterações manuais a pacotes feitas no seu interior provocam desvios de configuração, a menos que sejam documentadas ou automatizadas.

Uma máquina virtual costuma consumir mais memória e armazenamento, mas faz do sistema convidado uma unidade distinta de cópia de segurança e reversão. Essa vantagem só é real depois de um teste de restauro; um instantâneo no mesmo anfitrião não é uma cópia de recuperação independente.

Escolha a Fronteira por Serviço, Não por Servidor

Escolha Docker para conjuntos de aplicações fidedignas, com montagens restritas e definições reproduzíveis. Escolha LXC para serviços de sistema Linux eficientes que beneficiem de um espaço de utilizador mais completo e não precisem de um kernel independente. Escolha uma máquina virtual para cargas de trabalho não fidedignas ou expostas à Internet com consequências graves, sistemas operativos alternativos ou acesso exclusivo ao hardware que beneficie do isolamento do sistema convidado.

A decisão sobre o sistema operativo para o servidor doméstico é a camada seguinte, porque a escolha do anfitrião determina quais os controlos de cópia de segurança, rede, contentores e máquinas virtuais que são viáveis. Um servidor misto pode usar as três fronteiras sem tratar nenhuma como a opção predefinida universal.

Pare de otimizar a densidade quando um serviço precisa de acesso privilegiado ao anfitrião, expõe funcionalidades de administração sensíveis ou não pode ser restaurado de forma independente. A fronteira correta é a opção menos complexa que ainda contém a falha que realmente pretende evitar.