RH294 - ch06s05

Bookmark this page

Lab: Managing Complex Plays and Playbooks

In this lab, you modify a complex playbook to be easier to manage by using host patterns, includes, and imports.

Outcomes

Simplify host references in a playbook by specifying host patterns.
Restructure a playbook so that tasks are imported from external task files.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command prepares your environment and ensures that all required resources are available.

[student@workstation ~]$ lab start projects-review

Procedure 6.3. Instructions

You have inherited a playbook from the previous administrator of some web servers. The playbook is used to configure a web service on servera.lab.example.com, serverb.lab.example.com, serverc.lab.example.com, and serverd.lab.example.com. The playbook also configures the firewall on the four managed hosts so that web traffic is allowed.

Make the following changes to the playbook.yml playbook file so that it is easier to manage.

Simplify the list of managed hosts used by the play in the /home/student/projects-review/playbook.yml playbook by using a wildcard host pattern.

You have a second playbook, /home/student/projects-review/host-test.yml, that contains a play that you can use to test host patterns before you use them in the play in the playbook.yml playbook.

Change into the /home/student/projects-review directory. Review the hosts parameter in the playbook.yml file.

[student@workstation ~]$ cd ~/projects-review
[student@workstation projects-review]$ cat playbook.yml
---
- name: Install and configure web service
  hosts:
    - servera.lab.example.com
    - serverb.lab.example.com
    - serverc.lab.example.com
    - serverd.lab.example.com
...output omitted...

Verify that the host pattern server*.lab.example.com correctly identifies the four managed hosts that are targeted by the playbook.yml playbook. View the contents of the host-test.yml playbook, then run the playbook.

[student@workstation projects-review]$ cat host-test.yml
---
- name: List inventory hostnames
  hosts: server*.lab.example.com
  gather_facts: no
  tasks:
    - name: List inventory hostnames
      ansible.builtin.debug:
        msg: "{{inventory_hostname}}"

[student@workstation projects-review]$ ansible-navigator run \
> -m stdout host-test.yml

PLAY [List inventory hostnames] ********************************************

TASK [List inventory hostnames] ********************************************
ok: [servera.lab.example.com] => {
    "msg": "servera.lab.example.com"
}
ok: [serverb.lab.example.com] => {
    "msg": "serverb.lab.example.com"
}
ok: [serverc.lab.example.com] => {
    "msg": "serverc.lab.example.com"
}
ok: [serverd.lab.example.com] => {
    "msg": "serverd.lab.example.com"
}

PLAY RECAP *****************************************************************
servera.lab.example.com    : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
serverb.lab.example.com    : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
serverc.lab.example.com    : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
serverd.lab.example.com    : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Replace the host list in the playbook.yml playbook with the server*.lab.example.com host pattern.

---
- name: Install and configure web service
  hosts: server*.lab.example.com
...output omitted...

