Split up group_vars files

[swalkinshaw]

Issue #133 for reference.

Trying this out to see what it looks like.

Benefits:

• better organization
• old group_vars files were just growing a bit unruly as we added more
• better spots to reference documentation

Downsides?

• more files
• another subfolder

[fullyint]

I really like this!

This vault branch demos moving some variables to group_vars/<environment>/vault.yml files.
To start using Ansible Vault, users would just

• copy .vault_pass.example to .vault_pass, edit the password, and probably chmod 600 .vault_pass
• remove .example from the end of vault_password_file = .vault_pass.example in ansible.cfg
• encrypt vault.yml files by running ansible-vault encrypt group_vars/all/vault.yml group_vars/development/vault.yml group_vars/staging/vault.yml group_vars/production/vault.yml

/cc @nathanielks

[QWp6t]

While we doing this, I submit that we should rename all to common.

[swalkinshaw]

@QWp6t all is an Ansible concept for "every group" so we can't change it.

[nathanielks]

I dig it!

[retlehs]

didn't like this at first but i dig it now!

[austinpray]

Lol @QWp6t

[QWp6t]

I'm still cool.

... right?

[fullyint]

A few more comments about that Ansible vault branch.

It's optional

The playbooks will still run fine if users choose not to encrypt the vault.yml files.

Finding variable definitions

If you're looking at an ansible task, see a variable, then search for where the variable was defined in your code/project, your search won't find that definition if it is in a file encrypted by Ansible vault.

Quoting Raphael Campardou:

Leaf encryption was (is) a feature request, but in the meantime, there is an elegant way of keeping it both readable and secure: nested variables. For every sensitive variable, you create a prefixed double that goes in an encrypted file.

# var_file
db_password: {{ vaulted_db_passord }}
# and for a dctionnary
aws: 
  - "access_key_id='abcdefgh'"
  - "secret_access_key='{{ vaulted_aws_secret_access_key }}'"

# vault_file
vaulted_db_passord: a_super_secret
vaulted_aws_secret_access_key: the_aws_secret

In the example above, you might be searching for where db_password was defined and your search would find it. And there you'd realize that it's real value is defined in vaulted_db_passord.

I tried that but ran into trouble with the wordpress_sites dict (can't remember enough to explain). However, my "vaulted" variables are prefixed by vault. An example is password="{{ vault.mysql_root_password }}". At least that prefix lets you know that the variable is defined in one of the encrypted vault.yml files.

The exception in my branch is group_vars/all/vault.yml which has just mail_password and sudoer_passwords. We optionally could give those prefixes: vaulted_mail_password and vaulted_sudoer_passwords.

Avoiding committing unencrypted vault files

The README or wiki could mention the option for users to avoid committing unencrypted passwords using this script:

I wrote a simple pre-commit hook that checks if a file called "vault-something" is encrypted before committing. If not, it displays a helpful message.
-- Raphael Campardou

[nathanielks]

Only thing I'd caution against is storing variables in a vaulted hash as opposed to a prefix. Unless things are changing in 2.0, Ansible doesn't do any sort of merging, so if you want to modify that value (for whatever reason) you'll have to rewrite the entire hash instead of the one variable.

[fullyint]

@nathanielks Yeah, there's a real argument for trying to minimize the use of hashes. Ansible does allow a ansible.cfg setting hash_behaviour=merge but it appears that variable precedence creates some gotchas around when hashes will be merged vs. entirely overwritten. Here are a couple examples: one, two. The ansible project has a number of issues and PRs about it, so I'm not sure the current state.

I need to use a hash for variables I extracted from wordpress_sites because the "site key" in the vault hash allows me to connect the variable to the "site key" in wordpress_sites hash. Here's an example:

mysql_db: name="{{ vault[item.key].db_name | default(item.key) }}"
⋮
with_dict: wordpress_sites

(I didn't try it, but maybe setting hash_behaviour=merge would allow a second wordpress_sites hash in vault.yml to merge with the original wordpress_sites hash. That might be asking for trouble.)

The only way I see around using a hash for these wordpress_sites variables is to require users to manually add a site key prefix for each, which doesn't seem like a good idea:

example.com_db_name: example_staging
example.com_db_user: example_dbuser
example.com_db_password: example_dbpassword
⋮

mysql_root_password was the only variable not originally from wordpress_sites that I put in the vault hash. Seems fine to pull it out of the hash and prefix it:
vaulted_mysql_root_password

[austinpray]

My body is ready, let's get this show on the road

[BrandonShutter]

Are we merging this soon?

[austinpray]

@BrandonShutter yes