Установка и настройка 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.

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

Да            Нет