Here’s how I get things done with Ansible. As in all things, YMMV.

Project Workflow

When starting a new project, I start by cloning my anseedble project. This gives me a good starting point 1 to create a VM in Vagrant with the basic prereqs needed to install and configure things with Ansible.

cd ~/Source
git clone https://github.com/dheles/anseedble my-project

Since I’m not actually planning to add to anseedble, I need to break off its git-lationship 2 and start a new one:

cd my-project
rm -rf .git
git init

Then I do at least the minimum configuration to give the project its own identity:

Edit README.md (…obvi)

Set some vars 3:

# inventory/group_vars/all/vars.yml
project:        "my-project"
version:        "0.1.0"

and 4:

# inventory/group_vars/dev/vault.yml
vault_login_user_passphrase

And then I create a new repo for the project on GitHub (using the buttons, because easy). GitHub gives me that handy snippet to associate my project with the new repo. It’s so handy, I can never remember it; so to help with that (maybe), here it is:

git remote add origin https://github.com/dheles/ansible-role-my-role.git
git push -u origin master

Then there’s more of the

hack hack hack

-ing that often takes the form of my:

Role Workflow

Previously, I started by creating a playbook, with the idea of refactoring it into a role at some point down the line. Now, I have come to favor starting a piece of work as a role whenever possible. Obviously, there will still be some tasks which will be best left as playbooks, but I think these will be the exception than the rule. Part of the reason for this is that I found myself creating a lot of file and folder relationships to support the playbooks that will come for free to roles. Add to this the reusability of roles (for myself, as well as others) & this seems like a clear win to me.

So, to create a new role:

cd roles
ansible-galaxy init my-role
cd my-role
git init

Wait. git init? What?

I .gitignore the roles folder in anseedble (and any derivative projects).5 So, after init-ing it, I can manage the role as its own project. So, I set it up and then create and link up a GitHub repo for it (much as described above). Following Jeff Geerling’s 6 lead, I name my ansible role projects in GitHub like, “ansible-role-my-role,” so as to keep them easily identifiable. Within the projects where I use the role, I drop the prefix, so it’ll just be “my-role.”

So, add it to a playbook in the usual way:

- name: use my role
  hosts: all
  become: true

  roles:
  - { role: my-role }

Then iterate over it til it works satisfactorally. Then, check it in to GitHub. 7

OK. Hold up a sec. Once you do what we’re about to do, your local copy of your role will get overwritten, so do please make sure your work has been checked in first.

So, after your work has been checked in properly, 8 add it to requirements.yml:

- src: https://github.com/dheles/ansible-role-my-role
name: my-role

If this is your first role in this project, and you’re using Vagrant, you may need to comment in the following line in the Vagrantfile:

ansible.galaxy_role_file = "requirements.yml"

Otherwise, install your role manually:

ansible-galaxy install -r requirements.yml

Revisions

Sooner or later, I realize a role I am using in a project is in need of revision. This is particularly true, since I tend to start out with just-what-I-need, rather than building in lots of options and configurability at the outset. When it happens, I simply replace the installed version with a clone of the role’s repo from GitHub, make my changes, check in, and reinstall. Like so:

cd roles
rm -rf my-role
git clone https://github.com/dheles/ansible-role-my-role my-role
cd my-role

Again, its important to remember to comment out the role in requirements.yml, to avoid overwriting changes.

Notes

1 An Ansible seed, if you will. Geddit? An-seed-ble? Ok, you can go now: ↩

2 Not an actual word, BTW. I just made that up. ↩

3 “project” is used by my login-user role, which is included in anseedble. “version” just seems like a good idea. ↩

4 As per Ansible’s best practices ↩

5 Except any roles prefixed “local.” As the workflow I’m now using (described here) does not take advantage of this exception, maybe it is worth dropping it. ↩

6 I highly recommend his book, Ansible for DevOps. ↩

7 And possibly Ansible Galaxy, though I have yet to do so, myself. ↩

8 Do I sound like someone who may once 9 10 have had bite marks on his posterior that were a positive match for his own dental records? Yes, I suppose I do. ↩

9 Or more than once, perhaps. I can admit it. We’re among friends here, right? ↩

10 Does that footnote have a footnote? In a wiki? No. Of course not. … It has two. ↩