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 ]
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.
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?
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.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.
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
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
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.
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
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. ]
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.