☰

Стратегия библиотеки Ansible?

tag-icon • tag-icon ansible ansible-playbook
Стратегия библиотеки Ansible?

Я начинаю использовать ansible для управления конфигурацией и размышляю, как структурировать мой ansible-каталог. Например, web1есть хост, которому нужно внести изменения в конфигурациюАпачии/etc/ssh/sshd_config. jira1— это хост, который не используетАпачи, но необходимо внести те же изменения, что и/etc/ssh/sshd_config.

Моя идея была сделать каталог библиотеки в моем ansibleкаталоге и поместить sshd.ymlпод плейбуки. Я мог бы сделать каталог хоста с символическими ссылками на библиотеку:

ansible
   |
   |
   + library
   |       |
   |       +- sshd.yml
   |       +- apache.yml
   |       +- nginx.yml
   + web1
   |    |  
   |    + playbooks
   |              |
   |              +- symlink_to_../../library/sshd.yml
   |              +- symlink_to_../../library/apache.yml
   + jira1
        |  
        + playbooks
                  |
                  +- symlink_to_../../library/sshd.yml
                  +- symlink_to_../../library/nginx.yml

Это устраняет дублирующие .ymlфайлы, и ansible, похоже, не обращает внимания на символические ссылки. При взгляде на подкаталог я могу точно сказать, какие плейбуки нужны/используются для настройки данного хоста. Кажется, это хорошая схема, но есть ли лучший способ сделать это?

Единственное, что я могу придумать, это оснастить каждый плейбук, vars/factsкоторый включает/исключает каждый хост из конфигурации. Это кажется долгим путем, хотя; редактирование каждого плейбука каждый раз, когда я добавляю или удаляю хост из локальной сети.

решение1

Как написал Константин, у вас должны быть роли для этих стандартных строительных блоков, группы для каждого типа сервера и плейбуки для применения этих ролей. Поэтому ваша структура будет примерно такой:

ansible
   |
   |
   +-roles
   |   |
   |   +-sshd
   |   +-apache
   |   +-nginx
   |
   +-playbook_for_group_web.yml
   |
   +-playbook_for_group_jira.yml

Связанный контент