Ansible/Playbooks: Difference between revisions
From charlesreid1
No edit summary |
(→Roles) |
||
| (23 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 | |||
end | |||
== | ===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> | <pre> | ||
- name: | --- | ||
# playbook.yml | |||
- name: example play | |||
hosts: webservers | hosts: webservers | ||
roles: | |||
- common | |||
- web | |||
</pre> | </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= | |||
[[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_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= | |||
{{AnsibleFlag}} | |||
[[Category:Ansible Playbooks]] | |||
[[Category:Ansible | |||
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
