Установленный агент 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
На различные системы агент устанавливается, почти, одинаково.
Для начала, установим дополнительные пакеты:
Для этого, как раз, используются разные команды (в зависимости от операционной системы).
а) Для 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 }}
* где:
Проверяем корректность настройки:
consul validate /etc/consul.d/
Мы должны увидеть:
Configuration is valid!
Продолжаем. Создаем юнит в systemd:
vi /etc/systemd/system/consul.service
[Unit]Description=Consul client agentRequires=network-online.targetAfter=network-online.target
[Service]User=consulGroup=consulPIDFile=/var/run/consul/consul.pidRuntimeDirectory=consulExecStart=/usr/bin/consul agent -config-dir=/etc/consul.d -pid-file=/var/run/consul/consul.pidExecReload=/bin/kill -HUP $MAINPIDKillMode=processKillSignal=SIGTERMRestart=on-failureRestartSec=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>
С агентом завершили.
Выше мы рассмотрели базовый способ присоединения агента к кластеру. Однако, если мы включили проверку подлинности на стороне сервера, необходимо создать политику для агентов и сделать соответствующие настройки на клиентских нодах.
На сервере переходим в каталог с конфигурациями консула и создаем файл с политикой:
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-537c12a3818fSecretID: 37570fdb-798c-24e5-c8c3-612e86031345Description: Token for AgentLocal: falseCreate Time: 2021-09-09 16:36:57.216491588 +0300 MSKPolicies: b3f3a892-c792-726c-8136-9744fd7e0f7b — agent
Нам нужно значение поля SecretID — это токен, который мы будем использовать на агенте.
Переходим на клиентскую ноду и открываем наш конфигурационный файл:
Допишем:
… «acl»: { «enabled»: true, «tokens»: { «default»: «<token (SecretID)>» } } …
<token> — это сформированный на сервере токен.
Перезагружаем консул на агенте:
systemctl restart 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 …
Перейдем к конкретике.
По мере необходимости, я буду добавлять новые примеры.
Предварительно, разрешаем выполнение проверок. Для этого открываем наш конфигурационный файл консула:
Добавим в него:
…, «enable_local_script_checks»: true, «enable_script_checks»: true
Обратите внимание, что каждая строка должна заканчиваться запятой. Но последняя строка логической настройки не должна заканчиваться запятой, в противном случае, будет ошибка. Таким образом, когда мы дописываем конфигурацию, внимательно обращаем внимание на запятые.
Проверяем конфигурационный файл и перезапускаем консул:
Создаем конфигурацию:
vi /etc/consul.d/web.json
{ «service»: { «name»: «web», «tags»: [ «front» ], «port»: 80, «check»: { «args»: [ «curl», «localhost» ], «interval»: «10s» } }}
Проверяем конфигурационный файл:
Если мы увидим:
… то с конфигурационным файлом все хорошо — можно продолжать.
Применяем настройки:
В панели управления должен появиться наш сервис:
Также 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.consulAddress: 192.168.0.100
Данный пример не сильно отличается от предыдущего — прослушивать будем другой порт. Но мы в качестве проверки сервиса будем использовать метод 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» } }}
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» } }}
Создаем скрипт для проверки состояния базы:
mkdir /scripts
vi /scripts/keydb_check.sh
#!/bin/bashPATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
ping_check=$(keydb-cli ping)
if [ «$ping_check» = «PONG» ]then exit 0else exit 2fi
exit 2
Разрешим его запуск на исполнение:
chmod +x /scripts/keydb_check.sh
Рассмотрим процесс удаление сервисов и нод кластера.
Список зарегистрированных сервисов можно получить командой:
consul catalog services
Удаляем сервис:
consul services deregister -id=’web’
* где web — имя нашего сервиса, который необходимо снять с регистрации.
На агенте вводим:
consul leave
Если нам нужно форсированно удалить ноду, то с любого участника, где можно управлять кластером, вводим:
consul force-leave agent01
При настройке агента мы можем столкнуться с различными проблемами. Для их решения нам может помочь команда:
consul monitor
Также рассмотрим те, с которыми столкнулся я.
Ошибка возникаем при попытке подключить узел к кластеру. В итоге мы не обнаруживаем его среди участников (когда смотрим командой consul members). При этом мы видим в логах ошибку
… No installed keys could decryp
Причина: мы указали неверное значение для параметра encrypt.
Решение: состоит из двух шагов — проверки значения encrypt и удаление временного файла, где хранится его значение.
Для начала смотрим на сервере конфигурационный файл и находим в нем значение для опции encrypt. Точно такое же значение должно быть и на клиенте.
Однако, этого недостаточно, так как после первого запуска был создан файл local.keyring, в котором хранится неправильное значение. Просто удаляем его:
rm -f /var/lib/consul/serf/local.keyring
* где /var/lib/consul — путь, который мы указали в конфигурационно файле агента.
Ошибка появляется при подключении агента к кластеру.
Причина: на сервере включен ACL и требуется дополнительная аутентификация.
Решение: на клиенте включаем ACL, а на сервере создаем токен. Подробнее процедура описана выше.
Продолжая использовать данный сайт вы принимаете политику конфиденциальности и cookies