Nie można zobaczyć, jak wzór ambasadora zwiększa modułowość/prostotę architektury kontenerów w Docker

Question

Nie widzę, jak wdrożenie wzoru ambasadora pomogłoby nam uprościć/modularyzować projekt naszej architektury kontenerów.

Powiedzmy, że mam kontenera bazy db na host A i jest używany przez program db-client który siedzi na hosta B, które są połączone z kontenerów ambasadora db-ambassador i db-foreign-ambassador przez sieć:

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

Connections między pojemnikami w tej samej maszynie, np Od db do db-ambassador i db-foreign-ambassador do db-client odbywa się za pomocą parametru Docker's --link, podczas gdy rozmowy db-ambassador i db-foreign-ambassador odbywają się w sieci.

Ale, --link to tylko fantazyjny sposób wstawiania adresów IP, portów i innych informacji z jednego kontenera do drugiego. Gdy kontener zawiedzie, drugi z podłączonych do niego kontenerów nie otrzyma powiadomienia, a po ponownym uruchomieniu nie będzie znać nowego adresu IP awarii. Krótko mówiąc, jeśli pojemnik połączony z innym poszedł martwy, link jest również martwy.

Aby wziąć pod uwagę mój przykład, powiedzmy, że db podskoczył i uruchomił się ponownie, dzięki czemu został przypisany do innego adresu IP. db-ambassador musiałby zostać ponownie uruchomiony, aby zaktualizować połączenie między nimi ... Z wyjątkiem tego, że nie powinieneś. Po ponownym uruchomieniu db-ambassador zmieni się również adres IP, a foreign-db-ambassador nie będzie wiedział, gdzie go osiągnąć na nowym adresie IP.

Cytowanie an article w Dokumentach w Döcker chodzi o wzór ambasador,

Kiedy trzeba rewire swoją konsumenta do rozmowy na inny serwer Redis , można po prostu uruchom ponownie pojemnik Redis-ambasadora że konsument Jest podłączony do.

Ten wzorzec umożliwia również przezroczyste przenoszenie serwera Redis do innego hosta dokowanego od konsumenta.

wydaje się, że jest to dokładnie problem, który próbuje rozwiązać. Co, o ile mi wiadomo, całkowicie nie. Nie, jeśli uważasz, że --link jest przydatny tylko wtedy, gdy połączony kontener nie ulega awarii. Opcja uruchomienia węzła awarii na poprzednim IP byłaby dobrym obejściem if supported, przynajmniej dla małej/średniej architektury.

Czy brakuje mi czegoś oczywistego?

Answer 1

Jérôme miał kilka dobrych slajdów (11-33) na temat tego, jak ambasadorowie są lepsi niż inne sposoby odkrywania usług (np. DNS, magazyny klucz-wartość, plik konfiguracyjny bind-mount itp.) W jego slide deck on "Shipping Applications to Production in Containers with Docker". Ma także kilka sugestii, jak rozwiązać problem, o którym myślę, że wspomniałeś, szczególnie wygląda obiecująco.