Container vs máquina virtual: diferenças

Quem hospeda uma aplicação logo esbarra nos dois termos: a VPS que você aluga é uma máquina virtual, e a plataforma que recebe seu código costuma rodá-lo num container. Parecem a mesma coisa, mas isolam de jeitos diferentes, e isso muda o custo, a segurança e o trabalho de manutenção.

O que é uma máquina virtual?#

Uma máquina virtual (VM) é um computador simulado por software. Um hypervisor divide o hardware físico e entrega a cada VM CPU, memória e disco virtuais. Dentro dela roda um sistema operacional completo, incluindo o kernel, o núcleo que conversa com o hardware. Como roda um sistema inteiro, a VM exige mais CPU, memória e armazenamento, segundo a documentação da Microsoft.

O resultado é um computador à parte: você pode instalar qualquer sistema compatível, mexer em drivers e abrir qualquer porta. Em troca, atualizar o sistema, configurar o firewall e mantê-lo seguro passa a ser seu trabalho. É o modelo descrito em VPS vs plataforma de nuvem.

O que é um container?#

Um container é, nas palavras da documentação do Docker, um processo isolado com todos os arquivos de que precisa para rodar. Não existe segundo sistema operacional: todos os containers de uma máquina compartilham o mesmo kernel do host. A Microsoft o descreve como uma área leve e isolada que roda sobre o kernel do host e contém só a aplicação e algumas APIs do sistema em modo usuário.

Você pode ver isso num host Linux com o Docker Engine instalado direto (o Docker Desktop roda os containers dentro de uma VM, então ali o kernel mostrado é o dessa VM). Os dois comandos abaixo imprimem a mesma versão de kernel, porque o container não tem kernel próprio:

uname -r
docker run --rm alpine uname -r

Como o container isola sem um kernel próprio?#

No Linux, o isolamento vem de dois recursos do kernel:

• Namespaces fazem um recurso global parecer exclusivo de quem está dentro do namespace. Há namespaces para pontos de montagem (mnt), IDs de processo (pid), rede (net), nome de host (uts), usuários (user) e outros. Dentro do container, o processo enxerga só os próprios processos, a própria rede e o próprio sistema de arquivos.
• Cgroups (control groups) agrupam processos e limitam e monitoram o uso de recursos, como memória e CPU.

Por isso dá para limitar um container na hora de subir:

docker run --rm -m 256m --cpus 1 alpine echo "limitado a 256 MB e 1 CPU"

Esse isolamento é real, mas é feito pelo mesmo kernel que todos usam. Um defeito grave nesse kernel afeta todos os containers da máquina. Numa VM, uma falha no kernel do convidado fica restrita àquela VM: para atingir as outras, o invasor precisaria também escapar do hypervisor.

Container vs VM lado a lado#

A tabela segue a comparação da Microsoft para isolamento, sistema operacional e atualizações. Existem variações: containers com isolamento reforçado por uma VM leve, e containers rodando dentro de VMs (um arranjo comum na nuvem).

Quando usar um container?#

O container serve bem quando a aplicação é um processo comum e você quer empacotá-la e movê-la sem dor de cabeça:

• bots, APIs e sites em Node.js, Python, Java e linguagens parecidas;
• ambientes iguais em desenvolvimento e produção: a imagem leva as dependências junto, o que ajuda a evitar o "na minha máquina funciona";
• vários serviços pequenos dividindo o mesmo servidor;
• deploys frequentes, em que trocar a imagem é mais simples que reconfigurar uma máquina.

Configurações como chaves e URLs de banco ficam fora da imagem, em variáveis de ambiente, para a mesma imagem servir em qualquer ambiente.

Quando usar uma máquina virtual?#

A VM é a escolha quando você precisa do que o container não dá:

• um sistema operacional diferente do host, como Windows num servidor Linux;
• acesso ao kernel: módulos, drivers ou parâmetros de sistema;
• uma barreira de segurança forte entre cargas que não confiam umas nas outras;
• software que espera uma máquina inteira, administrada à mão.

Se você só quer manter um processo no ar, uma VM costuma ser mais máquina do que o necessário. As duas coisas também se combinam: a VPS que você aluga pode ser a base de um servidor Docker. Para o passo seguinte, veja o que é deploy.

Como fazer isso na Square Cloud#

A Square Cloud é hospedagem self-service baseada em containers. Cada aplicação roda em um container isolado, num datacenter Tier 3 em Nova York, sempre ligado e sem modo de suspensão, com reinício automático (ligado por padrão no deploy pelo painel) quando o processo encerra com erro. Você não administra um sistema operacional: faz o deploy do código e define a RAM da aplicação.

O deploy pode ser por upload de ZIP no painel, pela CLI, pelo GitHub (um push faz o deploy, via GitHub Action oficial ou webhook) ou pela extensão do VS Code. Há diversos runtimes, como Node.js, Python, Java, Go e Rust: veja os runtimes disponíveis hoje em Runtimes. As variáveis de ambiente ficam no painel, na API ou na CLI e valem no próximo restart, sem rebuild. Para escalar, você muda a RAM da aplicação (escala vertical); não há autoscaling.

Não há acesso root (o processo roda como usuário sem privilégio) nem Dockerfile ou imagem própria. Se você precisa de root, de outro sistema operacional ou de acesso ao kernel, o caminho é uma VM. Se um container basta, veja o que está incluído nos recursos da Square Cloud.