A brief introduction to Ansible roles for Linux system administration

Ansible is an open source automation platform that includes configuration management, application deployment, and infrastructure orchestration. It is a  popular automation tool for DevOps engineers and for system administrators. System administrators often face career burnout due to long hours and from performing repetitive tasks on many systems, but Ansible helps make these tasks easier to complete. Tasks such as user creation, service management, and software installs can be accomplished using Ansible. Ansible is procedure-based rather than declarative, which means you write all required steps into a YAML file and then run them sequentially on all target systems.

[ You might also like to read: Using an Ansible playbook to manage workstation and server updates ]

Nodes

In Ansible architecture, you have a controller node and managed nodes. Ansible is installed on only the controller node. It’s an agentless tool and doesn’t need to be installed on the managed nodes. Controller and managed nodes are connected using the SSH protocol. All tasks are written into a "playbook" using the YAML language. Each playbook can contain multiple plays, which contain tasks, and tasks contain modules. Modules are reusable standalone scripts that manage some aspect of a system's behavior. Ansible modules are also known as task plugins or library plugins.

Roles

Playbooks for complex tasks can become lengthy and therefore difficult to read and understand. The solution to this problem is Ansible roles. Using roles, you can break long playbooks into multiple files making each playbook simple to read and understand. Roles are a collection of templates, files, variables, modules, and tasks. The primary purpose behind roles is to reuse Ansible code. DevOps engineers and sysadmins should always try to reuse their code. An Ansible role can contain multiple playbooks. It can easily reuse code written by anyone if the role is suitable for a given case. For example, you could write a playbook for Apache hosting and then reuse this code by changing the content of index.html to alter options for some other application or service.

The following is an overview of the Ansible role structure. It consists of many subdirectories, such as:

|-- README.md
|-- defaults
|-------main.yml
|-- files
|-- handlers
|-------main.yml
|-- meta
|-------main.yml
|-- tasks
|-------main.yml
|-- templates
|-- tests
|-------inventory
|-- vars
|-------main.yml

Initially, all files are created empty by using the ansible-galaxy command. So, depending on the task, you can use these directories. For example, the vars directory stores variables. In the tasks directory, you have main.yml, which is the main playbook. The templates directory is for storing Jinja templates. The handlers directory is for storing handlers.

Advantages of Ansible roles:

• Allow for content reusability
• Make large projects manageable

Ansible roles are structured directories containing sub-directories.

But did you know that Red Hat Enterprise Linux also provides some Ansible System Roles to manage operating system tasks?

System roles

The rhel-system-roles package is available in the Extras (EPEL) channel. The rhel-system-roles package is used to configure RHEL hosts. There are seven default rhel-system-roles available:

• rhel-system-roles.kdump - This role configures the kdump crash recovery service. Kdump is a feature of the Linux kernel and is useful when analyzing the cause of a kernel crash.
• rhel-system-roles.network - This role is dedicated to network interfaces. This helps to configure network interfaces in Linux systens.
• rhel-system-roles.selinux - This role manages SELinux. This helps to configure the SELinux mode, files, port-context, etc.
• rhel-system-roles.timesync - This role is used to configure NTP or PTP on your Linux system.
• rhel-system-roles.postfix - This role is dedicated to managing the Postfix mail transfer agent.
• rhel-system-roles.firewall - As the name suggests, this role is all about managing the host system's firewall configuration.
• rhel-system-roles.tuned - Tuned is a system tuning service in Linux to monitor connected devices. So this role is to configure the tuned service for system performance.

The rhel-system-roles package is derived from open source Linux system-roles. This Linux-system-role is available on Ansible Galaxy. The rhel-system-roles is supported by Red Hat, so you can think of this as if rhel-system-roles are downstream of Linux system-roles. To install rhel-system-roles on your machine, use:

$ sudo yum -y install rhel-system-roles
or
$ sudo dnf -y install rhel-system-roles

These roles are located in the /usr/share/ansible/roles/ directory. 

This is the default path, so whenever you use playbooks to reference these roles, you don’t need to explicitly include the absolute path. You can also refer to the documentation for using Ansible roles. The path for the documentation is /usr/share/doc/rhel-system-roles

The documentation directory for each role has detailed information about that role. For example, the README.md file is an example of that role, etc. The documentation is self-explanatory.

The following is an example of a role.

Example

If you want to change the SELinux mode of the localhost machine or any host machine, then use the system roles. For this task, use rhel-system-roles.selinux

For this task the ansible-playbook looks like this:

---

- name: a playbook for SELinux mode
 hosts: localhost
 roles:

- rhel-system-roles.selinux
 vars:

- selinux_state: disabled

After running the playbook, you can verify whether the SELinux mode changed or not.

[ Looking for more on system automation? Get started with The Automated Enterprise, a free book from Red Hat. ] 

Wrap up

This brief introduction to Ansible roles should be enough to get you started using them in your playbooks. Remember that Ansible is meant to streamline and simplify those repetitive tasks and to make your sysadmin life easier.