Основы работы с системой обнаружения сервисов Consul

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

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

В этом мануале мы рассмотрим базовые функции и методы работы с Consul. В следующем мануале вы узнаете, как запустить Consul в среде производства.

Требования и цели

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

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

Для данного мануала (и остальных мануалов этой серии) вам понадобятся 4 компьютера. Первые три будут серверами, а последний будет агентом (который действует как клиент и может использоваться для запроса информации о системе).

Чтобы в дальнейшем у вас была возможность реализовать некоторые механизмы безопасности, вам нужно назвать все машины в рамках одного домена. Это значит, что в будущем вы сможете использовать wildcard SSL-сертификат.

Данные о машинах:

Имя хоста IP-адрес Роль
server1.example.com 192.0.2.1 Загрузочный сервер consul
server2.example.com 192.0.2.2 Сервер consul
server3.example.com 192.0.2.3 Сервер consul
agent1.example.com 192.0.2.50 Клиент consul

Для работы мы используем 64-битные серверы Ubuntu 14.04, но любой современный дистрибутив Linux будет работать аналогичным образом.

Загрузка и установка Consul

Сначала нужно загрузить и установить consul на каждой из наших машин. Для каждой из перечисленных выше машин следует предпринять следующие шаги. Вы должны войти в систему как root.

Установите утилиту unzip для извлечения исполняемого файла Consul. Также нужно использовать приложение screen, чтобы поддерживать несколько сеансов в одном окне терминала. Это полезно, поскольку Consul обычно занимает весь экран, когда не работает как сервис.

Обновите индекс локальных пакетов и установите требуемое ПО:

apt-get update
apt-get install unzip screen

Запустите сессию screen:

screen

Нажмите enter, если вы получите сообщение об авторском праве. После этого вы вернетесь в окно терминала, но теперь он работает в сессии screen.

Теперь можно загрузить Consul. Страница проекта предоставляет ссылки для загрузки бинарных пакетов для Windows, OS X и Linux.

Перейдите на эту страницу и щелкните правой кнопкой мыши на операционной системе и архитектуре, которая используется на ваших серверах. В этом руководстве мы будем использовать ссылку «amd64» в разделе «linux». Скопируйте ссылку на пакет.

В терминале перейдите в каталог /usr/local/bin, где будет храниться исполняемый файл. Введите wget и пробел, а затем вставьте URL-адрес, который вы скопировали с сайта:

cd /usr/local/bin
wget https://dl.bintray.com/mitchellh/consul/0.3.0_linux_amd64.zip

После этого можно распаковать и удалить архив:

unzip *.zip
rm *.zip

Теперь у вас есть доступ к команде consul.

Запуск сервера consul

Чтобы начать работу с consul, нужно запустить серверы. При настройке в многосерверной среде этот шаг необходимо выполнить поэтапно.

Первое, что нужно сделать, это запустить программу consul на одном из серверов в режимах server и bootstrap. Режим server означает, что consul запускается как экземпляр сервера, а не клиент. Параметр bootstrap используется для первого сервера. Это позволяет ему стать ведущим сервером кластера без выборов (так как это будет единственный доступный сервер).

В таблице хостов (в требованиях) server1 указан как загрузочный. На server1 запустите загрузку:

consul agent -server -bootstrap -data-dir /tmp/consul

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

. . .
2014/07/07 14:32:15 [ERR] agent: failed to sync remote state: No cluster leader
2014/07/07 14:32:17 [WARN] raft: Heartbeat timeout reached, starting election
2014/07/07 14:32:17 [INFO] raft: Node at 192.0.2.1:8300 [Candidate] entering Candidate state
2014/07/07 14:32:17 [INFO] raft: Election won. Tally: 1
2014/07/07 14:32:17 [INFO] raft: Node at 192.0.2.1:8300 [Leader] entering Leader state
2014/07/07 14:32:17 [INFO] consul: cluster leadership acquired
2014/07/07 14:32:17 [INFO] consul: New leader elected: server1.example.com
2014/07/07 14:32:17 [INFO] consul: member 'server1.example.com' joined, marking health alive

