path: root/examples/play.yml

#!/usr/bin/env ansible-playbook
# ^ Trick: the above line can be used to make your play an executable
# you also must add 'x' permissions to the file
#
# this file is based on phred's 'pedantically commented playbook'
# https://github.com/phred/ansible-examples/blob/master/pedantically_commented_playbook.yml
#
---
# ^^^ YAML documents can begin with the document separator "---"
# and end with the "...", neither is needed for Ansible # as it does not
# support multiple YAML documents per file, but some linters incorrectly insist
# you must have it ....
#
# The '#' is a comment character, so any line starting with it will be ignored by Ansible.

# Blank lines are ignored, so can be used # to create spacing to your taste.

# Note about YAML: like Python, cares about whitespace, it requires actual spaces, tabs won't work.
# Indent consistently throughout.
# Two-space or four space indents is what most users prefer, but do whatever you like.
#
# If you're new to YAML, keep in mind that YAML documents, like XML
# documents, represent a tree-like structure of nodes and text. More
# familiar with JSON?  Think of YAML as a strict (with spaces) but also more flexible
# JSON (fewer significant characters, e.g., :, "", {}, [] and liberal quoting).
# Also, JSON is a subset of YAML, so most YAML parser can read JSON just the same.
#
# The curious may read more about YAML at:
# http://www.yaml.org/spec/1.1/current.html
# there is a 1.2, but Ansible uses pyyaml which is mostly 1.1

# the following line configures 'vim' to handle 2 space indents.
# vim:ff=unix ts=2 sw=2 ai expandtab

###
# Notice the minus (-) on the line below, this is the start of a 'list' in YAML
# In Ansible this is the 'list of plays' which starts this playbook.
# Plays map the inventory hosts to the tasks, the most minimal play you can have
# just requires 'hosts'

