Hi Daniel, replies are inline.
On Wed, Jul 30, 2014 at 4:21 AM, Daniel Schroeder <[email protected]> wrote: > 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. > With an infrastructure of this size, you should really consider Ansible Tower. Tower allows you to upload a private key into a concept called a *credential* and this credential is securely provided to those who have access to it (shared with specific teams) and they don't get to see the credential. Each job template can also be associated with specific credentials for launching. Alternatively, you could just store your ansible.cfg in git and set ANSIBLE_CFG to the ansible.cfg path. > > 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. > It's recommended, to be consistent with the majority of the ansible community, that people don't adopt hash_behavior=merge. However there are some that really feel like they should use it. In this case, people can use it, it will continue to work, it may just be a little confusing. I recommend you set a policy on what you use so that everyone can easily read playbooks and know what might be going on. Most people don't need the complexity of hash_behavior=merge and I recommend people try to avoid it, since it starts to be fun figuring out where something added to a variable and you lose the ability to override hash variables completely. > > 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. > I'm not sure how you have callbacks and roles interlocking, as they are not related concepts. However, if your custom callback requires configuration, the common mechanism is for it to read an environment variable. This environment variable could even reference the path to a configuration file. Not too many people write custom callbacks, but if you're looking for something like logging to a database or making things API accessible, again, Tower provides this stock. For questions about that, feel free to ask [email protected]. > > 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 > > I agree this looks horrible, but I don't think this is ansible's fault. I think you could use some best practices organization advice here, but I'd first like to step back and ask what your callbacks *do* to understand the problem, and also ask why callbacks are project specific. We can then work out the best way to organize this as well as write your callbacks. > 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. > It looks like it's quite an order of magnitude too complex. But see above, let's talk through the callback question and I think making your callbacks configurable may solve the problem. However I want to understand a bit more about what they do first, and I think we can help completely eliminate all the symlink fun. > 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 > <https://groups.google.com/d/msgid/ansible-project/74ad0525-4925-45b5-9542-4c8de9bd270a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CA%2BnsWgxsfkc0CF106kTKhrT2mqe1182RSr82g8kardRXvr6x8Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
