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

 

Возможности Consul

Можно хранить информацию о расположении служб в конфигурационных файлах или использовать DNS, но это не очень подходит в динамической среде или при запуске микросервисов. Если служба выйдет из строя и окажется необходимым быстро подключиться к другому серверу, будут возникать задержки. Системы обнаружения сервисов автоматизируют процесс, позволяя получить ответ на вопрос, где работает нужный сервис, и изменить настройки в случае появления нового или отказа. Обычно под этим подразумевают набор сетевых протоколов (Service discovery protocols), обеспечивающих нужную функцию, хотя в современных реализациях это уже часть архитектуры, позволяющей обнаруживать связанные компоненты. На сегодня существует несколько решений, реализующих хранение информации об инфраструктуре, — как относительно сложных, использующих key/value-хранилище и гарантирующих доступность (ZooKeeper, Doozer, etcd), так и простых (SmartStack, Eureka, NSQ, Serf). Но, предоставляя информацию, они не слишком удобны в использовании и сложны в настройках.

Consul, разработанный в HashiCorp, также известной своими инструментами вроде Vagrant и Packer, вобрал лучшее, что есть у аналогов. При этом он очень прост в развертывании, может легко масштабироваться на несколько дата-центров, дружественен в использовании и поддержке, что делает его идеальным для современных инфраструктур. К тому же он мультисистемный. В отличие от многих подобных решений, он работает на Windows, OS X, FreeBSD, Solaris и Linux.

Consul предоставляет ряд функций, обеспечивающих доступность информации об инфраструктуре. Service Discovery позволяет обнаружить сервисы и заносить их в базу, называемую каталогом. Любые приложения, использующие Consul, обращаются к нему через localhost, то есть приложению не нужно знать, где хранятся данные, Consul все берет на себя. Для поиска предлагается API, реализованный через HTTP и DNS. Последний вариант дает возможность работать с Consul приложениям, которые о нем ничего не знают. Поддерживается два вида DNS-запроса: поиск узлов (node lookups) и сервисов (service lookups).

<node>.node[.datacenter].<domain>
[tag.]<service>.service[.datacenter].<domain>

Как видим, в запросе также можно конкретизировать дата-центр и, используя тег, указать нужный тип сервиса/узла. В случае если запросу соответствует несколько IP, они возвращаются случайным образом, чем обеспечивается простая балансировка нагрузки.

Служба регистрируется при помощи установки агента и настройки его параметров или через HTTP API. Последний вариант позволяет регистрировать любой внешний сервис, не принадлежащий дата-центру.

Установленные агенты собирают более 200 метрик и могут предоставлять любое количество проверок состояния системы и сервиса, которое необходимо. Администраторы самостоятельно определяют правила проверок. Полученная информация может быть использована для мониторинга, и Consul вполне заменяет системы мониторинга вроде Nagios. Обнаружив проблему с сервисом, Consul автоматически перенаправляет запрос к другому работающему узлу. При этом реализовано два сценария. Если узел уведомляет Consul, что он выключается и будет недоступен (left), его сервисы и проверки удаляются из каталога. Однако когда узел или сервис пропадает без предупреждения (failed), он помечается как критический, но информация некоторое время в каталоге сохраняется, а Consul пытается периодически проверить его доступность.

Также Consul реализует иерархическое key/value-хранилище, которое может быть использовано для любых целей: динамической конфигурации, обмена данными, маркировки, координации доступа к сервисам, выбора лидера и так далее. Доступ к данным производится при помощи HTTP API. Тут нужно отметить, что Consul скорее не заменяет, а дополняет средства конфигурации вроде Puppet и Chef.

Написан на Go и доступен под Mozilla Public License 2.0.

 

Архитектура Consul

Построен Consul по клиент-серверной схеме, использована децентрализованная архитектура. Агенты устанавливаются на все узлы Consul, позволяют ими управлять, обнаруживают сервисы, собирают данные о состоянии, реализуют интерфейсы DNS, API HTTP и RPC CLI. Агент может быть запущен в одном из двух режимов — клиентском или серверном. Клиентская часть собирает данные об узле и сервисе и отсылает их серверу. Компоненты инфраструктуры в поиске серверов или сервисов обращаются с запросом к любому агенту сети Consul, который пересылает его доступному серверу. Если сервер не может ответить на запрос, он направляет его на другие кластеры и возвращает полученный ответ.

