- Primary means of:
- Configuration management
- Deploying applications
- Provisioning
- Orchestration
- A sequence of tasks
cd $INTRO_ANSIBLE_DIR/working-with-playbooks
.
├── ansible.cfg
├── hosts
├── static-site.yml
├── templates
│ ├── index.html.j2
│ └── mysite.conf.j2
└── Vagrantfile
Name | Type | Description |
---|---|---|
static-site.yml |
file | Ansible playbook |
files | directory | Artefacts to be placed on remote host |
templates | directory | Templates that will be rendered and uploaded to remote host |
- A playbook is a YAML file containing a list of plays
-
A play is a dictionary object
<ul><li> <code style="color:red;">key</code><code>: </code><code style="color:blue;">value</code> </li></ul>
- Some keys in a play may contain dictionaries or lists
- A play must contain:
hosts
- A string representing a particular host or group of hosts
hosts: localhost
hosts: app.mywebsite.com
hosts: appserver
- These are what you will configure
- A string representing a particular host or group of hosts
- A play may optionally contain:
- tasks
- A list of dictionaries
- What you want to do
- name
- Description of the play
- vars
- Variables scoped to the play
- tasks
- A task is a dictionary object containing
- name
- Describes what the task does
- Optional but best practice to use
- module
- Dictionary object
- Key represents Python module which will perform tasks
- May have arguments
- name
-
Two styles of module object in tasks
- string form
- dictionary form
- Dictionary form is more suitable for complex arguments
- Matter of preference/style
vagrant up --provider virtualbox
- This creates an Ubuntu VM
- Additional ports for a static website
- 80 (HTTP)
- 443 (HTTPS)
static-site.yml
performs following actions- Installs nginx package
- Templates our nginx config (
templates/mysite.conf.j2
) - Renders template file (
templates/index.html.j2
) and place it on host - Re/Starts nginx
ansible-playbook static-site.yml
Visit the static site once playbook has finished.
- Some tasks we need to perform require sudo privileges on target machine
- The become attribute tells Ansible to run tasks as a certain user
- By default this is sudo
- Specify user with
become_user
- name: Set up static website with nginx hosts: myserver become: true tasks:
- Can be in play or task scope
- Accepts yes or true (no or false are implicit)
- We have used both
yum
andapt
to install packages in previous exercises, respectively - Some automation tools abstract common functions from different operating systems
- Eg. package to abstract package managers from various OS
- Ansible has a thin abstraction layer
- On Debian/Ubuntu use apt module
- On Centos use yum module
- It is sometimes necessary to run configuration/deploy tools more than once
- Debugging
- Temporary issues (eg. loss of network)
- Can be problematic if operations not prepared to manage repetition
- Unmanaged duplication
- Errors caused by violating unique constraints
- Most Ansible modules aim to be idempotent
- Can be run repeatedly and will only change once
- Output of each task indicates when target action resulted in a change
ok
: Already in desired state; Ansible did not change anythingchanged
: Ansible changed to desired state
- Makes behaviour declarative
- Log into your VM and remove some files
vagrant ssh sudo rm -f /usr/share/nginx/html/index.html /etc/nginx/sites-available/mysite.conf
- Run the
static-site-fail.yml
playbook - Remove fail task and run again
- Use Ansible Playbook to run complex tasks
- Playbook consists of array of YAML dictionaries called plays
- Each play contains array of tasks that are executed on remote host