AWX Best Practices (Inventories and Workflows)

Hi all,

I've been playing with AWX in a POC environment but I'm having trouble
working out the best way to lay out our inventories, jobs and workflows.
The Best Practices
<http://docs.ansible.com/ansible-tower/latest/html/userguide/best_practices.html&gt; guide
in the docs isn't exactly extensive so hopefully someone here will be able
to help.

We've already started putting roles into their own Galaxy-style
repositories, for example:

.

-- defaults
`-- main.yml
-- files
-- handlers
`-- main.yml
-- meta
`-- main.yml
-- README.md
-- tasks
`-- main.yml
-- templates
-- tests
>-- inventory
`-- test.yml

`-- vars
`-- main.yml

Then we've been using Git submodules to reference these in the individual
jobs like so:

.

-- action_plugins
  `-- plugin.py
-- ansible.cfg
-- collector.yml
-- group_vars
  >-- all.yml
  >-- dev.yml
  `-- prod.yml
-- inventories
  >-- dev.ini
  `-- prod.ini
-- library
  `-- module.py
-- playbook.yml
-- roles
  >-- role1 (Git submodule)
  `-- role2 (Git submodule)

`-- README.md

For AWX I know we'll have to replace the Git submodules with a
requirements.yml file but my main question is around Workflow Templates.
Specifically, with Workflow Templates available, what is the point of
having Job Templates at all? Why aren't they just "Role Templates". With
vanilla Ansible it makes sense to have a "job" called "Provision Web
Server" for instance that pulls down the Java role, then the Tomcat role,
then whatever else you need, but with Workflow Templates doesn't it just do
that all for you? Wouldn't you just have a "Provision Web Server" Workflow
Template that installs the Java "job" then the "tomcat" job and then
whatever else you need, or am I missing a major point here?

How are you guys setting your jobs and workflows up?

My second question is around inventories. I can see these getting very
messy very quickly with nests of groups and variables all over the place,
especially if you have multiple teams creating different jobs all with
their own variable names and ideas on how servers should be grouped for
their stuff to be deployed successfully. How do you set up your
inventories? Do you split them out by environment? By team? By job even? Do
you have multiple inventories for different purposes, sometimes with the
same server in a number of different ones?

I realise there's no cut-and-dry "best" way to do this yet but would be
interested to hear about what you guys are already doing or planning to do!

Cheers,

Bobby

Anyone?

Workflows really are just chains of job templates, it lets you take work that you might also ordinarily do singularly and build them up into something larger

what is the point of having Job Templates at all?

Because some people don’t (always) need workflows? Workflows are built up from job templates themselves. Some folks don’t want or need to break plays down into single roles and most of the time those playbooks and templates are useful as standalone components. As an example… we have a smoke test system on AWX/Tower. We already have playbooks/job templates that build images (which we use for the production AWX image publishing process) and provision systems (which we use any time we need a VM provisioned). These are ideal when used in conjunction with a smoke test play (which an engineer might want to run in a standalone fashion). We run these all of the time outside of the Full Smoke Test workflow, in some cases they are themselves collections of roles but they are 3 distinct processes that we happen to want to run together along with some failure handling playbooks that clean up resources.

Your intuition with Inventories is correct… there are a lot of ways to configure and lay it out and it’s really up to you the best way to do it for your own situation. I usually counsel people to organize inventories in a way that optimizes your playbook usage. If your teams are always running their own playbooks against their own inventory then by all means, break your inventory down into teams. It’s fine to duplicate hosts between inventories, that’s a common pattern if there is overlap in a system’s responsibility. You’ll just need to play with this to see what makes the most sense to you.

For your own sanity, though… don’t use submodules.

Another point regarding workflows… it’s important to note that workflows tasks can span different projects and inventories and rely on different sets of credentials. Job Templates are, by their nature, homogeneous when it comes to these concepts since a job template itself represents just a single execution of ansible-playbook.