Ansible/Playbooks
From charlesreid1
Contents
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