Экосистема Docker: обнаружение сервисов и распределенные хранилища конфигурации

Контейнеры обеспечивают элегантное решение для тех, кто хочет разрабатывать и развертывать приложения в масштабе. В то время как Docker предоставляет технологию создания контейнеров, многие другие проекты помогают в разработке инструментов, необходимых для соответствующей начальной загрузки и связи в среде развертывания.

Одна из основных технологий, на которую опираются многие среды Docker, - это обнаружение сервисов. Обнаружение службы позволяет приложению или компоненту обнаруживать информацию об их среде и соседях. Обычно это реализуется как распределенное хранилище значений ключей, которое также может служить более общим местом для определения деталей конфигурации. Настройка инструмента обнаружения служб позволяет вам отделить конфигурацию времени выполнения от фактического контейнера, что позволяет повторно использовать один и тот же образ в ряде сред.

В этом руководстве мы обсудим преимущества обнаружения служб в кластерной среде Docker. Мы сосредоточимся в основном на общих понятиях, но предоставим более конкретные примеры, где это уместно.

Основная идея обнаружения службы заключается в том, что любой новый экземпляр приложения должен иметь возможность программно идентифицировать детали его текущей среды. Это необходимо для того, чтобы новый экземпляр мог «подключаться» к существующей среде приложения без ручного вмешательства. Инструменты обнаружения служб обычно реализуются как глобально доступный реестр, в котором хранится информация об экземплярах или службах, которые в данный момент работают. В большинстве случаев для обеспечения отказоустойчивости и масштабируемости этой конфигурации реестр распределяется между доступными узлами в инфраструктуре.

Хотя основная цель платформ обнаружения служб состоит в том, чтобы предоставлять сведения о соединении для связывания компонентов вместе, они могут использоваться более широко для хранения любого типа конфигурации. Многие развертывания используют эту возможность, записывая свои данные конфигурации в инструмент обнаружения. Если контейнеры настроены так, что они знают, как искать эти детали, они могут изменять свое поведение в зависимости от того, что они находят.

Каждый инструмент обнаружения служб предоставляет API, который компоненты могут использовать для установки или извлечения данных. По этой причине для каждого компонента адрес обнаружения службы должен быть либо жестко закодирован в самом приложении / контейнере, либо предоставлен как опция во время выполнения. Обычно служба обнаружения реализуется как хранилище значений ключей, доступное с использованием стандартных методов http.

Портал обнаружения сервисов работает так, что каждый сервис, когда он подключается к сети, регистрируется с помощью инструмента обнаружения. Он записывает любую информацию, которая может понадобиться связанному компоненту для использования предоставляемого им сервиса. Например, база данных MySQL может зарегистрировать IP-адрес и порт, на котором работает демон, и, необязательно, имя пользователя и учетные данные, необходимые для входа.

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

Это берет детали конфигурации из самих контейнеров. Одним из преимуществ этого является то, что он делает контейнеры компонентов более гибкими и менее привязанными к конкретной конфигурации. Еще одним преимуществом является то, что он упрощает реагирование ваших компонентов на новые экземпляры связанных служб, что позволяет динамически изменять конфигурацию.

Одним из ключевых преимуществ глобально распределенной системы обнаружения служб является то, что она может хранить любые другие типы данных конфигурации, которые могут понадобиться вашим компонентам во время выполнения. Это означает, что вы можете извлечь еще больше конфигурации из контейнера и в большую среду выполнения.

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

Одной из функций распределенных хранилищ значений ключей в развертываниях Docker, которые могут быть изначально не очевидны, является хранение и управление членством в кластере. Хранилища конфигурации являются идеальной средой для отслеживания членства в хосте с помощью инструментов управления.

Часть информации, которая может храниться об отдельных хостах в распределенном хранилище значений ключей:

Эти детали, вероятно, не являются чем-то, что вам нужно беспокоиться при использовании платформы обнаружения служб в обычных обстоятельствах, но они предоставляют средства для инструментов управления для запроса или изменения информации о самом кластере.