Restructure the playbook.yml playbook so that the first three tasks in its play are kept in an external task file located at tasks/web_tasks.yml. Use the import_tasks feature to incorporate this task file into the play.
Create the tasks subdirectory.
[student@workstation projects-review]$ mkdir tasks
Place the contents of the first three tasks in the play in the playbook.yml playbook into the tasks/web_tasks.yml file. The task file should contain the following content:
--- - name: Install httpd ansible.builtin.dnf: name: httpd state: latest - name: Enable and start httpd ansible.builtin.service: name: httpd enabled: true state: started - name: Tuning configuration installed ansible.builtin.copy: src: files/tune.conf dest: /etc/httpd/conf.d/tune.conf owner: root group: root mode: 0644 notify: - restart httpd
Remove the first three tasks from the play in the playbook.yml playbook. Put the following lines in their place to import the tasks/web_tasks.yml task file.
- name: Import the web_tasks.yml task file import_tasks: tasks/web_tasks.yml
Restructure the playbook.yml playbook so that the fourth, fifth, and sixth tasks in its play are kept in an external task file located at tasks/firewall_tasks.yml. Use the import_tasks feature to incorporate this task file into the play.
Place the contents of the three remaining tasks in the play in the playbook.yml playbook into the tasks/firewall_tasks.yml file. The task file should contain the following content.
--- - name: Install firewalld ansible.builtin.dnf: name: firewalld state: latest - name: Enable and start the firewall ansible.builtin.service: name: firewalld enabled: true state: started - name: Open the port for http ansible.posix.firewalld: service: http immediate: true permanent: true state: enabled
Remove the remaining three tasks from the play in the playbook.yml playbook. Put the following lines in their place, which imports the tasks/firewall_tasks.yml task file.
- name: Import the firewall_tasks.yml task file import_tasks: tasks/firewall_tasks.yml
Both the tasks/web_tasks.yml file and the tasks/firewall_tasks.yml file contain tasks that install packages and enable services. Those could be consolidated into a single task file and you could use variables to control which packages and services are installed and enabled by those tasks.
Move the tasks that install packages and enable services into a new file named tasks/install_and_enable.yml and update them to use variables. Replace the original tasks with import_tasks statements, passing in appropriate values to the new variables.
Copy the ansible.builtin.dnf and ansible.builtin.service tasks from tasks/web_tasks.yml into a new file named tasks/install_and_enable.yml.
--- - name: Install httpd ansible.builtin.dnf: name: httpd state: latest - name: Enable and start httpd ansible.builtin.service: name: httpd enabled: true state: started
Replace the package and service names in tasks/install_and_enable.yml with the variables package and service.
--- - name: Install {{ package }} ansible.builtin.dnf: name: "{{ package }}" state: latest - name: Enable and start {{ service }} ansible.builtin.service: name: "{{ service }}" enabled: true state: started
Replace the ansible.builtin.dnf and ansible.builtin.service tasks in tasks/web_tasks.yml and tasks/firewall_tasks.yml with import_tasks statements that import tasks/install_and_enable.yml and set appropriate values on task variables to install the correct package and start the correct service.
--- - name: Install and start httpd import_tasks: install_and_enable.yml vars: package: httpd service: httpd
--- - name: Install and start firewalld import_tasks: install_and_enable.yml vars: package: firewalld service: firewalld

Confirm that you made the changes to the play in playbook.yml correctly, and then run the playbook.

Verify that the playbook.yml playbook contains the following contents:

---
- name: Install and configure web service
  hosts: server*.lab.example.com

  tasks:
    - name: Import the web_tasks.yml task file
      import_tasks: tasks/web_tasks.yml

    - name: Import the firewall_tasks.yml task file
      import_tasks: tasks/firewall_tasks.yml

  handlers:
    - name: restart httpd
      ansible.builtin.service:
        name: httpd
        state: restarted

Run the playbook.yml playbook with ansible-navigator run --syntax-check to verify the playbook contains no syntax errors. Correct any reported errors before preceding.
```
[student@workstation projects-review]$ ansible-navigator run \
> -m stdout playbook.yml --syntax-check
playbook: /home/student/projects-review/playbook.yml
```

Run the playbook.yml playbook.

[student@workstation projects-review]$ ansible-navigator run \
> -m stdout playbook.yml

PLAY [Install and configure web service] ***********************************

TASK [Gathering Facts] *****************************************************
ok: [serverd.lab.example.com]
ok: [serverc.lab.example.com]
ok: [serverb.lab.example.com]
ok: [servera.lab.example.com]

TASK [Install httpd] *******************************************************
changed: [serverb.lab.example.com]
changed: [servera.lab.example.com]
changed: [serverd.lab.example.com]
changed: [serverc.lab.example.com]

TASK [Enable and start httpd] **********************************************
changed: [servera.lab.example.com]
changed: [serverb.lab.example.com]
changed: [serverd.lab.example.com]
changed: [serverc.lab.example.com]

