Dove sta Docker su Proxmox: la decisione di collocazione e la trappola di compose

Proxmox è installato e vuoi far girare contenitori. La domanda non è "come lo installo", è dove lo metto. E non è una questione di gusto, è una questione di quante cose si rompono quando se ne rompe una.

Tre collocazioni

Direttamente sull’host. La più facile, e proprio quella da non fare. L’host è lo strato su cui poggia tutto il resto. Qualunque cosa ci installi si trova ora nel raggio d’impatto di ogni macchina virtuale: un conflitto di dipendenze, un disco pieno o un aggiornamento andato male non porta via solo i tuoi contenitori, ma tutto insieme.

Dentro un contenitore di sistema. Leggero e rapido da montare. In cambio stai facendo girare contenitori dentro un contenitore, e questo assetto ha spigoli propri: il modello dei permessi, gli strati di file system, il kernel condiviso. Scelto di proposito è ragionevole; scelto perché "era più facile" produce sorprese.

Dentro una macchina virtuale. Sulla carta il più pesante, nella pratica il più pulito. Quando l’impianto a contenitori crolla, quello che crolla è una macchina virtuale, non il tuo server. E quando vuoi rifarlo, rifai una macchina.

L’unica domanda che decide

"Se questo si rompe, che succede a tutto il resto?" Sull’host la risposta è "tutto", dentro una macchina virtuale la risposta è "una sola". L’uso di risorse, la facilità di installazione, tutto questo resta secondario accanto a quella risposta.

La seconda metà: compose è un programma

Un file compose sembra configurazione. Non lo è. Eseguirlo significa eseguire codice, e gira con i tuoi permessi. Due righe al suo interno possono consegnare al contenitore l’intera macchina.

Quando le persone copiano un file compose da internet non provano il disagio che provano copiando un comando. La differenza non sta nel pericolo, sta nell’aspetto: un comando sembra un comando, mentre compose sembra un file di impostazioni. Sembrarlo non lo rende sicuro.

Quattro righe da guardare prima di eseguirlo

Monta dentro il file system dell’host. Chiede la modalità privilegiata. Passa dentro il socket della gestione dei contenitori. Usa direttamente la rete dell’host.

Queste quattro sono le righe che bucano il confine del contenitore: se ce n’è una, quel contenitore non è più un contenitore, è l’host stesso. Leggerle richiede dieci secondi, e quei dieci secondi valgono più di tutto il resto di questa voce.

Che cosa fa Atlas

Atlas esamina i file compose e gli script di installazione prima dell’installazione, e questo esame sta sul server e non nell’interfaccia. Qualunque cosa mandi l’interfaccia, il controllo non si può saltare.

I riscontri arrivano su due livelli. Rosso significa qualcosa che porta il contenitore fuori dal confine del contenitore, cioè privilegi equivalenti a quelli dell’host; in quel caso serve un consenso esplicito. Giallo significa qualcosa che si può fare di proposito ma di cui devi essere informato. Sul lato del catalogo delle applicazioni il rosso non viene accettato affatto.

C’è un ultimo dettaglio e conta: l’analizzatore non dà opinioni, riferisce il fatto. Non dice "questo è pericoloso", dice "questa riga fa quello". Decide chi legge, perché la stessa riga può essere accettabile in un impianto e inaccettabile in un altro.