Virtualização vs. Conteinerização: Qual é a diferença?

Nos tempos atuais de computação em nuvem, você provavelmente já ouviu falar de máquinas virtuais (VMs) e containers. Ambos têm um papel a desempenhar, seja na computação em nuvem ou em data centers mais tradicionais (incluindo data centers locais). Este artigo explicará as diferenças entre os dois, comparará e contrastará, e analisará alguns casos de uso mostrando onde um ou outro é preferível.

Diferença técnica em poucas palavras

Vamos primeiro esclarecer as diferenças técnicas. Para isso, precisamos entender o que é um kernel de Sistema Operacional (SO). O kernel é responsável por todo o software de baixo nível, como:

• Alocar tempo de CPU de forma justa para processar
• Gerenciar a RAM
• Conceder acesso a dispositivos de hardware, como discos rígidos (magnéticos ou SSD), teclados, mouses, monitores, interfaces de rede, etc.
• Fornecer uma camada de abstração para acessar arquivos em discos rígidos, comumente conhecidos como “sistemas de arquivos”
• Lidando com comunicações entre processos
• Implementando as várias camadas de rede do stack de rede (IP, TCP, UDP, etc.)
• E muitos outros aspectos muito longos para detalhar aqui

Isso é bastante, e de fato os kernels (como o kernel Linux) são bem grandes, representando milhões de linhas de código.

Então, qual é a principal diferença técnica entre uma VM e um container? Uma VM executa seu próprio kernel enquanto um container usa o kernel de seu host. Um pequeno diagrama pode mostrar isso visualmente:

Figura 1: Containers vs. VMs

Algumas pessoas chamam os containers de “VMs leves”, o que é bastante incorreto porque eles têm muito menos processos (e muitas vezes apenas um processo) em execução dentro deles. Executar um sistema operacional completo dentro de um container é muito difícil e, muitas vezes, impossível.

Por outro lado, uma VM “acreditará” que é um sistema operacional completo, rodando em algum hardware real. É completamente desconhecido que esse hardware seja, na verdade, simulado por um software executado dentro do kernel do host, chamado hipervisor.

Sobre VMs

Você pode ver uma VM como um sistema operacional (o sistema operacional convidado) executado em cima de outro sistema operacional (o sistema operacional host), que por sua vez é executado no hardware real. Para poder executar VMs, o sistema operacional host requer um hipervisor. Isso fornece uma camada de virtualização completa com algum hardware simulado, para que o sistema operacional convidado acredite que está sendo executado sobre algum hardware real. De resto, o sistema operacional convidado se comporta exatamente como um sistema operacional padrão.

É bom saber: quando você executa uma instância em um fornecedor de nuvem, o fornecedor de nuvem na verdade cria uma VM.

As vantagens de usar VMs são:

• O sistema operacional convidado se comporta exatamente como um sistema operacional padrão e não tem conhecimento de que está sendo executado em um hipervisor e não em um hardware real.
• Uma VM pode ser “salva” como um único arquivo e simplesmente movida ou replicada em outro lugar.

E as desvantagens:

• Uma VM é volumosa (em termos de espaço em disco, CPU e uso de RAM); isso ocorre porque ela é um sistema operacional completo por si só.
• Uma VM requer muita manutenção, novamente porque é um sistema operacional completo; observe que você pode evitar esse problema projetando sua infraestrutura para ser imutável.
• Uma VM é um pouco mais lenta que o sistema operacional host por causa da camada do hipervisor, embora hoje em dia isso seja mínimo.
• Uma VM, em geral, é um pouco lenta para iniciar porque contém muitos processos e serviços.

Sobre containers

Agora vamos explorar os containers. Uma boa maneira de entender os containers é vê-los como um ou mais processos em execução no kernel do host. Mas o kernel do host os mantém em seu próprio ambiente isolado, o que significa que esses processos não podem ver mais nada em execução neste kernel. Os processos dentro de um determinado container podem ver uns aos outros, mas não podem ver os processos em execução dentro de outros containers ou do kernel do host.

Para que o kernel do host consiga executar containers, ele precisa da tecnologia de software necessária para poder segregar processos conforme descrito acima. O kernel Linux fornece essa tecnologia, que é chamada de “namespaces”.

Agora você pode ver que é impossível executar um sistema operacional completo dentro de um container porque há apenas um kernel em execução: o do sistema operacional host. Consequentemente, os containers não devem ser vistos como “VMs leves”, mas mais como caixas fechadas contendo processos. Os processos podem ser executados dentro de suas caixas, mas não podem sair de suas caixas e entrar em outras caixas.

Sem entrar em detalhes, é útil saber que o kernel do host pode ser ajustado para que os processos em um determinado container possam “ver” e “tocar” coisas que estão fora de sua caixa. Mas isso é um grande risco de segurança e deve ser evitado o máximo possível.

Então, quais são as vantagens de usar containers?

• Os containers são “leves”, no sentido de que executam apenas os processos necessários para a workload fornecida, o que significa que você economiza CPU, RAM e espaço em disco em comparação com VMs.
• Os containers geralmente iniciam rapidamente, mas isso depende do software que eles executam; de qualquer forma, eles iniciam mais rápido do que o mesmo software executado dentro de uma VM.
• Existem registros públicos que fornecem um grande número de imagens de containers para muitas aplicações, como o Docker Hub.
• A superfície de ataque é menor em comparação às VMs.

