Kiedy używać Docker-Compose i kiedy używać Docker-Swarm

Próbuję zrozumieć różnice lub podobieństwa między Docker-Compose i Docker-Swarm .

Czytając dokumentację, zrozumiałem, że docker-compose zapewnia mechanizm łączenia różnych kontenerów i współpracy, jako pojedyncza usługa (domyślam się, że używa tej samej funkcjonalności, co polecenie --link używane do łączenia dwóch kontenerów)

Ponadto rozumiem, że docker-swarm jest taki, że pozwala on zarządzać klastrem różnych hostów docker-host , z których każdy uruchamia kilka wystąpień kontenerów niektórych obrazów docker-images. Moglibyśmy zdefiniować połączenia jako sieci nakładkowe między różnymi kontenerami w roju (nawet jeśli znajdują się one między dwoma hostami docker w roju), aby połączyć je jako jednostkę.

Próbuję zrozumieć, czy docker-swarm powiódł się, docker-compose, a sieci nakładek to nowy (zalecany) sposób łączenia kontenerów?

Czy też jest tak, że docker-compose jest nadal integralną częścią całej rodziny docker i oczekuje się i zaleca, aby używać go do łączenia kontenerów w celu współpracy. Jeśli tak, to czy docker-compose działa z kontenerami w różnych węzłach w roju?

A może sieci nakładkowe służą do łączenia kontenerów z różnymi hostami w roju, a docker-compose służy do tworzenia łączy wewnętrznych?

Poza tym widzę również, że w dokumentacji dockera jest napisane, że --links nie jest już zalecane i wkrótce będzie przestarzałe.

Jestem nieco zdezorientowany???

Wielkie dzięki!

Prawdopodobnie pomoże zacząć od kilku definicji:

• docker-compose : Polecenie używane do konfigurowania i zarządzania grupą powiązanych kontenerów. Jest to nakładka na ten sam interfejs API, którego używa docker cli, więc możesz odtworzyć jego zachowanie za pomocą poleceń takich jak docker run.
• docker-compose.yml : plik definicji dla grupy kontenerów, używany przez docker-compose, a teraz także przez tryb roju.
• tryb roju : używany do zarządzania grupą silników docker jako pojedynczą jednostką i zapewniania orkiestracji (ciągłe próby korygowania wszelkich różnic między bieżącym stanem a stanem docelowym).
• usługa : jeden lub więcej kontenerów dla tego samego obrazu i konfiguracji w roju, wiele kontenerów zapewnia skalowalność.
• stos : Jedna lub więcej usług w roju, mogą być zdefiniowane przy użyciu pliku DAB lub docker-compose.yml.
• Sieć pomostowa : sieć zarządzana przez jeden silnik platformy dokującej, w której wiele kontenerów może komunikować się ze sobą. Możesz mieć wiele sieci zarządzanych przez aparat, a kontenery mogą być dołączone do zera lub większej liczby sieci.
• sieć nakładkowa : podobna do sieci mostkowej, ale obejmująca wiele silników platformy dokującej. Wymagają one magazynu kluczy / wartości, aby zachować swój stan. Tryb roju zapewnia to, ale jeśli tryb roju jest wyłączony, możesz również użyć etcd, consul lub zookeeper.
• łącza : metoda łączenia kontenerów, która jest starsza niż sieć mostowana. Jego użycie nie jest już zalecane.
• classic swarm : Poprzednik zintegrowanego trybu roju, który działa jako kontener, umożliwia wyświetlanie wielu silników jako jednego, ale nie zapewnia orkiestracji ani nie zawiera własnego magazynu k / v.

Aby odpowiedzieć na pytania:

czy docker-swarm się powiódł docker-compose, a sieci nakładkowe to nowy (zalecany) sposób łączenia kontenerów?

Czy też jest tak, że docker-compose jest nadal integralną częścią całej rodziny docker i oczekuje się i zaleca, aby używać go do łączenia kontenerów w celu współpracy. Jeśli tak, to czy docker-compose działa z kontenerami w różnych węzłach w roju?

Zapewniają różne funkcje i nadal będą służyć jakiemuś celowi. docker-compose nie może uruchamiać kontenerów w trybie swarm, ale nowsza wersja pliku docker-compose.yml (wersja 3) może służyć do definiowania stosu bezpośrednio w trybie roju bez użycia samego docker-compose. docker-compose jest potrzebny do zarządzania kontenerami poza trybem roju, na jednym silniku docker lub z klasycznym rojem.

A może sieci nakładkowe służą do łączenia kontenerów z różnymi hostami w roju, a docker-compose służy do tworzenia łączy wewnętrznych?

Poza tym widzę też, że w dokumentacji dockera jest napisane, że --links nie jest już zalecane i wkrótce będzie przestarzałe.

docker-compose, począwszy od wersji 2 pliku yml, domyślnie łączy ze sobą wiele kontenerów z nową siecią mostkową na projekt (domyślnie projekt jest nazwą katalogu). W przypadku klasycznego roju domyślnie byłaby to sieć nakładkowa korzystająca z zewnętrznego magazynu k / v. W przypadku stosu trybu roju byłaby to sieć nakładkowa.

