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

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

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

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

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

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

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.dmosk.local

hostnamectl set-hostname consul02.dmosk.local

hostnamectl set-hostname consul03.dmosk.local

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

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

vi /etc/hosts

192.168.0.15 consul01.dmosk.local
192.168.0.20 consul02.dmosk.local
192.168.0.25 consul03.dmosk.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.9.5"

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

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

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.9.5
Revision 3c1c22679
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.dmosk.local",
         "consul02.dmosk.local",
         "consul03.dmosk.local"
     ],
     "server": true,
     "start_join": [
         "consul01.dmosk.local",
         "consul02.dmosk.local",
         "consul03.dmosk.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.dmosk.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.dmosk.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. Перейдя по нему, мы должны увидеть страницу со статусом нашего кластера.

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

Да            Нет