Um script que sabe que fala com um contentor

Uma máquina anfitriã Proxmox pode correr duas coisas muito diferentes: uma máquina virtual completa com núcleo e firmware próprios, e um contentor que partilha o núcleo do anfitrião. De longe as duas são «um servidor» e o painel põe-nas numa só lista. De perto diferem de maneiras que contam para quem escreve automação, e até esta ronda um script não as sabia distinguir.

É uma má posição. Um script que pede a um contentor para alargar um disco virtual, ligar uma imagem ISO ou arrancar pela rede não pede algo difícil; pede algo que não existe. A falha chega quatro camadas mais tarde, como um comando aceite, posto em fila, enviado e depois recusado por um agente.

Sete campos, e ausente significa não apurado

Os scripts e os webhooks recebem agora um grupo de factos sobre o que está por baixo de um servidor: o seu tipo, o modelo de onde vem, se é não privilegiado, o armazenamento onde assenta a sua raiz, os seus pontos de montagem, o que sabe mesmo fazer e o que não sabe.

Qualquer um desses campos pode faltar, e faltar significa não apurado. É a mesma regra que a coluna subjacente segue, onde o tipo nunca foi preenchido em silêncio, e existe porque a alternativa é pior do que inútil. Uma imagem instantânea que escreve «máquina virtual» quando ninguém o mediu é um palpite entregue a um script que vai tomar uma decisão com ele.

Um tipo desconhecido não passa por isso a valor por omissão. O campo desaparece por completo do contexto de apresentação, e lê-lo é então um erro duro no momento em que o fluxo é guardado, em vez de uma cadeia vazia que torna uma condição falsa em silêncio. É o mesmo raciocínio da remoção de um grupo de variáveis que um gatilho não consegue fornecer: ruidoso ao guardar vence silencioso durante a execução.

É também o primeiro grupo aninhado do catálogo de variáveis. Um nome de campo com um ponto lá dentro é normalmente uma armadilha nesta base de código, porque o catálogo de tradução trata um ponto como um nível; aqui a chave do catálogo achata-o de propósito enquanto o caminho do contexto desce um nível, e um teste fixa a suposição de que há exatamente um ponto.

Os caminhos do anfitrião não viajam

Uma montagem ligada na configuração de um contentor parece uma chave, um caminho do anfitrião e um ponto de montagem. Esse caminho é uma pasta do hipervisor, e nunca deve sair de lá.

A regra na nossa própria documentação é frontal: os clientes nunca obtêm pela Provibr um interpretador de comandos do anfitrião, um caminho do seu sistema de ficheiros nem uma credencial de administração do hipervisor. Uma imagem instantânea de variáveis é exatamente uma via dessas. Acaba num script, no corpo de um webhook em casa de terceiros, e numa linha de auditoria.

A imagem instantânea nunca leva, por isso, a origem. Fica o que um cliente pode saber do seu próprio contentor: que chave é, onde está montada dentro do contentor e de que tipo de origem vem. Uma forma de texto fixa, porque um script lê isto cortando por um separador e não analisando prosa: mp1:bind:/srv diz que há uma montagem ligada em /srv, e não diz absolutamente nada de onde vem no anfitrião.

Isso vale também para uma montagem de volume. Um nome de armazenamento não é um caminho do anfitrião, mas é a nomenclatura própria do hipervisor, e nenhuma pergunta de script precisa dele. O nome do armazenamento aparece uma vez, à parte, como uma só palavra que o cliente já tinha visto ao encomendar.

O preço deste desenho está declarado em vez de escondido: os factos de montagem vêm da configuração que o agente lê durante uma cópia de segurança, portanto um contentor que nunca teve cópia não produz ponto de montagem nenhum. O campo falta então, e isso está correto, porque uma lista vazia afirmaria que o contentor não tem pontos de montagem.

Uma tabela cujo teste deriva os seus próprios casos

Já existia uma tabela escrita que diz, por cada comando de máquina virtual, se um contentor é capaz dele e porque não. Faltava uma tabela que cobrisse todos os comandos que uma integração Proxmox pode transportar, incluindo as cópias de segurança e as quatro leituras que descrevem a integração e não um convidado em particular.

Sem essa distinção, um crivo não consegue separar «nenhum juízo anotado» de «isto não é sobre um convidado de todo», e o único comportamento seguro para o segundo é deixar passar. É precisamente o ramo silencioso em que este projeto se continua a queimar.

A tabela nova é por isso derivada da escrita em vez de escrita ao lado, e o teste não enumera casos. Calcula o conjunto alcançável a partir dos registos, tomando cada tipo de comando que o fornecedor Proxmox não recusa e que serve também um recurso convidado, mais as leituras nomeadas no próprio descritor do fornecedor, e exigindo depois uma declaração por tipo. Vinte e sete comandos de convidado e quatro leituras de integração, e o teste foi provado primeiro vermelho e depois verde.

