Установка и настройка Consul-template

Thank you for reading this post, don't forget to subscribe!

Consul приложение для обнаружения сервисов (service discovery) на основе DNS и проверки их доступности. Оно используется для обеспечения связи между компонентами микросервисной инфраструктуры, позволяя создавать отказоустойчивую и масштабируемую систему с возможностью балансировки нагрузки. Consul разработан компанией HashiCorp, которой также принадлежат другие популярные продукты, например, Vagrant, TerraForm, Atlas, Vault.

Регистрация сервисов в консуле производится с помощью функции Consul Connect. Также регистрируются политики взаимодействия, например, мы можем указать, что сервис 1 может взаимодействовать с сервисом 2, но не может взаимодействовать с сервисом 3. Также для регистрации своего приложения доступна HTTP API или конфигурационные файлы самого консула (при наличии поддержки со стороны приложения).

Приложение может быть установлено на серверы под управлением всех популярных систем: Linux, Windows, MacOS, BSD. Поддерживаются следующие способы установки:

Копирование в систему бинарного файла.
Сборка приложения из исходников.
Установка в Kubernetes.
В виде контейнера Docker.

Приложение работает на следующих портах:

Порт	Протокол	Описание
8600	TCP and UDP	Сервер DNS
8500	TCP	Consul UI + API
8301	TCP and UDP	Порт LAN
8302	TCP and UDP	Порт WAN
8300	TCP	Сервис RPC
21000 - 21255		Диапазон портов для регистрации сервисов
8501	TCP	Защищенный Consul UI + API. По умолчанию, не настроен и задается любой. Данный номер рекомендован в официальной документации.
8502		gRPC API. По умолчанию, не настроен и задается любой. Данный номер рекомендован в официальной документации.

По своей сути Consul — это база данных по типу ключ-значение. При обращении к нему мы получаем информацию о работоспособном приложении. Поэтому, среди аналогов, иногда выделяют etcd и ZooKeeper и, даже, Redis.

Подготовка системы

Предварительно, нам нужно установить на компьютер, с которого будет запускаться процесс consul-template пакеты для:

загрузки файлов (wget).
распаковки архивов (unzip).

В зависимости от типа операционной системы, наши действия будут немного отличаться.

а) Для Deb (Ubuntu, Debian):

apt install wget unzip

б) Для RPM (Rocky Linux, CentOS):

yum install wget unzip

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

На компьютере, где должен работать consul-template необходимо установить соответствующий пакет и запустить его в качестве сервиса. Рассмотрим процесс по шагам.

Установка

Для установки нужно скачать бинарник и положить его каталог /usr/bin.

Заходим на страницу загрузки Consul Template официального сайта и смотрим нужную нам версию пакета (как правило, выбираем последнюю).

Создаем системную переменную, которая содержит версию устанавливаемого consul-template:

export VER='0.27.0'

Теперь загружаем на сервер архив с бинарником:

wget https://releases.hashicorp.com/consul-template/${VER}/consul-template_${VER}_linux_amd64.zip

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

unzip consul-template_${VER}_linux_amd64.zip -d /usr/bin

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

consul-template -v

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

consul-template v0.27.0 (d4af0222)

Переходим к настройке запуска процесса в качестве демона.

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

Создадим пользователя, от которого будет запускаться и работать наш сервис:

useradd -r -c 'Consul Agent' consul

Создадим рабочие каталоги:

mkdir -p /etc/consul-template.d /var/lib/consul/templates

В качестве владельца для созданных каталогов, назначим пользователя consul:

chown -R consul:consul /etc/consul-template.d /var/lib/consul/templates

Создадим конфигурационный файл для consul-template:

vi /etc/consul-template.d/config.hcl

consul {
  address = "127.0.0.1:8500"
#  token = "<token>"
  retry {
    enabled = true
    attempts = 12
    backoff = "250ms"
    max_backoff = "10s"
  }
}

reload_signal = "SIGHUP"
kill_signal = "SIGINT"
max_stale = "10m"
log_level = "warn"

wait {
  min = "2s"
  max = "5s"
}

deduplicate {
  enabled = true
  prefix = "consul-template/dedup/"
}

