Как работают сервисы
Чтобы развернуть образ приложения, когда Docker Engine находится в режиме swarm, вы создаёте службу. Часто сервис представляет собой образ микросервиса в контексте какого-то более крупного приложения. Примеры служб могут включать HTTP-сервер, базу данных или любой другой тип исполняемой программы, которую вы хотите запускать в распределенной среде.
При создании службы вы указываете, какой образ контейнера использовать и какие команды выполнять внутри запущенных контейнеров. Вы также определяете параметры для службы, в том числе:
порт, где swarm делает службу доступной за пределами swarm
оверлейная сеть для подключения службы к другим службам в swarm
Ограничения и резервирование ЦП и памяти
политика непрерывного обновления
количество реплик образа для запуска в swarm
Сервисы, задачи и контейнеры
Когда вы развертываете службу в swarm, диспетчер swarm принимает ваше определение службы как желаемое состояние службы. Затем он планирует службу на узлах в swarm как одну или несколько задач реплики. Задачи выполняются независимо друг от друга на узлах в swarm.
Например, представьте, что вы хотите сбалансировать нагрузку между тремя экземплярами прослушивателя HTTP. На приведенной далее диаграмме показана служба прослушивателя HTTP с тремя репликами. Каждый из трёх экземпляров прослушивателя является задачей в swarm.
Контейнер — это изолированный процесс. В модели режима swarm каждая задача вызывает ровно один контейнер. Задача аналогична «слоту», в который планировщик помещает контейнер. Как только контейнер активируется, планировщик распознает, что задача находится в состоянии выполнения. Если контейнер не проходит проверку работоспособности или завершается, задача завершается.
Задачи и расписание
Задача — это элементарная единица планирования в swarm. Когда вы объявляете желаемое состояние службы путём создания или обновления службы, оркестратор реализует желаемое состояние путём планирования задач. Например, вы определяете службу, которая указывает оркестратору постоянно поддерживать три экземпляра прослушивателя HTTP. В ответ оркестратор создаёт три задачи. Каждая задача — это слот, который планировщик заполняет, создавая контейнер. Контейнер — это экземпляр задачи. Если впоследствии задача прослушивателя HTTP не проходит проверку работоспособности или аварийно завершает работу, оркестратор создаёт новую задачу-реплику, которая порождает новый контейнер.
Задача – это однонаправленный механизм. Он монотонно проходит ряд состояний: назначено, подготовлено, выполняется и т. д. Если задача не выполняется, оркестратор удаляет задачу и её контейнер, а затем создаёт новую задачу для её замены в соответствии с желаемым состоянием, указанным службой.
Базовая логика режима Docker swarm — это планировщик и оркестратор общего назначения. Сами абстракции служб и задач не знают о контейнерах, которые они реализуют. Гипотетически вы могли бы реализовать другие типы задач, такие как задачи виртуальной машины или задачи неконтейнерного процесса. Планировщик и оркестратор не зависят от типа задачи. Однако текущая версия Docker поддерживает только контейнерные задачи.
На приведенной далее диаграмме показано, как режим swarm принимает запросы на создание службы и распределяет задачи по рабочим узлам.
Ожидающие службы
Служба может быть настроена таким образом, что ни один узел, находящийся в настоящее время в swarm, не может выполнять свои задачи. В этом случае служба остаётся в состоянии pending. Вот несколько примеров, когда служба может оставаться в состоянии pending.
Примечание
Если ваше единственное намерение — предотвратить развертывание службы, масштабируйте службу до 0 вместо того, чтобы пытаться настроить её таким образом, чтобы она оставалась в pending.
Если все узлы приостановлены или истощены, и вы создаёте службу, она находится в ожидании, пока узел не станет доступным. На самом деле, первый доступный узел получает все задачи, поэтому в производственной среде это не очень хорошо.
Вы можете зарезервировать определённый объём памяти для службы. Если ни один узел в swarm не имеет необходимого объема памяти, служба остаётся в состоянии ожидания до тех пор, пока не будет доступен узел, который может выполнять свои задачи. Если вы укажете очень большое значение, например 500 ГБ, задача останется в ожидании навсегда, если только у вас действительно нет узла, который может её удовлетворить.
Вы можете наложить ограничения на размещение службы, и данные ограничения могут не соблюдаться в определённый момент времени.
Такое поведение показывает, что требования и конфигурация ваших задач не сильно привязаны к текущему состоянию swarm. Как администратор swarm, вы объявляете желаемое состояние вашего swarm, и менеджер работает с узлами в swarm, чтобы создать это состояние. Вам не нужно микроуправлять задачами на swarm.
Реплицированные и глобальные сервисы
Существует два типа развертывания службы: реплицированное и глобальное.
Для реплицируемой службы вы указываете количество идентичных задач, которые хотите запускает. Например, вы решили развернуть службу HTTP с тремя репликами, каждая из которых обслуживает один и тот же контент.
Глобальная служба — это служба, которая запускает одну задачу на каждом узле. Заранее заданного количества заданий нет. Каждый раз, когда вы добавляете узел в swarm, оркестратор создаёт задачу, а планировщик назначает задачу новому узлу. Хорошими кандидатами для глобальных служб являются агенты мониторинга, антивирусные сканеры или другие типы контейнеров, которые вы хотите запускать на каждом узле в swarm.
На приведенной далее схеме желтым цветом показана реплика с тремя службами, а серым — глобальная служба.
