Service discovery что это
Свой облачный хостинг за 5 минут. Часть 2: Service Discovery
Привет Хабр! В предыдущей статье я рассказал как построить свой облачный хостинг за 5 минут, используя Ansible, Docker и Docker Swarm. В этой части я расскажу о том, как сервисы, запущенные в облаке, находят друг друга, как происходит балансировка нагрузки между ними и обеспечивается их отказоустойчивость.
Это вводная статья, здесь мы сосредоточимся на обзоре инструментов, которые будут решать проблему «обнаружения сервисов» в нашем облаке. В следующей части мы приступим к практике, поэтому я решил дать вам время поближе ознакомиться с ними.
Содержание
Проблема
Давайте разберем наиболее типичную проблему и ее распространенное решение – у нас есть веб-приложение и мы должны обеспечить балансировку нагрузки и его отказоустойчивость.
Мы можем запустить несколько копий нашего веб-приложения, которые будет мониторить Supervisor. Supervisor будет перезапускать наше веб-приложение, если возникнут какие-то ошибки, а также будет добавлять такие события в журнал. Проблему балансировки нагрузки решит установка Nginx. Конфигурация Nginx будет выглядеть примерно так:
Работать указанная конфигурация будет так – если в течение 5 секунд число неудачных попыток при обращении к одному из веб-приложений достигнет 3-ех, то такое приложение отметится как неработоспособное на 5 секунд (если оно упало с ошибкой, то Supervisor перезапустит его). Таким образом вся нагрузка равномерно распределиться только между рабочими копиями приложений.
Недостатки
На самом деле это хорошая конфигурация и если у вас немного приложений и нагрузка более-менее равномерная, тогда лучше использовать именно её.
Но мы строим облако, где будет запущено то или иное приложение – мы не знаем. Нагрузка у нас может меняться для разных сайтов/веб-приложений по разному, поэтому неплохо бы иметь возможность менять количество запущенных копий наших приложений в зависимости от ситуации. Другими словами – мы не можем заранее настроить Nginx/Apache/etc на такую конфигурацию.
Было бы круто, если бы Nginx и другие наши сервисы приспособились к динамической природе нашего облака. Решением именно этой задачи мы и займемся в этой статье.
Требования
Нам нужно место, где наши сервисы смогут регистрировать себя и получать информацию друг о друге. Docker Swarm, который мы начали использовать в предыдущей статье, «из коробки» умеет работать с etcd, Consul и Zookeeper.
Нам необходимо, что бы наши сервисы автоматически регистрировались и удалялись из вышеуказанных систем (мы же не будем обучать этому каждое приложение). Для этих целей мы используем Registrator (ниже рассмотрим его более подробно), который «из коробки» работает с Consul, etcd и SkyDNS 2 (поддержка Zookeeper в планах).
Наши сервисы должны иметь возможность находить друг друга с помощью DNS запросов. Эту задачу могут решить Consul и SkyDNS 2 (который работает в паре с etcd).
Мониторинг здоровья сервисов нам тоже необходим. Он доступен нам в Consul (который мы и будем использовать) «из коробки» и его поддерживает Registrator (он должен передавать информацию о том, как должен происходить мониторинг того или иного сервиса).
Последнее, но не менее важное – нужен сервис для автоматической конфигурации наших составляющих. Если мы запустили 10 копий одного веб-приложения и 20 копий другого, он должен понимать и немедленно реагировать на это (меняя конфигурацию Nginx, например). Выполнять эту роль будет Consul Template (ниже рассмотрим его более подробно).
Consul
Из перечисленных выше вариантов (Consul, Zookeeper, etcd), Consul является наиболее самостоятельным проектом, который в состоянии решить нашу проблему обнаружения сервисов «из коробки».
Не смотря на то, что Consul, Zookeeper и etcd расположены здесь в одном ряду, я бы не стал их сравнивать между собой. Все 3 проекта реализуют распределенное key/value хранилище и на этом их общие черты заканчиваются.
Consul нас обеспечит DNS сервером, которого нет в Zookeeper и etcd (можно добавить с помощью SkyDNS 2). Более того, Consul даст нам мониторинг здоровья (которым не могут похвастаться ни etcd, ни Zookeeper), что также необходимо для полноценного Service Discovery.
В нагрузку с Consul мы получим Web UI (демо которого можно глянуть уже сейчас) и качественную официальную документацию.
Registrator
Registrator получает информацию от Docker‘а о запуске/остановке контейнеров (через сокет-соединение, с помощью Docker API) и добавляет/удаляет их в/из Consul‘a.
Информацию о том или ином сервисе Registrator автоматически получает на основе опубликованных портов и из переменных окружения Docker контейнера. Другими словами – это работает с любыми контейнерами, которые у вас есть и требует дополнительного конфигурирования только в том случае, если необходимо переопределить параметры полученные автоматически.
И раз все наши сервисы работают исключительно в Docker контейнерах (и сам Registrator в том числе), то в Consul‘е всегда будет информация о всех запущенных сервисах нашего облака.
Это все конечно круто, но еще круче то, что Registrator может рассказать Consul‘у, как проверять здоровье наших сервисов. Делается это с помощью тех же переменных окружения.
Consul умеет проверять здоровье сервисов, если для сохранения информации о них используется Consul Service Catalog (который мы и задействуем).
Если же используется Consul Key-value Store (который тоже поддерживается Registrator’ом и использует, например, Docker Swarm для сохранения информации о Docker нодах), такой функции нет.
Давайте рассмотрим пример:
После подобного запуска, список наших сервисов у Consul‘а будет выглядеть следующим образом:
Как вы видите, на основе опубликованных портов Registrator сделал вывод, что зарегистрировать надо 2 сервиса (http и https). Более того, у Consul‘a теперь есть вся необходимая информация о том, как проверять здоровье этих сервисов.
Во втором случае – каждые 15 секунд Consul будет дергать переданный нами URL. Если код ответа сервера будет 2xx, то наш сервис «здоров», если 429 Too Many Requests, то в «экстренном состоянии», если все остальное, то «земля ему пухом».
Больше примеров и более подробную информацию вы может почерпнуть из официальной документации.
Consul Template
Мы решили где хранить информацию о всех сервисах нашего облака, а также как она будет туда попадать и автоматически там обновляться. Но мы еще не разобрались, как же будем получать информацию от туда и как, в последствии, будем её передавать нашим сервисам. Именно этим и будет заниматься Consul Template.
Для этого надо взять конфигурационный файл нашего приложения (которое мы хотим настроить) и сделать из него шаблон, согласно правилам HashiCorp Configuration Language.
Давайте рассмотрим простой пример с конфигурационным файлом Nginx:
После того, как мы объясним Consul Template где находится данный шаблон, куда положить результат и какую комманду выполнить (он это тоже умеет) при его изменении (в данном случае перезагрузить Nginx), начнётся магия. В данном случае Consul Template получит адреса и номера портов всех копий приложения «cool-app«, которые помечены тегом «tag1» и находятся в «здоровом» состоянии и добавит их в конфигурационный файл. Если таких приложений нет, тогда, как вы уже догадались, останется все, что находится после <
При каждом добавлении и удалении сервиса «cool-app» с тегом «tag1» конфигурационный файл будет перезаписываться, а после этого Nginx будет перезагружен. Все это происходит автоматически и не требует вмешательства, мы просто запускаем нужное количество копий нашего приложения и не о чём не беспокоимся.
Больше примеров вы можете найти в официальной документации.
Заключение
На сегодняшний день существует достаточное количество инструментов для решения проблемы обнаружения сервисов, но не так много средств, которые могли бы решить данную проблему «из коробки» и сразу обеспечить нас всем необходимым.
В следующей части я опубликовал набор сценариев для Ansible, которые сконфигурируют за нас все вышеописанные инструменты и мы сможем приступить в практике.
На этом все. Всем спасибо за внимание. Стабильных вам облаков и удачи!
Подписывайтесь на меня в Twitter, я рассказываю о работе в стартапе, своих ошибках и правильных решениях, о python и всём, что касается веб-разработки.
Consul: Service Discovery это просто, или прощаемся с конфиг-файлами
Что здесь интересного:
Обзорная статья о Consul (http://consul.io) — системе для поддержания обнаружения сервисов и распределенного хранилища ключ-значение. Кроме самого Consul, рассмотрим Consul-Template — средство для управления конфигурациями сервисов автоматически отражающее изменения в топологии. Статья будет интересна DevOps инженерам, системным архитекторам, тим-лидам проектов и прочим интересующимся микросервисными архитектурами.
Естественно я не могу осветить все аспекты функционирования и использования Consul но в статье будет описано достаточно, чтобы пытливый читатель заинтересовался и продолжил изучение глубже.
Consul: «что за птица — с чем едят?»
Лирическое отступление, но по теме.
В текущем мире огромных объемов данных, где распределенные системы их обработки становятся не чем-то из мира недостижимой фантастики но обыденными вещами, вопросы их правильного проектирования и реализации становятся очень важным моментом в последующем развитии этих систем. Каждый, кто хотя бы раз принимал участие в разработке архитектур автоматически масштабируемых, распределенных систем, знает что этот процесс очень трудоемкий и требующий достаточно серьезного стека знаний систем из которых можно строить подобные архитектурные решения. С учетом бурного развития облачных вычислений и появления IaaS платформ — разворачивание масштабируемых систем стало достаточно простым делом. Однако взаимодействие компонентов таких систем (интеграция новых компонентов, удаление неиспользуемых частей и т.д.) всегда вызывает головную боль у архитекторов, devops инженеров и программистов. Для этих целей можно придумывать свой велосипед (шаблоны конфигурационных файлов, поддержка саморегистрации со стороны приложения и т.д.), можно использовать локальные или распределенные системы хранения данных «ключ-значение» (redis, zookeeper, etcd и др.) а можно использовать системы обнаружения сервисов (Service Discovery).
Часто термин Service Discovery (в дальнейшем я буду использовать сокращение — SD) относится к системам сетевого обнаружения (протокол SDP, к примеру) но в последнее время SD используется и в программной части архитектур для взаимного обнаружения связанных компонентов систем. Особенно это касается микросервисного подхода к разработке программных комплексов. MSA (Micro Services Architecture), одними из первопроходцев и популяризаторов которой является Netflix, все чаще становится стандартом для разработки распределенных, авто-масштабируемых, высоко нагруженных систем. И Consul уже много где используется для обеспечения SD в подобного рода системах. К примеру Cisco использует его в своем движке для MSA — Cisco MI.
Собственно, Consul и есть удачное объединение K/V хранилища и SD функционала. Ну а теперь подробнее.
Consul: Чем он лучше?
Достаточно резонный вопрос «Зачем нам Consul, если у нас есть Zookeeper и он прекрасно справляется с задачей SD?». Ответ на поверхности — Zookeeper, и подобные системы (etcd, doozerd, redis, etc) не предоставляют функционала SD — их задача всего-лишь хранить данные в том или ином формате и гарантировать их доступность и консистентность в каждый отдельный момент времени (при условии правильной настройки и использования, конечно). Естественно такой модели будет вполне достаточно для обеспечения SD, но вот удобство использования (настройки, обслуживания, и т.д.) частенько оставляет желать лучшего.
К примеру, Zookeeper: это постоянная возня с его кластером, — начиная с первичной настройки (автоматизированная установка zk кластера средствами Ansible или SaltStack может доставить немало хлопот даже продвинутому специалисту), заканчивая передачами софту, использующему Zookeeper, ссылок на кластер вида zk://10.10.1.2:2181,10.10.1.3:2181,10.10.1.5:2181/app (необходимо предварительно знать где расположен кластер, все его ноды). Мало того, — если кластер Zookeeper по какой-то причине «переедет» на другие адреса (очень актуально в облачных средах, MSA архитектурах), придется перезапускать все использующие этот кластер приложения и сервисы.
С Consul все проще: ребята из HashiCorp сделали «все для людей». Consul распространяется как 1 бинарный файл (нет надобности следить за зависимостями, использовать пакетные менеджеры) и любой софт использующий Consul всегда делает запросы к нему на localhost (нет надобности хранить ссылку на кластер или master ноду сервиса), — Consul все берет на себя. Использование Gossip в качестве протокола обмена данными делает Consul быстрым, отказоустойчивым и не требующим выделенного мастера для нормального функционирования. На самом деле мастер как таковой формально имеется (даже кворум мастеров) но это необходимо по большей части для того, чтобы пережить полную остановку всех нод кластера (мастера обеспечивают периодическое сохранение оперативных данных на диск тем самым гарантируя персистентность данных). В итоге, для приложения (микросервиса) использующего Consul вся работа с SD сводится к общению с localhost:8500 — куда бы не переехало приложение — там всегда будет агент Consul. Мало того, для работы с Consul не нужно иметь каких-либо клиентских библиотек (как в случае с Zookeeper) — для этого используется простой и понятный HTTP REST API (простые данные, не более 20 разных API функций), либо DNS сервисы с SRV записями (да, — одна из функций Consul — предоставление DNS интерфейса к зарегистрированным сервисам).
Более подробно можно почитать тут.
Consul: Как поставить, и начать работу?
Сразу скажу, что останавливаться подробно на установке и настройке мы не будем — для читающих статью, думаю, это будет достаточно простым упражнением. Лишь одна проблема достойная внимания, — не прозрачность в поиске документации по установке на сайте, потому вот ссылки: начальная установка (как домашнее задание — разработка start/stop скриптов для своего любимого init.d/upstart/systemd — ненужное — вычеркнуть), запуск агентов и инициализация кластера.
Пара замечаний по поводу выбора топологии кластера. Не лишним будет отметить, что Consul не имеет обособленного мастера, который единолично принимал и распространял бы конфигурации сервисов и данные между нодами, — абсолютно любой агент может быть использован для регистрации сервисов и данных. Вообще-то говоря, мастер (точнее кворум мастов) как таковой имеется, и его основная роль — обеспечение персистентности данных при рестартах кластера.
Consul: Регистрируем сервис, используем запросы
Итак, имея готовый кластер (или одну ноду для тестов) начнем регистрировать сервисы. Для начала сгенерируем гипотетический сценарий на базе которого будем дальше разбираться с работой Consul: предположим у нас есть классическое web приложение состоящее из нескольких frontend сервисов, нескольких backend сервисов и хранилища данных — пусть будет mongodb. Оговорим сразу же, что инфраструктура тестовая и вопросы наподобие: почему MongoDB не кластеризован?, почему HAProxy, а не Nginx? и т.д. оставляю пытливому читателю в качестве домашнего задания.
При работе с Consul мы будем различать 2 вида сервисов — активные (использующие http rest api для собственной регистрации и внедрения проверок доступности) и пассивные (требующие предварительно приготовленных конфигурационных файлов для Consul). К первым будем относить сервисы разрабатываемые локально (продукт компании и его компоненты), ко вторым: сторонние приложения (необязательно поддерживающие работу с Consul, или не поддерживающих ее вообще, — к примеру MongoDB).
Итак, введем регистрацию для MongoDB сервиса — создадим файл /etc/consul.d/mongodb.json:
Самое важное тут:
1. address/port — собственно именно эти данные будут получать клиенты Consul в ответ на запрос информации о сервисе «mongo-db». Публикуемый адрес должен быть доступен.
2. Секция «checks» — список проверок позволяющих идентифицировать жив ли сервис. Это может быть любой скрипт (возвращающий 0 в случае нормального функционирования сервиса; 1 в случае warning статуса сервиса и любое другое значение в случае недоступности сервиса), http проверка (запрашивается некий URL и на основании ответа генерируется состояние сервиса — HTTP/2XX — сервис жив, HTTP/4XX, HTTP/5XX — сервис недоступен).
Последующий рестарт агента (с указанием /etc/consul.d/ как каталога с конфигурациями) примет этот файл и зарегистрирует MongoDB как сервис доступный для SD. Скрипт указанный в секции checks делает подключение к MongoDB на указанном хосте (тестируя доступность сервиса) и, к примеру, делает запрос к какой-то коллекции для проверки доступности данных.
В последствии проверить регистрацию можно при помощи curl:
Или с помощью встроенного в Consul DNS сервера:
Использование того или иного способа получения данных из Consul зависит от архитектуры запрашивающего компонента (для скриптов удобнее использовать DNS интерфейс, для компонентов написанных на ЯП высокого уровня — REST запросы или специализированные библиотеки).
Все сервисы, которые могут поддерживать саморегистрацию должны использовать библиотеки для необходимых ЯП: python, java, go, ruby, php. Необходимо не забывать помимо, собственно регистрации сервисов, грамотно разрабатывать скрипты проверки доступности того или иного сервиса чтобы не получить систему с зарегистрированными но не работающими сервисами.
Consul: Прощайте конфигурационные файлы.
Собственно добрались до самой сути, — дочитавшим посвящается… Итак в какой-то определенный момент времени мы получили среду в которой зарегистрированы сервисы (mongodb, backend, — к примеру) какую же выгоду можно получить?
В традиционных распределенных системах (без внедренного SD) используются в основном такая техника для добавления нового компонента в систему (скажем при росте нагрузки необходимо создать еще один backend):
1. Создается инстанс backend сервиса (зачастую при помощи систем оркестровки типа SaltStack/Puppet/Ansible/Hand-Made scripts/etc)
2. Система оркестровки по шаблонам генерирует новые конфигурационные файлы для сервисов использующих backend (load balancers, frontends, etc)
3. Та же система оркестровки генерирует конфиг файл для этого нового backend сервиса, указывая в нем контактную информацию о mongodb и прочих зависимых компонентах
4. Все зависимые сервисы перечитывают конфигурацию (или рестартуют) пересоздавая соединения между собой
5. Система дожидается конвергенции и переходит в рабочее состояние.
Подобный подход очень затратен — необходимо сделать генерации конфиг файлов, их распространение, перезапуски сервисов и т.д. Ко всему — в процесс вовлечена система оркестровки (сторонний по отношению к рабочей системе компонент) за доступностью которой тоже нужно следить.
SD позволяет существенно упростить этот процесс (как именно, пытливый читатель уже думаю догадался), но требует изменения поведения самих сервисов входящих в систему. И это не только поддержка SD (регистрации сервиса и обнаружения сервисов), но и Fail Tolerance (способность сервиса безболезненно переживать изменения в топологии подчиненных сервисов), активное использование KV хранилищ для обмена конфигурационной информацией, и т.д.
Единственный внешний компонент, который придется использовать в таких конфигурациях — Consul-Template — средство для подключения к Consul разнообразных, не поддерживающих SD, систем, к примеру: HAProxy. Задача этого программного средства отслеживать регистрации/дерегистрации сервисов и изменять конфигурации подчиненных сервисов, т.е. при регистрации нового backend автоматически будет перестроен конфиг HAProxy для включения этого нового инстанса в процесс балансировки нагрузки. Подробнее об этом можно почитать тут.
Собственно применение SD на базе Cunsul, Consul-Template, Consul-KV в принципе может помочь полностью избавится от каких-либо конфигурационных файлов и оставить все на откуп Consul.
Consul.io Часть 1
При разработке приложений необходимо уделять особое внимание архитектуре. Если изначально этого не сделать, проблемы масштабирования могут появиться внезапно (а иногда могут не иметь решения). Масштабирование приложения и эффективное использование ресурсов на начальном этапе — это сэкономленные месяцы работы в дальнейшем.
Для предотвращения подобных проблем часто используют распределенную архитектуру, то есть архитектуру с возможностью горизонтального масштабирования всех компонентов. Но к сожалению, при реализации SOA возникают новые проблемы, а именно: связность и сложность конфигурации сервисов.
В данной статье мы расскажем об одном из discovery-сервисов под названием Consul, с помощью которого можно решить вышеизложенные проблемы и сделать архитектуру более прозрачной и понятной.
Распределенные архитектуры(SOA) и проблемы их построения
Что такое discovery?
Discovery — это инструмент (или набор инструментов) для обеспечения связи между компонентами архитектуры. Используя discovery мы обеспечиваем связность между компонентами приложения, но не связанность. Discovery можно рассматривать как некий реестр метаинформации о распределенной архитектуре, в котором хранятся все данные о компонентах. Это позволяет реализовать взаимодействие компонентов с минимальным ручным вмешательством (т.е. в соответствии с принципом ZeroConf).
Роль discovery в процессе построения распределенной архитектуры
Консистентность
Распределенная архитектура подразумевает, что компоненты можно масштабировать горизонтально, при этом они должны владеть актуальной информацией о состоянии кластера. Discovery-сервис обеспечивает (де)централизованное хранилище и доступ к нему для любого узла. Компоненты могут сохранять свои данные и информация будет доставлена ко всем заинтересованным участникам кластера.
Регистрация и мониторинг
Вновь добавляемые сервисы должны сообщить о себе, а уже запущенные обязаны проходить постоянную проверку на доступность. Это является необходимым условием для автоматической конфигурации кластера. Балансеры трафика и зависимые ноды обязательно должны иметь информацию о текущей конфигурации кластера для эффективного использования ресурсов.
Обнаружение
Под обнаружением подразумевается механизм поиска сервисов, например, по ролям которые они выполняют. Мы можем запросить местоположение для всех сервисов определенной роли, не зная их точного количества и конкретных адресов, а зная лишь адрес discovery-сервиса.
Consul.io как реализация discovery
В данной статье рассматривается реализация discovery на базе Consul.
Consul — это децентрализованный отказоустойчивый discovery-сервис от компании HashiCorp (которая разрабатывает такие продукты как Vagrant, TerraForm, Otto, Atlas и другие).
Consul является децентрализованным сервисом, то есть Consul agent устанавливается на каждый хост и является полноправным участником кластера. Таким образом, сервисам не нужно знать адрес discovery в нашей сети, все запросы к discovery выполняются на локальный адрес 127.0.0.1.
Что еще необходимо знать про Consul:
Для распространения информации использует алгоритмы, которые базируются на модели eventual consistency.
Агенты для распространения информации используют протокол gossip.
Серверы для выбора лидера используют алгоритм Raft.
Лидер — это сервер, который принимает все запросы на изменение информации. Если провести аналогию с БД, то это master в контексте master/slave — репликации. Все остальные серверы реплицируют данные с лидера. Ключевое отличие от БД-репликации в том, что в случае выхода из строя лидера все остальные серверы запускают механизм выборов нового лидера и после выборов автоматически начинают реплицироваться с него. Механизм переключения полностью автоматический и не требует вмешательства администратора.
Каждый инстанс может работать в двух режимах: агент и сервер. Разница в том, что агент является точкой распространения информации, а сервер — точкой регистрации. Т.е. агенты принимают запросы только на чтение, а сервер может выполнять изменения уже имеющейся информации (регистрация и удаление сервисов). Фактически мы, в любом случае, выполняем запрос к локальному адресу, разница лишь в том, что запрос на чтение будет обработан агентом на локальном хосте, а запрос на изменение данных будет переадресован лидеру, который сохранит и распространит данные по всему кластеру. Если наш локальный агент не является лидером в данный момент, то наш запрос на изменение будет полностью обработан локально и распространен по кластеру.
Использование Consul в кластере
Consul кластер представляет собой сеть связанных узлов, на которых запущены сервисы, зарегистрированные в discovery. Consul гарантирует, что информация о кластере будет распространена по всем участникам кластера и доступна по запросу. Также реализована поддержка не только однорангового, но и многорангового, разделенного по зонам, кластера, которые в терминологии Consul называются датацентрами. При помощи Consul можно работать как с конкретным датацентром, так и выполнять действия над любым другим. Датацентры не изолированы друг от друга в рамках discovery. Агент в одном ДЦ может получить информацию из другого ДЦ, что может помочь в построении эффективного решения для распределенной системы.
Агенты Consul, запущенные в режиме server, помимо своей основной роли, получают еще и роль потенциального лидера кластера. Рекомендуется использовать в кластере не менее трех агентов в режиме server для обеспечения отказоустойчивости. Использования режима server не накладывает никаких ограничений на основную функциональность агента.
При вводе нового узла в кластер, нам необходимо знать адрес любого узла в кластере. Выполнив команду:
consul join node_ip_address
мы регистрируем новый узел в кластере и, спустя короткое время, информация о состоянии всего кластера будет доступна этому узлу. Соответственно, новый узел окажется доступным для запросов от остальных узлов.
Типы узлов: internal, external
Рассмотрим пример запроса регистрации компонента (JSON должен быть передан в PUT-запросе):
Пример запроса на удаление компонента из каталога:
http://localhost:8500/v1/agent/service/deregister/[ServiceID]
Пример запроса на перевод сервиса в режим maintenance:
http://localhost:8500/v1/agent/service/maintenanse/[ServiceID]?enable=true|false
При помощи флага enable мы можем переключать состояние и добавить необязательный параметр reason, который содержит текстовое описание причины перевода компонента в режим обслуживания.
Если нам необходимо зарегистрировать какой-либо внешний сервис и у нас нет возможности “научить” его регистрироваться в Consul самостоятельно, то мы можем зарегистрировать его не как сервис-провайдер, а именно как внешний сервис (external service). После регистрации мы сможем получить данные о внешнем сервисе через DNS:
Помимо HTTP API вы можете использовать конфигурационные файлы агента с описанием сервисов.