- hosts: all
  ###########
  # Play keyword: hosts
  # Required: yes
  # Description:
  #   The selection of hosts (or host) that the tasks in this play play should apply to.
  #
  ## Example values:
  #   hosts: all -- applies to all hosts
  #   hosts: host1 -- apply ONLY to the host that inventory defines as 'host1'
  #   hosts: group1 -- apply to all hosts in group1
  #   hosts: group1,group2 -- apply to hosts in group1 & group2
  #   hosts: group1,host1 -- hosts in group1 AND host
  #
  ## now using host patterns (TODO: url)
  #   hosts: group1,!group3 -- hosts in group1 that are not in group3
  #   hosts: group1,&group3 -- hosts in group1 that are also in group3
  #   hosts: group1:&group3 -- same as above, but using : instead of , as separator
  #   hosts: group1:!group2:&group3 -- hosts in group1 what are not in group2 but are also in group3
  #
  ## Using a variable value for 'hosts'
  #
  # You can, in fact, set hosts to a variable, for example:
  #
  #   hosts: '{{mygroups}}' -- apply to all hosts specified in the variable 'mygroups'
  #
  # This is handy for testing playbooks, running the same playbook against a
  # staging environment before running it against production, occasional
  # maintenance tasks, and other cases where you want to run the playbook
  # against just a few systems rather than a whole group.
  # Note that the variable cannot be set in inventory, since we need to know the hosts
  # before we can use inventory variables. So normally 'extra vars' are used, as you can
  # see below.
  #
  # If you set hosts as shown above, then you can specify which hosts to
  # apply the playbook to on each run as so:
  #
  #   ansible-playbook playbook.yml --extra-vars="mygroups=staging"
  #
  # Use --extra-vars to set the variable to any combination of groups, hostnames,
  # or host patterns just like the examples in the previous section.
  #

  name: my heavily commented play
  ###########
  # Play keyword: name
  # Default: play###
  # Required: no
  # Description: Just a description to document the play

  gather_facts: yes
  ###########
  # Play keyword:  gather_facts
  # Default: None
  # Required: no
  # Description:
  #   This controls if the play will trigger a 'fact gathering task' (aka 'gather_facts' or 'setup' action) to get information about the remote target.
  #   These facts normally provide useful variables on which to base decisions and task inputs. For example `ansible_os_distribution` can tell us if
  #   the target is a RHEL, Ubuntu or FreeBSD machine (among others), number of CPUs, RAM, etc.
  # TODO: url to fact gathering

  remote_user: login_user
  ###########
  # Play keyword:  user
  # Default: depends on connection plugin, for ssh it is 'current user executing Ansible'
  # Required: no
  # Description:
  #   Remote user to login on remote targets and 'normally' execute the tasks as

  become: True
  ###########
  # Play keyword: become
  # Default: False
  # Required: no
  # Description:
  #   If True, always use privilege escalation to run tasks from this play, just like passing the
  #   --become flag to ansible or ansible-playbook.


  become_user: root
  ###########
  # Play keyword: become_user
  # Default: None
  # Required: no
  # Description:
  #   When using privilege escalation this is the user you 'become' after login with the remote_user
  #   for example you login to the remote as 'login_user' then you 'become' root to execute the tasks

  become_method: sudo
  ###########
  # Play keyword: become_method
  # Default: sudo
  # Required: no
  # Description:
  #   When using privilege escalation this chooses the become plugin to use for privilege escalation.
  #   use `ansible-doc -t become -l` to list all the options.

  connection: ssh
  ###########
  # Play keyword: connection
  # Default: ssh
  # Required: no
  # Description:
  #   This sets which connection plugin Ansible will use to try to communicate with the target host.
  #   notable options are paramiko (python implementation of ssh, mostly useful in corner cases in which the ssh cli
  #   does not work well with the target. Also 'local' which forces a 'local fork' to execute the task, but normally
  #   what you really want is `delegate_to: localhost` see examples below in 'Run things locally!' entry.
  #   use `ansible-doc -t connection -l` to list all the options.

  vars:
  ###########
  # Play keyword: vars
  # Default: none
  # Required: no
  # Description:
  #   Mapping of variables defined for this play, normally for use in templates or as variables for tasks.

    # to get the value just use {{color}} to reference that value
    color: brown

    # Mapping structures allow complex variables structures, to use you can reference
    #  the variable name with {{web['memcache']}} when using nested key value or {{web}}
    # when using the whole structure..
    web:
      memcache: 192.168.1.2
      httpd: apache

    # lists use a slightly different notation {{ mylist[1] }} to get 'b', they are 0 indexed.
    mylist:
       - a
       - b
       - c

    # Variables can be dynamically set via Jinja templates, to be filled when consumed.
    #
    # In this playbook, this will always evaluate to False, because 'color'
    #  is set to 'brown' above.
    #
    # When ansible interprets the following, it will first expand 'color' to
    # 'brown' and then evaluate 'brown' == 'blue' as a Jinja expression.
    is_color_blue: "{{ color == 'blue' }}"

    # TODO: (url variables)

  vars_files:
  ##########
  # Play keyword: vars_files
  # Required: no
  # Description:
  #   Specifies a list of YAML files to load variables from.
  #
  #   Always evaluated after the 'vars' section, no matter which section
  #   occurs first in the playbook.  Examples are below.
  #
  #   Example YAML for a file to be included by vars_files:
  #   ---
  #   monitored_by: phobos.mars.nasa.gov
  #   fish_sticks: "good with custard"
  #   ... # (END OF DOCUMENT)
  #
  #   Remove the indentation & comments of course, the '---' should be at
  #   the left margin in the variables file.
  #
    # Include a file from this absolute path
    - /srv/ansible/vars/vars_file.yml

    # Include a file from a path relative to this playbook
    - vars/vars_file.yml

    # By the way, variables set in 'vars' or as extra vars are available here.
    - vars/{{something}}.yml

    # It's also possible to pass an array of files, in which case
    # Ansible will loop over the array and include the first file that
    # exists.  If none exist, ansible-playbook will halt with an error.
    #
    # An excellent way to handle platform-specific differences.
    - [ 'vars/{{platform}}.yml', vars/default.yml ]

    # Files in vars_files process in order, so later files can
    # provide more specific configuration:
    - [ 'vars/{{host}}.yml' ]

    # Hey, but if you're doing host-specific variable files, you might
    # consider setting the variable for a group in your inventory and
    # adding your host to that group. Just a thought.


  vars_prompt:
  ##########
  # Play keyword: vars_prompt
  # Required: no
  # Description:
  #   A list of variables that Ansible will prompt for manual input each time this playbook
  #   runs.  Used for sensitive data and also things like release numbers that
  #   vary on each deployment.
  #
  #   Ansible won't prompts for this value if already provided, like when
  #   passed through --extra-vars, but not from inventory.
  #
  #   Also it won't prompt if it detects that it is a non interactive session.
  #   For example, when called from cron.
  #
    - name: passphrase
      prompt: "Please enter the passphrase for the SSL certificate"
      private: yes
      #   The input won't be echoed back to the terminal when private (default yes)

    # Not sensitive, but something that should vary on each playbook run.
    - name: release_version
      prompt: "Please enter a release tag"
      private: no

    # you can even have a default
    - name: package_version
      prompt: "Please enter a package version"
      default: '1.0'

    # You can find more advanced features in https://docs.ansible.com/ansible/latest/user_guide/playbooks_prompts.html

  roles:
  ##########
  # Play keyword: roles
  # Required: no
  # Description: A list of roles to import and execute in this play. Executes AFTER pre_tasks and play fact gathering, but before 'tasks'.
  # TODO url roles + url to 'play stages'

  tasks:
  ##########
  # Play keyword: tasks
  # Required: no
  # Description: A list of tasks to perform in this play. Executes AFTER roles and before post_tasks

    # A simple task
    # Each task must have an action. 'name' is optional but very useful to document what the task does
    - name: Check that the target can execute Ansible tasks
      action: ping

    ##########
    # Ansible modules do the work!, 'action' is not needed, you can use the 'action itself' as part of the task
    - file: path=/tmp/secret mode=0600 owner=root group=root
    #
    # Format 'action' like above:
    # <modulename>: <module parameters>
    #
    # Test your parameters using:
    #   ansible -m <module> -a "<module parameters>"
    #
    # Documentation for the stock modules:
    # http://ansible.github.com/modules.html

    # normally most will want to use 'k: v' notation instead of 'k=v' used above (but useful for adhoc execution).
    # while both formats are mostly interchangable, `k: v` is more explicit, 'type friendly' and simpler to escape.
    - name: Ensure secret is locked down
      file:
         path: /tmp/secret
         mode: '0600'
         owner: root
         group: root

    # note that 'action options' are indented inside the option, while 'task keywords' stay on the top level

    ##########
    # Use variables in the task! It expands on use.
    - name: Paint the server
      command: echo {{color}}

    # you can also define variables at the task level
    - name: Ensure secret is locked down
      file:
         path: '{{secret_file}}'
         mode: '0600'
         owner: root
         group: root
      vars:
        secret_file: /tmp/secret

    ##########
    # Trigger handlers when things change!
    #
    # Most Ansible actions can detect and report when something changed.
    # Like if file permissions were not the same as requested,
    # a file's content is different or a package was installed (or removed)
    # When a change is reported, the task assumes the 'changed' status.
    # Ansible can optionally notify one or more Handlers.
    # Handlers are like normal tasks, the main difference is that they only
    # run when notified.
    # A common use is to restart a service after updating it's configuration file.
    # https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#handlers-running-operations-on-change

    # TODO: explain handler per stage execution

    # This will call the "Restart Apache" handler whenever 'copy' alters
    # the remote httpd.conf.
    - name: Update the Apache config
      copy:
        src: httpd.conf
        dest: /etc/httpd/httpd.conf
      notify: Restart Apache

    # Here's how to specify more than one handler
    - name: Update our app's configuration
      copy:
        src: myapp.conf
        dest: /etc/myapp/production.conf
      notify:
        - Restart Apache
        - Restart Redis

    ##########
    # Include tasks from another file!
    #
    # Ansible can insert a list of tasks from another file. The file
    # must represent a list of tasks, which is different than a play.
    #
    # Task list format:
    #   ---
    #   - name: create user
    #     user: name={{myuser}} color={{color}}
    #
    #   - name: add user to group
    #     user: name={{myuser}} groups={{hisgroup}} append=true
    #   ... # (END OF DOCUMENT)
    #
    #   A 'tasks' YAML file represents a list of tasks. Don't use playbook
    #   YAML for a 'tasks' file.
    #
    #   Remove the indentation & comments of course, the '---' should be at
    #   the left margin in the variables file.

    # TODO: point at import_playbook, includes and roles
    # In this example the user will be 'sklar'
    #  and 'color' will be 'red' inside new_user.yml
    - import_tasks: tasks/new_user.yml
      vars:
        myuser: sklar
        color: red

    # In this example the user will be 'mosh'
    #  and $color will be 'mauve' inside new_user.yml
    - import_tasks: tasks/new_user.yml
      vars:
        myuser: mosh
        color: mauve


    ##########
    # Run a task on each thing in a list!
    #
    # Ansible provides a simple loop facility. If 'loop' is provided for
    # a task, then the task will be run once for each item in the provided
    # list.  Each iteration will create the 'item' variable with a different value.
    - name: Create a file named via variable in /tmp
      file: path=/tmp/{{item}} state=touched
      loop:
        - tangerine
        - lemon

    - name: Loop using a variable
      file: path=/tmp/{{item}} state=touched
      loop: '{{mylist}}'
      vars:
        # defined here, but could be anywhere before the task runs
        # also note that YAML lists can be flush with their key,
        # we normally indent for clarity, but this form is also correct.
        mylist:
        - tangerine
        - lemon
    ##########
    # Conditionally execute tasks!
    #
    # Sometimes you only want to run an action when a under certain conditions.
    # Ansible supports using conditional Jinja expression, executing the task only when 'True'.
    #
    # If you're trying to run an task only when a value changes,
    # consider rewriting the task as a handler and using 'notify' (see below).
    #
    - name: "shutdown all ubuntu"
      command: /sbin/shutdown -t now
      when: '{{is_ubuntu|bool}}'

    - name: "shutdown the if host is in the government"
      command: /sbin/shutdown -t now
      when: "{{inventory_hostname in groups['government']}}"

      # another way to write the same.
    - name: "shutdown the if host is in the government"
      command: /sbin/shutdown -t now
      when: "{{'government' in group_names}}"

    # Ansible has some built in variables, you can check them here (TODO url)
    # inventory_hostname is the name of the current host the task is executing for (derived from the hosts: keyword)
    # group_names has the list of groups the current host (inventory_hostname) is part of
    # groups is a mapping of the inventory groups with the list of hosts that belong to them

    ##########
    # Run things as other users!
    #
    # Each task has optional keywords that control which
    # user a task should run as and whether or not to use privilege escalation
    # (like sudo or su) to switch to that user.

    - name: login in as postgres and dump all postgres databases
      shell: pg_dumpall -w -f /tmp/backup.psql
      remote_user: postgres
      become: False

    - name: login normally, but sudo to postgres to dump all postgres databases
      shell: pg_dumpall -w -f /tmp/backup.psql
      become: true
      become_user: postgres
      become_method: sudo

    ##########
    # Run things locally!
    #
    # Each task can also be delegated to the control host
    - name: create tempfile
      local_action: shell dd if=/dev/urandom of=/tmp/random.txt count=100

    # which is equivalent to the following
    - name: create tempfile
      shell: dd if=/dev/urandom of=/tmp/random.txt count=100
      delegate_to: localhost
    # delegate_to can use any target, but for the case above, it is the same as using local_action
    # TODO url to delegation and implicit localhost

  handlers:
  ##########
  # Play keyword: handlers
  # Required: no
  # Description:
  #   Handlers are tasks that run when another task has changed something.
  #   See above for examples on how to trigger them.
  #   The format to define a handler is exactly the same as for tasks.
  #   Note that if multiple tasks notify the same handler in a playbook run
  #   that handler will only run once for that host.
  #
  #   Handlers are referred to by name or using the listen keyword.
  #   They will be run in the order declared in the playbook.
  # For example: if a task were to notify the handlers in reverse order like so:
  #
  #   - task: ensure file does not exist
  #     file:
  #       name: /tmp/lock.txt
  #       state: absent
  #     notify:
  #     - Restart application
  #     - Restart nginx
  #
  # The "Restart nginx" handler will still run before the "Restart application"
  # handler because it is declared first in this playbook.

    # this one can only be called by name
    - name: Restart nginx
      service:
         name: nginx
         state: restarted

    # this one can be called by name or via any entry in the listen keyword
    - name: redis restarter
      service:
         name: redis
         state: restarted
      listen:
        - Restart redis

    # Any module can be used for the handler action
    # even though this can be triggered multiple ways and times
    # it will only execute once per host
    - name: restart application that should really be a service
      command: /srv/myapp/restart.sh
      listen:
        - Restart application
        - restart myapp

    # It's also possible to include handlers from another file.  Structure is
    # the same as a tasks file, see the tasks section above for an example.
    - import_tasks: handlers/site.yml


# NOTE: this is not a complete list of all possible keywords in a play or task (TODO: url playbook object and keywords), just an example of very common options.

# below is the "totally optional" YAML "End of document" marker.
...