Dare a un container un indirizzo proprio sulla rete: cosa guadagni, cosa paghi

La disposizione predefinita è questa: il container condivide l'indirizzo della macchina e tu lo raggiungi attraverso un numero di porta. È semplice, è sicura, e per la maggior parte del lavoro basta.

Ci sono casi in cui non basta, e sono prevedibili.

Quando un numero di porta non basta

Due applicazioni vogliono lo stesso numero. Ne sposti una su un altro numero, e poi i collegamenti che quell'applicazione genera da sé non contengono quel numero e le cose si confondono.

L'applicazione si annuncia in rete. Trovare stampanti, trovare lettori multimediali, trovare dispositivi della casa intelligente: funziona con messaggi che si autoannunciano. Quei messaggi non sopravvivono alla mappatura delle porte. L'applicazione si annuncia, ma l'indirizzo che annuncia è quello della macchina, e l'altra parte non la raggiunge.

Vuoi vedere l'applicazione nell'elenco dei dispositivi del router. Per darle un indirizzo fisso, scrivere una regola di firewall a parte, vederne il traffico separatamente. Con la mappatura delle porte quell'applicazione per la rete non esiste; esiste solo la macchina.

L'altra strada: dare al container un'identità propria

Il container compare in rete con il proprio indirizzo hardware, prende il proprio indirizzo dal router, e sta nell'elenco dei dispositivi come un apparecchio fisico.

La prima reazione di solito è "perché non fanno tutti così". La risposta sta nel prezzo.

Prezzo uno: la macchina non raggiunge il proprio container

È la parte che sorprende di più, e di solito si scopre a lavoro finito.

Tutti i dispositivi della rete raggiungono quel container. La macchina che lo ospita no.

Il motivo ha senso: entrambi usano la stessa interfaccia fisica, e il traffico non torna indietro dallo switch. La macchina manda fuori il pacchetto, e il pacchetto non rientra sulla propria scheda.

Le conseguenze sono quotidiane: un controllo di salute che gira sulla macchina non raggiunge l'applicazione, un altro container sulla stessa macchina non riesce a collegarsi, uno script che hai scritto non funziona. Tutto questo mentre da fuori la rete sembra impeccabile.

Una soluzione c'è, ma è un pezzo in più: aprire sulla macchina una seconda interfaccia virtuale attaccata alla stessa scheda e far passare da lì la rotta verso l'indirizzo del container. Una volta installata il problema sparisce, ma essendo un'aggiunta, se viene dimenticata nessuno capisce.

Prezzo due: consumi un indirizzo vero

Ogni container consuma un indirizzo della tua rete. Dieci applicazioni significa dieci indirizzi. In una rete piccola arrivi presto al limite.

Inoltre, se l'indirizzo è un prestito può cambiare. Quando cambia, tutto ciò che vi era fissato, compresa una regola che hai scritto, punta in silenzio nel posto sbagliato.

Prezzo tre: la scheda di rete e il firewall

La scheda deve accettare più di un indirizzo hardware. La maggior parte delle connessioni senza fili non lo fa, e certi ambienti virtuali arrivano con la cosa disattivata. Non decidere senza provare.

E il tuo firewall ora vede in rete un dispositivo che non conosce. Per te è un container; per chi scrive le regole è un apparecchio qualsiasi. Non è un problema, ma se resta non detto un giorno confonderà qualcuno.

L'indirizzo non basta, serve anche un nome

Un'applicazione con indirizzo e senza nome è metà del guadagno. Nessuno vuole imparare a memoria un indirizzo.

Perché il nome venga annunciato in rete, qualcosa deve fare quel lavoro. L'immagine dell'applicazione di solito non contiene quel pezzo, e non c'è motivo che lo contenga: un'immagine di database non deve annunciarsi in rete.

La regola

Una mappatura di porte dà un numero a una porta. Un'identità di rete concede la cittadinanza.

Concedi la cittadinanza solo quando la rete deve davvero trattare quell'applicazione come un dispositivo. Se non serve, un numero di porta è insieme più semplice e più sicuro.

Cosa fa Atlas

Nell'allestire tutto questo Atlas non tocca l'immagine dell'applicazione. Apre accanto a essa un piccolo aiutante, e l'aiutante condivide lo stack di rete dell'applicazione. È l'aiutante a chiedere l'indirizzo al router, ed è lui ad annunciare il nome in rete.

Questo collegamento è voluto e porta due cose. L'immagine dell'applicazione non deve contenere né un client per l'indirizzo né un annunciatore di nome. E poiché lo stack di rete appartiene all'applicazione, quando l'applicazione si ferma l'aiutante cade con lei, senza lasciare dietro un container orfano.

Per il problema della macchina che non raggiunge il proprio container viene installato il ponte descritto sopra, e viene installato come servizio, così si ricostruisce al riavvio della macchina.

Quello che vale davvero la pena raccontare è un difetto trovato in quel ponte durante una prova sul campo.

Il ponte apriva una rotta verso l'indirizzo del container. Ma non cancellava la rotta di un container sparito. Dopo un riavvio era rimasta appesa la rotta di un indirizzo temporaneo. La conseguenza: se più tardi un altro dispositivo prende quell'indirizzo, il traffico destinato a lui viene deviato nel ponte. Il difetto quindi non colpisce il container, ma un terzo innocente della rete.

La correzione è stata smettere di lasciare il ponte come una cosa che aggiunge soltanto rotte, e renderlo una cosa che cancella le rotte che non corrispondono più a un container vivo.

La lezione generale vale anche fuori dalla rete: aggiungere è la metà facile. Una rotta, una regola, una mappatura è un'affermazione che fai sul mondo. Quando il mondo cambia, un'affermazione che nessuno ha ritirato diventa una bugia, e di solito colpisce non te ma qualcuno che non c'entra nulla con te.