Агент с функциями сервера имеет расширенный список возможностей: сбор данных от агента, обмен сообщениями о состоянии с другими серверами, автоматический выбор лидера в кластере (по алгоритму Raft), репликация данных. Сеть Consul может использовать один сервер, но сами разработчики из HashiCorp рекомендуют, чтобы избежать потери данных, использовать от трех до пяти серверов в дата-центре (особенности Raft: кластер из трех узлов сохраняет работоспособность при выходе одного сервера). Серверы образуют кластер и самостоятельно выбирают лидера, отвечающего за координацию. Первый/единственный сервер обычно запускается в так называемом bootstrap-режиме, то есть назначается лидером вручную, но в последующем можно убрать эту «привилегию». Кворум для проведения операций и обеспечения согласованности требуется в каждом дата-центре. При наличии нескольких ДЦ в каждом создается отдельный кластер.

Для обмена данными между агентами используется протокол gossip, позволяющий не только транслировать события и запросы, но и обнаруживать неработающие узлы и уведомлять об этом остальную часть кластера. Обмен между агентами по gossip происходит в LAN — 8301/TCP/UDP, в WAN — 8302/TCP/UDP, RPC клиента с сервером и репликация между серверами — 8300/TCP, CLI RPC — 8400/TCP, HTTP API — 8500/TCP, DNS-интерфейс — 8600/TCP/UDP.

Для защиты подключения может быть использован ключ, уникальный для всех членов кластера и TLS. Кроме управления через API и CLI, для удобного просмотра параметров реализован веб-интерфейс. Поддерживается интеграция с Atlas — еще одним решением HashiCorp, позволяющим разработчикам быстро развертывать приложения.

 

Установка Consul

Исходный код доступен на GitHub, поставляются готовые ZIP-архивы, собранные для 32/64-битных и ARM-версий Windows, OS X, FreeBSD, Solaris и Linux. Отдельно доступны ссылки на вспомогательные инструменты, в том числе разработанные комьюнити, SDK и интерфейс. Здесь есть полезные решения. Например, Consul Template позволяет отслеживать шаблоны и распространять их, если обнаружены изменения. C его помощью можно легко обновлять конфигурационные файлы. На GitHub поиском можно найти библиотеки для разных языков программирования, позволяющих создавать совместимые с Consul приложения. Также доступны готовые образы, дающие возможность развернуть Consul-кластер на базе Docker. Для Ubuntu есть два PPA: ppa:jbboehr/consul и ppa:bcandrea/consul. Но в них не самая актуальная версия, хотя для простого знакомства вполне достаточная. Кроме того, мы получаем сразу нужные конфигурационные файлы и в последующем можем просто подменить бинарник более новой версией.

Рассмотрим развертывание при помощи официального архива. Чтобы познакомиться со всеми возможностями и командами Сonsul, желательно использовать три сервера и один клиент, минимально подойдет сервер + клиент.

Для форматирования вывода в JSON-формате понадобится утилита jq:

$ sudo apt-get instal jq unzip
$ wget -c https://releases.hashicorp.com/consul/0.6.3/consul_0.6.3_linux_amd64.zip

Архив содержит единственную утилиту consul, реализующую агент. В зависимости от параметров можем запускать как клиент, так и сервер. Для удобства использования разархивируем файл в каталог, видимый переменной PATH. В идеале следует создать учетную запись, из-под которой в последующем и запускать Сonsul, но для экспериментов достаточно и того, что есть:

$ sudo unzip consul_0.6.3_linux_amd64.zip -d /usr/bin
 

Запускаем клиент

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

Параметры запуска агента Consul
Параметры запуска агента Consul

Например, ключ -dev позволит запустить агент в development-режиме, в котором будут выводиться основные параметры среды, — очень полезно при знакомстве:

$ consul agent -dev -bind 192.168.86.10
Запуск агента Consul в режиме development
Запуск агента Consul в режиме development

Как правило, на сервере имеется несколько сетевых интерфейсов, Consul может определить нужный для работы автоматически, но это не всегда получается. Поэтому лучше сразу указывать на интерфейс при помощи -bind. По умолчанию агентом используется DNS-имя узла, но можно задать произвольное при помощи -node. Также, если не указать, будет создан дата-центр dc1, но при необходимости его можно переопределить. Еще один важный параметр, -join, позволяет указать на сервер, к которому нужно подключиться. После подключения информация о других агентах будет получена автоматически. Но пока у нас сервера нет.

Кроме -dev, есть еще один полезный ключ, позволяющий просмотреть все текущие установки:

Продолжение статьи доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все статьи на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта, включая эту статью. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Вариант 2. Купи одну статью

Заинтересовала статья, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для статей, опубликованных более двух месяцев назад.


Комментарии

Подпишитесь на ][, чтобы участвовать в обсуждении

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

Check Also

Кеш-атаки по сторонним каналам. Что произошло в области утечек на аппаратном уровне за последние два года

Несмотря на то что до 2016 года существовало лишь несколько публикаций о кеш-атаках на сма…