Heya,
I'm currently evaluating Ansible for our company but I'm having problems to
understand how we would set up our global structure. We have like 10.000
hosts and hundreds of different projects with different teams and needs.
Still we need to use a common code base (roles, plugins) and not re-invent
the wheel in every project. Of course I understand roles and playbooks. My
problem is how settings are handled and from there it leads to more
problems.
1) User settings vs. project settings
According to the docs, Ansible looks in different locations for the cfg
file and uses the first found, ignoring all others. So it is not possible
to have settings in different locations, which makes it hard to allow user
specific settings (e.g. *private_key_file*) and at the same time define
company wide or project specific settings, which should be stored in git.
Ideally Ansible would respect all cfg files, merge the content and handle
the settings with precedence in the order like described in the docs.
2) Settings are global, not per playbook
But different playbooks might have different needs, e.g. a playbook could
require *hash_behaviour=merge*. To archive this one would need to create a
folder specific for the playbook, place the cfg with the settings inside,
cd to that folder and run *ansible-playbook* from there.
Another thing are callbacks. Those are fired as soon as they exists in the
per settings defined folder. So every playbook which has a specific
callback would require its own callback directory + settings. When
following this pattern, you'd need to create the roles within this
directory as well as those need to be located on the same level you execute
*ansible-playbook* on.
This all makes it very hard to re-use roles and plugins. I worked on a
structure that might work but is a symlink mayhem:
group_vars
all
group-1
group-N
host_vars
host-1
host-N
inventory
production
staging
uat
library
modules
mod-1.py
mod-N.py
plugins
callback
callback-1.py
callback-N.py
filter
filter-1.py
filter-N.py
lookup
lookup-1.py
lookup-N.py
playbooks
project-1
ansible.cfg
group_vars -> ../../group_vars
host_vars -> ../../host_vars
library
modules -> ../../../library/modules
plugins
callback
callback-1.py -> ../../../../../library/plugins/callback/callback-
1.py
callback-N.py -> ../../../../../library/plugins/callback/callback-
N.py
filter -> ../../../../library/plugins/filter
lookup -> ../../../../library/plugins/lookup
production -> ../../inventory/production
playbook-1.yml
playbook-N.yml
roles -> ../../roles
staging -> ../../inventory/staging
uat -> ../../inventory/uat
project-N
...
roles
role-1
role-N
Roles, inventory, host_vars, group_vars, modules and plugins are defined on
the root level. The playbooks directory holds all projects. Every project
then can define it's own cfg with specific settings. The inventory files,
roles, *_vars, modules, filter-plugins and lookup-plugins are symlinked
into the project-folder. With the callbacks it's more tricky as those would
be fired as soon as they exists. So every callback that is required for a
project needs to be symlinked explicitly.
This enables us to globally handle all re-usable components while every
project can define its own settings. A project would/could be a submodule
in the main git repo.
So this seems to work. Only that user specific settings are still not
possible. Does this setup make sense from the PoV of more experienced
Ansible users? IMHO this looks quite complex and I wonder what I'm missing
here because things shouldn't be that complex.
Thanks in advance,
Daniel
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/74ad0525-4925-45b5-9542-4c8de9bd270a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
