VM ou contentor? O que vender no Proxmox

O Proxmox VE corre dois tipos de convidado. Uma máquina virtual KVM arranca o seu próprio kernel por trás de firmware emulado, e um contentor LXC partilha o kernel do anfitrião onde assenta. Para um cliente que compra um VPS, ambos são «um servidor com root», e é por isso que a comparação costuma ser feita numa tabela de marketing com linhas sobre densidade e sobrecarga.

Essas linhas são verdadeiras e não são as que lhe vão custar dinheiro. O que custa é o conjunto de sítios onde os dois parecem idênticos na API e se comportam de forma diferente por baixo, porque é aí que um painel, um sistema de faturação ou um fluxo de encomenda faz discretamente a coisa errada e ninguém dá por isso durante um mês.

Acrescentámos há pouco um segundo tipo de computação à nossa própria integração com o Proxmox, o que obrigou a ler a API com a pergunta específica «onde é que estes dois divergem». Foi isto que saiu daí, pela ordem em que nos surpreendeu.

Um cluster, um espaço de números

Comece pelo identificador, porque tudo o resto depende dele. Um convidado do Proxmox é endereçado por um número, e é tentador assumir que máquinas virtuais e contentores têm cada um o seu intervalo: 100 podia ser uma VM e 100 podia também ser um contentor, distinguidos pelo tipo.

Não podem. O espaço de números é partilhado por todo o cluster, e três propriedades da API dizem-no. O ponto final que entrega o identificador livre seguinte não recebe parâmetro nenhum de tipo, pelo que não pode saber qual dos dois está prestes a criar. A listagem de recursos do cluster devolve máquinas e contentores em conjunto no mesmo campo numérico. E a própria lista de convidados do cluster é indexada por esse número.

Isto tem uma consequência direta para tudo o que guarde convidados do Proxmox na sua própria base de dados. Ponha o tipo na restrição de unicidade, de modo a que «máquina 5001» e «contentor 5001» sejam duas linhas diferentes, e fica com um esquema capaz de conter dois registos para um convidado e de os deixar disputá-lo. O identificador é único por si só, e o tipo é uma observação guardada ao lado dele. Se estiver a escolher intervalos para uma frota, a aritmética em escolher um intervalo de VMID no Proxmox não muda quando chegam os contentores, e é esse o ponto.

Um contentor é desempacotado, não clonado

A segunda divergência é o caminho de criação, e é maior do que parece.

Uma máquina virtual é normalmente produzida clonando um modelo: indica-se uma origem, escolhe-se completa ou ligada, e obtém-se uma cópia de uma imagem de disco. Um contentor é produzido desempacotando um arquivo para um volume novo. Não há convidado de origem, não há escolha entre completa e ligada, e não há unidade de cloud-init, porque não há nada onde ligar uma unidade.

Portanto o corpo do pedido quase não tem campos em comum com o que cria uma máquina. Um contentor quer ostemplate a apontar para um arquivo num armazenamento, uma opção unprivileged, um hostname, um rootfs e um valor de swap. Uma máquina quer scsi0, scsihw, bios, boot e um ide2 quando arranca a partir de uma ISO. Reutilizar um vocabulário para o outro é o erro a evitar de propósito: as palavras são suficientemente parecidas para que um campo chamado disk signifique duas coisas diferentes no mesmo código dentro de um ano.

Dois pormenores desse corpo vale a pena roubar, seja qual for a base sobre a qual construa.

rootfs=<storage>:<size> é uma alocação, não uma referência. Significa «criar um volume novo com estes gigabytes neste armazenamento». A forma que nomeia um volume existente é quase idêntica e faz uma coisa categoricamente diferente: adota um volume que pode ainda conter dados de outra pessoa.

Deixar um parâmetro de fora é a resposta segura. Aninhamento, keyctl, FUSE, montagens de ligação e passagem de dispositivos estão todos desligados a menos que os envie, e não há um valor «vazio» de que se tenha de lembrar. A postura correta por omissão para uma plataforma de alojamento é, portanto, um pedido curto e não um pedido longo. O campo da arquitetura conta a mesma história: o Proxmox deriva-a do arquivo, e enviar uma que discorde falha no momento do desempacotamento.

Três coisas que um contentor nunca fará

Algumas lacunas são itens de roteiro. Três são estruturais, e confundir as duas categorias no seu próprio produto é a forma de acabar a prometer uma funcionalidade que não pode existir.

Cinco dessas linhas precisam de mais do que uma célula, em três grupos.

O arranque pela rede, a instalação por ISO e a escolha de firmware são impossíveis por uma razão, não por três: um contentor não tem firmware. Não corre um carregador de arranque, não tem ordem de arranque, e iniciá-lo não envolve nada a que se pudesse dizer para tentar primeiro a rede. Se vender um produto onde «reinstalar a partir da nossa biblioteca de imagens» é uma funcionalidade, note que o caminho PXE de uma resposta DHCP a uma instalação pronta não tem equivalente em contentores. Reconstruir um contentor é um mecanismo diferente com garantias diferentes, e merece um ecrã próprio em vez de um botão acinzentado.