Как видите, лидер кластера не был найден, так как это первая нода. Однако, поскольку в команде есть опция bootstrap, этот сервер смог сам войти в состояние лидера, чтобы инициировать кластер с одним хостом.

Запуск других серверов

На server2 и server3 теперь можно запустить сервис consul без опции bootstrap:

consul agent -server -data-dir /tmp/consul

Вы также увидите логи для этих серверов. В конце будут такие предупреждения:

. . .
2014/07/07 14:37:25 [ERR] agent: failed to sync remote state: No cluster leader
2014/07/07 14:37:27 [WARN] raft: EnableSingleNode disabled, and no known peers. Aborting election.
2014/07/07 14:37:53 [ERR] agent: failed to sync remote state: No cluster leader

Это происходит потому, что они не могут найти лидера кластера и не могут сами стать лидерами. Это происходит потому, что серверы еще не связаны друг с другом.

Теперь нужно объединить эти серверы. Это можно сделать по-разному, но самый простой способ – подключиться с сервера server1.

Поскольку сервер consul запускается в текущем окне терминала server1, нужно создать еще один терминал screen, чтобы выполнить дополнительные операции. Создайте новое окно терминала в текущей сессии server1, набрав:

CTRL-A C

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

CTRL-A N

Вернитесь в новый терминал, подключитесь к другим двум экземплярам, указав их IP-адреса:

consul join 192.0.2.2 192.0.2.3

Это должно немедленно соединить все три сервера в один кластер. Вы можете проверить это:

consul members
Node                 Address             Status  Type    Build  Protocol
server1.example.com  192.0.2.1:8301  alive   server  0.3.0  2
server2.example.com  192.0.2.2:8301  alive   server  0.3.0  2
server3.example.com  192.0.2.3:8301  alive   server  0.3.0  2

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

Удаление загрузочного сервера и повторное подключение в качестве обычного сервера

Теперь все три сервера объединены в кластер.

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

Для этого остановите сервис consul на server1. Это позволит оставшимся в кластере машинам выбрать лидера. Затем нужно перезапустить consul на server1 без опции bootstrap и снова подключить его к кластеру.

На сервере server1 вернитесь в терминал consul:

CTRL-A N

Остановите сервис:

CTRL-C

Перезапустите его без опции bootstrap:

consul agent -server -data-dir /tmp/consul

Вернитесь в терминал и заново подключите сервер к кластеру.

CTRL-A N
consul join 192.0.2.2

Теперь все три сервера находятся в одинаковой позиции. Они будут копировать информацию друг друга и обрабатывать ситуации, когда один из них становится недоступным. Теперь к кластеру могут присоединиться другие серверы: просто  запустите сервер без bootstrap и добавьте его в кластер.

Добавление клиента и обслуживание веб-интерфейса

Теперь, когда кластер доступен, можно подключиться к нему с помощью клиентской машины.

Разместить веб-интерфейс consul можно на клиентской машине (это позволит взаимодействовать с кластером и следить за его состоянием). Для этого перейдите на страницу загрузки веб-интерфейса. Кликните правой кнопкой мыши на кнопке загрузки и скопируйте ссылку.

На клиентской машине перейдите в домашний каталог. Введите wget и пробел, а затем вставьте URL-адрес, который вы скопировали со страницы:

cd ~
wget https://dl.bintray.com/mitchellh/consul/0.3.0_web_ui.zip

Когда загрузка будет завершена, распакуйте и удалите архив:

unzip *.zip
rm *.zip

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

Чтобы подключиться к кластеру, используйте вызов consul, который вы использовали для серверов, но с другими флагами.

