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

Introduction to Ansible

Introduction to Ansible

Youtube link: https://youtu.be/6ovLhYgAiO4

A brief intro about it and what is it used for. All about Inventories, configuration files and how to use the inbuilt ansible modules to run adhoc-commands
remotely on your managed hosts. Using ansible roles for making your ansible playbooks modular and reusable. Best practices for structuring your ansible playbook. Demo:
A very simple example of provisioning a remote server using an ansible-playbook from controlling node.

Material and code: https://github.com/prodicus/talks/tree/master/accepted/bangpypers/intro-to-ansible-april-meetup

Tasdik Rahman

April 15, 2017
Tweet

More Decks by Tasdik Rahman

Other Decks in Programming

Transcript

  1. Introduction to Ansible
    Tasdik Rahman (@tasdikrahman)
    Engg. Intern @ Cisco, formerly Wingify(S16)

    View full-size slide

  2. Brief history
    A con guration management tool, deployment
    tool, and ad-hoc task execution tool all in one.
    Initially developed by Michael DeHaan.
    Inspired by Func (previously used by tumblr)
    Userbase includes NASA, Apple, Juniper et al.
    2

    View full-size slide

  3. Why Ansible? Or any other
    tool for that matter?
    3

    View full-size slide

  4. Before Con guration management
    manual con guration.
    results in Flaky servers.
    4

    View full-size slide

  5. Enter Ansible
    Follows a push approach.
    Agentless.
    Uses OpenSSH for transport.
    Easy to understand yaml styled con guration.
    Requires python installed on the managed node
    Runs tasks in a sequential manner.
    Immutable infrastructure.
    Idempotency!
    5

    View full-size slide

  6. Using Ansible
    Brings server to a known/deterministic state.
    6

    View full-size slide

  7. Inventory
    sample /etc/ansible/hosts le
    [testdroplets]
    ubu ansible_ssh_host=139.59.3.235
    icinga ansible_ssh_host=139.59.24.40
    [testansible]
    host0.example.org ansible_host=192.168.33.10
    host1.example.org ansible_host=192.168.33.11
    host2.example.org ansible_host=192.168.33.12
    [testansible:vars]
    ansible_user=tasdik
    From v2.0 , Ansible has deprecated the ssh above.
    7

    View full-size slide

  8. Inventory
    holds a list of Ansible-managed servers
    by default, hosts picked up from /etc/ansible/hosts
    can also be speci ed by giving -i option on
    the command line.
    [testdroplets]
    ubuntu1404
    [testdroplets] would be the groupname inside
    which ubuntu1404 is a host.
    8

    View full-size slide

  9. A host can co-exist in two groups at the same time.
    [webservers]
    foo.example.com
    [dbservers]
    foo.example.com
    Ansible will look for additional variables
    de nitions in group and host variable les which
    will be searched in directories group_vars and
    host_vars , below the directory where the main
    inventory le is located.
    group_vars/linux
    host_vars/host0.example.org
    9

    View full-size slide

  10. Ad-hoc commands
    would be something that you might type in to do
    something really quick, but don’t want to save for
    later.
    Ansible has a great deal of modules
    General syntax
    $ ansible -m \
    -a "OPT_ARGS" -u
    basically used for things which you don't want to
    write a playbook for!
    10

    View full-size slide

  11. Show us one
    $ ansible testdroplets -l ubu \
    -u root \
    -m shell -a "free m"
    using -l ubu to limit the command to only the
    server with hostname ubu inside the testdroplets
    group (or in ansible terms, a "pattern")
    specifying root as the remote user to ssh into on
    the remote machine with -u .
    -m shell means use module "shell".
    as shell module takes additional params i.e the
    command to be run, passing it through -a switch.
    11

    View full-size slide

  12. Ansible playbooks
    12

    View full-size slide

  13. Playbook's you said?
    just a series of ansible commands (tasks), like the
    ones we used with the ansible CLI tool. These
    tasks are targeted at a speci c set of hosts/groups.
    expressed in YAML format
    Each playbook is composed of one or more ‘plays’
    in a list.
    The goal of a play is to map a group of hosts to
    some well de ned roles, represented by things
    ansible calls tasks.
    At a basic level, a task is nothing more than a call
    to an ansible module
    13

    View full-size slide

  14. ---
    - hosts: nginx
    remote_user: root
    vars:
    message: "Welcome to the Aril Meetup!"
    tasks:
    - name: nginx | Install
    apt: pkg=nginx state=installed update_cache=true
    - name: nginx | remove default index.html
    file:
    path: /var/www/html/index.nginx-debian.html
    state: absent
    - name: nginx | copy template site
    template:
    src: files/index.html.j2
    dest: /var/www/html/index.nginx-debian.html
    notify:
    - restart nginx
    handlers:
    - name: restart nginx
    service: name=nginx state=restarted 14

    View full-size slide

  15. You can have multiple plays in your playbook.
    ---
    - hosts: web
    tasks:
    name: foo
    task: ...
    - hosts: db
    tasks:
    name: foo
    task: ...
    hosts : a list of one or more groups or host
    patterns, separated by colons
    remote_user : just the name of the user account
    15

    View full-size slide

  16. tasks items can be brokdn down over multiple
    lines to improve the structure
    ...
    - tasks:
    name: foo
    apt: pkg=nginx state=installed
    ...
    can be written using YAML 's dict to pass key=value
    ...
    - tasks:
    name: foo
    apt:
    pkg:nginx
    state:installed
    ...
    16

    View full-size slide

  17. Tasks
    Are executed in order, one at a time, against all
    machines matched by the host pattern, before
    moving on to the next task.
    17

    View full-size slide

  18. But wouldn't this become messy
    for complex tasks?
    YES!
    How?
    18

    View full-size slide

  19. Ansible Roles
    19

    View full-size slide

  20. What do they do?
    as we add more & more functionality to our
    playbook, it becomes unreadable at some point.
    allow you to create very minimal playbooks that
    then look to a directory structure to determine
    the actual con guration steps they need to
    perform.
    enforces modularity so that we can resuse
    commonly used tasks(roles) again.
    20

    View full-size slide

  21. Organising your roles
    roles/
    common/
    files/
    templates/
    tasks/
    handlers/
    vars/
    defaults/
    meta/
    In a playbook, it would look like this:
    ---
    - hosts: webservers
    roles:
    - common 21

    View full-size slide

  22. files : contains regular les/scripts that need to
    be transferred to the hosts you are con guring for
    this role.
    handlers : All handlers that were in your playbook
    previously can now be added here.
    meta : can contain les that establish role
    dependencies. You can list roles that must be
    applied before the current role can work correctly.
    templates : place all les that use variables to
    substitute information during creation here.
    tasks : contains all of the tasks in a playbook.
    vars : Variables for the roles can be speci ed in
    this directory and used in your con guration les. 22

    View full-size slide

  23. what goes inside these?
    Within all of the directories but the files and
    templates , if a le called main.yml exists, its
    contents will be automatically added to the
    playbook that calls the role
    23

    View full-size slide

  24. roles


    ─ basic_server_hardening
    │ ├

    ─ defaults
    │ │ └

    ─ main.yml
    │ ├

    ─ handlers
    │ │ └

    ─ main.yml
    │ └

    ─ tasks
    │ └

    ─ main.yml


    ─ create_new_user
    │ ├

    ─ defaults
    │ │ └

    ─ main.yml
    │ └

    ─ tasks
    │ └

    ─ main.yml


    ─ vimserver


    ─ defaults
    │ └

    ─ main.yml


    ─ files
    │ └

    ─ vimrc_server


    ─ tasks


    ─ main.yml
    24

    View full-size slide

  25. If Ansible modules are the tools in your
    workshop, playbooks are your instruction
    manuals, and your inventory of hosts are your
    raw material.
    -- http://docs.ansible.com/ansible/playbooks.html


    25

    View full-size slide

  26. References
    http://docs.ansible.com/ansible/intro_adhoc.html
    http://docs.ansible.com/ansible/intro_inventory.html
    http://docs.ansible.com/ansible/intro_patterns.html
    http://docs.ansible.com/ansible/playbooks.html
    http://docs.ansible.com/ansible/playbooks_roles.html
    http://docs.ansible.com/ansible/modules.html
    http://docs.ansible.com/ansible/YAMLSyntax.html
    26

    View full-size slide

  27. Questions?
    Would be happy to answer them!
    http://tasdikrahman.me/
    Twitter (@tasdikrahman)
    Github (@prodicus)
    Materials for the talk @
    https://github.com/prodicus/talks
    27

    View full-size slide