No entanto, existem desvantagens no uso de containers:

• Você não pode executar um sistema operacional completo dentro de um container.
• Em teoria, uma exploit em um container pode levar a exploits em outros containers. No entanto, isso é muito raro hoje em dia porque a tecnologia de namespace do Linux (que é usada para executar containers) agora é muito madura e segura.
• Você não pode salvar um container em um único arquivo e movê-lo.
• O sistema de arquivos raiz é efêmero, ou seja, tudo o que você escrever nele será destruído quando você encerrar o container.

Comparando VMs e containers

Agora vamos passar para as diferenças práticas entre VMs e containers. Obviamente, a primeira coisa a ser observada é que você pode executar containers dentro de VMs, mas não o contrário.

VMs e containers atendem a propósitos diferentes. Uma VM executa um sistema operacional completo e é projetada para ser usada a longo prazo. Por outro lado, um container executa uma workload específica e é efêmero e imutável por natureza. Uma consequência disso é que, se seus containers exigirem armazenamento de longo prazo (ou seja, armazenamento persistente que sobreviverá quando o container for reiniciado, por exemplo), ele precisará montar volumes, que precisam ser declarados e gerenciados separadamente.

Em termos gerais, os containers são mais ágeis para trabalhar do que as VMs porque são projetados para se concentrar em uma única tarefa. Na verdade, quando seu caso de uso requer VMs, normalmente seria difícil usar containers. No entanto, quando seu caso de uso pode usar containers, normalmente você pode escolher entre containers e VMs (embora a arquitetura seja bem diferente entre essas duas opções).

Você provavelmente já ouviu falar de ferramentas de orquestração de containers, como o Kubernetes. Se estiver usando containers, você provavelmente precisará de uma ferramenta desse tipo, que tem sua própria curva de aprendizado e considerações de segurança. Se estiver usando VMs do seu fornecedor de nuvem, normalmente você só precisará das ferramentas de gerenciamento fornecidas por esse fornecedor, como grupos de escalonamento automático e balanceadores de carga. Se você estiver usando VMs em um data center tradicional, provavelmente precisará de uma ferramenta de orquestração orientada a VM, como o VMware vSphere, que novamente terá sua própria curva de aprendizado (provavelmente ainda mais íngreme do que as ferramentas de orquestração de containers).

Por fim, os containers são mais adequados para configurar uma malha de serviço, uma arquitetura alternativa ao uso de balanceadores de carga internos.

Figura 2: Malha de serviço vs. balanceadores de carga

Podemos ver intuitivamente nos diagramas acima que a segunda arquitetura consome mais recursos do que a primeira. É possível criar uma malha de serviços, por exemplo, usando o HashiCorp Consul, mas é mais trabalhoso e difícil de configurar do que usar, digamos, o Istio em um cluster Kubernetes.

Aspectos de segurança

Embora superficialmente semelhantes, VMs e containers apresentam desafios de segurança muito diferentes. Em primeiro lugar, as camadas de software que permitem ambas as tecnologias (hipervisores e namespaces do kernel, respectivamente) estão agora muito maduras e muito seguras, então não devem ser uma preocupação para nenhuma delas em termos de segurança.

As VMs basicamente executam um sistema operacional inteiro, portanto, todas as etapas necessárias para proteger um sistema inteiro são necessárias para uma VM, como:

• Fortalecimento do SO
• Implementando software antivírus
• Aplicação de correção regular e oportuna (pode ser evitada se usar infraestrutura imutável)
• Execução de processos como usuários regulares em vez de root
• Fortalecendo o servidor SSH
• Configurando o firewall
• Reduzindo a superfície de ataque (removendo software desnecessário)
• Usando scanners para identificar vulnerabilidades ao construir a imagem
• Adotando ferramentas para identificar vulnerabilidades em tempo de execução

Como podemos ver nesta lista, proteger uma VM é um trabalho árduo. Muito disso é feito ao construir a imagem que será usada para executar a VM, mas uma quantidade significativa de trabalho ainda é feita em tempo de execução para detectar vulnerabilidades e um sistema comprometido.

Em contraste, proteger um container é mais fácil:

• Certifique-se de não executar o container no modo privilegiado.
• Execute o(s) processo(s) como usuário comum, não como root.
• Garanta que as permissões do sistema de arquivos sejam as mais restritivas possíveis.
• Use scanners para identificar vulnerabilidades ao construir a imagem.

Ainda há aspectos de segurança de tempo de execução relacionados à execução de containers, mas eles geralmente são mais fáceis de manusear e implementar do que para VMs.

Em ambos os casos, todas as etapas descritas para proteger o sistema operacional host no caso da VM acima também se aplicam ao sistema operacional host que executará as VMs/containers.

A CrowdStrike pode fornecer várias soluções para proteger suas workloads contra vírus e outros softwares maliciosos, bem como ataques de rede.

A diferença entre VMs e containers é bem fácil de entender em nível técnico. O contraste entre eles se torna mais aparente e interessante quando observamos os casos de uso relevantes para cada um.

Desde que o Docker foi criado, o uso de containers tem aumentado constantemente. Eles são ágeis e impõem imutabilidade. Além disso, combinados com um orquestrador poderoso como o Kubernetes, eles têm vantagens significativas sobre as VMs. É por isso que os containers estão lentamente assumindo o controle, embora algumas organizações continuem a usar VMs tradicionais por um longo tempo.