intermediate_example.yml 2.67 KB
Newer Older
1
---
2
# see examples.yml first!
Michael DeHaan committed
3
# This file explains some more advanced features of playbooks.
4 5 6
# because of the comments it's less concise than it normally is.  But feel
# free to comment your playbooks if you like.

7
- hosts: all
8 9 10

  # we can define variables the normal way...

11
  vars:
12 13 14 15 16 17 18
    release: 2.0

  # but they can also come from other files.  This can be a relative
  # or absolute path.  This is a good way to store 'secret' variable
  # files but still keep the playbook in public source control

  vars_files:
19
    - vars/external_vars.yml
20 21 22

  # as with before, every play has a list of tasks in it

23
  tasks:
24 25 26 27

  # tasks can be written the normal way...

  - name: arbitrary command
28
    action: command /bin/true
29 30 31 32

  # or we can promote reuse and simplicity by including tasks
  # from other files, for instance, to reuse common tasks

33
  - include: tasks/base.yml
34 35 36

  # we could also have done something like:
  # - include: wordpress.yml user=timmy
Michael DeHaan committed
37
  # and had access to the template variable $user in the
38 39 40
  # included file, if we wanted to.  Variables from vars
  # and vars_files are also available inside include files

41
  handlers:
Michael DeHaan committed
42

43 44
    # handlers can also be included from files, to promote reuse
    # and simpler recipes, you may wish to only have one
45 46 47
    # handler file for all your plays and playbooks.  This example really
    # doesn't notify any handlers, it is just showing you how they would
    # be included (see intro_example for usage).
48

49
    - include: handlers/handlers.yml
50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

    # you can mix things that are directly in the file with things
    # that are included.  Order is executed as written, but only
    # handlers that have been notified get executed

    - name: restart foo
      action: service name=foo state=restarted

# ===============================================================

# Here's a second play in the same playbook.  This will be run
# after the first playbook completes on all hosts.  You may want
# a different play for each class of systems, or may want a different
# play for each stage in a complex multi-node deployment push
# process.  How you use them are up to you.

# any play in a playbook can be executed by a user other than root
# if you want.  sudo support is coming too.

- hosts: webservers
  user: mdehaan

  # vars must be specified again for the next play in the playbook
  # but can be reused by including from vars_files if you want
  # you can use vars, vars_files, or both.  vars_files overrides
Michael DeHaan committed
75
  # those set in vars.
76 77 78 79

  vars:
     release: 2.0
  vars_files:
80
     - vars/external_vars.yml
81 82 83 84 85 86 87 88 89 90 91


  # these all runs as the user 'mdehaan'.  If there were any handlers
  # they would as well.

  tasks:

     - name: some random command
       action: command /bin/true