Uno script che sa di parlare con un contenitore

Un host Proxmox può far girare due cose molto diverse: una macchina virtuale completa con nucleo e firmware propri, e un contenitore che condivide il nucleo dell’host. Da lontano sono entrambe «un server» e il pannello le mette in un solo elenco. Da vicino differiscono in modi che contano per chi scrive automazione, e fino a questo giro uno script non sapeva distinguerle.

È una brutta posizione. Uno script che chiede a un contenitore di ampliare un disco virtuale, collegare un’immagine ISO o avviarsi dalla rete non chiede qualcosa di difficile; chiede qualcosa che non esiste. Il fallimento arriva quattro strati più tardi, come comando accettato, messo in coda, inviato e poi rifiutato da un agente.

Sette campi, e assente significa non accertato

Gli script e i webhook ricevono ora un gruppo di fatti su cosa ci sia sotto un server: il suo tipo, il modello da cui viene, se è non privilegiato, l’archiviazione su cui sta la sua radice, i suoi punti di montaggio, cosa sa davvero fare e cosa non sa fare.

Ognuno di quei campi può mancare, e mancare significa non accertato. È la stessa regola che segue la colonna sottostante, dove il tipo non è mai stato riempito in silenzio, ed esiste perché l’alternativa è peggio che inutile. Un’istantanea che scrive «macchina virtuale» quando nessuno l’ha mai misurato è una congettura consegnata a uno script che ci prenderà una decisione.

Un tipo sconosciuto non diventa quindi un valore predefinito. Il campo sparisce del tutto dal contesto di resa, e leggerlo è allora un errore duro nel momento in cui il flusso viene salvato, invece di una stringa vuota che rende falsa una condizione in silenzio. È lo stesso ragionamento della rimozione di un gruppo di variabili che un innesco non può fornire: rumoroso al salvataggio batte silenzioso all’esecuzione.

È anche il primo gruppo annidato del catalogo delle variabili. Un nome di campo con un punto dentro è di solito una trappola in questa base di codice, perché il catalogo di traduzione tratta il punto come un livello; qui la chiave del catalogo lo appiattisce di proposito mentre il percorso del contesto scende di un livello, e una prova fissa l’ipotesi che ci sia esattamente un punto.

I percorsi dell’host non viaggiano

Un montaggio legato nella configurazione di un contenitore somiglia a una chiave, un percorso dell’host e un punto di montaggio. Quel percorso è una cartella dell’ipervisore, e non deve mai uscirne.

La regola nella nostra documentazione è schietta: i clienti non ottengono mai tramite Provibr un interprete di comandi dell’host, un percorso del suo sistema di file né una credenziale di amministrazione dell’ipervisore. Un’istantanea di variabili è esattamente una via di quel tipo. Finisce in uno script, nel corpo di un webhook presso terzi e in una riga di verifica.

L’istantanea non porta quindi mai la sorgente. Resta ciò che un cliente può sapere del proprio contenitore: quale chiave sia, dove sia montata dentro il contenitore e da che tipo di sorgente venga. Una forma di testo fissa, perché uno script legge questo tagliando su un separatore e non analizzando prosa: mp1:bind:/srv dice che un montaggio legato sta su /srv, e non dice assolutamente nulla di dove venga sull’host.

Vale anche per un montaggio di volume. Un nome di archiviazione non è un percorso dell’host, ma è la nomenclatura propria dell’ipervisore, e nessuna domanda di script ne ha bisogno. Il nome dell’archiviazione compare una volta, a parte, come una sola parola che il cliente aveva già visto ordinando.

Il prezzo di questo disegno è dichiarato invece che nascosto: i fatti di montaggio vengono dalla configurazione che l’agente legge durante una copia di sicurezza, quindi un contenitore che non ha mai avuto una copia non produce alcun punto di montaggio. Il campo manca allora, ed è corretto, perché un elenco vuoto sosterrebbe che il contenitore non ha punti di montaggio.

Una tabella la cui prova ricava i propri casi

Esisteva già una tabella scritta che dice, per ogni comando di macchina virtuale, se un contenitore ne è capace e perché no. Mancava una tabella che coprisse ogni comando che un’integrazione Proxmox può portare, comprese le copie di sicurezza e le quattro letture che descrivono l’integrazione e non un singolo ospite.

Senza quella distinzione un setaccio non può separare «nessun giudizio annotato» da «questo non riguarda affatto un ospite», e l’unico comportamento sicuro per il secondo è lasciar passare. È proprio il ramo silenzioso su cui questo progetto continua a scottarsi.

La tabella nuova è quindi ricavata da quella scritta invece che scritta accanto, e la prova non elenca casi. Calcola l’insieme raggiungibile dai registri, prendendo ogni tipo di comando che il fornitore Proxmox non rifiuta e che serve anche una risorsa ospite, più le letture nominate sul descrittore del fornitore stesso, e pretendendo poi una dichiarazione per tipo. Ventisette comandi di ospite e quattro letture di integrazione, e la prova è stata dimostrata prima rossa e poi verde.

