Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Some Ansible Best Practices

Some Ansible Best Practices

Serge van Ginderachter

December 12, 2015

More Decks by Serge van Ginderachter

Other Decks in How-to & DIY


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

    Serge van Ginderachter @svg github.com/srvg ops consultant @ ginsys.eu github.com/ginsys [email protected]
  2. do one thing and do it well roles are the

    <body> of ansible focus on small roles that do one specific thing
  3. 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.
  4. 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
  5. 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
  6. 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?
  7. 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
  8. 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$
  9. 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
  10. -- 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