Um teste por caso não consegue encontrar um caso em falta. Esta base de código já aprendeu essa lição três vezes, e esta é a terceira forma da mesma guarda.

Um comando falta de propósito, e o comentário diz onde o procurar. Executar um comando dentro de um contentor significaria hoje corrê-lo como administrador no hipervisor, fora do contentor, com as permissões do anfitrião. Isso não é uma função de scripts com pegada pequena; é um interpretador de comandos do anfitrião com nome simpático. Quem a construir terá uma ronda própria, com um executor dentro do convidado, um direito próprio e um rasto de auditoria próprio.

Uma recusa antes do envio não deixa linha

O portal já recusava comandos impossíveis. Essa recusa acontece a um comando que já existe: a linha está na base de dados, a operação foi criada, e o cliente vê uma tarefa a falhar.

O que se pedia era validação antes do envio, e é exatamente essa a diferença. Pedir a um contentor o seu equipamento virtual deve dar uma frase e não uma linha de auditoria.

Os dois crivos não podem desalinhar-se, porque leem a mesma tabela. Não é uma segunda verdade; é a mesma verdade, uma camada antes. O portal continua a ser preciso para o pedido repetido ou forjado que nunca passa pela função do painel.

O motivo da recusa é apresentado como uma só mensagem com um ramo por motivo, e a guarda à volta exige duas coisas: um ramo para cada motivo, e que as frases difiram entre si. Um ramo em falta numa escolha de língua cai no valor por omissão e diz algo que é verdade e não significa nada, e esse modo de falhar já é conhecido deste projeto.

O sistema operativo na lista errada

O achado que só uma base de dados real produziu nada tinha a ver com o anterior.

As entradas de sistema operativo guardavam antes a sua origem de instalação numa coluna e guardam agora em duas, sendo a antiga lida como recurso para as linhas que nenhum escritor novo alguma vez tocou. Os modelos de contentor chegaram depois e vão para uma coluna própria, e numa linha nova são também projetados para a antiga.

O recurso não sabia disso. Lia uma referência de contentor na coluna antiga como modelo de máquina virtual, pelo que um sistema operativo com apenas um modelo de contentor aparecia na lista de máquinas virtuais do fluxo de encomenda, sem tipo de computação, e uma encomenda feita sobre ele teria mais tarde encalhado numa origem de clonagem sem identificador para clonar.

A correção é um ramo: uma referência de contentor na coluna antiga não é uma origem de máquina virtual. Nada se perde, porque o lado do contentor lê a sua própria coluna e nenhuma outra, e as linhas suficientemente antigas para precisarem do recurso não podem por construção transportar uma referência de contentor: essa coluna ainda não existia.

Um segundo achado veio de uma imagem de ecrã e não de uma verificação. Na lista das coisas que um contentor não sabe fazer estava um comando de pagamento que pertence a outro fornecedor e que no Proxmox não existe para nenhum dos dois tipos. Verdadeiro, e completamente fora de sítio na página de detalhe de um contentor. Foi retirado dessa lista.

O que anotaríamos

1. 01Ausente é uma resposta. Se não conhece o tipo, não ponha um valor por omissão. Um palpite entregue à automação é pior do que um buraco que o script consegue ver.
2. 02A segurança de permissões é uma propriedade da forma, não de quem chama. Desenhe a imagem instantânea de modo que o caminho do anfitrião não esteja lá, e nenhum leitor futuro o poderá deixar escapar.
3. 03Uma forma de texto fixa vence a prosa. Alguém vai cortar isto por um separador.
4. 04Derive os casos do registo. Um teste por caso é estruturalmente incapaz de encontrar o caso que ninguém escreveu.
5. 05Recuse antes de registar. Uma recusa que produz uma linha de auditoria já contou ao cliente a história errada.
6. 06Olhe para as imagens de ecrã. A entrada fora de sítio era verdadeira, passou por todas as verificações, e era logo errada para um olho humano.

Para ser claro sobre o que isto é: os contentores podem ser encomendados no Proxmox e os factos de computação estão em produção. Várias coisas não estão provadas. Nada disto foi exercitado nesta ronda contra um hipervisor real, os factos de montagem dependem de ter havido pelo menos uma cópia de segurança, uma frase do fluxo de encomenda ainda diz «a VM» num contentor, e o contador de licenças ainda conta um contentor como máquina virtual.

Do trabalho de plataforma da Provibr. Porque é que um contentor não privilegiado é uma medição e não uma definição está em não privilegiado é uma medição, não uma definição, e que pontos de montagem uma cópia de segurança de um contentor contém ou não está em o que uma cópia de segurança não contém.