http://localhost:8080/ansible_101/3.playbooks/index.html An Ansible playbook is a YAML-formatted file that defines a series of automation tasks to be executed on one or more managed hosts, allowing administrators to consistently configure systems, deploy applications, and orchestrate infrastructure through repeatable, human-readable automation. Core Components of an Ansible Playbook Playbook - The overall YAML file that contains one or more plays. Play - A set of tasks applied to a specified group of hosts. Hosts - The target systems or inventory groups on which the play runs. Tasks - Individual actions executed in sequence, such as installing packages or creating files. Modules - The built-in or custom units of work that tasks invoke (for example, package, service, copy, or user). Variables - User-defined values that make playbooks reusable and customizable. Handlers - Special tasks that run only when notified, typically used to restart services after a configuration change. Roles - A standardized structure for organizing playbooks, tasks, variables, templates, and files into reusable components. Templates - Dynamic configuration files, usually written with Jinja2 syntax, that are rendered with variable values before deployment. Inventory - The list of managed hosts and groups that Ansible targets during execution. Facts - Information automatically gathered about managed hosts, such as operating system, IP addresses, and memory details. Tags - Labels that allow selective execution of specific tasks or plays. Together, these components enable Ansible to automate infrastructure management in a modular, repeatable, and maintainable way. Hugo en-us Mon, 08 Jun 2026 10:40:21 -0400 http://localhost:8080/ansible_101/3.playbooks/playbook_structure/index.html Fri, 05 Jun 2026 10:40:21 -0400 http://localhost:8080/ansible_101/3.playbooks/playbook_structure/index.html Following is a sample playbook file to show the possible components: --- - name: Configure web servers hosts: webservers become: true vars: package_name: httpd tasks: # this is a comment - name: Install Apache ansible.builtin.package: name: "{{ package_name }}" state: present The first line is the name of ansible play contained int he playbook. The second line lists the hosts that the play is run against. This must match one or more entries in the inventory file. It can be individual servers or a group. http://localhost:8080/ansible_101/3.playbooks/facts/index.html Fri, 05 Jun 2026 10:40:21 -0400 http://localhost:8080/ansible_101/3.playbooks/facts/index.html By default, the first step ansible does is to gather facts about the hosts it’s going to execute against. These facts can be used in variables for more complex plays. If you are concerned about performance, you disable fact gathering by setting gather_facts: false in the top section of the playbook. Let’s run our first playbook to see the facts that are returned. First, have a look at playbooks/facts.yml, then execute it. http://localhost:8080/ansible_101/3.playbooks/modules/index.html Fri, 05 Jun 2026 10:40:21 -0400 http://localhost:8080/ansible_101/3.playbooks/modules/index.html Ansible has built-in modules for a great number of tasks. In the last lab we used the built-in package module to install software. The documentation for ansible is very useful. Browse to https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/package_module.html#ansible-collections-ansible-builtin-package-module Here you will see the documentation for the package module. The docs show parameters and attributes, include what’s required and what default values are. It also has a good examples section that give practical use cases for the module. http://localhost:8080/ansible_101/3.playbooks/template/index.html Mon, 08 Jun 2026 10:40:21 -0400 http://localhost:8080/ansible_101/3.playbooks/template/index.html One way to make changes to files is using templates. Ansibe uses the Jinja2 template format. In the ansible-workshop/playbooks/templates directory you’ll see a file motd.j2 template file that we’ll use to modify the /etc/motd file on our target systems. The template takes advantage of ansible facts to make changes to the file that are custom to the system by using variables derived from facts. After reviewing the template file, review the motd.yml playbook. Notice that you set the ownership and permissions for the file. Alls file related modules support these same directives. http://localhost:8080/ansible_101/3.playbooks/webserver/index.html Mon, 08 Jun 2026 10:40:21 -0400 http://localhost:8080/ansible_101/3.playbooks/webserver/index.html We are now going to install, configure and enable a web server on our target systems. Take a look at the webserver.yml playbook. It’s first installing the packages, then using systemctl to enable the webserver and making sure it’s started. Execute the playbook ansible-playbook webserver.yml After the playbook completes successfully, run the following commands to ensure the package is installed and the service is started and enabled: ansible all -m command -a "rpm -q httpd" ansible all -m command -a "systemctl is-active httpd" ansible all -m command -a "systemctl is-enabled httpd" Edit the playbook and add another task to create a custom web page. http://localhost:8080/ansible_101/3.playbooks/ssh_config/index.html Mon, 08 Jun 2026 10:40:21 -0400 http://localhost:8080/ansible_101/3.playbooks/ssh_config/index.html A lot of security hardening has to do with editing existing files so that they comply with security baselines. Review the ssh_hardening.yml playbook. It uses the lineinfile module to change the contents of the SSH config file. It uses a regular expression to make content and to change it to the value that we want. Note that backup is set to true. This is not the default behavior but is very important when manipulating files. It’s very easy to get the syntax wrong when making changes and clobber the file.