Ansible is a free and open-source automation framework for configuration management, application deployment, and infrastructure orchestration. It is a well-liked automation tool among DevOps developers and system administrators. System administrators frequently experience burnout as a result of working long hours and doing repetitive operations on multiple systems, but Ansible makes these chores easier to complete.
An Ansible Course can be used to perform tasks such as user creation, service administration, and software installation. Ansible is a procedure-based rather than declarative system, which means you write all necessary steps into a YAML file and then run them sequentially on all target systems.
Ansible modules abstract system activities so you don’t have to worry about implementation specifics. You simply define the desired state, and Ansible guarantees that it is met by the target system. This module availability is one of Ansible’s primary advantages, and it is frequently referred to as Ansible having “batteries included.” While there are modules for a wide variety of activities, we frequently hear from newcomers that they don’t know where to begin.
Although the modules you choose will be entirely dependent on your needs and what you’re attempting to automate with Ansible, these are the top example modules you’ll need to get started with Ansible for Linux system automation.
You can use the copy module to copy a file from the Ansible control node to the destination hosts. It allows you to set ownership, rights, and SELinux labels to the target file in addition to copying it. This module is idempotent, which means it will only copy the file if the identical file with the same content and permissions is not already present.
The copy module is an excellent choice for copying a small number of files containing static content. Look at the synchronize module if you need to copy a big number of files. Next, look at the template module to copy files with dynamic content.
There is a controller node and managed nodes in the Ansible architecture. Only the controller node has Ansible installed. It is an agentless tool that does not require installation on managed nodes. The SSH protocol is used to connect the controller and managed nodes. Using the YAML language, all tasks are written into a “playbook.” Each playbook can contain many plays, each of which contains tasks, and each of which contains modules. Modules are standalone scripts that can be reused to manage a specific part of a system’s behavior. Modules in Ansible are sometimes known as task plugins or library plugins.
Playbooks for complex operations can become rather extensive, making them difficult to read and comprehend. Ansible roles are the solution to this problem. You can use roles to divide long playbooks into numerous files, making each playbook easy to read and comprehend. Templates, files, variables, modules, and tasks comprise roles. The basic goal of roles is to reuse Ansible code.
Engineers and sysadmins in DevOps should always aim to reuse their code. Ansible roles can have many playbooks. If the role is appropriate for a given scenario, it can readily reuse code created by anyone. For instance, you might create a playbook for Apache hosting and then reuse it by modifying the content of index.html to change parameters for another application or service.
Using the ansible-galaxy command, all files are created empty at first. As a result, depending on the work, you can make use of these directories. Variables, for example, are stored in the vars directory. The main playbook, main.yml, may be found under the tasks directory. The templates directory is where you’ll find Jinja templates. The handlers directory is used to store handlers.
Ansible roles have the following advantages
- Allow for the reuse of content.
- Make big jobs more doable.
- Ansible roles are hierarchical folders with subdirectories.
However, did you know that we have certain Ansible System Roles for managing operating system tasks?
Roles in the system
The package rhel-system-roles is available in the Extras (EPEL) channel. RHEL hosts are configured using the rhel-system-roles package. There are seven rhel-system-roles by default:
- rhel-system-roles.kdump – This role is responsible for configuring the kdump crash recovery service. Kdump is a Linux kernel feature that can be used to investigate the reason for a kernel crash.
- This role is dedicated to network interfaces. rhel-system-roles.network – This role is dedicated to network interfaces. This aids in the configuration of network interfaces on Linux systems.
- This role manages SELinux. rhel-system-roles.selinux – This role manages SELinux. This is useful for configuring the SELinux mode, files, port-context, and so on.
- rhel-system-roles.timesync – This role is used to configure your Linux system’s NTP or PTP.
- rhel-system-roles.postfix – This role is responsible for the administration of the Postfix mail transfer agent.
- rhel-system-roles.firewall – As the name implies, this role is responsible for controlling the firewall configuration on the host system.
- rhel-system-roles.tuned – Tuned is a Linux system tuning service for monitoring linked devices. As a result, this role is responsible for configuring the tuned service for system performance.
The rhel-system-roles package is based on the open-source Linux system-roles package. Ansible Galaxy supports this Linux-system-role. Red Hat supports rhel-system-roles, therefore think of it as if rhel-system-roles is a descendant of Linux system-roles. This is the default path for installing rhel-system-roles on your computer, so you don’t need to explicitly provide the absolute path whenever you use playbooks to reference these roles. You may also look up how to use Ansible roles in the manual. The documentation may be found in /usr/share/doc/rhel-system-roles.
Each position’s documentation directory contains thorough information about that role. The README.md file, for example, is an example of that role, and so on. The instructions are self-explanatory.
This brief overview of Ansible roles should be sufficient to get you started utilizing them in your playbooks. Remember that Ansible is designed to automate and simplify repetitive operations, making your life as an administrator easier.