Как установить и использовать Consul Template для рендеринга файлов

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

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

Consul-template позволяет нам формировать файлы на основе шаблонов с данными, которые хранятся в Consul. Это можно использовать для формирования конфигурационных файлов или скриптов. В инструкции мы рассмотрим процесс установки consul-template на операционные системы Linux на базе Deb и RPM.

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

Предварительно, нам нужно установить на компьютер, с которого будет запускаться процесс 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/»
}

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

  • 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»
}

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

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

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

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

На узле с consul-template

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

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

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

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

* в данном примере мы будем запускать скачанный нами банарник 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»
  }
}

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

  • 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»]

Нужный нам токен — 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
}

* где 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»
}

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

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

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

* если вы работали с 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»

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

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

systemctl daemon-reload

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

systemctl restart consul-template

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

cat /tmp/render.txt

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