Vault and .vpass
For setting up the vault, Ansible’s documentation puts it quite simply. It is stated that the best way is just to add another layer of indirection at the variable file level. This can be achieved by having the sensitive variables reference encrypted ones. For instance a variable
my_secret could reference
vault_my_variable. That second variable would be contained within the vault file that resides next to the original.
It’s the password of passwords. However I set it up, I have to be able to en/decrypt that file using a password. When I run
ansible-playbook I have a flag that I can pass. That flag is
--ask-vault-pass. Then I would have to put in the password for every run.
Another way to pass the password to a run would be to use a vault password file. That would be with the flag
--vault-password-file which would point to the password file. Either that, or I can also set the env var
ANSIBLE_VAULT_PASSWORD_FILE. That way Ansible will automatically search for the password in that file.
That file can also be a python script. The plaintext version should be a string stored as a single line in the file. But the script can do anything, including prompt for input. For now, I think that a plaintext password file will do just fine, but I will definitely put that in keepassx.
So there are three locations. Like I mentioned somewhere else, I want my roles to be able to stand on their own, so I wanted a vault to be included inside of the role itself, but also have one in the playbook level as well.
There’s a milestone on github to have every
.yml file that underneath the role’s
defaults folder be automatically included in the variables. Unfortunately, using
include_vars supersedes the
group_vars entries, so that wouldn’t work. I guess I’ll wait until 2.3 comes out and hopefully they’ll have something worked out. I’d personally much prefer it to be the
vars/ directory as that would make more sense just namespace-wise, but as long as they can give me an option I won’t complain.
This is a bit easier because of the way Ansible parses the file structure for the inventory. So in each
group_vars directory, there is now a folder called
all that holds both
vault.yml that both get parsed at execution.
Both of these setups are completely agnostic as to what role is being called from which playbook. It took me awhile to come up with this system, but I think it’s the most robust that could be available to me. I’ll tell you what - my skeleton for my plays and my roles is getting beefier by the day.
Synchronize vs Copy
Not delete files - rsync no delete Does overwrite changed files
- No de-duplication
I mean, you don’t want to have them make too many decisions. But you do want to give them some.
Roles should have two sections:
- CHANGE ME
- SANE DEFAULTS
When playbooks copy the variables from here, they should only include the CHANGE ME by default. They can of course choose to include other variables as needed.
All vars are placed in the
all should have a file named
main.yml that has one section per role that’s in the
site.yml play under “Roles in Common”. There’s also going to be another file under there that’s
vault.yml. This is encrypted, obviously with all the sensitive info.
Each play should have it’s own file. It too should have one section per role that’s in it’s play.
Sensible defaults should stay in their roles, and not be mentioned in the playbook. In the role itself? Sure, fine. But not in the playbook.
This is the naming scheme of things, etc. Hard to tell from sensible defaults, but consider this. A blog wouldn’t want to have a subheader of “smacz’s blog” when someone else was forking it, now would they. That’s a personal default. This should definitely be included in the playbook.
Easy - these go in the playbook’s vault.
These use the
when_defined dictate that ansible has.
In my repo, one can see that I have a directory that is named
Raw that contains a skeleton of both a role as well as a playbook. The names of these have been changed to “blank” with varying degrees of capitalization. If there is a file or if inside of a file there is the word ‘blank’ that’s in an actual role, that’s just because I haven’t changed it from the skeleton setup. I’ll want to find out all of that.
Singular and Simple
site.yml and the plays/ directory
During the time I was developing the playbook that was directing my mailserver rollout, I came across a few architectural glitches, as well as a few shortcuts. I have found that the easiest way to think of a playbook is that it does nothing except contribute to the layers of indirection.
For one, there should never be any internal plays, as they are all almost always re-usable, and should therefore be put in a role, as it would be more modular that way.
Secondly, site.yml can itself contain plays. For instance:
- name: Tasks segregated at the role level hosts: all remote_user: root roles: - common - iptables - postfix-server - mysql
This was for my mailserver. Before I included any other playbooks, I set up the roles that were in common for all of the hosts, and it worked! For instance, they might all have different iptables configurations, but that is dealt with at the variable level, and since they all need to address it during their setup, I might as well have them all run at once.
That’s another advantage to this, initially, all of the hosts run at once. If I only did
include’s that pointed to my plays, and they were for individual or separate groups of hosts, they each run iptables on their first go-round. That means that I’d be stuck waiting for iptables task that would take three (in this case with three machines) times as long to complete. This way, I can send it to them in parallel and only spend (iptables * time) amount of time instead of 3 * (iptables * time). If that makes sense. IDK. Trust me on this one. It’s waaaay better.
plays/ directory can be populated with plays that define roles that are only for certain hosts within that playbook. If you reallY think about it, if there’s only one type of server, that means that all tasks are tasks in common. Therefore there really needs be no
plays/ directory or at least no plays. At that point, the
site.yml can contain all of the roles.
Never really used it. Will probably have to once I start using ansible-galaxy. Got rid of it in all of my playbooks, but it’s still in my skeleton.
Once again, since I’m not using ansible galaxy, I might as well not use roles, external or internal. Internal roles are located in their own special directory, and external roles are gotten from ansible-galaxy, and I don’t use it!
Parenthesis showing which task handler is running and [X/X] notation as well
In squid I just copy-pasted the
httpd SSL config task and didn’t even change the variable names.
It needs an upgrade to the latest version of PHP and the latest version of nextcloud.