Как установить и настроить Consul-агента и зарегистрировать на кластере сервис

Опубликовано: 10.09.2021

Установленный агент Consul позволяет обмениваться информацией с кластером, отправляя состояние работы сервисов, которые запущены на узле. Мы рассмотрим процесс установки агента на компьютер под управлением Linux на базе Deb (Ubuntu, Debian) или RPM (Rocky Linux, CentOS). Также мы приведем примеры регистрации и настройки проверки сервисов.

Подготовка системы

Предварительно, необходимо настроить брандмауэр. Открываем порты 8300,8301,8302,8500. В зависимости от системы управления netfilter, команды будут отличаться.

а) iptables (как правило для систем на базе deb):

iptables -I INPUT -p tcp —match multiport —dports 8300,8301,8302,8500 -j ACCEPT

iptables -I INPUT -p udp —match multiport —dports 8301,8302 -j ACCEPT

Для сохранения правил используем один из методов, предложенных в данной инструкции.

б) firewalld (чаще для RPM-based):

firewall-cmd —permanent —add-port={8300,8500}/tcp

firewall-cmd —permanent —add-port={8301,8302}/{udp,tcp}

firewall-cmd —reload

Установка агента

На различные системы агент устанавливается, почти, одинаково.

Для начала, установим дополнительные пакеты:

wget — утилита для загрузки файлов.
unzip — пакет для распаковки архивов zip.

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

а) Для Deb:

apt install wget unzip

б) Для RPM:

yum install wget unzip

Теперь можно приступать к установке консула.

На странице со списком релизов необходимо посмотреть на все версии и выбрать необходимую. Также мы можем посмотреть версию consul на сервере:

… и установить такую же.

Так или иначе, создаем переменную с номером версии:

export VER=»1.10.2″

И скачиваем архив с бинарным файлом:

wget https://releases.hashicorp.com/consul/${VER}/consul_${VER}_linux_amd64.zip

Распаковываем его в каталог /usr/bin:

unzip consul_${VER}_linux_amd64.zip -d /usr/bin

Проверяем, что команды консул выполняются:

Мы должны увидеть версию программы:

Consul v1.10.2
…

Агент установлен.

Настройка и запуск агента

Настроим запуск агента в качестве сервиса. Для этого мы создадим юнит в systemd.

Создаем учетную запись, от которой будет работать агент:

useradd -r -c ‘Consul Agent’ consul

* в данном примере мы создадим системную (-r) учетную запись consul. Для удобства восприятия мы также добавим комментарий (-c).

Создаем каталоги для приложения консул:

mkdir -p /var/lib/consul /etc/consul.d

И выставим на них соответствующие права:

chown consul:consul /var/lib/consul /etc/consul.d

chmod 775 /var/lib/consul /etc/consul.d

* в данном примере мы указали, что владельцем данных каталогов будет созданная учетная запись consul. Права будут полные у владельца, остальные смогут читать данные.

Создаем конфигурационный файл:

vi /etc/consul.d/config.json

{
«server»: false,
«datacenter»: «dc1»,
«node_name»: «agent01»,
«data_dir»: «/var/lib/consul»,
«bind_addr»: «192.168.0.100»,
«client_addr»: «127.0.0.1»,
«retry_join»: [«192.168.0.15», «192.168.0.20», «192.168.0.25»],
«encrypt»: «zpjf5a4reDbJFpT6FeaF0LGxD0zBRPSRbIoUkLBt0ps=»,
«log_level»: «warn»,
«enable_syslog»: true,
«telemetry»: {
«disable_compat_1.9»: true
}
}

* где:

server — указывает на использование серверного режима. При значении false используется режим клиента.
datacenter — датацентр, к которому будет присоединяться участник кластера. dc1 — датацентр по умолчанию.
node_name — имя, которым будет представлен узел в кластере.
data_dir — каталог на компьютере, который будет использоваться консулом для хранения своей информации.
bind_addr — IP-адрес, на котором будет слушать сервис.
client_addr — адрес, к которому будут привязаны клиентские интерфейсы. На практике, были проблемы при указании нескольких адресов. Проблема не наблюдается при использовании 127.0.0.1 для client_addr и внешнего сетевого адреса для bind_addr.
retry_join — список серверов консула, к которым должен присоединиться агент.
encrypt — ключ, который был сформирован для серверов консул и используется в качестве значения параметра encrypt (его можно посмотреть в конфигурационном файле на сервере consul).
log_level — уровень логирования. Возможны варианты trace, debug, info, warn, err. По умолчанию используется info.
enable_syslog — вести ли системный лог.
disable_compat_1.9 — запрещает все метрики, которые объявлены устаревшими, начиная с версии 1.9.

