Ansible Firefighting Hotline Series (10): Automating Linux Network Configuration with RHEL-system-roles.network

Ansible Firefighting Hotline Series (10): Automating Linux Network Configuration with rhel-system-roles.network

#Linux #Automation #Ansible #Network #NetworkManagement #NetworkConfigurationAutomation

🔥 Say Goodbye to Complexity! Why is Network Configuration in Need of Automation?

Dear operations engineers, SREs, and cloud engineers, please recall these moments that give us headaches:

•New Machine Setup 🤯: Dozens of new servers arrive, and you need to log in one by one, typing repetitive nmcli commands to configure static IPs, gateways, and DNS. The process is long and prone to errors. A single incorrect IP can lead to the failure of the entire application deployment.•Bulk Changes ☕️->🥶: Suddenly notified, “All servers need to change their backup DNS!”. What was once a leisurely afternoon tea time instantly turns into a “copy-paste competition” across dozens or even hundreds of terminal windows.•Inconsistent Environments 😵💫: The network configurations of development, testing, and production environments always have subtle differences, relying on documentation and memory to maintain them is a disaster. The lack of standardized configurations lays countless hidden dangers for failures.

In the era of cloud and automation, manual network configuration is synonymous with inefficiency and risk. It is not only repetitive labor but also the enemy of stability.

Today, we will put an end to this chaos! This article will guide you in using the Red Hat Ansible Automation Platform (or the community version of Ansible) to build a modular, precisely controlled NetworkManager management role, upgrading network configuration from a “manual workshop” to an “automated assembly line”, allowing you to easily handle network change requirements of any scale!✨

✨ The Art of Design: Why We Build Automation This Way?

An excellent automation solution should not only work but also be user-friendly and easy to extend. Our design strictly follows the best practices of enterprise-level automation, with core advantages including:

•Declarative “Final State” Management 🎯 You no longer need to write step-by-step operation scripts. Instead, you only need to declare your desired network final state in a centralized variable file (host_vars) like filling out a configuration checklist—such as “I need a connection named static-ens10 with IP xxx and DNS yyy”. Ansible will automatically analyze the differences between the current state and the desired state and execute the necessary operations accurately.•Functional Modularity and Logical Decoupling 🧩 We split different operations (viewing, adding, modifying, deleting, controlling) into independent task files. The benefits of this approach are:•Single Responsibility🧩 Each file does one thing, making the code logic extremely clear and easy to maintain and debug.•Flexible Combination🧩configure_network_role.yml becomes the master controller, allowing you to enable various functional modules as needed, like building with Legos.•Precise Execution through Tags🧩 This is the highlight of this solution! We have tagged each type of operation (pre_check, apply_config, post_check, etc.). This means you can fully control the behavior of the Playbook from the command line:•Want to inspect?--pre_check<code>•Want to deploy new configurations?<code>--tags apply_config•This mode transforms Ansible from a "full execution" tool into a Swiss Army knife that canexecute precisely on demand, completely eliminating the risk of misoperation.<h3>✨ Ansible Official Tool: <code>rhel-system-roles.network Introduction

rhel-system-roles is a set of Ansible roles included in Red Hat Enterprise Linux 8 (in CentOS 8 it is called linux-system-roles), developed and maintained by Red Hat, aimed at providing a stable and consistent system management automation interface.rhel-system-roles.network is the role specifically responsible for network configuration, considered the easiest way to configure network settings on managed hosts.

🤩 Its core benefits include:

•Abstraction and Simplification: You do not need to worry about whether the underlying system is RHEL 7, 8, or 9, nor do you need to memorize complex nmcli commands. You only need to describe your desired network configuration through a variable called network_connections.•Idempotency Guarantee: The role has built-in state-checking logic. If you run the Playbook repeatedly, it will only apply necessary changes, skipping configurations that already meet the expected state, ensuring the safety and predictability of the automation process.•Comprehensive Functionality: In addition to simple static/DHCP configurations, it also natively supports advanced features such as network bonding, teaming, VLAN, MACVLAN, etc.•Official Support: As part of RHEL, this role has been thoroughly tested and supported by Red Hat, making it the preferred choice for enterprise production environments.

The Ansible Role is applicable to the following operating system versions::

•✅ Red Hat Enterprise Linux (RHEL) 7.4+, 8, 9•✅ CentOS 7, 8 Stream, 9 Stream•✅ Rocky Linux 8, 9•✅ AlmaLinux 8, 9•✅ Oracle Linux 7, 8, 9

🚀 Getting Started from Scratch: Three Steps to Deploy Your Linux Network Configuration Automation Tool

Don’t worry about complexity; I have prepared all the steps for you. You just need to copy and paste to have this powerful tool!

Prerequisites 📋

