Какова связь между концепцией сервиса в docker-compose и концепцией контейнера?

#docker #docker-compose

#docker #docker-compose

Вопрос:

В docker-compose мы можем определить service атрибут image или build изображение из файла dockerfile. Похоже, service это то же самое, с container которым также запущен экземпляр based image .

Итак, в чем разница между service и container ?

Ответ №1:

Концептуально сервис и контейнер — это совершенно разные вещи.

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

Кроме того, в docker-compose сервис может иметь 0 ..n экземпляров, где n по умолчанию равно 1 и может быть переопределено. Доступ по HTTP будет сбалансирован по нагрузке с помощью compose, а службы будут зарегистрированы в реестре, который позволяет другим службам искать их по имени для доступа (dns).

Существуют и другие различия, такие как размещение сервисов по умолчанию в общей сети. И еще одно отличие заключается в том, что compose является декларативным, где «запуск docker» является обязательным. В отрасли существует сильное предпочтение первому.

Комментарии:

1. ИМХО, Compose используется на одном хосте, по сравнению с Swarm, который предназначен для развертывания нашего приложения в кластере. Можем ли мы иметь более 1 экземпляра сервиса на одном хосте?

Ответ №2:

Ваше предположение кажется правильным. Docker заявляет, что они следуют спецификации compose для облачных приложений. Согласно спецификации compose:

Сервисы определяются образом Docker и набором аргументов времени выполнения. Все контейнеры внутри сервиса создаются идентично с этими аргументами.

Функционально они должны быть одинаковыми. файлы docker-compose — это более простой способ определить, как должен выполняться контейнер (по сравнению с предоставлением длинных команд docker CLI). Сервисы — это концепция, используемая docker-compose для абстрагирования некоторого вычислительного ресурса, который можно масштабировать и заменять независимо от других компонентов.

Вся заслуга в документе compose-spec / spec.md. Это лучшее описание, которое я прочитал о том, что они подразумевали под этим.