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

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

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

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

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

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

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

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

Я немного смущен???

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

Ответ 1

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

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

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

Доклер-рой преуспел в создании докеры и оверлейных сетей - новый (рекомендуемый) способ подключения контейнеров?

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

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

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

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

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

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

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

Ответ 2

создавать или создавать рояльные или рояльные сети

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

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

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

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

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

Редактировать: я не видел, что вы получили ответ уже!

Ответ 3

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

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

Таким образом, docker-compose является частью оркестровки контейнера в экосистеме докера.

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

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

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

Ответ 4

Docker - это открытая платформа для разработки, доставки и запуска приложений. Docker позволяет вам отделить ваши приложения от вашей инфраструктуры, чтобы вы могли быстро доставлять программное обеспечение. С Docker вы можете управлять своей инфраструктурой так же, как вы управляете своими приложениями. Больше на: http://writeulearn.com/docker/