526 lines
19 KiB
YAML
526 lines
19 KiB
YAML
|
#!/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 invenotry 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 conneciton 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 escalationj 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 examplle 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 Asnible will use to try to communicate with the target host.
|
||
|
|
# notable options are paramiko (python implementation of ssh, mostly useful in corener 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.
|
||
|
|
...
|