Automating Your Daily Jobs

Are you struggling to find automation use cases to start with Ansible automation? Your workplace is a great place to start your search for automation use cases. Track the most repeated jobs that you or your team are doing every day and you will see the opportunity to automate these tasks. This can be simple server information gathering, collecting operating system versions, or a simple weekly reboot job.

In this chapter, you will learn how to use the Jinja2 template to create reports and emails with the help of Ansible. You will also learn how to develop Ansible artifacts in a modular way and include tasks and variables dynamically.

In this chapter, we will cover the following topics:

• Using Ansible to collect server details
• Collecting system information
• System scanning and remediation using Ansible
• Automated weekly system reboot using Ansible
• Automating notifications

We will start with ansible_facts and learn how to...

Technical requirements

The following are the technical requirements for this chapter:

• A Linux machine for the Ansible control node
• Two or more Linux machines with Red Hat repositories configured (if you are using other Linux operating systems instead of Red Hat Enterprise Linux (RHEL) machines, then make sure you have the appropriate repositories configured to get packages and updates)

All the Ansible configurations, playbooks, commands, and snippets for this chapter can be found in this book’s GitHub repository at https://github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-03.

Using Ansible to collect server details

In the previous chapter, you learned how to use Ansible for basic automation by using simple playbooks and tasks. In this chapter, you will learn more by automating the simple day-to-day jobs in your workplace.

An up-to-date system inventory with easy access is the dream of every system engineer and IT team. In large enterprises, it is common to use configuration management database (CMDB) software. However, engineers must maintain their spreadsheets to keep the server and device information they are managing. When you have software-defined infrastructures such as virtual machines and virtual appliances, verifying and updating these local spreadsheets will become a tedious task.

Maintaining such information can be automated using Ansible, as shown in the following diagram:

Figure 3.1 – Maintaining a system information database using Ansible

Ansible and ansible_facts can be used to create and update your...

Collecting system information

In this section, you will extract the required information from ansible_facts and generate HTML reports inside the web server that you created in the previous section.

ansible_facts contains a lot of information about nested dictionaries and lists. Search and go through the content and find the important information you need for your report.

To see the content of ansible_facts, execute the following ad hoc command:

Figure 3.20 – Ansible facts output after using an ad hoc command

Using the less or more commands after the pipe (|) symbol will keep the output on top without you having to scroll to the bottom. It is possible to scroll down or up using the arrow keys or find the text by searching for it (/ + <text>).

Find sample ansible_facts details for a Linux machine at https://github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-03/node1-ansible-facts.

Follow these steps to use some...

System scanning and remediation using Ansible

Security scanning and remediation are critical, and organizations are spending more time and money on this area every year. When there are new features and changes in the operating system and applications, you will have more configurations to check and validate to ensure the best security practices are in place. With the help of Ansible, it is possible to automate the security scanning and remediation tasks for your systems and devices.

In this section, you will automate a few basic security and compliance configurations based on the CIS Red Hat Enterprise Linux 8 Benchmark.

CIS Benchmark

CIS provides the best practices and configurations for systems and platforms to ensure security and compliance. Refer to https://www.cisecurity.org/cis-benchmarks to learn more about CIS Benchmarks.

When we have several tasks in a playbook or role, then we can split the tasks into multiple files and call them using the include_tasks module...

Automated weekly system reboot using Ansible

A scheduled and planned system reboot is a standard process in an IT environment to ensure the servers and applications are working well and the environment is stable with service restart operations. The reboot command might be simple when it executes but the reboot process and its formalities are not straightforward.

A generic server reboot activity involves multiple steps, as shown in the following diagram:

Figure 3.42 – Typical system reboot job workflow

Imagine that you have hundreds of servers to reboot every week and your team is too small to handle such critical operations on weekends. It is possible to automate the entire workflow using Ansible by using backup operations before reboot and service verifications after reboot.

The Ansible reboot module was introduced in Ansible 2.7 (2018). At the time of writing, this module is part of ansible-core and included in all Ansible installations.

...

Automating notifications

It is very important to notify the administrators and end users about the changes you are making in the environment. Whether it’s a simple package installation or a system reboot, the end user should be aware of the downtime and changes that are occurring. Instead of sending emails manually, the Ansible mail module can be used to automate email notifications. The Ansible mail module is powerful and can support most email features, including custom headers, attachments, and security.

Encrypting sensitive data using Ansible Vault

If the email server (SMTP) is not open (configured to send email without authentication), then you need to authenticate the SMTP server with a username and password (app password or secret key). Keeping such sensitive information in plain text is not a best practice, so you need to store it in a safe method. To store such sensitive information, use key vault tools, in which the information will be saved in an encrypted format...

Summary

In this chapter, you learned how to create Ansible roles, Jinja2 templates, and Ansible Vault secrets. You also learned how to collect system information from Ansible facts and use the Jinja2 template to create reports and configurations. The use cases you have practiced were very generic, such as collecting system information, configuring standard system files, rebooting servers, and sending email notifications. As an exercise, enhance the use cases by adding more tasks and validation (such as validating the reboot activity before sending an email and so on).

In the next chapter, you will learn about the importance of version control systems (VCSs) in Ansible, the best practices to keep your Ansible artifacts safe, and how to enable collaboration and sharing to improve the quality of Ansible artifacts.

Further reading

To learn more about the topics that were covered in this chapter, take a look at the following resources:

• How to pass extra variables to an Ansible playbook: https://www.redhat.com/sysadmin/extra-variables-ansible-playbook
• Ansible for Security and Compliance: https://www.ansible.com/use-cases/security-and-compliance