Установка и настройка кластера Consul Hashicorp на CentOS или Rocky Linux

Используемые термины: Consul , CentOS .

В данной инструкции мы рассмотрим установку и настройку кластера системы обнаружения сервисов Consul. Данный кластер будет состоять из трех нод, каждая из которых будет под управлением операционной системы Rocky Linux или CentOS версий 7 / 8.

Предварительная настройка
Кластер Consul
Установка
Настройка
Проверка
Аутентификация
Примеры дополнительных команд для управления кластером

Подготовка сервера

Выполним предварительные операции по настройке наших серверов.

1. Установка дополнительных пакетов

Выполняем команду:

yum install unzip wget

* где:

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

2. Настраиваем время

Задаем часовой пояс:

timedatectl set-timezone Europe/Moscow

* в данном примере мы задаем московское время. Полный перечень возможных вариантов можно получить командой: timedatectl list-timezones .

Устанавливаем утилиту для синхронизации времени:

yum install chrony

Запускаем ее в качестве сервиса:

systemctl enable chronyd —now

3. Настройка имени серверов

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

hostnamectl set-hostname consul01.remontka.local

hostnamectl set-hostname consul02.remontka.local

hostnamectl set-hostname consul03.remontka.local

* предполагается, что нашим трем серверам будут заданы имена consul01 , consul02 и consul03 . Они будут в домене remontka.local .

Чтобы серверы могли обращаться друг к другу по именам, мы должны либо зарегистрировать их в локальной системе DNS, либо добавить на каждом сервере записи в файл hosts:

vi /etc/hosts

192.168.0.15 consul01.remontka.local
192.168.0.20 consul02.remontka.local
192.168.0.25 consul03.remontka.local

4. Настройка безопасности

Открываем порты в брандмауэре:

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

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

firewall-cmd —reload

* подробное описание портов есть на странице Что такое Consul .

Установка и запуск Consul

Выполним установку компонентов, сборку кластера и его запуск.

Установка

Установка будет выполнена путем копирования бинарного файла. Для начала перейдем на страницу загрузки программного продукта и посмотрим его последнюю версию.

После подставим нужную версию в переменную:

export VER=»1.10.2″

* в моем примере будет устанавливаться версия 1.10.2.

После загружаем архив с бинарником:

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

И распаковываем его:

unzip consul_${VER}_linux_amd64.zip

Копируем полученных бинарник в каталог /usr/bin:

mv consul /usr/bin/

Проверяем, что приложение может запускаться в наших системах:

consul -v

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

Consul v1.10.2
Revision 3cb6eeedb
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

Можно переходить к настройке.

Настройка

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

useradd -r -c ‘Consul DCS service’ consul

* в данном примере мы создадим учетную запись consul , которая будет системной. Также мы добавим небольшой комментарий.

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

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 . Права будут полные у владельца, остальные смогут читать данные.

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

consul keygen

zpjf5a4reDbJFpT6FeaF0LGxD0zBRPSRbIoUkLBt0ps=

Полученный ключ сохраняем. Его мы будем использовать при настройке всех узлов кластера.

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

vi /etc/consul.d/config.json

{
«bind_addr»: «0.0.0.0»,
«bootstrap_expect»: 3,
«client_addr»: «0.0.0.0»,
«datacenter»: «dc1»,
«data_dir»: «/var/lib/consul»,
«domain»: «consul»,
«enable_script_checks»: true,
«dns_config»: {
«enable_truncate»: true,
«only_passing»: true
},
«enable_syslog»: true,
«encrypt»: «zpjf5a4reDbJFpT6FeaF0LGxD0zBRPSRbIoUkLBt0ps=»,
«leave_on_terminate»: true,
«log_level»: «INFO»,
«rejoin_after_leave»: true,
«retry_join»: [
«consul01.remontka.local»,
«consul02.remontka.local»,
«consul03.remontka.local»
],
«server»: true,
«start_join»: [
«consul01.remontka.local»,
«consul02.remontka.local»,
«consul03.remontka.local»
],
«ui_config»: { «enabled»: true }
}

