I don't think there's a One True Way, it really boils down to the team
you're working
with and what makes sense for them given the mix of environments
they're managing.
Some people use one inventory for ALL their servers, if you need cross-site
plays that might be necessary. If you're lucky enough to not need that...
Personally I'm a huge fan of one inventory per site. I think I posted
it earlier,
but the gist is this layout:
.
├── california
│ ├── group_vars
│ │ ├── all
│ │ ├── group1
│ │ └── group2
│ └── hosts
├── newyork
│ ├── group_vars
│ │ ├── all
│ │ ├── group1
│ │ └── group2
│ └── hosts
└── site.yml
|___ (other ad hoc playbooks etc. up at this level too)
Each playbook run just needs a '-i environment_name' and you're set.
It works great if you run isolated environments (prod / dev / staging)
which you want broad consistency between, but also are likely
to have differences in number of servers, types of users with SSH access,
levels of encryption, etc.
When it comes to setting vars, my general rule of thumb is to use
as few 'tiers' of variables as possible, otherwise it gets messy and its
hard to find where they're set. There are about a dozen places to set vars
in Ansible, you don't need to use them all. Generally, I go with:
1. environment-wide globals in $inventory/group_vars/all
(I used to set them inline in static inventories, but group_vars
support yaml syntax
and it plays nicer with dynamic inventories)
2. roles have 'sane' defaults in $rolename/defaults/main.yml.
Logfile paths, service account names, etc.
If no sane default exists, that's where it is documented
(via a commented out example var, with a suggestion where to set this).
This is essentially the 'README' for the role.
3. $inventory/group_vars/groupname - relevant to roles those
groups are performing. Easy to 'cat' to see how e.g. preprods
mongodb is setup.
4. host_vars/hostname is a Last Resort, usually on brownfield
sites to track inconsistencies.
"ls */host_vars/*" returns a handy list of servers we probably
need to rebuild.
In theory, this approach should mean diffing 2 inventory directories
gives a good idea of what's different between them.
I've built pretty complex stacks with
this approach from a single site.yml and it can work really well.
On 21 June 2017 at 21:50, William Saxton <sax...@gmail.com> wrote:
> Yeah, I'm currently playing around with exactly these things. I guess I'm
> looking for some best-practice guidance for how to handle this situation. I
> see a couple of ways people are handling these kinds of things...but none
> seem to be very elegant.
>
> I'm trying to talk my team into using Ansible over Puppet because it,
> initially, seemed a lot easier to get started with. Now that I'm digging
> deep into this, though, Puppet is much easier when it comes to managing
> hierarchical data (via hiera).
>
> On Wednesday, June 21, 2017 at 3:08:02 PM UTC-4, Dick Davies wrote:
>>
>> I played around with 'flat file' variables and a dynamic inventory a while
>> back;
>> group variables seemed to override the inventory level ones.
>>
>> YMMV, check the precedence levels for vars for the version of Ansible
>> you're running.
>>
>> On 20 June 2017 at 22:39, William Saxton <sax...@gmail.com> wrote:
>> > Our current configuration management system stores hostnames and
>> > attributes
>> > for each of our systems, including things like "project" and "site".
>> > I'd
>> > like to use these attributes when determining which values to provision
>> > a
>> > system with using ansible, just like Puppet does with hiera.
>> >
>> > Right now I have an external inventory script working pretty well.
>> > Here's
>> > an example output:
>> >
>> > {
>> > "generic": ["swrgen1.example.com", "swrgen2.example.com"],
>> >
>> > "_meta": {
>> > "hostvars": {
>> > "swrgen1.example.com": {
>> > "site": "california"
>> > },
>> > "swrgen2.example.com": {
>> > "site": "newyork"
>> > }
>> > }
>> > }
>> > }
>> >
>> > What I'd like to do is for ansible to be able to override default
>> > variables
>> > if a site or project-based file exists that contains this variable.
>> > Right
>> > now, I have the following setup working:
>> >
>> > # example_playbook.yml
>> > ---
>> > - name: variable precedence test
>> > hosts: all
>> > vars_files:
>> > - [ "/etc/ansible/vars/site/{{ site }}.yml",
>> > "/etc/ansible/vars/site/default.yml" ]
>> > tasks:
>> > - debug: var=server_memory_size
>> >
>> > With variable directories setup as:
>> >
>> > # /etc/ansible/vars/site/california.yml
>> > ---
>> > server_memory_size: 1gb
>> >
>> > And
>> >
>> > # /etc/ansible/vars/site/default.yml
>> > ---
>> > server_memory_size: 512gb
>> >
>> > So, as expected, I get the following output when running the playbook:
>> >
>> > [root@swransible ansible]# ansible-playbook plays/example_playbook.yml
>> > PLAY [variable precedence test]
>> > *********************************************************************
>> >
>> > TASK [Gathering Facts]
>> >
>> > ******************************************************************************
>> >
>> > ok: [swrgen1.example.com]
>> > ok: [swrgen2.example.com]
>> >
>> > TASK [debug]
>> >
>> > ****************************************************************************************
>> >
>> > ok: [swrgen1.example.com] => {
>> > "changed": false,
>> > "server_memory_size": "1gb"
>> > }
>> > ok: [swrgen2.example.com] => {
>> > "changed": false,
>> > "server_memory_size": "512mb"
>> > }
>> >
>> > Is this the "right" way to do this? Is there a better way? Everything
>> > I've
>> > seen on "ansible/hiera" google searches is about 2 years old and it
>> > seems
>> > like quite a bit has changed over the last few years.
>> >
>> > The biggest drawback to this is that EVERY playbook will need to have a
>> > vars_files entry along with the entire variable file hierarchy. This
>> > seems
>> > hugely repetitive.
>> >
>> > --
>> > 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 ansible-proje...@googlegroups.com.
>> > To post to this group, send email to ansible...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/ansible-project/96de3153-c343-4ae4-8893-a51be2cffb97%40googlegroups.com.
>> > 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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAK5eLPTZcAHsBQS2o2i_Jxy7Vx840ed48mcD-BQortENVwryOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
