Showing results for 
Search instead for 
Did you mean: 

Ansible User Types: Playbook executors

In my experience, there are at least 3 types of users when it comes to Ansible:

1.) Users who execute playbooks.

2.) Users who write/modify  playbooks for playbook executors.

3.) Users who write/modify Ansible roles for other playbook writers.

As users gain more experience, they generally move from 1 to 3.  A variety of tradecraft best practices surround each of these 3 distinct types of users.  Having a clear understanding of the "roles" and responsibilities of each user type helps make for a more effective Ansible ecosystem. 

At the same time, writing a new role using playbook writing best practices can result in a frustrating experience with Ansible.

So to start: What sorts of competencys and tradecraft do you think should be demonstrated by someone who executes (already written) playbooks?

I'll post a few of my thoughts below.

6 Replies

  1. Get know as many of the options for ansible-playbook as you can. 
  2. Know the variables that need to be defined for the playbook.
  3. Know how  to write an inventory file.
  4. Know how to define variables using group_vars and host_vars directories.
  5. How can I best handle and protect secrets and sensitive values needed by the playbooks?
  6. Configure a variety of connection settings for Ansible. It's not necessary to allow passwordless SSH directly to the root user account on all machines from VM.
  7. Get to know the various settings that are possible in ansible.cfg file.  I typically have a different ansible.cfg for each automation scenario, at the top level of my project directory.
  8. Before running a playbook, make sure it is vetted.  If a user is primarily a playbook executor, then he/she should not run a "black box" playbook that he/she does not understand.

There are likely others; these are just a few off the top of my head.

Mission Specialist
Mission Specialist

I'm fairly new to roles (using them), so I'd add as a compentency:

 - how to use roles and how to find roles in Galaxy.


Sandra - I agree using roles is a competency - but I see this a competency if you are writing a new playbook.  I was trying to draw out better practices in people who will only be running playbooks, and not able to edit or make changes to the playbook.  Was hoping to see the creative and interesting ways people can utilize playbooks without having to make changes to a playbook itself.

You're right however- using roles, and finding roles, is a tradecraft in and of itself.  There are definitely better practices regarding their use.  Do you have any thing you'd like to share?

Flight Engineer Flight Engineer
Flight Engineer

Hi Dan, your three roles for ansible users (😂) is a spot-on description of how I have learned to incorporate Ansible into most facets of my work as a Principal Systems Administrator.
I began by using Ansible for basic repetative tasks:
$ ansible all -m yum -a "name=* state=latest security=true"
Then go get a cup of coffee. :)
I graduated to writing playbooks, and after a great Ansible and OpenShift training event by Emergent, I advanced to turning my playbooks -- which configured newly-built systems -- into roles that are applied regularly to ensure baseline compliance.
I would suggest 'how to properly use variables' as a defining factor of the third stage. And not just variables, but all the various related topics such as how to build the folder structure for roles and playbooks for automatic incorporation to the role/play. Where to put the task files, Jinja templates, etc.
Once a user advances from one-shot ad hoc ansible to playbooks, and they get comfortable with playbook syntax and yaml structure, the next step to basic roles is pretty easy. Its mostly learning how to structure your files. The benefit of using ansible.cfg files, inventories, and plays/tasks placed in ./tasks/main.yml is not apparent to people in stage 2, but is crucial to reducing the amount of extra coding, explicit calls to load a file/define a variable, etc. that a solid type 3 user will demonstrate. I often see this lacking in otherwise fine yaml crafters.
-- Jaffo

UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.
-- Dennis Ritchie

An example of tradecraft for a playbook executor:  You are responsible for enabling access to all the machines for SSH.  This can be done with arguments passed to the ansible commands, or by defining default behavior in the ansible.cfg, or by defining appropriate variables in group/host variables (and likely others). 

What other things "best practices" are there for running playbooks?  How, for example, do you handle sensitive variables (passwords) when running your playbook?



Another really interesting use of ansible-playbook is the use of the "--list-tags", "--skip-tags", "--tags", and "--limit" options.

THis allows the person running the playbook to skip certain tasks, only execute certain tasks, and to skip certain hosts during playbook execution. 

Join the discussion
You must log in to join this conversation.