A consola é o mesmo tipo de diferença com um nome familiar. O Proxmox dá-lhe uma consola para um contentor, mas é um terminal sobre um websocket, não o framebuffer de um adaptador gráfico, e um cliente VNC não o desenha. Um separador de consola passa a ter duas implementações por trás, e a resposta honesta no entretanto é dizer que o separador ainda não está disponível em vez de abrir um visualizador que mostra um retângulo preto.

Pausar e hibernar merecem uma nota de rodapé porque apanham a lógica de aplicação de limites. Se a sua plataforma suspende uma máquina quando um cliente ultrapassa um limite, e «suspender» significa pausar, então os contentores ficam completamente fora dessa aplicação: o comando é recusado, nenhum trabalhador comunica nada, e o cliente continua a correr. A fronteira pertence ao modo, não ao comando. Parar um contentor é perfeitamente possível.

O swap é uma decisão de produto, não uma predefinição

Chegámos ao que vai aparecer em pedidos de suporte.

O Proxmox dá a um contentor novo 512 MiB de swap a menos que diga o contrário. Herde isso em silêncio e um plano vendido como «2 GiB de memória» entrega 2,5 GiB de memória utilizável, e a diferença não aparece como um número maior em lado nenhum: aparece como um contentor que fica lento em vez de atingir uma condição honesta de falta de memória, meses mais tarde, num anfitrião que começou a fazer swap.

Enviamos o valor explicitamente em cada criação, e o valor que escolhemos é zero. Zero é uma escolha e não uma ausência. Seja qual for o que escolher, escolha-o deliberadamente, escreva-o no plano, e garanta que o número que um cliente vê é o número que o hipervisor recebe.

Medir o swap tem o seu próprio preço. A listagem em massa que lhe dá contadores de CPU, memória, disco e rede para todos os convidados de um cluster não transporta campo nenhum de swap, para nenhum dos tipos. O único sítio onde o Proxmox o comunica é o ponto final de estado por convidado, pelo que é uma chamada HTTP extra por contentor em execução, para sempre. Lemo-lo uma vez por minuto: três vezes por minuto triplica a carga sobre o hipervisor de outra pessoa por um número que se move em minutos, e uma vez a cada cinco minutos coloca exatamente uma amostra num agregado de cinco minutos, o que torna a coluna do máximo igual à da média e, portanto, decoração.

Dois defeitos que enviámos por assumir que eram a mesma coisa

Ambos estavam em produção há meses antes da ronda que os foi procurar.

O primeiro: o nosso ecrã de importação listava contentores como máquinas virtuais. A listagem de recursos do cluster com type=vm não é um filtro de QEMU, devolve os dois tipos, e o campo que diz qual deles era simplesmente não estava a ser lido. Nada falhou. A lista estava errada.

O segundo era mais silencioso. Cada contentor em execução recebia duas chamadas ao agente convidado por ronda de sondagem, mais uma depois de cada comando, contra um caminho que só existe para o QEMU. Cada uma era uma falha garantida, e nada veio ao de cima, porque um enriquecimento opcional falhado deve ser sobrevivível e era. Foi encontrado por um teste que conta que caminhos são chamados em vez de afirmar sobre resultados, o que é um hábito que vale a pena copiar: afirme apenas sobre resultados e uma categoria inteira de trabalho inútil fica invisível.

O que escreveríamos antes de vender qualquer um deles

Se está a decidir o que um produto de alojamento deve oferecer no Proxmox, quatro perguntas levam-no quase até ao fim.

1. 01O tipo é uma propriedade do plano ou uma escolha na finalização da encomenda? Ambas as opções são defensáveis. Uma predefinição por baixo da escolha não é: um cliente que encomendou um contentor e recebeu uma máquina ficou com um modelo de segurança diferente, um kernel diferente e um conjunto de capacidades diferente do que escolheu.
2. 02Que recusas são permanentes e quais são temporárias? Diga-o na interface, com essas palavras. «Não é possível num contentor» e «ainda não está construído» são promessas diferentes.
3. 03De onde vem a proteção contra falsificação de origem? A lacuna honesta no nosso próprio trabalho: uma máquina clonada recebe filtragem de IP na entrega e um contentor ainda não. O Proxmox tem os mesmos pontos finais de firewall para ambos, pelo que é um passo de construção e não um obstáculo, mas um contentor entregue sem isso pode enviar tráfego a dizer que é outra pessoa.
4. 04O que mostra a monitorização para um contentor? Tudo o que derive de um agente convidado, de um framebuffer ou de firmware fica vazio. Vazio não faz mal. Vazio apresentado como um zero saudável faz.

Temos o campo do plano, o caminho de encomenda e o pedido de criação construídos e medidos contra a forma HTTP em bruto da API. O que não fizemos foi criar um contentor no hipervisor de produção de alguém, pelo que a descrição honesta do nosso suporte a contentores é «a forma está certa e a ida e volta está por testar», que é uma coisa útil de se conseguir dizer em voz alta acerca da própria plataforma.

Isto saiu da construção da integração com o Proxmox para o Provibr, onde o agente corre dentro da rede do próprio cliente e só se liga para fora. O hábito relacionado de não confiar na resposta de sucesso de um hipervisor está em porque um 200 do Proxmox não é um resultado.