Korzystanie z sieci platformy Docker jest preferowanym sposobem komunikacji między kontenerami. Potrzebujesz sieci dla grupy kontenerów, które chcesz odizolować od reszty środowiska Dockera. docker-compose automatyzuje tworzenie sieci, ale możesz to również zrobić z wiersza poleceń za pomocą docker networks create.

Łączenie zostało w dużej mierze zastąpione przez sieci Dockera z wbudowanym wykrywaniem DNS. Po usunięciu linków z pliku docker-compose.yml może być konieczne zastąpienie ich depends_onsekcją, aby wymusić kolejność uruchamiania kontenera. W przeciwnym razie istnieje bardzo niewiele scenariuszy, w których łączenie ma sens, a całe użycie, które widziałem, pochodzi od kogoś, kto śledzi nieaktualną dokumentację.

tworzenie lub rój lub rój sieci nakładek

Przekonasz się, że musisz użyć wszystkich powyższych, jeśli robisz coś innego niż prezentacja na swoim laptopie itp.

Celowo oddzieliłem sieci nakładek roju i roju, ponieważ nie musisz używać obu, ale nie możesz uzyskać sieci nakładkowej bez roju pod nią.

Compose służy do jednoczesnego tworzenia wielu kontenerów. Teraz ma sens, że są ze sobą spokrewnieni, chociaż mogą nie być. Ale załóżmy typowy przypadek, gdy kontenery są przeznaczone dla usług, które są ze sobą powiązane, wtedy chciałbyś, aby rozmawiały ze sobą w jakiś sposób, ale jednocześnie kontrolowały sposób, w jaki rozmawiają ze sobą za pomocą sieci. Na przykład weź aplikację trójwarstwową, która ma serwer WWW, serwer aplikacji i bazę danych. Powiedzmy, że wszystkie trzy komponenty są dokeryzowane i używasz funkcji Compose do ich wspólnego wywoływania zamiast uruchamianiadocker run..trzy razy z różnymi parametrami itd. Pojawią się wszystkie trzy, ale chciałbyś kontrolować sposób ich łączenia. Chcesz, aby serwer WWW mógł komunikować się z serwerem aplikacji, ale nie bezpośrednio z bazą danych. I chcesz, aby serwer aplikacji komunikował się (pingował) z kontenerem serwera db, a także wysyłał polecenie ping do serwera WWW. Wszystkie połączenia są dwukierunkowe, ale ograniczone tylko do tych usług, z którymi chcesz się komunikować. W takim układzie zazwyczaj skonfigurowałbyś 2 sieci - powiedzmy frontendi backend. Kontenery internetowe i aplikacji są połączone z siecią frontendową. Kontenery aplikacji i bazy danych są połączone z siecią zaplecza. Ponieważ między bazą danych a kontenerami WWW nie ma wspólnej sieci, nie mogą one się ze sobą stykać (pingować), co jest Twoim zamiarem.

Teraz, jeśli chcesz, aby te 3 usługi mogły działać w klastrze składającym się z setek maszyn, a także chcesz je skalować, potrzebujesz sieci obejmującej wiele hostów. W tym miejscu pojawia się sieć nakładkowa (w roju). Sieci typu overlay to nic innego jak sieć z wieloma hostami zbudowana w technologii VxLAN. Nie musisz wiedzieć o VxLAN, poza tym, że jest to standardowa topologia sieci, która jest obsługiwana w prawie każdej nowoczesnej infrastrukturze sieciowej.

Mam nadzieję, że to wyjaśnia.

Edycja: nie widziałem, że masz już odpowiedź!

Myślę, że większość rozumiesz poprawnie, ale wymagane są pewne poprawki.

Masz rację, docker-compose polega na wywołaniu aplikacji z wieloma kontenerami. Wcześniej robiłeś to, docker run ..aby uruchomić każdy kontener. Zwykle nowoczesne aplikacje uwzględniające paradygmat mikrousług mogą składać się z dziesiątek usług i korzystanie z docker run ..nich bardzo szybko stanie się bardzo męczące. Dlatego docker-compose umożliwia wyrażenie wszystkich kontenerów i ich właściwości oraz sposobu, w jaki łączą się one ze sobą jako plik yamllub json, dzięki czemu można nim zarządzać w łatwiejszy sposób.

Tak więc docker-compose jest częścią aranżacji kontenerów w ekosystemie docker.

Linki są różne, są po prostu częścią docker-compose lub docker runpoleceń i są przestarzałe na rzecz software defined networksktórych overlay networkssą tylko jednym z nich.

Swarm to komponent planowania w dockerze. Co to jest planowanie - to nic innego jak ustalenie, gdzie „umieścić” kontenery w klastrze hostów dockera. Możesz mieć klaster setek serwerów i setki kontenerów, z których każdy zawiera usługę dla kilkunastu różnych aplikacji. W jaki sposób te kontenery powinny być dystrybuowane w klastrze setek serwerów, czy niektóre kontenery powinny być umieszczone tylko na określonych hostach, ponieważ spełniają określone kryteria, czy może powinny znajdować się bliżej (lub nie) innych kontenerów, które są w jakiś sposób powiązane ... wszystko to jest częścią komponentu planowania, który jest wykonywany przez docker Swarm.

Proponuję zapoznać się z dokumentacją wprowadzającą na docker.com tutaj: https://docs.docker.com/engine/getstarted-voting-app/