Non riesco a vedere come il pattern ambassador migliora la modularità/semplicità dell'architettura contenitore in Docker

Question

Non riesco a vedere come l'implementazione dello schema di ambassador possa aiutarci a semplificare/modulare la progettazione della nostra architettura contenitore.

Diciamo che ho un contenitore di database db su host A e viene utilizzato da un programma db-client che si trova su un host B, che sono collegati tramite contenitori ambasciatore db-ambassador e db-foreign-ambassador su una rete:

[host A (db) --> (db-ambassador)] <- ... -> [host B (db-forgn-ambsdr) --> (db-client)] 

Connessioni tra contenitori nella stessa macchina, ad es db a db-ambassador e db-foreign-ambassador a db-client vengono eseguiti tramite il parametro --link di Docker mentre i dialoghi db-ambassador e db-foreign-ambassador sulla rete.

Ma, --link è solo un modo elegante di inserire indirizzi IP, porte e altre informazioni da un contenitore a un altro. Quando un contenitore fallisce, l'altro contenitore a cui è collegato non viene avvisato, né saprà il nuovo indirizzo IP del contenitore in crash al suo riavvio. In breve, se un contenitore collegato a un altro è morto, anche il collegamento è morto.

Per considerare il mio esempio, diciamo che db si è arrestato in modo anomalo e si riavvia, quindi viene assegnato a un altro IP. db-ambassador dovrebbe essere riavviato anche, per aggiornare il collegamento tra di loro ... Tranne che non si dovrebbe. Se db-ambassador viene riavviato, anche l'IP verrà modificato e foreign-db-ambassador non saprà dove raggiungerlo nel nuovo indirizzo IP.

Citando an article nei documenti del Docker circa il modello ambasciatore,

Quando è necessario ricollegare il consumatore di parlare con un altro server Redis , si può semplicemente riavviare il contenitore Redis-ambasciatore che il consumatori è collegato a.

Questo modello consente inoltre di spostare in modo trasparente il server Redis su un host di finestra mobile diverso dall'utente.

sembra che questo sia esattamente il problema che sta cercando di risolvere. Che, per quanto riguarda la mia comprensione, non ha assolutamente funzionato. Non se si considera che --link è utile solo finché il contenitore collegato non si arresta in modo anomalo. L'opzione per avviare un nodo in arresto anomalo sul suo precedente IP sarebbe stata una buona soluzione, if supported, almeno per un'architettura di piccole/medie dimensioni.

Mi manca qualcosa di ovvio?

Answer 1

Jérôme ha alcune buone diapositive (11-33) su come gli ambasciatori sono migliori di altri metodi di individuazione dei servizi (ad esempio DNS, archivi di valori-chiave, file di configurazione di bind-mount, ecc.) Nel suo slide deck on "Shipping Applications to Production in Containers with Docker". Ha anche alcuni suggerimenti su come risolvere il problema che penso tu stia menzionando, specialmente lo Docker Grand Ambassador sembra promettente.