Этот туториал является 5-ой частью из 5-ти в серии статей Экосистема Docker.
Docker предоставляет полный набор функциональности для построения, загрузки, запуска и остановки контейнеров. Он хорошо подходит для управления этими процессами в среде с единственным хостом и минимальным набором контейнеров.
Однако многие пользователи Docker используют платформу для удобного масштабирования большого количества контейнеров между значительным числом разных хостов.
В этой статье мы обсудим инструменты распределения задач (schedulers) и оркестровки (orchestration) в Docker. Они представляют собой основной интерфейс управления контейнерами для администраторов распределённых систем.
Когда приложения масштабируется за пределы нескольких хостов, возможность управления каждым хостом и абстрагирования от особенностей платформы хоста является весьма заманчивой целью. Оркестровка - это широкий термин, который обозначает распределение контейнеров, управление кластером, и возможность добавления дополнительных хостов.
В данном случае, “распределение” означает возможность администратора загружать файлы настроек на хост, которые определяют параметры запуска конкретного контейнера. В то время, как распределение относится к конкретному акту загрузки информации о настройках, в более общем смысле планировщики (schedulers) предназначены для работа с системой инициализации хостов для управления распределением работы между доступными ресурсами хостов.
Управление кластером представляет собой управление группой хостов. Это может включать добавление и удаление хостов из кластера, получение информации о текущем статусе хостов и контейнеров, а также старт и остановку процессов. Управление кластером тесно связано с распределением работы между хостами, поскольку планировщик должен иметь доступ к каждому хосту кластера для распределения задач. По этой причине нередко одно и то же приложение используется и для управления кластером и для распределения задач между хостами.
Для запуска и управления контейнерами на хостах кластера планировщик должен взаимодействовать с системой инициализации каждого хоста. В то же время для простоты использования планировщик отображает унифицированное представление состояния запущенных сервисов на всём кластере. В конечном итоге, это выглядит так, как будто работа осуществляется с системой инициализации всего кластера в целом. Для этого многие планировщики копируют структуру управления системы инициализации отдельного хоста, которую они представляют в унифицированном виде.
Одной из основных обязанностей планировщика является выбор хоста. Если администратор решает запустить задачу (контейнер) на кластере, именно планировщик зачастую определяет, какой хост выбрать. Администратор может при необходимости задать определённые требования к параметрам запуска задачи в соответствии со своими потребностями, но именно планировщик, в конечном итоге, отвечает за выполнение этих требования.
Планировщики обычно имеют определённую политику распределения задач по умолчанию. Эта политика описывает, каким образом будут распределены задачи в отсутствии каких-либо указаний от администратора системы. Например, планировщик может отправлять новые задачи на те машины, на которых запущено меньше всего задач.
Обычно планировщики предоставляют возможность администратору изменять политику распределения задач для более тонкой настройки. Например, если два контейнера должны всегда работать на одном и том же хосте, поскольку они представляют собой части единой системы, это требование может быть задано в процессе распределения задач. Точно так же, если два контейнера не должны находиться на одном хосте, например, для обеспечения повышенной доступности сервиса, это также может быть задано в явном виде.
Также планировщики могут принимать во внимание ограничения, накладываемые в виде мета-данных. Например, если хост содержит том с данными, необходимыми для работы приложения, можно в явном виде пометить этот хост для установки данного приложения. Некоторые приложения должны быть установлены на все хосты кластера. Большинство планировщиков позволяют решать задачи подобного рода.
Распределение задач между хостами часто тесно связано с задачами управления кластером, поскольку обе эти функции подразумевают непосредственную работу как с хостами, так и с кластером, как единым целым.
Программное обеспечение по управлению кластером может быть использовано для получения информации о хостах, входящих в кластер, для добавления и удаления хостов из кластера, и даже для тонкой настройки отдельных хостов кластера. Все эти функции могут выполняться как планировщиком, так и специальным отдельным процессом.
Зачастую управление кластером также ассоциируется с инструментом обнаружения сервисов (service discovery tool) и распределённым хранилищем типа “ключ-значение” (distributed key-value store). Эти сервисы хорошо подходят для хранения распределённой информации о настройках кластера в силу распределённого характера самого кластера.
Поэтому, если сам планировщик не предоставляет каких-либо настроек, некоторые операции над кластером могут быть совершены путём изменения настроек в хранилище конфигураций (configuration store) с помощью предоставляемых API. Например, изменения настроек того, входит ли хост в кластер, могут быть осуществлены посредством изменений соответствующих значений в сервисе обнаружения (discovery service).
Хранилище “ключ-значение” также нередко используется для хранения мета-данных о настройках конкретных хостов. Хосты можно помечать специальными ярлыками, которые могут быть использованы для распределения задач между индивидуальными хостами и группами хостов.
Иногда, даже при разделении приложения на отдельные изолированные сервисы, эти сервисы должны восприниматься, как единое целое. В некоторых случаях развёртывание одного такого сервиса без развёртывания остальных не имеет никакого смысла, поскольку они должны работать сообща.
Расширенное распределение задач, учитывающее необходимость группировки контейнеров, доступно сразу в нескольких существующих проектах. Пользователи могут получить немало пользы от их использования.
Управление группами контейнеров (group container management) позволяет администратору работать с набором контейнеров, как с единым целым. Запуск и выполнение тесно связанных компонентов, как единого целого, упрощает управление приложением, не жертвуя при этом преимуществами разделения функциональности между отдельными компонентами. В конечном итоге, это позволяет администраторам пользоваться преимуществами контейнеризации и сервис-ориентированной архитектуры минимизируя при этом усилия по управлению системой.
Группировка приложений позволяет распределять задачи в группе таким образом, чтобы они выполнялись вместе, позволяя запускать и останавливать всю группу одновременно. Также группировка приложений позволяет осуществлять более сложные задачи, например, настройку отдельных подсетей для каждой группы приложений или масштабирование на уровне наборов контейнеров (ранее мы могли масштабировать работу только на уровне отдельных контейнеров).
Концепцией, связанной с управлением кластером, является инициализация. Инициализация представляет собой процесс добавления хоста и его базовой настройки, после чего хост полностью готов к работе. В случае с Docker инициализация обычно подразумевает настройку Docker и добавления хоста в существующий кластер.
Несмотря на то, что в результате процесса инициализации хост должен быть готов к работе, методология инициализации разнится в зависимости от используемых инструментов и типа хоста. Например, если хост представляет собой виртуальную машину, для его настройки могут быть использованы инструменты вроде vagrant
. Большинство облачных провайдеров позволяют вам создавать новые хосты при помощи API. В то же время, инициализация физического сервера, скорее всего, потребует выполнения некоторых ручных операций. Инструменты управления инициализацией вроде Chef, Puppet, Ansible или Salt позволяют осуществлять первичную настройку хоста, в том числе обеспечивая его информацией, необходимой для его добавления в существующий кластер.
Инициализация может осуществляться как администратором, так и автоматически с помощью инструментов управления кластером в целях автоматического масштабирования. Последний способ подразумевает наличие возможности запроса дополнительных хостов, а также задания триггеров для запроса этих хостов. Например, если Ваше приложение испытывает серьёзную нагрузку, Вы можете захотеть, чтобы Ваша система автоматически поднимала новые хосты и горизонтально масштабировала контейнеры для облегчения этой нагрузки.
Вот некоторые примеры популярных планировщиков, поддерживающих базовое распределение задач и управление кластером:
В части управления кластером конфигурации Mesosphere использует следующий компонент:
Следующие проекты позволяют осуществлять расширенное (advanced) распределение задач и управление группами контейнеров:
Управление кластером и распределение задач являются ключевым компонентом реализации контейнеризованных сервисов на распределённом наборе хостов. Они обеспечивают основу управления запуска и контроля сервисов Вашего приложения. Эффективно используя распределение задач, Вы можете в значительной степени влиять на работу Ваших приложений, прилагая при этом незначительные усилия.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Экосистема Docker
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!