Red Hat Satellite 6 Administration

Ansible Roles help with reuse of generic Ansible code. You can package tasks, variables, files, templates, and other resources into a role to provision infrastructure or to deploy applications. The resulting Ansible Role is a standardized directory structure that you can reuse by copying the directory to other systems. You can then execute that role from an Ansible Playbook.

Reusable, modular roles use passed-in playbook variables. Variables can modify the behavior of a role by setting site-specific hostnames, IP addresses, usernames, secrets, and other locality-specific details. For example, an Ansible Role could use variables for the host name, a database administrative user and password, and other environment-specific parameters to deploy a database. The role author can set appropriate default variable values to work with playbooks that might not set the variables.

The following list shows some benefits of using Ansible Roles to manage hosts:

An Ansible Role is defined by a standardized structure of subdirectories and files. The top-level directory defines the name of the role itself. Files are organized into subdirectories that are called according to each file's purpose in the role, such as tasks or handlers. The files and templates subdirectories contain files that tasks in other YAML files reference.

The following tree command displays the directory structure of the user.example role.

[user@host roles]$ tree user.example
user.example/
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

Ansible searches these directories for relevant content. All these directories are optional.

Role variables are defined in the vars/main.yml file by using key-value pairs. The variables are referenced in the role YAML file and they have the {{ VAR_NAME }} format. These variables have a high precedence, and inventory variables cannot override them. You must use these variables to control the internal role functions.

You create default variables to set initial values that configure a role or customize its behavior. These variables are defined in the defaults/main.yml file with key: value pairs in the role directory hierarchy.

Default variables have the lowest precedence and are meant to be overridden by other variables, including inventory variables. These variables are intended for a playbook author to customize or control how a role or playbook behaves. Variables can provide information to the role to configure or deploy objects correctly. Use either vars/main.yml or defaults/main.yml, but not both, to define a specific variable.

The recommended time synchronization service for Red Hat Enterprise Linux 7 and later is the chronyd service. In Red Hat Enterprise Linux 6, however, the recommended service is the ntpd service. In an environment with a mixture of Red Hat Enterprise Linux 6 and 7 hosts, you must manage the configuration files for both services.

With RHEL system roles, you no longer need to maintain configuration files for both services. You can use the rhel-system-roles.timesync role to configure time synchronization for both Red Hat Enterprise Linux 6 and 7 hosts. A simplified YAML file with role variables defines the configuration of time synchronization for both types of hosts.

RHEL system roles are based on the open-source Linux System Roles project, on Ansible Galaxy. Unlike Linux system roles, Red Hat supports RHEL system roles as part of a standard Red Hat Enterprise Linux subscription. RHEL system roles have the same lifecycle support benefits as a Red Hat Enterprise Linux subscription.

Some RHEL system roles are in Technology Preview status. This status means that the role is tested and stable, but the role interface might be updated in the future, to become incompatible with the current version. Red Hat recommends that you run integration tests for playbooks that incorporate any Technology Preview role.

The Fully Supported system roles also have stable interfaces. For any Fully Supported system role, Red Hat endeavors to ensure that role variables remain unchanged in later versions. Playbook refactoring due to system role changes should be minimal.

Other roles are in development in the upstream Linux System Roles project, and are not yet available through a RHEL subscription. These roles are available through Ansible Galaxy.

You can install and import Red Hat Enterprise Linux system roles into Satellite. To install the rhel-system-roles packages, ensure that the Server Extras repository is enabled in the system.

[root@satellite ~]# subscription-manager repos \
--enable=rhel-7-server-extras-rpms
Repository 'rhel-7-server-extras-rpms' is enabled for this system.
[root@satellite ~]# satellite-maintain packages install rhel-system-roles
...output omitted...
  Success!
...output omitted...

This command installs the system roles in the /usr/share/ansible/roles directory. You can review and customize the roles before you import them into Satellite or Capsule, depending on where you want to use them. When you are ready to import the system roles, follow the same steps as the custom roles to import them. The system roles have a name with the linux-system-roles.role_name format.

With a role is imported into Satellite and assigned to a host, it is available to run on that host.