Chapter 12. Using Ansible roles to permanently configure kernel parameters

As an experienced user with good knowledge of Red Hat Ansible Engine, you can use the kernel_settings role to configure kernel parameters on multiple clients at once. This solution:

  • Allows usage of external dependencies.
  • Provides a friendly interface with efficient input setting.
  • Keeps all intended kernel parameters in one place.

After you run the kernel_settings role from the control machine, the kernel parameters are applied to the managed systems immediately and persist across reboots.

12.1. Introduction to the kernel settings role

RHEL System Roles is a collection of roles and modules from Ansible Automation Platform that provide a consistent configuration interface to remotely manage multiple systems.

RHEL System Roles were introduced for automated configurations of the kernel using the kernel_settings system role. The rhel-system-roles package contains this system role, and also the reference documentation.

To apply the kernel parameters on one or more systems in an automated fashion, use the kernel_settings role with one or more of its role variables of your choice in a playbook. A playbook is a list of one or more plays that are human-readable, and are written in the YAML format.

You can use an inventory file to define a set of systems that you want Ansible Engine to configure according to the playbook.

With the kernel_settings role you can configure:

  • The kernel parameters using the kernel_settings_sysctl role
  • Various kernel subsystems, hardware devices, and device drivers using the kernel_settings_sysfs role
  • The CPU affinity for the systemd service manager and processes it forks using the kernel_settings_systemd_cpu_affinity role
  • The kernel memory subsystem transparent hugepages using the kernel_settings_transparent_hugepages and kernel_settings_transparent_hugepages_defrag roles

Additional resources

  • For a detailed reference on kernel_settings role variables and for the example playbooks, install the rhel-system-roles package, and see the README.md and README.html files in the /usr/share/doc/rhel-system-roles/kernel_settings/ directory.
  • For more information about playbooks, see Working with playbooks in Ansible documentation.
  • For more information on creating and using inventories, see How to build your inventory in Ansible documentation.

12.2. Applying selected kernel parameters using the kernel settings role

Follow these steps to prepare and apply an Ansible playbook to remotely configure kernel parameters with persisting effect on multiple managed operating systems.

Prerequisites

  • Your Red Hat Ansible Engine subscription is attached to system, also called control machine, from which you want to run the kernel_settings role. See the How do I download and install Red Hat Ansible Engine article for more information.
  • Ansible Engine repository is enabled on the control machine.
  • Ansible Engine is installed on the control machine.

    Note

    You do not need to have Ansible Engine installed on the systems, also called managed hosts, where you want to configure the kernel parameters.

  • The rhel-system-roles package is installed on the control machine.
  • An inventory of managed hosts is present on the control machine and Ansible Engine is able to connect to them.

Procedure

  1. Optionally, review the inventory file for illustration purposes:

    #  cat /home/jdoe/<ansible_project_name>/inventory
    [testingservers]
    pdoe@192.168.122.98
    fdoe@192.168.122.226
    
    [db-servers]
    db1.example.com
    db2.example.com
    
    [webservers]
    web1.example.com
    web2.example.com
    192.0.2.42

    The file defines the [testingservers] group and other groups. It allows you to run Ansible Engine more effectively against a specific collection of systems.

  2. Create a configuration file to set defaults and privilege escalation for Ansible Engine operations.

    1. Create a new YAML file and open it in a text editor, for example:

      #  vi /home/jdoe/<ansible_project_name>/ansible.cfg
    2. Insert the following content into the file:

      [defaults]
      inventory = ./inventory
      
      [privilege_escalation]
      become = true
      become_method = sudo
      become_user = root
      become_ask_pass = true

      The [defaults] section specifies a path to the inventory file of managed hosts. The [privilege_escalation] section defines that user privileges be shifted to root on the specified managed hosts. This is necessary for successful configuration of kernel parameters. When Ansible playbook is run, you will be prompted for user password. The user automatically switches to root by means of sudo after connecting to a managed host.

  3. Create an Ansible playbook that uses the kernel_settings role.

    1. Create a new YAML file and open it in a text editor, for example:

      #  vi /home/jdoe/<ansible_project_name>/kernel_roles.yml

      This file represents a playbook and usually contains an ordered list of tasks, also called plays, that are run against specific managed hosts selected from your inventory file.

    2. Insert the following content into the file:

      ---
      - name: Configure kernel settings
        hosts: testingservers
      
        vars:
          kernel_settings_sysctl:
            - name: fs.file-max
              value: 400000
            - name: kernel.threads-max
              value: 65536
          kernel_settings_sysfs:
            - name: /sys/class/net/lo/mtu
              value: 65000
          kernel_settings_transparent_hugepages: madvise
      
        roles:
          - linux-system-roles.kernel_settings

      The name key is optional. It associates an arbitrary string with the play as a label and identifies what the play is for. The hosts key in the play specifies the hosts against which the play is run. The value or values for this key can be provided as individual names of managed hosts or as groups of hosts as defined in the inventory file.

      The vars section represents a list of variables containing selected kernel parameter names and values to which they have to be set.

      The roles key specifies what system role is going to configure the parameters and values mentioned in the vars section.

      Note

      You can modify the kernel parameters and their values in the playbook to fit your needs.

  4. Optionally, verify that the syntax in your play is correct.

    #  ansible-playbook --syntax-check kernel-roles.yml
    
    playbook: kernel-roles.yml

    This example shows the successful verification of a playbook.

  5. Execute your playbook.

    #  ansible-playbook kernel-roles.yml
    BECOME password:
    
    PLAY [Configure kernel settings]  ... PLAY RECAP **
    fdoe@192.168.122.226       : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0
    pdoe@192.168.122.98        : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0

    Before Ansible Engine runs your playbook, you are going to be prompted for your password and so that a user on managed hosts can be switched to root, which is necessary for configuring kernel parameters.

    The recap section shows that the play finished successfully (failed=0) for all managed hosts, and that 4 kernel parameters have been applied (changed=4).

  6. Restart your managed hosts and check the affected kernel parameters to verify that the changes have been applied and persist across reboots.

Additional resources

  • For more information about RHEL System Roles, see Getting started with RHEL System Roles.
  • For more information about all currently supported variables in kernel_settings, see README.html and README.md files in the /usr/share/doc/rhel-system-roles/kernel_settings/ directory.
  • For more details about Ansible inventories, see Working with Inventory in Ansible documentation.
  • For more details about Ansible configuration files, see Configuring Ansible in Ansible documentation.
  • For more details about Ansible playbooks, see Working With Playbooks in Ansible documentation.
  • For more details about Ansible variables, see Using Variables in Ansible documentation.
  • For more details about Ansible roles, see Roles in Ansible documentation.