Когда использовать Docker-Compose и когда использовать Docker-Swarm
Я пытаюсь понять различия или сходства между D-Compose и D-Swarm.
Читая документацию, я понял, что docker-compose предоставляет механизм для связывания различных контейнеров и совместной работы в качестве единого сервиса (я полагаю, он использует ту же функциональность, что и команда --link, используемая для связи двух контейнеров).
Кроме того, мое понимание docker-swarm состоит в том, что он позволяет вам управлять кластером различных хостов docker, каждый из которых запускает несколько экземпляров контейнера с некоторыми образами docker. Мы могли бы определить соединения как оверлейные сети между различными контейнерами в рое (даже если они через два хоста-докера в рое), чтобы соединить их как единое целое.
То, что я пытаюсь понять, является ли docker-swarm преуспел ли docker-compose, и оверлейные сети - это новый (рекомендуемый) способ подключения контейнеров?
Или же docker-compose все еще является неотъемлемой частью всего семейства docker, и его целесообразно и целесообразно использовать для подключения контейнеров для совместной работы. Если да, то работает ли docker-compose с контейнерами на разных узлах в рое??
Или оверлейные сети предназначены для соединения контейнеров между различными хостами в Swarm, а docker-compose для создания внутренних ссылок?
Кроме того, я также вижу, что в документации докера упоминается, что --links больше не рекомендуется и скоро устареет.
Я немного смущен???
Большое спасибо!
3 ответа
Вероятно, это поможет начать с нескольких определений:
- docker-compose: команда, используемая для настройки и управления группой связанных контейнеров. Это интерфейс того же API-интерфейса, который используется докером Cli, поэтому вы можете воспроизвести его поведение с помощью таких команд, как
docker run, - docker-compose.yml: файл определения для группы контейнеров, используемый docker-compose и теперь также в режиме роя.
- режим роя: используется для управления группой механизмов докеров как единым целым и обеспечения оркестровки (постоянно пытается исправить любые различия между текущим состоянием и целевым состоянием).
- сервис: один или несколько контейнеров для одного изображения и конфигурации в Swarm, несколько контейнеров обеспечивают масштабируемость.
- stack: одна или несколько служб в Swarm, они могут быть определены с использованием файла DAB или docker-compose.yml.
- мостовая сеть: сеть, управляемая одним механизмом докера, где несколько контейнеров могут связываться друг с другом. У вас может быть несколько сетей, управляемых движком, и контейнеры могут быть подключены к нулю или нескольким сетям.
- оверлейная сеть: аналогична мостовой сети, но охватывает несколько механизмов докеров. Для этого требуется хранилище ключей / значений для поддержания их состояния. Режим роя обеспечивает это, но если режим роя отключен, вы также можете использовать 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 необходим для управления контейнерами вне режима роя, на одном движке докера или с классическим роем.
Или оверлейные сети предназначены для соединения контейнеров между различными хостами в Swarm, а docker-compose для создания внутренних ссылок?
Кроме того, я также вижу, что в документации докера упоминается, что --links больше не рекомендуется и скоро устареет.
docker-compose, начиная с версии 2 файла yml, по умолчанию соединяет несколько контейнеров с новой мостовой сетью для каждого проекта (по умолчанию в проекте используется имя каталога). При использовании классического роя по умолчанию будет использоваться оверлейная сеть с использованием внешнего хранилища K / V. А при использовании стека режима роя это будет наложенная сеть.
Использование сетей Docker является предпочтительным способом связи контейнеров друг с другом. Вы хотите сеть для каждой группы контейнеров, которую вы хотите изолировать от остальной среды вашего докера. docker-compose автоматизирует создание этой сети, но вы также можете сделать это из командной строки с помощью docker networks create,
Связывание в значительной степени заменено сетями докеров со встроенным обнаружением DNS. Когда вы удаляете ссылки из вашего docker-compose.yml, вам может потребоваться заменить их на depends_on раздел для обеспечения порядка запуска контейнера. В противном случае, существует очень мало сценариев, в которых связывание имеет смысл, и все, что я видел, это использование кем-то, кто следит за устаревшей документацией.
создавать или роить или роить оверлейные сети
Вы обнаружите, что вам нужно использовать все вышеперечисленное, если вы делаете что-то кроме демонстрации на своем ноутбуке и т. Д.
Я намеренно отделил сети наложения роя и роя, потому что вам не нужно использовать оба, но вы не можете получить сеть наложения, не имея роя под ним.
Compose предназначен для объединения нескольких контейнеров. Теперь имеет смысл, что они связаны друг с другом, хотя могут и не быть. Но давайте предположим типичный случай, когда контейнеры предназначены для служб, которые связаны друг с другом, тогда вы бы хотели, чтобы они каким-то образом общались друг с другом, но все же контролировали, как они общаются друг с другом, используя сети. Например, возьмите трехуровневое приложение с веб-сервером, сервером приложений и базой данных. Допустим, все три компонента докеризованы, и вы используете compose, чтобы собрать их вместе вместо запуска docker run.. три раза с разными параметрами и т. д. Все три подойдут, но вы захотите контролировать, как они соединяются друг с другом. Вы хотите, чтобы веб-сервер мог общаться с сервером приложений, но не напрямую с БД. И вы бы хотели, чтобы appserver говорил (проверял) контейнер сервера 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 - это компонент планирования в Docker. Что такое планирование - это не что иное, как выяснение, где "разместить" свои контейнеры в кластере узлов докеров. У вас может быть кластер из сотен серверов, и вы можете иметь сотни контейнеров, каждый из которых инкапсулирует службу для дюжины различных приложений. Теперь, как эти контейнеры должны быть распределены по вашему кластеру из сотен серверов, если некоторые контейнеры будут размещены только на определенных хостах, потому что они удовлетворяют определенным критериям, или, может быть, они должны быть ближе (или нет) к другим контейнерам, которые так или иначе связаны... Все это является частью компонента планирования, который выполняется Docker Swarm.
Я предлагаю вам ознакомиться с документацией по началу работы на docker.com здесь: https://docs.docker.com/engine/getstarted-voting-app/