Quando vale a pena mudar de uma instância de contêiner para uma VM

A maioria das pessoas começa com uma instância de contêiner porque é a maneira mais rápida de executar uma carga de trabalho. Esse é um bom padrão. O problema começa quando você passa mais tempo lutando contra o meio ambiente do que fazendo o trabalho que veio fazer.

Mudar para uma máquina virtual (VM) não é uma opção “mais avançada” por si só. É uma escolha prática quando você precisa de um formato normal de servidor Linux e o tempo de execução do contêiner continua atrapalhando.

Se você quiser o rápido “qual devo escolher?” versão, leia isso primeiro: VM ou contêiner: como escolher em 60 segundos. Se você quiser a atualização do produto que introduziu as VMs, comece aqui: A computação agora oferece suporte a máquinas virtuais (VMs).

Os sinais de que é hora de mudar

Você não precisa de um grande motivo. Você precisa de um motivo sólido que continue voltando. Esses são os que importam na vida real.

Você continua precisando de sudo, pacotes do sistema ou mudanças no nível do sistema operacional. Se suas instruções de configuração começarem com “instalar esses pacotes” e você não conseguir fazer isso de forma limpa, você já está pagando o imposto. Uma VM oferece um sistema operacional completo e o controle que o acompanha.

Você quer que o Docker funcione normalmente. Se seu fluxo de trabalho depende do próprio Docker (especialmente do Docker Compose ou de pilhas de vários serviços), uma VM é o caminho mais limpo. Você gastará menos tempo com soluções alternativas e mais tempo com envios. Execute o Docker da maneira normal em uma VM de computação

Você está tentando executar uma carga de trabalho “em forma de servidor”. Alguns softwares esperam serviços de sistema, daemons em segundo plano e uma máquina que se comporte como um host Linux clássico. Às vezes, você pode dobrá-lo em um recipiente. Raramente vale a pena lutar quando uma VM está disponível.

Você precisa de um isolamento mais rígido para ter paz de espírito. Os contêineres são eficientes. As VMs oferecem limites mais fortes porque são um ambiente totalmente virtualizado. Se você estiver em uma situação de vários locatários, fazendo benchmarks ou trabalhando com requisitos operacionais mais rigorosos, esse isolamento pode ser a diferença entre confiança e dúvidas constantes.

Você quer um ambiente de sistema estável e persistente para o trabalho iterativo. Se seu fluxo de trabalho envolve a modelagem gradual da máquina (cadeias de ferramentas, configurações do sistema, dependências duradouras), é mais natural fazer isso em uma VM do que dentro de um ambiente de execução de contêiner destinado a permanecer enxuto.

Uma regra simples da qual gostamos: se você passou mais de uma hora tentando “fazer o contêiner se comportar como uma VM”, pare e use uma VM.

Quando você deve ficar em um contêiner

Às vezes, a resposta honesta é “não troque”.

Se sua carga de trabalho for um único serviço ou for baseada em um modelo conhecido, os contêineres geralmente permanecem mais simples. Eles também são mais fáceis de reproduzir e substituir. Se você estiver fazendo experimentos rápidos, trabalhos curtos ou qualquer coisa que queira criar e desmontar sem se preocupar com a manutenção do sistema operacional, os contêineres ainda são a ferramenta certa.

Se não tiver certeza, você também pode tratar os contêineres como a fase de observação e as VMs como a fase de construção. Esse caminho é comum e é sensato.

O que muda quando você muda para uma VM

Uma VM oferece controle total do sistema operacional. Isso significa que você escolhe um sistema operacional Linux, se conecta por SSH e gerencia a máquina como faria em qualquer outro servidor. Isso também significa que você possui mais da configuração. Você instalará as dependências do sistema, ficará de olho no uso do disco e decidirá como seus serviços serão executados.

O resto deve parecer familiar. Você ainda escolhe a localização e o hardware da mesma forma e ainda gerencia tudo no mesmo console do Compute.

Para obter detalhes do ciclo de vida, como comportamento de parar/iniciar e o que persiste, trate os documentos como a fonte da verdade: Iniciar, interromper e encerrar instâncias.

Como mudar sem drama

Você não precisa de um grande projeto de migração. Você precisa de um movimento controlado com um plano de reversão.

Comece listando o que a configuração do seu contêiner precisa ser executada: variáveis de ambiente, portas abertas, dados externos e quaisquer serviços com os quais ela se comunica. Isso é o que torna uma carga de trabalho “sua”, independentemente do tempo de execução.

Crie uma VM que corresponda à sua forma atual. Escolha o mesmo local e aproximadamente a mesma classe de hardware. Isso mantém a comparação de desempenho honesta e evita a introdução de uma segunda variável durante a migração. Se você precisar de uma atualização sobre a criação de VMs, use: Início rápido de computação.

Decida como você deseja executar a carga de trabalho na VM. Você tem duas opções comuns. Se sua carga de trabalho já é enviada como contêineres e você escolheu uma VM principalmente para “O Docker funciona normalmente”, o caminho mais simples geralmente é executar a mesma pilha na VM usando o Docker. Se você estiver migrando porque precisa de ferramentas no nível do sistema operacional, você pode executar o aplicativo diretamente na VM. Ambos são válidos. Escolha aquele que reduz o tempo de configuração e a manutenção futura da sua equipe.

Mova os dados deliberadamente. Não confie em “provavelmente ainda estará lá”. Coloque artefatos importantes em um local projetado para armazenamento e compartilhamento (armazenamento de objetos, um repositório, um repositório de conjunto de dados, tudo o que sua equipe já confia). Se você precisar de ajuda para pensar em persistência, este explicador tem como objetivo remover a ambigüidade: Uma VM mantém minhas alterações? Explicação da persistência na computação.

Teste a VM antes de alternar o tráfego. Execute a mesma carga de trabalho, confirme se ela se comporta e, em seguida, alterne. Mantenha a instância do contêiner por tempo suficiente para reverter se notar algo estranho.

Se você expor serviços à Internet, planeje as portas com antecedência. É aqui que as pessoas perdem tempo. Configure a conectividade quando souber do que precisa e mantenha-a restrita. Se você quiser a versão em inglês simples das opções de conexão, use: SSH, HTTPS, TCP, UDP: como expor um serviço de uma VM de computação.

Perguntas comuns que as pessoas fazem antes de mudar

A mudança interromperá meu fluxo de trabalho?

Não deveria, se você separar “configuração de carga de trabalho” de “tempo de execução”. Suas variáveis de ambiente, portas e caminhos de dados são o fluxo de trabalho real. O tempo de execução é o contêiner ou a VM que o hospeda.

Eu tenho que aprender muitas coisas novas?

Você fará mais configurações do Linux-y em uma VM, sim. Esse é o ponto. O negócio é que você pare de lutar contra o meio ambiente e comece a usar ferramentas normais. Para muitas equipes, isso representa uma redução líquida no esforço após a primeira configuração.

Devo mudar só porque as VMs existem agora?

Não. Se os recipientes já couberem, continue usando-os. Alterne quando tiver uma necessidade concreta: Docker, controle do sistema operacional, serviços do sistema, isolamento ou reprodutibilidade.

Experimente o Compute

Se você está atingindo limites com uma instância de contêiner, não a trate como uma falha pessoal. Trate isso como um sinal. Inicie uma VM, controle a si mesmo o sistema operacional e mantenha o trabalho em andamento.

‍