Коли використовувати Docker-Compose, а коли Docker-Swarm

Я намагаюся зрозуміти відмінності чи подібності між Docker-Compose та Docker-Swarm .

Читаючи документацію, я зрозумів, що docker-compose надає механізм зв’язування різних контейнерів та спільної роботи як єдиної служби (я здогадуюсь, що вона використовує ту ж функціональність, що і команда --link, яка використовується для зв’язку двох контейнерів)

Крім того, я розумію docker-swarm у тому, що він дозволяє керувати кластером різних докер-хостів , кожен з яких запускає кілька екземплярів контейнерів деяких образів docker. Ми могли б визначити з'єднання як накладні мережі між різними контейнерами в рої (навіть якщо вони перебувають через два докер-хости в рої), щоб з'єднати їх як єдине ціле.

Я намагаюся зрозуміти, чи вдалося docker-swarm здійснити docker-compose та overlay network - це новий (рекомендований) спосіб підключення контейнерів?

Або це те, що docker-compose все ще є невід’ємною частиною всієї родини докерів, і, як очікується, доцільно використовувати його для підключення контейнерів до спільної роботи. Якщо так, докер-компонування працює з контейнерами через різні вузли в рої ??

Або це те, що накладні мережі призначені для з'єднання контейнерів між різними хостами в рої, а docker-compose - для створення внутрішніх посилань ??

Крім того, я також бачу, що в документації докера згадується, що --посилання більше не рекомендуються і незабаром застаріють.

Я трохи розгубився ???

Дуже дякую!

Можливо, допоможе почати з кількох визначень:

• docker-compose : Команда, що використовується для налаштування та управління групою пов'язаних контейнерів. Це інтерфейс до того самого API, який використовується докером cli, тому ви можете відтворити його поведінку за допомогою таких команд, як docker run.
• docker-compose.yml : Файл визначення групи контейнерів, що використовується docker-compose, а тепер також у режимі рою.
• режим рою : Використовується для управління групою двигунів докерів як єдиного цілого та забезпечення оркестрації (постійно намагаючись виправити будь-які відмінності між поточним станом та цільовим станом).
• послуга : Один або кілька контейнерів для одного зображення та конфігурації в рої, кілька контейнерів забезпечують масштабованість.
• стек : одна або кілька служб у рої, їх можна визначити за допомогою DAB або файлу docker-compose.yml.
• мостова мережа : Мережа, керована одним механізмом докера, де кілька контейнерів можуть взаємодіяти між собою. У вас може бути кілька мереж, якими керує движок, а контейнери можуть бути приєднані до нуля або більше мереж.
• мережа накладання : подібна до мостової мережі, але охоплює декілька модулів докерів. Вони потребують сховища ключа / вартості, щоб підтримувати свій стан. Ройовий режим забезпечує це, але якщо режим ройового режиму вимкнений, ви також можете використовувати etcd, консула або охоронця зоопарку.
• посилання : метод з'єднання контейнерів разом, що передує мостовій мережі. Його використання більше не рекомендується.
• класичний рій : Попередник інтегрованого режиму рою, який працює як контейнер, дозволяє декільком двигунам виглядати як один, але не забезпечує оркестрації або включає власний сховище k / v.

Щоб відповісти на запитання:

чи вдався docker-swarm docker-compose та overlay network - це новий (рекомендований) спосіб підключення контейнерів?

Або це те, що docker-compose все ще є невід’ємною частиною всієї родини докерів, і, як очікується, доцільно використовувати його для підключення контейнерів до спільної роботи. Якщо так, докер-компонування працює з контейнерами через різні вузли в рої ??

Вони забезпечують різну функціональність і надалі будуть виконувати цілі. docker-compose не може запускати контейнери всередині режиму рою, але новіша версія файлу docker-compose.yml (версія 3) може бути використана для визначення стека безпосередньо в режимі рою без використання самого docker-compose. docker-compose необхідний для управління контейнерами поза режимом рою, на одному двигуні докера або з класичним роєм.

Або це те, що накладні мережі призначені для з'єднання контейнерів між різними хостами в рої, а docker-compose - для створення внутрішніх посилань ??

Крім того, я також бачу, що в документації докера згадується, що --посилання більше не рекомендуються і незабаром застаріють.

docker-compose, починаючи з версії 2 файлу yml, за замовчуванням з’єднує кілька контейнерів разом із новою мостовою мережею для кожного проекту (проект за замовчуванням має назву каталогу). З класичним роєм це за замовчуванням буде накладеною мережею за допомогою зовнішнього сховища k / v. А зі стеком режиму рою це буде накладена мережа.

