From charlesreid1

 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
=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
<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
* modules should check whether the desired final state has already been achieved, and exit without doing anything if so
=Example: Secure Nginx Server=
=Example: Secure Nginx Server=


[[Ansible/Nginx_Playbook]] - a page that walks through two example playbooks
[[Ansible/Nginx Playbook]] - a page that walks through two example playbooks


* [https://charlesreid1.com/wiki/Ansible/Nginx_Playbook#Ansible_Playbook_Example_1:_Nginx_Server_Playbook Example 1: nginx server playbook]
* [https://charlesreid1.com/wiki/Ansible/Nginx_Playbook#Ansible_Playbook_Example_1:_Nginx_Server_Playbook Example 1: nginx server playbook]
* [https://charlesreid1.com/wiki/Ansible/Nginx_Playbook#Ansible_Playbook_Example_2:_Secure_Nginx_Server_Playbook Example 2: secure nginx server playbook]
* [https://charlesreid1.com/wiki/Ansible/Nginx_Playbook#Ansible_Playbook_Example_2:_Secure_Nginx_Server_Playbook Example 2: secure nginx server playbook]
=Full Stack Example: Django Celery RabbitMQ Postgres=
[[Ansible/Full Stack Playbook]] - a page that walks through a playbook for a full stack example


=Flags=
=Flags=


[[Category:Ansible]]
{{AnsibleFlag}}
[[Category:Infrastructure]]
 
[[Category:Python]]
[[Category:Ansible Playbooks]]

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