Some Ansible Best Practices

Some Ansible Best Practices


Serge van Ginderachter

December 12, 2015


  1. (Some) Ansible Best Practices according to @svg Ansible Meetup Berchem

  2. Hi! My name is Serge and I’m an Ansible User

    Serge van Ginderachter @svg ops consultant @
  3. do one thing and do it well roles are the

    <body> of ansible focus on small roles that do one specific thing

  5. provide small roles with extensive parameterization your role variables are

    your API
  6. assumptions are bad deploying on some public cloud? or high

    secure private banking datacenter? direct internet connection? internet repository or local mirror? proxy access? Allow for flexible options when writing your role.
  7. generic galaxy role assume remote_user is root? or assume sudo

    is needed?
  8. privilege escalation in roles explicit is better than implicit -

    if task needs root, explicitly use become: true and become_user: root - or become_user: myapp - cumbersome for all tasks - use blocks in v2
  9. Use full YAML notation instead of key=value yaml-with-ansible/

  10. action: or modulename: ? - action: module: file dest: /blah/foo

  11. mention all module parameters explicitly if not, owner and group

    depend on remote_user OR become_user mode depends on some default os/user setting
  12. beware of defaults! defaults are bad!

  13. defaults change over time Java 8 is the new stable

    for now don’t build an app depending on the ‘latest stable’ of that library do not rely on group_vars/all {{role}}/defaults/main.yml is for providing a sane default example, not for running values explicit is better than implicit what if a role changes a default?
  14. all the things at once?

  15. update the default? group_vars/all ? group_vars/development ? group_vars/my_fancy_app ? upgrade

    all your Java 8 based apps at once, when changing the default to 9? … in all that application’s environments like dev, test and prod, at once? when java 9 is the new 8
  16. Code and Data separation ideally: code = ansible playbooks, plays,

    roles data = ansible inventory
  17. Constants, Variables, Parameters role/vars are constants play vars are constants

    too, but roles are better role/defaults are nothing more than examples group_vars and host_vars exist at both inventory level and playbook level most logical would be to override playbook vars with inventory vars keep things simple, don’t mix $ grep $ -r playbook/play.yml:- hosts: all playbook/play.yml: tasks: playbook/play.yml: - debug: var=myvar inventory/hosts:localhost inventory/group_vars/all:myvar: inventory playbook/group_vars/all:myvar: playbook $ ansible-playbook -i inventory/hosts playbook/play.yml PLAY *************************************************************************** TASK [setup] ******************************************************************* ok: [localhost] TASK [debug var=myvar] ********************************************************* ok: [localhost] => { "changed": false, "myvar": "playbook" } PLAY RECAP ********************************************************************* localhost : ok=2 changed=0 unreachable=0 failed=0 [2.1.0 (devel bd0f9a4afc)] serge@goldorak:~/Temp/ansible2$
  18. Variables inventory group_vars are powerful - also complex when lots

    of groups and childs keep it explicit at runtime, ansible only cares about vars per host, no reason why dynamic inventory script could not return only host vars and do the merging for you ansible.cfg: hash_behaviour=merge sounds cool for fancy dictionary things is not portable
  19. -- tags keep tags high level playbook role perhaps 1

    role ~ 1 tag do not overuse tags what do you want to achieve with tags? many tags within a role? perhaps you need smaller roles avoid. again, explicit is better than implicit role dependencies
  20. other resources

  21. Questions?