TASK [Tuning configuration installed] **************************************
changed: [serverd.lab.example.com]
changed: [serverc.lab.example.com]
changed: [serverb.lab.example.com]
changed: [servera.lab.example.com]

TASK [Install firewalld] ***************************************************
ok: [serverb.lab.example.com]
ok: [servera.lab.example.com]
ok: [serverd.lab.example.com]
ok: [serverc.lab.example.com]

TASK [Enable and start firewalld] ******************************************
ok: [servera.lab.example.com]
ok: [serverb.lab.example.com]
ok: [serverc.lab.example.com]
ok: [serverd.lab.example.com]

TASK [Open the port for http] **********************************************
changed: [serverd.lab.example.com]
changed: [serverb.lab.example.com]
changed: [servera.lab.example.com]
changed: [serverc.lab.example.com]

RUNNING HANDLER [restart httpd] ********************************************
changed: [serverd.lab.example.com]
changed: [serverb.lab.example.com]
changed: [serverc.lab.example.com]
changed: [servera.lab.example.com]

PLAY RECAP *****************************************************************
servera.lab.example.com    : ok=8    changed=5    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
serverb.lab.example.com    : ok=8    changed=5    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
serverc.lab.example.com    : ok=8    changed=5    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
serverd.lab.example.com    : ok=8    changed=5    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Evaluation

Run the lab grade projects-review command from workstation to confirm success on this exercise. Correct any reported failures and rerun the script until successful.

[student@workstation ~]$ lab grade projects-review

Finish

On the workstation machine, change to the student user home directory and use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish projects-review

This concludes the section.

Discuss Red Hat Enterprise Linux Automation with Ansible

Go to community

Red Hat Linux Automation with Ansible (RH294)

Haley_Ruccio

24 lip 2023

Learn how to automate Linux system administration tasks with Red Hat Ansible Automation PlatformRed Hat Enterprise Linux Automation with Ansible (RH294) is designed for Linux administrators and developers who need to automate repeatable and error-prone steps for system provisioning, configuration, application deployment, and orchestration. This course is based on Red Hat® Enterprise Linux® 9 and Red Hat Ansible Automation Platform 2.2.Course content summaryInstall Red Hat Ansible Automation Platform on control nodes.Create and update inventories of managed hosts and manage connections to them.Automate administration tasks with Ansible Playbooks and ad hoc commands.Write effective playbooks at scale.Protect sensitive data used by Ansible Automation Platform with Ansible Vault.Reuse code and simplify playbook development with Ansible Roles and Ansible Content Collections.Audience for this courseThis course is geared toward Linux system administrators, DevOps engineers, infrastructure automation engineers, and systems design engineers who are responsible for these tasks:Automating configuration managementEnsuring consistent and repeatable application deploymentProvisioning and deployment of development, testing, and production serversIntegrating with DevOps continuous integration/continuous delivery workflowsPrerequisites for this coursePass the Red Hat Certified System Administrator (RHCSA) exam (EX200), or demonstrate equivalent Red Hat Enterprise Linux knowledge and experience.Take our free assessment to gauge whether this offering is the best fit for your skills.

980

curl finds no route to host?

TPeters

23 lip 2023

I am doing the self-paced course RH294 . With two exercises (Ch.3 final Lab and Ch.4 lab exercise 2) I ran into this problem:after installing and starting a web service, from the classroom web termicaI I cannot reach servera.lab.example.com with curl: "No route to host". This despite the fact that I can ping it, open a shell to it, and install the package on it with Ansible.Anyone else have the same problem?What might be the cause?

1702

Welcome to the Red Hat Linux Automation with Ansible (RH294) group in the Red Hat Learning Community

cschunke

18 lip 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Linux Automation with Ansible! To gain the most value from this group - click the "Join Group" button in the upper right hand corner.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH294.Read more about Red Hat Linux Automation with Ansible here.

351

Revision: rh294-9.0-c95c7de