Установка агента Consul и примеры регистрации сервисов

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

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

Инсталляция агента
Настройка и запуск клиентской части
ACL авторизация
Описание процесса регистрации сервиса
Примеры регистрации и проверок
    Включение возможности делать проверку
    HTTP-запросы
    Java (такие же http с другим методом проверки)
    KeyDB
    Без агента (на примере Postgresql)
    Описание нескольких проверок
Вывод ноды из кластера и удаление регистрации
Возможные проблемы и их решение

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

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

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

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

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

а) Для Deb:

apt install wget unzip

б) Для RPM:

yum install wget unzip

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

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

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

Также мы можем посмотреть версию consul на сервере:

consul -v

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

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

CONSUL_VER="1.17.1"

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

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

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

unzip consul_*_linux_amd64.zip -d /usr/bin

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

consul -v

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

Consul v1.17.1
...

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

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

Настроим запуск агента в качестве сервиса. Для этого мы создадим юнит в 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
}

* где:

  • 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 — вести ли системный лог.

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

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.17.1  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

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

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

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

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

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

{
  "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 или Define health 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

4. Postgresql (без агента)

В данном примере мы рассмотрим пример регистрации сервиса без агента с указанием его адреса. В нашем случае это сервис Postgresql.

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

vi /etc/consul.d/postgresql.json

{
  "service": {
    "name": "db",
    "tags": [
      "master"
    ],
    "port": 5432,
    "address": "db.dmosk.local"
  }
}

* мы добавили директиву address, чтобы указать консулу, на каком сервере у нас находится данный сервис. В качестве значения можно использовать IP-адрес или имя хоста.

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

consul validate /etc/consul.d/

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

systemctl restart consul

5. Несколько проверок

Мы можем перечислить несколько проверок. Каждая настройка описывается в фигурных скобках и это все оборачивается в квадратные скобки. Ключевое слово check меняем на checks.

Проверим работу веб-сервера как в части запущенной службы, так и возможности получения ответа по порту 80:

vi /etc/consul.d/web_service.json

{
  "service": {
    "name": "web",
    "tags": [
      "active"
    ],
    "port": 80,
    "checks": [{
      "http": "http://localhost:80",
      "interval": "10s",
      "method": "GET",
      "timeout": "5s",
      "deregister_critical_service_after": "10s"
    },
    {
      "id": "nginx",
      "name": "nginx service",
      "args": ["systemctl", "is-active", "nginx.service"],
      "interval": "10s",
      "timeout":"1s"
    }]
  }
}

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

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

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

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

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

consul catalog services

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

consul services deregister -id='web'

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

Удаление нод

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

consul leave

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

consul force-leave agent01

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

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

consul monitor

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

No installed keys could decrypt

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

... No installed keys could decrypt the message

Причина: возможны два варианта:

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

Решение для обоих вариантов одно и то же.

Решение: состоит из двух шагов — проверки значения 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, а на сервере создаем токен. Подробнее процедура описана выше.

# DevOps # Linux
Дмитрий Моск — частный мастер
Была ли полезна вам эта инструкция?

Да            Нет