Сегодняшние сети нельзя назвать статичными. Распределенные системы, облачные сервисы, системы виртуализации и микросервисы привели к тому, что управлять при помощи традиционных инструментов становится невозможно. Серверы могут перемещаться, сервисы появляются и отключаются. Вручную отследить очень сложно. На выручку придут системы обнаружения сервисов (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

По следам Mirai. Разбираемся, как трояны поражают IoT, на примере самого злого из них

Пора отправлять в архивы истории старый анекдот о том, что вредоноса для Linux нужно снача…