From charlesreid1

 
(3 intermediate revisions by the same user not shown)
Line 3: Line 3:
The Ansible documentation has a nice overview of playbooks: https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html
The Ansible documentation has a nice overview of playbooks: https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html


Notes on playbooks:
==Brief Notes==
 
===Playbooks===
 
* playbooks are a way of executing commands on remote machines in a scripted way
* playbooks are a way of executing commands on remote machines in a scripted way
* can orchestrate multiple ordered processes
* can orchestrate multiple ordered processes
Line 12: Line 15:
* users - the remote user is the user that Ansible will run the particular task as
* users - the remote user is the user that Ansible will run the particular task as


Notes on tasks:
===Tasks===


* each play has a list of tasks associated with it
* each play has a list of tasks associated with it
Line 18: Line 21:
* ansible completes the task on all remote machines before it moves on to the next task
* ansible completes the task on all remote machines before it moves on to the next task


Notes on handlers:
===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
* 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


Notes on being idempotent:
===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
* Roles can be dependent on other roles (that's the purpose of the "meta" yaml file)
 
Example:
* the following playbook entry will automatically populate the play with a list of variables, tasks, and handlers from the roles subdirectory
* the roles subdirectory will contain two subdirectories, common and web, with files for those roles
 
<pre>
---
# playbook.yml
- name: example play
  hosts: webservers
  roles:
  - common
  - web
</pre>
 
===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
* idempotent means you can run it multiple times with the same outcome as running it one time

Latest revision as of 17:00, 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
  • Roles can be dependent on other roles (that's the purpose of the "meta" yaml file)

Example:

  • the following playbook entry will automatically populate the play with a list of variables, tasks, and handlers from the roles subdirectory
  • the roles subdirectory will contain two subdirectories, common and web, with files for those roles
---
# playbook.yml
- 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