From charlesreid1

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