Чтобы машина работала в режиме клиента, ей не нужен флаг server. По умолчанию интерфейс каждой ноды доступен с по локальному интерфейсу loopback. Чтобы получить доступ к веб-интерфейсу удаленно, вместо этого нужно указать внешний IP-адрес клиента.

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

Команда подключения получится довольно длинная. Она будет выглядеть так:

consul agent -data-dir /tmp/consul -client 192.0.2.50 -ui-dir /home/your_user/dir -join 192.0.2.1

Клиент подключится к кластеру как к обычный агент (не сервер). Этот агент будет отвечать на запросы на своем внешнем IP-адресе вместо обычного интерфейса 127.0.0.1. Потому вам нужно будет использовать дополнительный флаг rpc-addr в любых командах consul.

Например, если вы хотите запросить список членов кластера у клиента, вам нужно будет указать правильный интерфейс и порт, который вы выбрали:

consul members -rpc-addr=192.0.2.50:8400
Node     Address             Status  Type    Build  Protocol
agent1   192.0.2.50:8301    alive   client  0.3.0  2
server2  192.0.2.2:8301  alive   server  0.3.0  2
server1  192.0.2.1:8301  alive   server  0.3.0  2
server3  192.0.2.3:8301  alive   server  0.3.0  2

Вывод может показаться запутанным, но он дает возможность подключиться к интерфейсу consul. Для этого вам нужно указать адрес клиента и добавить :8500/ui в браузере:

http://192.0.2.50:8500/ui

Вы можете посмотреть разные меню и изучить интерфейс. Он позволяет визуализировать кластер и отслеживать состояние ваших машин и сервисов.

Добавление сервисов и проверок

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

Для примера установим Nginx на клиентскую машину. Остановите текущую сессию клиента:

CTRL-C

Установите Nginx:

apt-get install nginx

Создайте каталог конфигураций для хранения определений сервисов:

mkdir ~/services

Внутри этого каталога создайте файл web.json, который описывает веб-сервис:

nano ~/services/web.json

В этом файле должна быть структура для определения сервиса. В рамках этой структуры мы определим подструктуру для проверки работоспособности сервиса.

Базовая структура выглядит следующим образом:

{
"service": {
. . .
"check": {
. . .
}
}
}

Здесь нужно определить имя сервиса и сообщить consul, какой порт он должен проверять. Кроме того, можно предоставить consul список тегов, которые можно использовать для произвольной категоризации сервиса (для сортировки).

В итоге структура выглядит так:

{
"service": {
"name": "web server",
"port": 80,
"tags": ["nginx", "demonstration"],
"check": {
. . .
}
}
}

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

Для проверки данного сервиса добавьте простой веб-запрос curl (как говорится в документации consul). На самом деле вам не нужно знать, что можно извлечь с помощью curl, главное – удалось ли выполнить команду без ошибок. Потому весь вывод команды можно сбросить.

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

{
"service": {
"name": "web server",
"port": 80,
"tags": ["nginx", "demonstration"],
"check": {
"script": "curl localhost:80 > /dev/null 2>&1",
"interval": "10s"
}
}
}

Сохраните и закройте файл.

Теперь можно просто перезапустить сессию клиента consul и направить на каталог:

consul agent -data-dir /tmp/consul -client 192.0.2.50 -ui-dir /home/your_user/dist -join 192.0.2.1 -config-dir /home/your_user/services

Нода перезапустится и подключится к кластеру. Если вы вернетесь в интерфейс, вы увидите в нем сервис.

Вернитесь на клиентскую машину, создайте новый терминал и остановите веб-сервер.

CTRL-A C
service nginx stop

Обновив UI, вы увидите, что теперь проверка показывает, что сервис не работает.

Заключение

Теперь у вас есть общее представление о том, как работает consul. Примеры, приведенные в этом мануале, не отображают пользы consul в среде производства. Об этом мы поговорим в следующем мануале.

Tags: ,

Добавить комментарий