Una prova per caso non può trovare un caso mancante. Questa base di codice ha imparato quella lezione tre volte ormai, e questa è la terza forma della stessa guardia.

Un comando manca di proposito, e il commento dice dove cercarlo. Eseguire un comando dentro un contenitore vorrebbe dire oggi lanciarlo come amministratore sull’ipervisore, fuori dal contenitore, con i permessi dell’host. Non è una funzione di script dall’impronta ridotta; è un interprete di comandi dell’host con un nome simpatico. Chi la costruirà avrà un giro suo, con un esecutore dentro l’ospite, un permesso suo e una traccia di verifica sua.

Un rifiuto prima dell’invio non lascia righe

La passerella rifiutava già i comandi impossibili. Quel rifiuto capita a un comando che esiste già: la riga è nella base dati, l’operazione è stata creata, e il cliente guarda un incarico fallire.

Ciò che si chiedeva era la validazione prima dell’invio, ed è esattamente la differenza. Chiedere a un contenitore il suo hardware virtuale deve dare una frase e non una riga di verifica.

I due setacci non possono sfasarsi, perché leggono la stessa tabella. Non è una seconda verità; è la stessa verità, uno strato prima. La passerella resta necessaria per la richiesta ripetuta o contraffatta che non passa mai per la funzione del pannello.

Il motivo del rifiuto viene reso come un solo messaggio con un ramo per motivo, e la guardia intorno pretende due cose: un ramo per ogni motivo, e che le frasi differiscano tra loro. Un ramo assente in una scelta di lingua ricade sul valore predefinito e dice qualcosa di vero che non significa nulla, e questo modo di guastarsi questo progetto lo conosce già.

Il sistema operativo nell’elenco sbagliato

Il ritrovamento che solo una base dati vera ha prodotto non aveva nulla a che vedere con quanto precede.

Le voci di sistema operativo tenevano un tempo la loro sorgente di installazione in una colonna e ora in due, con la vecchia letta come ripiego per le righe che nessun nuovo scrittore ha mai toccato. I modelli di contenitore sono arrivati dopo e vanno in una colonna propria, e su una riga nuova vengono proiettati anche in quella vecchia.

Il ripiego non ne sapeva nulla. Leggeva un riferimento di contenitore nella colonna vecchia come modello di macchina virtuale, così un sistema operativo con solo un modello di contenitore compariva nell’elenco delle macchine virtuali del flusso d’ordine, senza tipo di calcolo, e un ordine fatto su di esso sarebbe poi finito su una sorgente di clonazione senza identificativo da clonare.

La correzione è un ramo: un riferimento di contenitore nella colonna vecchia non è una sorgente di macchina virtuale. Non si perde nulla, perché il lato contenitore legge la propria colonna e nessun’altra, e le righe abbastanza vecchie da aver bisogno del ripiego non possono per costruzione portare un riferimento di contenitore: quella colonna non esisteva ancora.

Un secondo ritrovamento è venuto da un’immagine di schermo e non da una verifica. Nell’elenco delle cose che un contenitore non sa fare compariva un comando di pagamento che appartiene a un altro fornitore e che su Proxmox non esiste per nessuno dei due tipi. Vero, e del tutto fuori posto sulla pagina di dettaglio di un contenitore. È stato tolto da quell’elenco.

Cosa annoteremmo

1. 01Assente è una risposta. Se non conosce il tipo, non metta un valore predefinito. Una congettura consegnata all’automazione è peggio di un buco che lo script può vedere.
2. 02La sicurezza dei permessi è una proprietà della forma, non del chiamante. Progetti l’istantanea in modo che il percorso dell’host non ci sia dentro, e nessun lettore futuro potrà farlo trapelare.
3. 03Una forma di testo fissa batte la prosa. Qualcuno taglierà questo su un separatore.
4. 04Ricavi i casi dal registro. Una prova per caso è strutturalmente incapace di trovare il caso che nessuno ha scritto.
5. 05Rifiuti prima di registrare. Un rifiuto che produce una riga di verifica ha già raccontato al cliente la storia sbagliata.
6. 06Guardi le immagini di schermo. La voce fuori posto era vera, è passata da ogni verifica, ed era subito sbagliata per un occhio umano.

Per chiarezza su cosa sia tutto questo: i contenitori sono ordinabili su Proxmox e i fatti di calcolo sono in produzione. Diverse cose non sono dimostrate. Nulla di ciò è stato esercitato in questo giro contro un ipervisore reale, i fatti di montaggio dipendono dall’esserci stata almeno una copia di sicurezza, una frase del flusso d’ordine dice ancora «la VM» su un contenitore, e il contatore di licenze conta ancora un contenitore come macchina virtuale.

Dal lavoro di piattaforma di Provibr. Perché un contenitore non privilegiato sia una misura e non un’impostazione è spiegato in non privilegiato è una misura, non un’impostazione, e quali punti di montaggio una copia di sicurezza di un contenitore contenga o no è spiegato in cosa una copia di sicurezza non contiene.