Ansible/Playbooks: Difference between revisions
From charlesreid1
(→Roles=) |
|||
| Line 26: | Line 26: | ||
* the handlers are triggered once at the end of each block of tasks - this keeps them from being restarted over and over by a set of related tasks | * the handlers are triggered once at the end of each block of tasks - this keeps them from being restarted over and over by a set of related tasks | ||
===Roles | ===Roles=== | ||
* Roles are just a way of automatically loading variables, tasks, and task handlers. | * Roles are just a way of automatically loading variables, tasks, and task handlers. | ||
| Line 42: | Line 42: | ||
- web | - web | ||
</pre> | </pre> | ||
===Tags=== | ===Tags=== | ||
Revision as of 16:58, 10 December 2018
Overview
The Ansible documentation has a nice overview of playbooks: https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html
Brief Notes
Playbooks
- playbooks are a way of executing commands on remote machines in a scripted way
- can orchestrate multiple ordered processes
- playbooks are written in YAML
- each playbook can contain one or more plays
- each play will target different servers (maybe all of them, maybe just web servers, maybe just db servers)
- user specifies hosts - remote machines on which Ansible will run commands
- users - the remote user is the user that Ansible will run the particular task as
Tasks
- each play has a list of tasks associated with it
- tasks are executed in order on all machines that match the host pattern
- ansible completes the task on all remote machines before it moves on to the next task
Handlers
- handlers are "conditional tasks" - tasks that are triggered by other tasks
- the handlers are triggered once at the end of each block of tasks - this keeps them from being restarted over and over by a set of related tasks
Roles
- Roles are just a way of automatically loading variables, tasks, and task handlers.
- Roles use a known file structure to load appropriate vars/tasks/handlers
- A given play will specify a list of roles in the playbook - this indicates that ansible should look for variables/tasks/handlers that match up with those roles, and add them to the play
So, for example, the following playbook entry will automatically populate the play with a list of variables, tasks, and handlers from the roles subdirectory (which will itself contain subdirectories for each role):
--- - name: example play hosts: webservers roles: - common - web
Tags
- Tags are a way of only running part of your playbook
- Think of tags as a filtering operation
Idempotence
- idempotent means you can run it multiple times with the same outcome as running it one time
- modules should check whether the desired final state has already been achieved, and exit without doing anything if so
Example: Secure Nginx Server
Ansible/Nginx Playbook - a page that walks through two example playbooks
Full Stack Example: Django Celery RabbitMQ Postgres
Ansible/Full Stack Playbook - a page that walks through a playbook for a full stack example
Flags