- The document provides best practices for using Ansible including organizing content with roles and hierarchies, making playbooks readable with tasks, comments and whitespace, tagging tasks for organization, avoiding duplication, ensuring idempotency, templating with Jinja2, and testing playbooks. It emphasizes documenting processes, non-idempotent tasks can cause issues, and validating changes with testing.

1. Ansible Best PracticesTyler Turk – DevOps Engineer at WP Engine

2. Who am I?
DevOps Engineer at WP Engine
Enjoys Operations, Development,
and long walks on the beach

3. General Overview

4. Content Organization
• Follow hierarchy best practices
• Use roles for content
• Simplify your roles

5. Make it readable; keep it simple
• Always provide a task name
• Always define state
• Over-use comments and white-space

6. Tag all the things
• Tags help organization
• --skip-tags=tags,to,skip
• --tags=only,run,these,tags

7. Don’t Repeat Yourself!
• Re-use code when possible
• Leverage jinja2 templating
• Avoid duplication unless
absolutely necessary

8. Idempotency

9. What is idempotence?
Idempotence is the property of certain
operations in mathematics and computer
science, that can be applied multiple times
without changing the result beyond the
initial application

10. Why is idempotency important?
Config Management that lacks idempotency introduces doubt!
• Ensure no changes unless things actually change
• Some idempotency issues can be big issues (> versus >>)
• Hides the real changes in a cloud of doubt
• Reduction in speed if changes are consistently made
• Testing becomes increasingly difficult

11. Shooting Yourself in the Foot
• Conflicting tasks for differing roles
• Remember: Don’t Repeat Yourself!
• Double check your work

12. How do we get there?
• Fully understand requirements
• Document required processes and
procedures
• Requirement verification with invested
parties
• Review module docs to ensure it is
idempotent

13. Some Modules Lacking Idempotency
• Shell module
• Command module
• File module with touch argument

14. What are changed_when and failed_when?

15. Templating

16. Jinja2 – An Introduction
• Python templating language
• Many filters available
(to_nice_json, to_nice_yaml, sort)
• Conditional evaluation on task result
(success, changed, failed, skipped)
Additional Information:
http://docs.ansible.com/playbooks_variables.html#using-variables-about-jinja2
http://jinja.pocoo.org/docs/templates/#builtin-filters

17. Variables with Jinja2
• Avoid dictionaries if values will change
• Accessible with double curly braces
{{ i_am_a_variable }}
{{ cluster.datacenter }}
• Verify variable definition
{% if cluster.lbmaster is not defined %}
# Potential Error: No lbmaster
{% endif %}

18. More with Jinja2
• Simple file templating with loops
• Simple file templating with if/else
• Even use variables for file names!
• Iterate through items, globs, and
hashes

19. Lessons Learned

20. Lessons Learned
• Long running tasks should run in
screen!
• Leverage the community on IRC
• Validate proper order of operations
• Overly document playbooks and
procedures

21. More Lessons Learned
• Burn and churn on virtual
instances for additional testing
• Consistency in playbook
development
• Implement actual testing with
ansible-lint and other CI utilities
• Do not merge non-idempotent pull
requests

22. Questions?
What about testing? That’s next!

23. References
Ansible Playbook Best Practices
http://docs.ansible.com/playbooks_best_practices.html
Ansible (Real Life) Good Practices
http://www.reinteractive.net/posts/167-ansible-real-life-good-practices
Jinja2 Documentation
http://jinja.pocoo.org/docs/