(Some) Ansible Best Practices according to @svg Ansible Meetup Berchem 12/12/2015

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]

do one thing and do it well roles are the of ansible focus on small roles that do one specific thing

DON’T DO BIG SILO ROLES: SPLIT IN SMALL ROLES:

provide small roles with extensive parameterization your role variables are your API

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.

generic galaxy role assume remote_user is root? or assume sudo is needed?

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

Use full YAML notation instead of key=value http://blog.bandwidth.com/why-you-should-use-yaml-as- yaml-with-ansible/

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

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

beware of defaults! defaults are bad!

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?

all the things at once?

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

Code and Data separation ideally: code = ansible playbooks, plays, roles data = ansible inventory

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$

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

-- 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

other resources https://www.theodo.fr/blog/2015/10/best-practices-to-build-great-ansible-playbooks/ https://www.reinteractive.net/posts/167-ansible-real-life-good-practices

Questions?