Используемые термины: Consul, Linux.
Consul-template позволяет нам формировать файлы на основе шаблонов с данными, которые хранятся в Consul. Это можно использовать для формирования конфигурационных файлов или скриптов. В инструкции мы рассмотрим процесс установки consul-template на операционные системы Linux на базе Deb и RPM.
Предварительно, нам нужно установить на компьютер, с которого будет запускаться процесс consul-template пакеты для:
В зависимости от типа операционной системы, наши действия будут немного отличаться.
а) Для Deb (Ubuntu, Debian):
apt install wget unzip
б) Для RPM (Rocky Linux, CentOS):
yum install wget unzip
На компьютере, где должен работать 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-template с использованием нашего конфигурационного файла:
consul-template -config /etc/consul-template.d/config.hcl
Мы должны увидеть пустую строку. Значит наша система настроена верно. Можно прервать выполнение команды комбинацией Ctrl + C.
Если наш сервер 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-fe35283e3426SecretID: 9f06d485-03e5-dc1a-5a84-50dea3db7522Description: Token for Consul TemplateLocal: falseCreate Time: 2021-09-10 17:28:36.630170352 +0300 MSKPolicies: d31bfc3e-c6ed-dd9f-3228-103b0d70f42d — consul-template
Нам нужна строка SecretID — это и есть нужный нам токен. Его также можно увидеть в веб-инструменте для работы с консулом.
С сервером мы закончили. Переходим на клиента.
Открываем конфигурационный файл, который был нами создан для consul-template:
Дописываем в него токен (в примере выше строка была — нужно только снять комментарий и подставить правильное значение):
consul { … token = «9f06d485-03e5-dc1a-5a84-50dea3db7522» …}
* в данном примере 9f06d485-03e5-dc1a-5a84-50dea3db7522 — тот токен, который мы получили на сервере. Само собой, у вас он будет другой.
Проверяем корректность конфига:
consul-template -config /etc/consul-template.d/
Можно пробовать запуск:
Мы должны увидеть пустую строку. После прерываем выполнение комбинацией Ctrl + C.
Последнее, что нужно сделать в рамках нашей настройки, создать юнит в systemd для автоматического запуска сервиса.
Создаем файл:
vi /etc/systemd/system/consul-template.service
[Unit]Description=Consul-Template DaemonDocumentation=https://github.com/hashicorp/consul-template/Wants=basic.targetAfter=network.target
[Service]User=consulGroup=consulExecStart=/usr/bin/consul-template -config=/etc/consul-template.d/SuccessExitStatus=12ExecReload=/bin/kill -HUP $MAINPIDKillSignal=SIGINTKillMode=processRestart=on-failureRestartSec=42sLimitNOFILE=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» }}
* в данном примере обращаем внимание на следующее:
Создаем шаблон и после перезапускаем сервис:
vi /var/lib/consul/templates/nginx.ctmpl
systemctl restart consul-template
Подробнее про то, как создаются шаблоны в консуле можно почитать на странице gitee.com/ucasrichard/consul-template.
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.f9uzXJVNjYVUmZjw6ZpCLB6Atoken_accessor vxTy5ESvfOHzP6Ca7TjlX2dstoken_duration 768htoken_renewable truetoken_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 для доступа к нужным нам данным.
Создаем настройку для шаблона:
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.** где:
4. Немного отредактируем наш файл для юнита в systemd:
…[Service]Environment=»VAULT_SKIP_VERIFY=true»…
* данная опция нужна, если сертификат для vault не проходит проверку, а такое бывает не редко. В противном случае, данную настройку можно и не делать.
Чтобы конфигурация для systemd обновилась, вводим:
Теперь можно перезапускать сервис:
Если мы все сделали правильно, то мы увидим файл:
cat /tmp/render.txt
… с нужными нам данными из Vault.
Продолжая использовать данный сайт вы принимаете политику конфиденциальности и cookies