Note: As the number of files increases, you will want to manage them by creating a directory structure to store related files. I’ve updated my directory structure to the structure below. the playbooks will be created during this exercise, and the locations will be apparent in the commands shown in examples. The files in global_vars are used later.
opt/
ansible/
ansible.cfg
files/
sudoers/
sudoer_support
global_vars/
variables.yml
vault_passwords
host_vars/
inventory/
inventory
playbooks/
alsa_remove.yml
nginx_web.yml
README.md
Ansible playbooks are files that contain the details that in prior sections, we specified on the command line. This allows for more complicated actions without the tedium of typing everything in each tie we need to trigger automation by Ansible.
The files are YAML (.yml) files. This file format requires strict adherence to the YAML standard. This is beyond the scope of this tutorial and can be researched further here: https://yaml.org/ Be warned, the website is actually presented as a .yml file, so it looks rather odd.
The following is a basic .yml file that will install the latest version of Nginx from the host’s yum/dnf repository:
---
- hosts: all
become: true
tasks:
- name: Install Nginx Web Service
dnf:
name: nginx
state: latest
This is one play with one task, stored in one playbook (nginx_web.yml). It will execute actions against all hosts in the inventory file, and will request that the commands be executed using sudo. The name of the play (“Install Nginx Web Service”) is used in the output to show the results of that portion of the playbook. A playbook can contain more than one play. Finally, the “state: latest” line ensures that the latest version of the of Nginx will be installed.
NB: From professional experience, this is not really a good idea. Once an updated package is dropped into the repo, this playbook will end up updating Nginx on the server when the playbook is run again. It is very possible that the group maintaining the repository is a different group than those maintaining the playbooks, so unless these teams are in tight sync (which is most often, not the case) the software on the server could be updated before testing, and could cause breakage in a production service. The seasoned systems administrator will recognize this, and takes steps to prevent that from happening.
The playbook is run using the ansible-playbook command. The following shows the output of running this command on the command-line:
 |
| Figure 5.1: Running a playbook to install Nginx twice. |
Starting out, Nginx is not installed on either server in our inventory. The first thing we notice is that the gather-facts module is executed. This is necessary for a playbook, and Ansible will add this for you behind the scenes. In the Install Nginx Web Service play, we see that there were changes to the targets. Finally, we get a Play Recap that shows a summary of what took place, and the results. The “ok=2” output indicates that two plays were executed (Gathering Facts and Install Nginx Web Service) and did not result in an error. “changed=1” indicates that one change was made (installation of Nginx).
In the second run, Nginx was still installed, so this shows the output when no changes are required.
No comments:
Post a Comment