consul {

address = "127.0.0.1:8500"

# token = "<token>"

retry {

enabled = true

attempts = 12

backoff = "250ms"

max_backoff = "10s"

}

reload_signal = "SIGHUP"

kill_signal = "SIGINT"

max_stale = "10m"

log_level = "warn"

wait {

min = "2s"

max = "5s"

}

deduplicate {

enabled = true

prefix = "consul-template/dedup/"

}

* где необходимо обратить внимание на:

address — адрес консула. Это может быть сервер или агент. В данном примере предполагается, что консул работает на том же сервере, где запускается consul-template.
token — если на сервере Consul используется ACL, то нам нужен токен для подключения. Об этом чуть подробнее ниже в инструкции.

Попробуем запустить consul-template с использованием нашего конфигурационного файла:

consul-template -config /etc/consul-template.d/config.hcl

Мы должны увидеть пустую строку. Значит наша система настроена верно. Можно прервать выполнение команды комбинацией Ctrl + C.

ACL

Если наш сервер Consul выполняет проверку подлинности, при вводе команды для запуска consul-template мы увидим ошибку:

[ERR] (dedup) failed to create session: Unexpected response code: 403 (rpc error making call: rpc error making call: Permission denied)

Она означает, что мы не указали токен, он неправильный или токен привязан к политике, у которой нет нужных прав доступа.

Для настройки ACL нам нужно выполнить часть действий на сервере консула, часть на компьютере с consul-template.

На сервере

Переходим в каталог с консулом:

cd /etc/consul.d/

* обратите внимание, что в нашем случае это может быть другой каталог.

Создаем файл, в котором будет описание нашей политики:

vi consul-template-policy.txt

session_prefix "" {
  policy = "write"
}

session_prefix "" {

policy = "write"

}

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

consul acl policy create -name "consul-template" -rules @consul-template-policy.txt

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

consul acl token create -description "Token for Consul Template" -policy-name consul-template

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

AccessorID:       aa8a118c-0dbf-14de-d1c4-fe35283e3426
SecretID:         9f06d485-03e5-dc1a-5a84-50dea3db7522
Description:      Token for Consul Template
Local:            false
Create Time:      2021-09-10 17:28:36.630170352 +0300 MSK
Policies:
   d31bfc3e-c6ed-dd9f-3228-103b0d70f42d - consul-template

AccessorID: aa8a118c-0dbf-14de-d1c4-fe35283e3426

SecretID: 9f06d485-03e5-dc1a-5a84-50dea3db7522

Description: Token for Consul Template

Local: false

Create Time: 2021-09-10 17:28:36.630170352 +0300 MSK

Policies:

d31bfc3e-c6ed-dd9f-3228-103b0d70f42d - consul-template

Нам нужна строка SecretID — это и есть нужный нам токен. Его также можно увидеть в веб-инструменте для работы с консулом.

С сервером мы закончили. Переходим на клиента.

На узле с consul-template

Открываем конфигурационный файл, который был нами создан для consul-template:

vi /etc/consul-template.d/config.hcl

Дописываем в него токен (в примере выше строка была — нужно только снять комментарий и подставить правильное значение):

consul {
  ...
  token = "9f06d485-03e5-dc1a-5a84-50dea3db7522"
  ...
}

consul {

...

token = "9f06d485-03e5-dc1a-5a84-50dea3db7522"

...

}

* в данном примере 9f06d485-03e5-dc1a-5a84-50dea3db7522 — тот токен, который мы получили на сервере. Само собой, у вас он будет другой.

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

consul-template -config /etc/consul-template.d/

Можно пробовать запуск:

consul-template -config /etc/consul-template.d/config.hcl

Мы должны увидеть пустую строку. После прерываем выполнение комбинацией Ctrl + C.

Сервис

Последнее, что нужно сделать в рамках нашей настройки, создать юнит в systemd для автоматического запуска сервиса.

Создаем файл:

vi /etc/systemd/system/consul-template.service

[Unit]
Description=Consul-Template Daemon
Documentation=https://github.com/hashicorp/consul-template/
Wants=basic.target
After=network.target

[Service]
User=consul
Group=consul
ExecStart=/usr/bin/consul-template -config=/etc/consul-template.d/
SuccessExitStatus=12
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGINT
KillMode=process
Restart=on-failure
RestartSec=42s
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target

[Unit]

Description=Consul-Template Daemon

Documentation=https://github.com/hashicorp/consul-template/

Wants=basic.target

After=network.target

[Service]

User=consul

Group=consul

ExecStart=/usr/bin/consul-template -config=/etc/consul-template.d/

SuccessExitStatus=12

ExecReload=/bin/kill -HUP $MAINPID

KillSignal=SIGINT

KillMode=process

Restart=on-failure

RestartSec=42s

LimitNOFILE=4096

[Install]

WantedBy=multi-user.target

* в данном примере мы будем запускать скачанный нами банарник consul-template и передавать ему в качестве настройки путь до каталога, где лежат конфигурационные файлы.

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

systemctl daemon-reload

Стартуем наш сервис и проверяем его состояние:

systemctl start consul-template

systemctl status consul-template

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

systemctl enable consul-template

Готово. Наша система готова к работе с шаблонами.

Работа с шаблонами

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

vi /etc/consul-template.d/templates.hcl

Мы можем создать несколько конфигураций для шаблонов. Каждый из них описывается опцией template:

template {
  source = "/var/lib/consul/templates/nginx.ctmpl"
  destination = "/etc/nginx/nginx.conf"
  command = "systemctl reload nginx"
  command_timeout = "10s"
  error_on_missing_key = false
  backup = true
  wait {
    min = "2s"
    max = "10s"
  }
}

template {

source = "/var/lib/consul/templates/nginx.ctmpl"

destination = "/etc/nginx/nginx.conf"

command = "systemctl reload nginx"

command_timeout = "10s"

error_on_missing_key = false

backup = true

wait {

min = "2s"

max = "10s"

}

* в данном примере обращаем внимание на следующее:

source — путь до файла с шаблоном.
destination — путь до конечного файла, который будет создан на основе шаблона.
command — команда, которая может быть выполнена после отработки шаблона.

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

vi /var/lib/consul/templates/nginx.ctmpl

systemctl restart consul-template

Подробнее про то, как создаются шаблоны в консуле можно почитать на странице gitee.com/ucasrichard/consul-template.

Vault

Consul и Vault разработаны одной компанией Hashicorp. И consul-template можно использовать, чтобы вытаскивать данные из хранилища паролей. Подробнее про настройку Vault Templates можно прочитать в инструкции Настройка Vault Agent Templates — рекомендуется с ней ознакомиться.

Consul-template можно использовать вместо Vault Template. Есть небольшие отличия по настройке.

1. Необходимо создать токен на сервере Vault, который будет привязан к политике, которой можно обращаться к нужным нам данным:

vault token create -policy=pl-agent-app-test

* подробнее, про создание таких политик рассказано в выше описанной инструкции, также можно ознакомиться с политиками доступа Vault в инструкции Установка, настройка и работа с Hashicorp Vault.

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

Key                  Value
---                  -----
token                s.f9uzXJVNjYVUmZjw6ZpCLB6A
token_accessor       vxTy5ESvfOHzP6Ca7TjlX2ds
token_duration       768h
token_renewable      true
token_policies       ["default" "pl-agent-app-test"]
identity_policies    []
policies             ["default" "pl-agent-app-test"]

Key Value

--- -----

token s.f9uzXJVNjYVUmZjw6ZpCLB6A

token_accessor vxTy5ESvfOHzP6Ca7TjlX2ds

token_duration 768h

token_renewable true

token_policies ["default" "pl-agent-app-test"]

identity_policies []

policies ["default" "pl-agent-app-test"]

Нужный нам токен — s.f9uzXJVNjYVUmZjw6ZpCLB6A. Сохраняем его.

2. Добавляем конфигурацию для Vault в consul-template:

vi /etc/consul-template.d/vault.hcl

vault {
    address = "https://active.vault.service.dc1.consul:8200"
    token = "s.npuzXJV6jYVUmKjw6ZpCLBHj"
    renew_token = false
}

vault {

address = "https://active.vault.service.dc1.consul:8200"

token = "s.npuzXJV6jYVUmKjw6ZpCLBHj"

renew_token = false

}

* где active.vault.service.dc1.consul — адрес нашего сервера vault (обратите внимание, что в данном примере он зарегистрирован в консуле); s.npuzXJV6jYVUmKjw6ZpCLBHj — токен, который мы создали в vault для доступа к нужным нам данным.

Создаем настройку для шаблона:

vi /etc/consul-template.d/templates.hcl

template {
  source      = "/var/lib/consul/templates/vault_template.ctmpl"
  destination = "/tmp/render.txt"
}

template {

source = "/var/lib/consul/templates/vault_template.ctmpl"

destination = "/tmp/render.txt"

}

3. Создаем сам шаблон:

vi /var/lib/consul/templates/vault_template.ctmpl

{{ with secret "secret/applications/myapp/db" }}
login: {{ .Data.data.login }}
passwd: {{ .Data.data.password }}
{{ end }}

passwd: {{ .Data.data.password }}

* если вы работали с vault-template, то обратите внимание, что синтаксис ничем не отличается при работе с consul-template.
** где:

secret/applications/myapp/db — путь, по которому мы сохранили наши секреты.
.Data.data.login — конструкция для извлечения значения ключа login.
.Data.data.password — конструкция для извлечения значения ключа password.

4. Немного отредактируем наш файл для юнита в systemd:

vi /etc/systemd/system/consul-template.service

...
[Service]
Environment="VAULT_SKIP_VERIFY=true"
...

...

[Service]

Environment="VAULT_SKIP_VERIFY=true"

...

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

Чтобы конфигурация для systemd обновилась, вводим:

systemctl daemon-reload

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

systemctl restart consul-template

Если мы все сделали правильно, то мы увидим файл:

cat /tmp/render.txt

… с нужными нам данными из Vault.

Centos