Quais são as vantagens e desvantagens de configurar contentores, máquinas virtuais e bare metal num servidor doméstico para programadores?

Use contentores para aplicações reproduzíveis, VMs para fronteiras de kernel ou de confiança e bare metal apenas quando o acesso ao hardware ou a simplicidade do anfitrião o exigirem claramente.

Um servidor doméstico para programadores raramente precisa de um modelo de implementação universal. Uma arquitetura útil atribui cada carga de trabalho com base no isolamento, na dependência do sistema operativo, no estado, no acesso ao hardware e no método de recuperação, mantendo depois o anfitrião suficientemente simples para ser recriado.

Escolha a fronteira de isolamento antes do ambiente de execução

Os contentores partilham o kernel do anfitrião, pelo que são eficientes para serviços concebidos para a mesma base Linux. As VMs incluem os seus próprios sistemas operativos convidados, o que cria uma fronteira entre kernels mais forte e permite requisitos de sistema operativo diferentes. O bare metal elimina uma camada de virtualização, mas acopla a carga de trabalho diretamente ao anfitrião.

Uma comparação entre a arquitetura de contentores e de VMs prática destaca esta distinção entre kernel partilhado e sistema operativo separado. Use-a como modelo de isolamento, não como afirmação de que um formato é universalmente mais seguro ou mais rápido.

Coloque aplicações reproduzíveis e com o mesmo nível de confiança em contentores. Use uma VM quando uma carga de trabalho precisar de um kernel diferente, de testes arriscados ou de uma fronteira de atualização independente. Reserve o bare metal para o hipervisor, o proprietário do armazenamento ou um serviço dependente de hardware.

Coloque o estado persistente fora da camada descartável

Uma imagem de contentor pode ser recriada; o respetivo volume da base de dados, não. Um instantâneo de VM é conveniente, mas não é automaticamente uma cópia de segurança da base de dados consistente com a aplicação. Um sistema de ficheiros bare metal pode ser redundante; ainda assim, precisa de uma cópia independente.

Defina a unidade de restauro de cada serviço antes da implementação. Se o restauro exigir a preservação de um anfitrião não documentado, a configuração está demasiado acoplada.

Atribua o acesso ao hardware de forma deliberada

O acesso à GPU, HBA, dispositivos USB e redes especializadas pode ser mais simples em bare metal, mas o passthrough para uma VM pode criar uma fronteira de falha mais clara. Os contentores podem aceder aos dispositivos com menos sobrecarga, mas esse acesso enfraquece o isolamento e torna-os dependentes dos controladores do anfitrião.

Em laboratórios domésticos mistos, é comum usar um modelo híbrido de VMs e contentores, pois uma VM pode definir o limite de confiança ou de sistema operativo, enquanto os contentores permitem empacotar aplicações de forma reproduzível dentro dela.

Escolha o acesso direto ao dispositivo só depois de confirmar o comportamento após o reinício, o suporte para reinicialização do dispositivo, as consequências para as cópias de segurança e o que acontece quando o kernel do anfitrião muda.

Featured

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

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Adapte a rede ao domínio de falha

Mantenha os serviços de infraestrutura, como DNS, proxy inverso e monitorização, em redes estáveis. Coloque as VMs e os contentores experimentais em pontes ou VLANs separadas quando não devam aceder à gestão do armazenamento nem aos destinos das cópias de segurança.

Disponibilize aplicações através de um único percurso de acesso controlado, em vez de encaminhar uma porta para cada carga de trabalho. Use identidades de serviço e credenciais com permissões limitadas para que uma aplicação de pré-visualização comprometida não possa administrar o anfitrião.

Se for necessário um sistema de ficheiros partilhado, escolha deliberadamente o modelo de acesso. A comparação entre SMB e NFS ajuda a distinguir as partilhas destinadas aos utilizadores das montagens de infraestrutura Linux.

Use uma configuração híbrida por defeito e defina condições claras para mudar

Uma configuração predefinida sensata é um hipervisor mínimo instalado diretamente no hardware ou um anfitrião Linux, uma VM para cargas de trabalho que precisem de um limite de confiança ou de sistema operativo separado e contentores para serviços reproduzíveis. Assim, preserva a flexibilidade sem transformar cada aplicação num sistema operativo convidado.

Valide a configuração recriando um contentor a partir da configuração, restaurando uma VM para armazenamento alternativo e recuperando uma base de dados persistente sem usar a instância de execução original. Meça a utilização do CPU e da memória, a latência do armazenamento e a duração das cópias de segurança durante a concorrência normal.

Retire uma carga de trabalho dos contentores quando o acoplamento ao kernel ou o risco de confiança forem inaceitáveis. Retire-a de uma VM quando o acesso ao hardware ou a sobrecarga medida impedirem a tarefa. Evite executá-la diretamente no hardware quando a reconstrução do anfitrião exigir alterações profundas à aplicação.

Regra final de configuração

A configuração é aprovada quando cada serviço tem uma função identificada, um estado protegido, um percurso de acesso controlado, uma restauração testada e um critério mensurável para dividir ou expandir a topologia.