Когда использовать Docker-Compose, а когда - Docker-Swarm

Я пытаюсь понять различия или сходства между Docker-Compose и Docker-Swarm .

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

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

Что я пытаюсь понять, так это то, что docker-swarm преуспел в docker-compose, а оверлейные сети - это новый (рекомендуемый) способ подключения контейнеров?

Или docker-compose по-прежнему является неотъемлемой частью всего семейства docker, и ожидается и желательно использовать его для подключения контейнеров для совместной работы. Если да, работает ли docker-compose с контейнерами на разных узлах роя?

Или это оверлейные сети для соединения контейнеров между разными хостами в рое, а docker-compose - для создания внутренних ссылок?

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

Я немного запуталась ???

Большое спасибо!

Вероятно, это поможет начать с нескольких определений:

• docker-compose : команда, используемая для настройки и управления группой связанных контейнеров. Это интерфейс того же API, что и docker cli, поэтому вы можете воспроизвести его поведение с помощью таких команд, как docker run.
• docker-compose.yml : файл определения для группы контейнеров, используемый docker-compose, а теперь также режимом swarm.
• режим роя : используется для управления группой докеров как единым целым и обеспечения оркестровки (постоянно пытается исправить любые различия между текущим состоянием и целевым состоянием).
• service : один или несколько контейнеров для одного и того же образа и конфигурации в swarm, несколько контейнеров обеспечивают масштабируемость.
• stack : одна или несколько служб внутри роя, они могут быть определены с помощью файла DAB или файла docker-compose.yml.
• мостовая сеть : сеть, управляемая одним движком докеров, в которой несколько контейнеров могут связываться друг с другом. У вас может быть несколько сетей, управляемых движком, и контейнеры могут быть присоединены к нулю или более сетям.
• оверлейная сеть : похожа на мостовую сеть, но охватывает несколько механизмов докеров. Им требуется хранилище ключей / значений для поддержания их состояния. Это обеспечивает режим Swarm, но если режим Swarm отключен, вы также можете использовать etcd, consul или zookeeper.
• ссылки : метод соединения контейнеров, предшествующий мостовой сети. Его использование больше не рекомендуется.
• классический рой : предшественник интегрированного режима роя, который работает как контейнер, позволяет нескольким движкам отображаться как один, но не обеспечивает оркестровку и не включает собственное хранилище k / v.

Чтобы ответить на вопросы:

Docker-swarm преуспел в docker-compose и overlay-сетях - это новый (рекомендуемый) способ подключения контейнеров?

Или docker-compose по-прежнему является неотъемлемой частью всего семейства docker, и ожидается и желательно использовать его для подключения контейнеров для совместной работы. Если да, работает ли docker-compose с контейнерами на разных узлах роя?

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

Или это оверлейные сети для соединения контейнеров между разными хостами в рое, а docker-compose - для создания внутренних ссылок?

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

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

Использование сетей докеров является предпочтительным способом взаимодействия контейнеров друг с другом. Вам нужна сеть для каждой группы контейнеров, которую вы хотите изолировать от остальной части вашей докерной среды. docker-compose автоматизирует создание сети, но вы также можете сделать это из командной строки с помощью docker networks create.

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

компоновка, роение или роение оверлейных сетей

Вы обнаружите, что вам нужно использовать все вышеперечисленное, если вы делаете что-либо, кроме демонстрации на своем ноутбуке и т. Д.

Я сознательно разделил оверлейные сети роя и роя, потому что вам не нужно использовать оба, но вы не можете получить оверлейную сеть, не имея под ней роя.

Compose предназначен для объединения нескольких контейнеров. Теперь понятно, что они связаны друг с другом, хотя это может и не быть. Но давайте предположим типичный случай, когда контейнеры предназначены для служб, которые связаны друг с другом, тогда вы хотите, чтобы они каким-то образом общались друг с другом, но при этом контролировали, как они общаются друг с другом, используя сети. Например, возьмем трехуровневое приложение, в котором есть веб-сервер, сервер приложений и база данных. Скажем, все три компонента dockerized, и вы используете compose для их объединения вместо запускаdocker run..три раза с разными параметрами и т. д. Появятся все три, но вы захотите контролировать, как они соединяются друг с другом. Вы хотите, чтобы веб-сервер мог общаться с сервером приложений, но не напрямую с базой данных. И вы хотите, чтобы сервер приложений общался (пинговал) с контейнером сервера db, а также пинговал веб-сервер. Все соединения являются двусторонними, но ограничиваются только теми службами, с которыми вы хотите взаимодействовать друг с другом. Для такой схемы вы обычно устанавливаете 2 сети - скажем frontendи backend. Контейнеры веб-сайтов и приложений подключены к внешней сети. Контейнеры app и db подключены к серверной сети. Поскольку между db и веб-контейнерами нет общей сети, они не могут касаться друг друга (пинговать), что и является вашим намерением.

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

Надеюсь, это проясняет.

Изменить: я не видел, чтобы вы уже получили ответ!

Я думаю, что вы в основном правильно понимаете, что это такое, но требуется некоторая настройка.

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

Итак, docker-compose - это часть оркестровки контейнеров в экосистеме докеров.

Ссылки бывают разные, они являются лишь частью docker-compose или docker runкоманд и устарели в пользу software defined networksтого, что overlay networksявляется лишь одной из них.

Swarm - это компонент планирования в докере. Что такое планирование - это не что иное, как выяснение, где «разместить» ваши контейнеры в вашем кластере хостов докеров. У вас может быть кластер из сотен серверов, и у вас могут быть сотни контейнеров, каждый из которых инкапсулирует службу для десятка различных приложений. Теперь, как эти контейнеры должны быть распределены по вашему кластеру из сотен серверов, если некоторые контейнеры должны быть размещены только на определенных хостах, потому что они удовлетворяют определенным критериям или, возможно, они должны быть ближе (или нет) к другим контейнерам, которые каким-то образом связаны ... все это часть компонента планирования, который выполняется докером Swarm.

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