* где:

bind_addr — адрес, на котором будет слушать наш сервер консул. Это может быть IP любого из наших сетевых интерфейсов или, как в данном примере, все.
bootstrap_expect — ожидаемое количество серверов в кластере.
client_addr — адрес, к которому будут привязаны клиентские интерфейсы.
datacenter — привязка сервера к конкретному датацентру. Нужен для логического разделения. Серверы с одинаковым датацентром должны находиться в одной локальной сети.
data_dir — каталог для хранения данных.
domain — домен, в котором будет зарегистрирован сервис.
enable_script_checks — разрешает на агенте проверку работоспособности.
dns_config — параметры для настройки DNS.
enable_syslog — разрешение на ведение лога.
encrypt — ключ для шифрования сетевого трафика. В качестве значения используем сгенерированный ранее.
leave_on_terminate — при получении сигнала на остановку процесса консула, корректно отключать ноду от кластера.
log_level — минимальный уровень события для отображения в логе. Возможны варианты «trace», «debug», «info», «warn», and «err».
rejoin_after_leave — по умолчанию, нода покидающая кластер не присоединяется к нему автоматически. Данная опция позволяет управлять данным поведением.
retry_join — перечисляем узлы, к которым можно присоединять кластер. Процесс будет повторяться, пока не завершиться успешно.
server — режим работы сервера.
start_join — список узлов кластера, к которым пробуем присоединиться при загрузке сервера.
ui_config — конфигурация для графического веб-интерфейса.

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

consul validate /etc/consul.d/config.json

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

…
Configuration is valid!

В завершение настройки создадим юнит в systemd для возможности автоматического запуска сервиса:

vi /etc/systemd/system/consul.service

[Unit]
Description=Consul Service Discovery Agent
Documentation=https://www.consul.io/
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=consul
Group=consul
ExecStart=/usr/bin/consul agent
-node=consul01.remontka.local
-config-dir=/etc/consul.d
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGINT
TimeoutStopSec=5
Restart=on-failure
SyslogIdentifier=consul

[Install]
WantedBy=multi-user.target

Обратите внимание, что в данном примере указан сервер consul01.remontka.local . Мы должны заменить это значение для каждого из настраиваемых серверов. Таким образом, у нас будет три файла с разными значениями для опции node .

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

systemctl daemon-reload

Система установлена, настроена и готова к запуску.

Запуск и проверка

Стартуем наш сервис:

systemctl start consul

Также разрешаем автоматический старт при запуске сервера:

systemctl enable consul

Смотрим текущее состояние работы сервиса:

systemctl status consul

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

…
Active: active (running) since …
…

Состояние нод кластера мы можем посмотреть командой:

consul members

А данной командой можно увидеть дополнительную информацию:

consul members -detailed

Также у нас должен быть доступен веб-интерфейс по адресу:
http://<IP-адрес любого сервера консул>:8500 . Перейдя по нему, мы должны увидеть страницу со статусом нашего кластера.

Аутентификация

При входе на веб-интерфейс или работе из командной строки, мы заметим, что система позволяет выполнять операции без запроса идентификационных данных. Если нам нужно обезопасить систему, настроим ACL и донастроим сервис.

Включение ACL

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

vi /etc/consul.d/config.json

Добавляем строки:

{
…
«ui_config»: { «enabled»: true },
«acl»: {
«enabled»: true,
«default_policy»: «deny»,
«enable_token_persistence»: true
}
}

* обратите внимание, что строка «ui_config»: { «enabled»: true }, у нас уже была в конфигурационном файле, но мы добавили запятую в конце, так как это критично для конфига в формате json. Наша добавленная настройка acl запрещает по умолчанию доступ и требует ввода токена безопасности.

Проверяем корректность внесенных настроек:

consul validate /etc/consul.d/config.json

Если ошибок нет, то перезапускаем сервис:

systemctl restart consul

Заходим на веб-интерфейс — мы обнаружим, что в правом верхнем углу появилась ссылка для входа в систему:

Мы идем в правильном направлении.

Получение мастер-токена (Bootstrap Token)

Первый токен, который мы создаем, является Bootstrap Token (Global Management). Его рекомендуется использовать только для генерирования других токенов и получения максимальных привилегий, когда это необходимо.

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

consul acl bootstrap

* если она вернула ошибку Failed ACL bootstrapping: Unexpected response code: 500 (The ACL system is currently in legacy mode.) , то значит, что мы не на всех нодах применили новую настройку (включили ACL). Проверяем, на всех ли серверах кластера внесены соответствующие изменения по добавлению ACL.

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

AccessorID: af5eaac1-4f0b-d46a-58ba-64ec857dfc4c
SecretID: 59ac7fa8-dca6-e066-ff33-0bf9bb6f466a
Description: Bootstrap Token (Global Management)
Local: false
Create Time: 2021-09-01 16:28:58.710545082 +0300 MSK
Policies:
00000000-0000-0000-0000-000000000001 — global-management

В данном примере 59ac7fa8-dca6-e066-ff33-0bf9bb6f466a — нужный нам для аутентификации SecretID. Возвращаемся в веб-интерфейсу и пробуем войти в систему с использованием данного кода.

Если нам нужно удалить данный токен, вводим команду:

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

export CONSUL_HTTP_TOKEN=59ac7fa8-dca6-e066-ff33-0bf9bb6f466a

* где 59ac7fa8-dca6-e066-ff33-0bf9bb6f466a , полученный нами SecretID .

Создать новый токен можно командой:

consul acl token create -policy-name global-management

Чтобы увидеть список токенов, вводим:

consul acl token list

Если нам понадобиться удалить токен, мы должны использовать его AccessorID :

consul acl token delete -id 54b5f2bb-1a57-3884-f0ea-1284f84186f5

* где будет удален токен с AccessorID 54b5f2bb-1a57-3884-f0ea-1284f84186f5.

Настройка политики для DNS

После включения ACL наша система перестанет отвечать на запросы DNS. Это связано с политикой блокировки по умолчанию. Для разрешения запросов мы должны создать политику с разрешением данных запросов, получить для ее токен и применить данный токен на всех нодах консула.

На одной из нод создаем файл с политикой:

cd /etc/consul.d/

vi dns-request-policy.txt

node_prefix «» {
policy = «read»
}
service_prefix «» {
policy = «read»
}

Создаем политику в консуле:

consul acl policy create -name «dns-requests» -rules @dns-request-policy.txt

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

consul acl token create -description «Token for DNS Requests» -policy-name dns-requests

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

AccessorID: b53741e2-7663-eag6-fd67-a64dbd32feb5
SecretID: 42bd65e5-42a5-356b-a81b-60eff20f657
Description: Token for DNS Requests
Local: false
Create Time: 2021-09-02 12:37:42.342511655 +0300 MSK
Policies:
89e42b6b-bbec-5263-bc7b-60f3a604a0d6 — dns-requests

* где SecretID — это нужный нам токен.

На всех компьютерах с consul авторизовываемся:

export CONSUL_HTTP_TOKEN=59ac7fa8-dca6-e066-ff33-0bf9bb6f466a

* где 59ac7fa8-dca6-e066-ff33-0bf9bb6f466a — ранее созданный токен для получения доступа к управлению консулом.

И вводим:

consul acl set-agent-token default 42bd65e5-42a5-356b-a81b-60eff20f657

* где 42bd65e5-42a5-356b-a81b-60eff20f657 — тот SecretID, который мы получили на основе политики, разрешающей запросы DNS.

Дополнительные команды

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

Unexpected response code: 403 (rpc error making call: Permission denied)