Проверяем корректность настройки:

consul validate /etc/consul.d/

Мы должны увидеть:

Configuration is valid!

Продолжаем. Создаем юнит в systemd:

vi /etc/systemd/system/consul.service

[Unit]
Description=Consul client agent
Requires=network-online.target
After=network-online.target

[Service]
User=consul
Group=consul
PIDFile=/var/run/consul/consul.pid
RuntimeDirectory=consul
ExecStart=/usr/bin/consul agent
-config-dir=/etc/consul.d
-pid-file=/var/run/consul/consul.pid
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
KillSignal=SIGTERM
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

Перечитываем конфигурацию systemd:

systemctl daemon-reload

Разрешаем автозапуск сервиса, стартуем его и проверяем статус:

systemctl enable consul

systemctl start consul

systemctl status consul

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

consul members

Среди членов кластера мы должны увидеть свой компьютер, например:

…
agent01 192.168.0.100:8301 alive client 1.10.2 2 dc1 <default>

С агентом завершили.

Использование ACL

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

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

cd /etc/consul.d

vi agent-policy.txt

node_prefix «» {
policy = «write»
}
node «» {
policy = «write»
}
service_prefix «» {
policy = «write»
}
service «» {
policy = «write»
}

* это пример политики, которой слишком много позволено. Для увеличения безопасности, мы можем ограничиться перечислением конкретных значений. Например, service «web» для возможности регистрировать сервисы, названия которых начинаются на web.

Создаем политику agent на основе файла agent-policy.txt:

consul acl policy create -name «agent» -rules @agent-policy.txt

И после, создаем токен на основе политики agent:

consul acl token create -description «Token for Agent» -policy-name agent

Мы получим что-то на подобие:

AccessorID: ddcf169e-237b-836c-47cf-537c12a3818f
SecretID: 37570fdb-798c-24e5-c8c3-612e86031345
Description: Token for Agent
Local: false
Create Time: 2021-09-09 16:36:57.216491588 +0300 MSK
Policies:
b3f3a892-c792-726c-8136-9744fd7e0f7b — agent

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

Переходим на клиентскую ноду и открываем наш конфигурационный файл:

vi /etc/consul.d/config.json

Допишем:

…
«acl»: {
«enabled»: true,
«tokens»: {
«default»: «<token (SecretID)>»
}
}
…

<token> — это сформированный на сервере токен.

Перезагружаем консул на агенте:

systemctl restart consul

Регистрация сервисов

Рассмотрим общий принцип регистрации сервиса в консуле.

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

Добавить настройку в консул.
Проверить конфигурацию и перезапустить сервис consul.
Проверить регистрацию.
Настроить проверку состояния.

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

{
«service»: {
«name»: «<имя сервиса>»,
«tags»: [
«<теги>»
],
«port»: <порт>
}
}

Чтобы настройка применилась, перезагружаем консул.

Проверить, что сервис зарегистрировался можно в веб-панели. Также мы можем опросить сервис в DNS:

nslookup -port=8600 <тег>.<имя сервиса>.service.<датацентр>.<домен> <IP-адрес сервера консул>

или:

dig @<IP-адрес сервера консул> -p 8600 <тег>.<имя сервиса>.service.<датацентр>.<домен>

* в боевой среде стоит настроить перенаправление запросов для домена консула (по умолчанию, consul) на серверы консула. Также для корректной работы многих приложений необходимо сделать так, чтобы консул отвечал на DNS-запросы по порту 53 — для этого можно использовать dnsmasq.

Более конкретно, мы рассмотрим настройки в примерах.

Для проверки состояния нашего сервиса используется конфигурация следующего вида:

{
«service»: {
…
«check»: {
«args»: [
«<аргумент>»,
«<аргумент>»
],
«interval»: «<время опроса>»
}
}
}

* это всего лишь пример. Конфигурация для выполнения проверок может использовать разные подходы. Подробнее, можно почитать в инструкции Consul. Health-check на сайте influunt.ru или Checks на официальном сайте консула.

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

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

…
«enable_local_script_checks»: true,
«enable_script_checks»: true
…

Перейдем к конкретике.

Примеры регистрации сервисов

По мере необходимости, я буду добавлять новые примеры.

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

