Используемые термины: 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)
Лидер
Простой http-запрос, который поможет увидеть лидера:
curl http://localhost:8500/v1/status/leader
Raft и лидер
Получить информацию о работе raft и текущем лидере можно командой:
consul operator raft list-peers
Начиная с consul версии 1.15 мы можем перенести роль лидера на другую ноду. Для этого выполняем команду:
consul operator raft transfer-leader -id=»server id»
