Some Ansible Best Practices

Transcript

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

   View Slide

2. 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
   serge@ginsys.eu
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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.
   

   View Slide

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

   View Slide

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
   

   View Slide

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

   View Slide

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

    View Slide

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
    

    View Slide

12. beware of defaults!
    defaults are bad!
    

    View Slide

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?
    

    View Slide

14. all the things at once?
    

    View Slide

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
    

    View Slide

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

    View Slide

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$
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

21. Questions?
    

    View Slide