Використання докерних мереж є найкращим способом зв’язку контейнерів між собою. Вам потрібна мережа для кожної групи контейнерів, яку ви хочете ізолювати від решти середовища докера. docker-compose автоматизує створення цієї мережі, але ви також можете зробити це з командного рядка за допомогою docker networks create.

Посилання значною мірою замінено докерними мережами з вбудованим виявленням DNS. Коли ви видаляєте посилання з вашого docker-compose.yml, можливо, вам доведеться замінити їх depends_onрозділом, щоб забезпечити порядок запуску контейнера. В іншому випадку є дуже мало сценаріїв, коли зв’язування має сенс, і все те, що я бачив, відбувається від когось, хто слідує за застарілою документацією.

складати або роїти або роїти накладні мережі

Ви виявите, що вам потрібно використовувати все вищезазначене, якщо ви робите щось інше, ніж демонстрацію на своєму ноутбуці тощо.

Я навмисно відокремив ройові та ройові накладні мережі, тому що вам не потрібно використовувати обидва, але ви не можете отримати накладну мережу, не маючи рою під нею.

Compose призначений для зведення декількох контейнерів разом. Зараз має сенс, що вони пов’язані між собою, хоча можуть і не бути. Але припустимо, типовий випадок, коли контейнери призначені для служб, пов’язаних між собою, тоді ви хотіли б, щоб вони якимось чином спілкувались між собою, але при цьому контролювали, як вони спілкуються між собою за допомогою мереж. Наприклад, візьмемо трирівневу програму, яка має веб-сервер, сервер додатків та db. Скажімо, всі три компоненти докеризовані, і ви використовуєте compose, щоб зібрати їх разом m, а не запускатиdocker run..три рази з різними параметрами і т. д. Усі троє з’являться, але ви хочете контролювати, як вони з’єднуються між собою. Ви хочете, щоб веб-сервер міг спілкуватися з сервером додатків, але не безпосередньо з db. І ви хотіли б, щоб сервер додатків розмовляв (пінгував) контейнер сервера db, а також пінгував веб-сервер. Всі з'єднання є двосторонніми, але обмежені лише тими послугами, які ви хочете мати можливість спілкуватися між собою. Для такої домовленості ви зазвичай встановлюєте 2 мережі - скажімо frontendта backend. Контейнери Інтернету та додатків підключені до зовнішньої мережі. Контейнери додатків та баз даних підключені до внутрішньої мережі. Оскільки між db та веб-контейнерами немає спільної мережі, вони не можуть торкатися (пінгувати) один одного, що є вашим наміром.

Тепер, якщо ви хочете, щоб ці 3 служби могли працювати на вашому кластері з 100 машин, і ви також хочете масштабувати їх, вам знадобиться мережа, яка охоплює кілька хостів. Саме там накладається мережа накладання (у рої). Накладання мереж - це не що інше, як побудова мереж із декількома хостами за технологією VxLAN. Вам не потрібно знати про VxLAN, за винятком того, що це стандартна топологія мережі, яка підтримується майже у всій сучасній мережевій інфраструктурі.

Я сподіваюся, що це уточнює.

Редагувати: я не бачив, що ви вже отримали відповідь!

Я думаю, що у вас є більша частина розуміння правильного щодо того, що це таке, але потрібна певна настройка.

Ви правильно вважаєте, що docker-compose - це відкривати багатоконтейнерні програми. Раніше ви звикли робити docker run ..кожен контейнер. Зазвичай сучасні програми, що охоплюють парадигму мікропослуг, можуть складатися з десятків сервісів, і їх використання docker run ..дуже скоро стане втомливим. Отже, docker-compose дозволяє висловити всі контейнери та їх властивості, а також те, як вони з’єднуються між собою у вигляді файлу yamlабо jsonфайлу, щоб ви могли простіше керувати ним.

Отже, docker-compose - це частина організації контейнера в екосистемі docker.

Посилання різні, вони є лише частиною docker-compose або docker runкоманд і застаріли на користь software defined networksяких overlay networksє лише однією з них.

Рой - це компонент планування в докері. Що таке планування - це не що інше, як з’ясування, де «розмістити» ваші контейнери у вашому кластері хостів докерів. Ви можете мати кластер із сотень серверів, і у вас можуть бути сотні контейнерів, кожен з яких інкапсулює послугу для десятка різних додатків. Тепер, як ці контейнери слід розподіляти по кластеру з сотень серверів, чи слід розміщувати деякі контейнери лише на певних хостах, оскільки вони відповідають певним критеріям, або, можливо, вони повинні бути ближче до (або ні) інших контейнерів, які якимось чином пов'язані ... все це є частиною компонента планування, який виконує Docker Swarm.

Я пропоную вам ознайомитися з документацією щодо початку роботи на docker.com тут: https://docs.docker.com/engine/getstarted-voting-app/