Обнаружение неисправностей может быть реализовано несколькими способами. Проблема заключается в том, будет ли в случае сбоя компонента служба обнаружения обновлена, чтобы отразить тот факт, что она больше не доступна. Этот тип информации крайне важен для сведения к минимуму сбоев приложений или служб.

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

Этого также можно достичь, связав «вспомогательный» контейнер с каждым компонентом, единственная обязанность которого - периодически проверять работоспособность компонента и обновлять реестр, если компонент выходит из строя. Проблема с этим типом архитектуры заключается в том, что вспомогательный контейнер может выйти из строя, что приведет к неправильной информации в хранилище. Некоторые системы решают эту проблему, имея возможность определять проверки работоспособности в инструменте обнаружения служб. Таким образом, сама платформа обнаружения может периодически проверять, доступны ли все еще зарегистрированные компоненты.

Одним из ключевых улучшений базовой модели обнаружения услуг является динамическая реконфигурация. В то время как обычное обнаружение службы позволяет влиять на начальную конфигурацию компонентов путем проверки информации обнаружения при запуске, динамическая реконфигурация включает в себя настройку компонентов для реагирования на новую информацию в хранилище конфигурации. Например, если вы реализуете балансировщик нагрузки, проверка работоспособности на внутренних серверах может показать, что один из членов пула не работает. Работающий экземпляр балансировщика нагрузки должен быть проинформирован и должен иметь возможность настроить его конфигурацию и перезагрузить, чтобы учесть это.

Это может быть реализовано несколькими способами. Поскольку пример балансировки нагрузки является одним из основных вариантов использования этой возможности, существует ряд проектов, которые фокусируются исключительно на перенастройке балансировщика нагрузки при обнаружении изменений конфигурации. Настройка конфигурации HAProxy распространена из-за ее повсеместного распространения в пространстве балансировки нагрузки.

Некоторые проекты являются более гибкими в том смысле, что их можно использовать для запуска изменений в любом типе программного обеспечения. Эти инструменты регулярно запрашивают службу обнаружения, и при обнаружении изменения используют системы шаблонов для создания файлов конфигурации, которые включают значения, найденные в конечной точке обнаружения. После создания нового файла конфигурации соответствующая служба перезагружается.

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

При первом знакомстве с глобально доступным хранилищем конфигурации одна проблема беспокоит безопасность. Действительно ли нормально хранить информацию о соединении в глобально доступном месте?

Ответ на этот вопрос во многом зависит от того, что вы выбираете для размещения в магазине, и сколько уровней безопасности вы считаете необходимым для защиты ваших данных. Почти каждая платформа обнаружения сервисов позволяет шифровать соединения с помощью SSL / TLS. Для некоторых служб конфиденциальность может быть не очень важной, и размещение службы обнаружения в частной сети может оказаться удовлетворительным. Тем не менее, большинство приложений, вероятно, выиграют от дополнительной безопасности.

Существует несколько способов решения этой проблемы, и различные проекты предлагают свои собственные решения. Решение одного из проектов - продолжать разрешать открытый доступ к самой платформе обнаружения, но шифровать записанные в нее данные. Потребитель приложения должен иметь связанный ключ для расшифровки данных, которые он находит в хранилище. Другие стороны не смогут получить доступ к незашифрованным данным.

Для другого подхода некоторые инструменты обнаружения служб реализуют списки контроля доступа, чтобы разделить пространство ключей на отдельные зоны. Затем они могут назначить владельца или доступ к областям на основе требований доступа, определенных конкретным пространством ключей. Это упрощает предоставление информации для одних сторон, сохраняя ее конфиденциальность от других. Каждый компонент может быть настроен так, чтобы иметь доступ только к той информации, которая ему явно необходима.

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

Некоторые из наиболее распространенных инструментов обнаружения служб:

Некоторые другие проекты, которые расширяют базовое обнаружение услуг:

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

Вnext guide мы обсудим способы, которыми контейнеры и хосты Docker могут взаимодействовать с настраиваемыми сетевыми конфигурациями.