В анзибле мы пытаемся получить доступ к различным шаблонам в зависимости от переменной.
У нас есть следующие файлы шаблонов, например:
templates
app1.conf.j2
app2.conf.j2
app3.conf.j2
taks
app.yml
В задачах нам нужно скопировать файл шаблона на основе имени приложения. например: мы укажем переменную с именем instance_name для app1, app2 или app3.
Теперь, исходя из переменной, нам нужно скопировать файл приложения в / opt / ((instance_name}} / conf.d /.
мы создали задачу ansbile следующим образом, но она не работает.
- name: 'Copy {{ instance_name }} file to /opt/conf.d/ Directory'
template:
src: "{{ instance_name }}.conf.j2"
dest: "/opt/{{ instance_name }}/conf.d/"
owner: root
group: root
mode: 0644
Когда мы жестко кодируем "src" для app1.conf.j2, он работает для app1.
С этого URL https://docs.ansible.com/ansible/latest/modules/template_module.html#parameter-src он указывает, что значение может быть относительным или абсолютным путем.
Пожалуйста, дайте нам знать, возможно ли это с помощью этого метода? У нас есть около 20 приложений, и это лучший способ упростить доступную книгу, указав только переменную.
Нет никаких передовых практик, только мнения о том, насколько элегантно решение для конкретной проблемы. Особенно актуально для Ansible, учитывая гибкость в том, как он позволяет вам делать то, что вы хотите.
Роли отличные. Можно создать роль для каждой группы приложений, и каждая из них содержит необходимые шаблоны конфигурации, например roles/app1/templates/app1.conf.j2 Возможно, у него есть несколько задач и шаблонов, например, если приложение запускает какой-либо процесс через диспетчер служб, гарантирует, что брандмауэр хоста разрешает это, а также подключает что-то через некую служебную сетку.
app1's defaults/main.yml может содержать
instance_name: app1
Который затем может быть использован tasks/main.yml (некоторые параметры опущены для краткости, возможно, они были перенесены в настройки модуля по умолчанию на блоке.)
- name: 'Copy config to /opt/conf.d/'
template:
src: "{{ instance_name }}.conf.j2"
dest: "/opt/{{ instance_name }}/conf.d/"
Если бы все это было в одном дереве рядом с вашим сценарием (не обязательно, в частности, роли можно было бы хранить в другом месте), это могло бы выглядеть как пример организации контента в документации:
playbook.yml
roles/
app1/
tasks/
main.yml
templates/
app1.conf.j2
app2/
tasks/
main.yml
templates/
app2.conf.j2
И тогда в playbook их просто нужно перечислить:
roles:
- app1
- app2
Реализация таких ролей может повторяться, поскольку каждая роль должна делать одно и то же. Если роли отличаются только парой переменных, создайте общую роль и вызовите ее несколько раз с разными параметрами роли.
roles:
- role: appgeneric
vars:
instance_name: app1
- role: appgeneric
vars:
instance_name: app2
Переменные для параметров модуля - это здорово, ответ на ваш вопрос - да. Тем не мение, переменные имена задач действительно не работают. Названия задач глобальны и анализируются рано, поэтому, возможно, --extra-vars cli, но не об итерации цикла или переменной хоста.
Итак, что делать, если у вас есть общая именованная роль и общая именованная задача, выполняемая через 20 развертываний приложений? Ошибки должны быть информативными, если шаблон не может загрузить файл, он сообщит вам, какое имя файла. Немного увеличиваем многословие с ansible-playbook -vv помогает понять, что происходит, но является беспорядочным и многословным. Рассмотрите возможность использования программного обеспечения для ведения журнала playbook поверх Ansible, например ARA или AWX / Tower. В отчетах указано, какое выполнение загружено, какие переменные могут предоставить контекст.