•💻 Control Node: A computer with Ansible installed and the rhel-system-roles package installed (sudo yum install rhel-system-roles).•🖥️ Managed Node: A Linux server with Network Manager, and the control node can SSH into it without a password.

🚀 Deployment and Execution: Complete Automation in Three Steps

Step 1: 📁 Create Project Directory and All Files

A clear directory structure is the beginning of good practice. We will create all necessary files and directories.

Execute the following command to create the directory structure::

# Create the main project directory
mkdir network_role_project
cd network_role_project

# Create directories for storing host variables
mkdir -p host_vars/Test-RHEL-7.9-2/network_config.yml
mkdir -p host_vars/Test-RHEL-7.9-3/network_config.yml
mkdir -p host_vars/Test-RHEL-7.9-4/network_config.yml

Your directory structure now looks like this:

[root@ansible25 network_role_project]# tree
.
├── ansible.cfg
├── configure_network_role.yml
├── group_vars
│   └── web_network_servers
│       └── common_config.yml
├── host_vars
│   ├── Test-RHEL-7.9-2
│   │   └── network_config.yml
│   ├── Test-RHEL-7.9-3
│   │   └── network_config.yml
│   └── Test-RHEL-7.9-4
│       └── network_config.yml
└── inventory

Create the inventory file

•Purpose: To inform Ansible on which hosts to perform operations.•Location: network_role_project/inventory•Content:

[network_servers]
Test-RHEL-7.9-2
Test-RHEL-7.9-3
Test-RHEL-7.9-4

Create a Network Blueprint for Target Machine “Server1”

•Purpose: To define the expected network state for server1.•Location: network_role_project/host_vars/Test-RHEL-7.9-2/network_config.yml•Content:

    ---
    # Define network connection for server1 in this file
    network_connections:
      - name: static-ens192
        interface_name: ens192
        type: ethernet
        state: up
        autoconnect: yes
        ip:
          address:
            - "10.71.18.251/23"
          gateway4: "10.71.19.254"
          dns:
            - 10.72.17.5
            - 10.68.5.26
          dns_search:
            - szx.redhat.com
            - redhat.com

Create a Network Blueprint for Target Machine “Server2”

•Purpose: To define the expected network state for server2.•Location: network_role_project/host_vars/Test-RHEL-7.9-3/network_config.yml•Content:

    ---
    # Define network connection for server2 in this file
    network_connections:
      - name: static-ens192
        interface_name: ens192
        type: ethernet
        state: up
        autoconnect: yes
        ip:
          address:
            - "10.71.18.252/23"
          gateway4: "10.71.19.254"
          dns:
            - 10.72.17.5
            - 10.68.5.26
          dns_search:
            - szx.redhat.com
            - redhat.com

Create the configure_network_role.yml Main Execution Playbook

•Purpose: This is the only Playbook you need to run, responsible for calling the role and executing validation tasks.•Location: network_role_project/configure_network_role.yml•Content:

---
- name: Configure network using rhel-system-roles.network
  hosts: network_servers
  become: true

  tasks:
    - name: "Before applying configuration - List network interfaces and basic information"
      ansible.builtin.debug:
        msg: |
          List of network interfaces for host {{ inventory_hostname }}: {{ ansible_facts.interfaces }}
          Default IPv4 interface information:
            Address: {{ ansible_facts.default_ipv4.address | default('N/A') }}
            Gateway: {{ ansible_facts.default_ipv4.gateway | default('N/A') }}
      tags: [pre_check]

    - name: "Apply rhel-system-roles.network role"
      ansible.builtin.include_role:
        name: rhel-system-roles.network
      tags: [apply_config]

    - name: "Refresh host facts to get the latest network status"
      ansible.builtin.setup:
        gather_subset:
          - network
      tags: [post_check]

    - name: "After applying configuration - Confirm and print detailed configuration of eth/ens xx"
      ansible.builtin.debug:
        msg: |
          Configuration applied!
          Current IPv4 configuration for interface 'eth1':
          Address: {{ ansible_facts.eth1.ipv4.address }}
          Subnet Mask: {{ ansible_facts.eth1.ipv4.netmask }}
          Gateway: {{ ansible_facts.default_ipv4.gateway }}
      when: "'eth1' in ansible_facts.interfaces"
      tags: [post_check]

Step 2: 🚀 Execute Automation

Everything is ready! Now, ensure you are in the network_role_project directory, and then execute your Playbook!

# ansible-playbook -i inventory configure_network_role.yml

Step 3: 📊 Interpret Output Results

Ansible will show you a clear execution process:

1Gathering Facts: Ansible first collects basic information from all servers.2Before applying configuration – Confirm network interfaces exist: pre_check task will run, and if there are no eth/ensX interfaces on the server, it will report an error and prompt you.3Apply rhel-system-roles.network role: The core role begins execution. If the server’s network configuration does not match your “blueprint”, you will see a changed status here. If it already matches, it will intelligently skip, showing ok.4Refresh host facts: Recollect network information to ensure we are verifying the latest state.5After applying configuration – Verify if eth/ensX IP address is correct: post_check task will run and provide the final verification result. If everything goes smoothly, you will see a success message like below:

    TASK [Refresh host facts to get the latest network status] 
    ************
    ok: [Test-RHEL-7.9-2]

    TASK [After applying configuration - Confirm and print detailed configuration of eth/ens xx] 
    ************
    ok: [Test-RHEL-7.9-2]

Advanced Tips: Use Tags for Precise Control

In complex operational scenarios, we do not always need to run the entire Playbook. Sometimes we just want to perform a pre-configuration check, sometimes we only want to apply core changes, and sometimes we just want to do a post-configuration verification. Ansible’s Tags feature is designed for this purpose.

🚀 Precise Execution and Output Interpretation

Now, you can use the --tags (or -t) command line parameter to precisely call the parts you want to execute.

Scenario A: Check Only Without Applying (Safety Inspection)

Suppose you only want to check whether the ethX/ensX interfaces exist on the server, but do not apply any network changes.

•Execute Command:

ansible-playbook -i inventory configure_network_role.yml --tags pre_check

•Expected Output: You will see the Playbook only runs tasks with the pre_check tag, and then it will end directly. The core apply_config and post_check tasks will be completely skipped.

    PLAY [Configure network using rhel-system-roles.network] 
    ***************
    TASK [Gathering Facts] 
    ***************
    ok: [Test-RHEL-7.9-2]
    TASK [Before applying configuration - List network interfaces and basic information] 
    ***************
    ok: [Test-RHEL-7.9-2] =&gt;
      msg: |-
        List of network interfaces for host Test-RHEL-7.9-2: ['lo', 'ens192']
        Default IPv4 interface information:
          Address: 10.71.18.251
          Gateway: 10.71.19.254
    PLAY RECAP
    ***************
    Test-RHEL-7.9-2: ok=2 changed=0 unreachable=0 failed=0  ...

Scenario B: Apply Only Without Checking (Quick Deployment)

Suppose you are very sure the configuration is correct and just want to quickly apply the configuration in host_vars, skipping all checks to save time.

•Execute Command:

ansible-playbook -i inventory configure_network_role.yml --tags apply_config

•Expected Output: The Playbook will skip pre_check, directly running the apply_config task to configure the network, and then end, with post_check also skipped.

    PLAY [Configure network using rhel-system-roles.network] 
    ***************

    TASK [Gathering Facts] 
    ***************
    ok: [Test-RHEL-7.9-2]

    TASK [Apply rhel-system-roles.network role] 
    ***************
    PLAY RECAP
    ***************
    Test-RHEL-7.9-2: ok=1 changed=0 unreachable=0 failed=0  ...

Scenario C: Apply and Verify (Common CI/CD Pattern)

This is the most common pattern: execute changes and then immediately verify whether the changes were successful.

•Execute Command:

ansible-playbook -i inventory configure_network_role.yml --tags apply_config,post_check

•Expected Output: The Playbook will skip pre_check, execute apply_config to make changes, and thencontinue executingpost_check task to verify if the IP address is configured correctly and output the final success message.

    PLAY [Configure network using rhel-system-roles.network] 
    ***************

    TASK [Gathering Facts] 
    ***************
    ok: [Test-RHEL-7.9-2]

    TASK [Apply rhel-system-roles.network role] 
    ***************

    TASK [Refresh host facts to get the latest network status] 
    ***************
    ok: [Test-RHEL-7.9-2]

    TASK [After applying configuration - Confirm and print detailed configuration of eth/ens xx] 
    ***************
    skipping: [Test-RHEL-7.9-2]

    PLAY RECAP
    ***************
    Test-RHEL-7.9-2: ok=2 changed=0 unreachable=0 failed=0  ...

In this way, the same Playbook can flexibly respond to various operational scenarios, greatly enhancing its practicality and professionalism.

Congratulations! You have successfully used Ansible’s official best practices to complete network automation configuration and verification for multiple servers!

Summary and Resources

Through Red Hat’s official rhel-system-roles.network, we have achieved a highly reliable and efficient network automation method. This declarative, data-driven model is the core idea of modern automated operations.

Are you eager to deploy it in your environment?

To avoid any omissions while copying the code, we have packaged the complete project containing all categorized and filled code for you!

🎁 Click the link below to 【Read the Original】 (best viewed on a computer), and download the complete source code to add an officially certified “tool” to your operations toolbox!👇👇👇