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
Tweet

More Decks by Serge van Ginderachter

Other Decks in How-to & DIY

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
    [email protected]

    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)] [email protected]:~/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