Thank you for reading this post, don't forget to subscribe!
Установленный агент 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 на сервере:
consul -v
… и установить такую же.
Так или иначе, создаем переменную с номером версии:
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 -v
Мы должны увидеть версию программы:
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
{ "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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
[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
1 2 3 4 5 6 7 8 9 10 11 12 |
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
Мы получим что-то на подобие:
1 2 3 4 5 6 7 |
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
Допишем:
1 2 3 4 5 6 7 8 |
... "acl": { "enabled": true, "tokens": { "default": "<token (SecretID)>" } } ... |
<token> — это сформированный на сервере токен.
Перезагружаем консул на агенте:
systemctl restart consul
Регистрация сервисов
Рассмотрим общий принцип регистрации сервиса в консуле.
Для каждого сервиса можно создавать свой конфигурационный файл (или писать все в одном). Пошагово, необходимо:
- Добавить настройку в консул.
- Проверить конфигурацию и перезапустить сервис consul.
- Проверить регистрацию.
- Настроить проверку состояния.
Синтаксис для конфигурации при регистрации сервиса следующий:
1 2 3 4 5 6 7 8 9 |
{ "service": { "name": "<имя сервиса>", "tags": [ "<теги>" ], "port": <порт> } } |
Чтобы настройка применилась, перезагружаем консул.
Проверить, что сервис зарегистрировался можно в веб-панели. Также мы можем опросить сервис в DNS:
nslookup -port=8600 <тег>.<имя сервиса>.service.<датацентр>.<домен> <IP-адрес сервера консул>
или:
dig @<IP-адрес сервера консул> -p 8600 <тег>.<имя сервиса>.service.<датацентр>.<домен>
* в боевой среде стоит настроить перенаправление запросов для домена консула (по умолчанию, consul) на серверы консула. Также для корректной работы многих приложений необходимо сделать так, чтобы консул отвечал на DNS-запросы по порту 53 — для этого можно использовать dnsmasq.
Более конкретно, мы рассмотрим настройки в примерах.
Для проверки состояния нашего сервиса используется конфигурация следующего вида:
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "service": { ... "check": { "args": [ "<аргумент>", "<аргумент>" ], "interval": "<время опроса>" } } } |
* это всего лишь пример. Конфигурация для выполнения проверок может использовать разные подходы. Подробнее, можно почитать в инструкции Consul. Health-check на сайте influunt.ru или Checks на официальном сайте консула.
Чтобы настроить проверку сервиса, мы добавляем опцию check и передаем в качестве аргументов опции проверки.
Но чтобы это работало, в конфигурационном файле консула нужно добавить две строки:
1 2 3 4 |
... "enable_local_script_checks": true, "enable_script_checks": true ... |
Перейдем к конкретике.
Примеры регистрации сервисов
По мере необходимости, я буду добавлять новые примеры.
0,Включение возможности делать проверку
Предварительно, разрешаем выполнение проверок. Для этого открываем наш конфигурационный файл консула:
vi /etc/consul.d/config.json
Добавим в него:
1 2 3 |
..., "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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ "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
1 2 3 4 5 6 7 8 9 10 11 12 13 |
#!/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, а на сервере создаем токен. Подробнее процедура описана выше.