Предварительно, разрешаем выполнение проверок. Для этого открываем наш конфигурационный файл консула:

vi /etc/consul.d/config.json

Добавим в него:

…,
«enable_local_script_checks»: true,
«enable_script_checks»: true

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

Проверяем конфигурационный файл и перезапускаем консул:

consul validate /etc/consul.d/

systemctl restart consul

1. HTTP (веб)

Создаем конфигурацию:

vi /etc/consul.d/web.json

{
«service»: {
«name»: «web»,
«tags»: [
«front»
],
«port»: 80,
«check»: {
«args»: [
«curl»,
«localhost»
],
«interval»: «10s»
}
}
}

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

Если мы увидим:

Configuration is valid!

… то с конфигурационным файлом все хорошо — можно продолжать.

Применяем настройки:

systemctl restart consul

В панели управления должен появиться наш сервис:

Также dns-запрос:

nslookup -port=8600 web.service.dc1.consul 192.168.0.15

или:

nslookup -port=8600 front.web.service.dc1.consul 192.168.0.15

… должен вернуть IP-адрес нашего сервера с агентом, например:

Non-authoritative answer:
Name: web.service.dc1.consul
Address: 192.168.0.100

2. Java (http)

Данный пример не сильно отличается от предыдущего — прослушивать будем другой порт. Но мы в качестве проверки сервиса будем использовать метод http.

Создаем конфигурацию:

vi /etc/consul.d/java.json

{
«service»: {
«name»: «java»,
«tags»: [
«back»
],
«port»: 8080,
«check»: {
  «http»: «https://localhost:8080»,
  «tls_skip_verify»: false,
  «method»: «GET»,
«interval»: «10s»,
  «timeout»: «2s»
}
}
}

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

Применяем настройки:

systemctl restart consul

3. KeyDB (Redis)

KeyDB и Redis являются довольно популярными базами резидентского типа. Рассмотрим на примере первой процесс регистрации сервиса в Consul и проверки состояния, которое мы будем проверять с помощью скрипта.

Создаем конфигурацию:

vi /etc/consul.d/keydb.json

{
«service»: {
«name»: «keydb»,
«tags»: [
«db»
],
«port»: 6379,
«check»: {
«args»: [ «/scripts/keydb_check.sh» ],
«interval»: «10s»,
«timeout»: «1s»
}
}
}

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

Создаем скрипт для проверки состояния базы:

mkdir /scripts

vi /scripts/keydb_check.sh

#!/bin/bash
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

ping_check=$(keydb-cli ping)

if [ «$ping_check» = «PONG» ]
then
exit 0
else
exit 2
fi

exit 2

Разрешим его запуск на исполнение:

chmod +x /scripts/keydb_check.sh

Применяем настройки:

systemctl restart consul

Вывод из эксплуатации членов кластера

Рассмотрим процесс удаление сервисов и нод кластера.

Снятие с регистрации сервисов

Список зарегистрированных сервисов можно получить командой:

consul catalog services

Удаляем сервис:

consul services deregister -id=’web’

* где web — имя нашего сервиса, который необходимо снять с регистрации.

Удаление нод

На агенте вводим:

consul leave

Если нам нужно форсированно удалить ноду, то с любого участника, где можно управлять кластером, вводим:

consul force-leave agent01

Возможные ошибки

При настройке агента мы можем столкнуться с различными проблемами. Для их решения нам может помочь команда:

consul monitor

Также рассмотрим те, с которыми столкнулся я.

No installed keys could decryp

Ошибка возникаем при попытке подключить узел к кластеру. В итоге мы не обнаруживаем его среди участников (когда смотрим командой consul members). При этом мы видим в логах ошибку

… No installed keys could decryp

Причина: мы указали неверное значение для параметра encrypt.

Решение: состоит из двух шагов — проверки значения encrypt и удаление временного файла, где хранится его значение.

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

Однако, этого недостаточно, так как после первого запуска был создан файл local.keyring, в котором хранится неправильное значение. Просто удаляем его:

rm -f /var/lib/consul/serf/local.keyring

* где /var/lib/consul — путь, который мы указали в конфигурационно файле агента.

Перезагружаем консул на агенте:

systemctl restart consul

Coordinate update blocked by ACLs

Ошибка появляется при подключении агента к кластеру.

Причина: на сервере включен ACL и требуется дополнительная аутентификация.

Решение: на клиенте включаем ACL, а на сервере создаем токен. Подробнее процедура описана выше.

ADMINS24