5 steps to consistently patch RHEL and Windows systems

Staying on top of patching Red Hat Enteprise Linux (RHEL) and Windows systems can be time-consuming and error-prone. Unpatched systems can create security issues and disrupt your critical business operations. To complicate matters, Windows administrators and Linux administrators often don't speak the same "language," which can create friction between teams and delay essential patch processes. 

By using Red Hat Ansible Automation Platform for automated patch management of both RHEL and Windows in a single workstream, you can ensure even more consistency and operational efficiency in your environment by making patching repeatable and predictable. Through automation, you can ensure your servers are secure and compliance mandates are satisfied, giving your teams valuable time back in their day. This integrated approach is illustrated in Figure 1.

When patch management is treated as code, it establishes a single pipeline for both operating systems and a solid foundation for integration with ITSM systems, observability tools, as well as AIOps workflows. By adding visual dashboards, you can turn raw data into actionable compliance insights, providing more clarity and control over the patching process.

Let's get started. 

Step 1: Build a centralized inventory

To begin, create an Ansible Playbook that collects a complete inventory of every managed RHEL and Windows server using Ansible's dynamic inventory plug-ins (Figure 2). 

In the following example, we're pulling live host data from Azure and your CMDB, but you could easily expand this to include VMware, AWS, OpenShift Virtualization, or Google Cloud. Click here to access the entire module.

---
- name: Pull live host data from Azure
  hosts: all
  tasks:
    - name: Pull live host data from Azure
      register: azure_hosts
      azure.azcollection.azure_rm_virtualmachine_info:
        resource_group: resource_group_name
        name: vm_name

We can use an intelligent classification by OS, environment, and maintenance window using tagging and the keyed_group directive. Note the use of tags to separate and label servers which will allow you to run Ansible Playbooks for specific operating systems. You can reference these groups in other playbooks. 

This is an example of keyed_groups:

---
keyed_groups:
  - key: platform_details | lower | regex_replace(" ", "_")
    prefix: os

In this example, you will create groups based on the platform_details information the AWS EC2 inventory plug-in retrieves. For instance, you could sort your AWS infrastructure into groups using the platform_details key (see Figure 4):

• os_linux_unix
• os_red_hat_enterprise_linux
• os_windows
• and so on, based on the information AWS provides.

For more examples of keyed_groups, check out the examples in the inventory plug-in documentation for these popular public clouds: 

• AWS EC2 Guide
• Microsoft Azure inventory plug-in documentation
• Google Cloud inventory plug-in documentation

Step 2: Create job templates in Ansible Automation Platform 

Create a job template scheduled to run during an approved maintenance window for your organization. 

Step 3: Apply RHEL and Windows patches

Now you can apply the right patches in the correct order with built-in safety checks. For Linux systems, use the ansible.builtin.dnf or ansible.builtin.apt module. For Windows systems, leverage the Ansible Certified Content Collection for Windows using the win-updates module to limit updates and manage reboots. You can even incorporate snapshotting LVM volumes or pausing critical services for added security.  We can also, in either operating system case, employ block rescue logic. 

Here is an example playbook with safety checks:

---
- name: Cross-platform patching playbook with safety checks
  hosts: all
  become: true
  tasks:

    - name: Linux - Patch with snapshot and safety block
      when: ansible_os_family in ["RedHat", "Debian"]
      block:
        - name: Pause critical service (example: httpd or nginx)
          ansible.builtin.service:
            name: "{{ critical_service }}"
            state: stopped

        - name: Apply updates using DNF
          ansible.builtin.dnf:
            name: '*'
            state: latest
          when: ansible_os_family == "RedHat"

        - name: Apply updates using APT
          ansible.builtin.apt:
            upgrade: dist
            update_cache: true
          when: ansible_os_family == "Debian"

        - name: Start critical service
          ansible.builtin.service:
            name: "{{ critical_service }}"
            state: started

Step 4: Validate success and generate compliance reports

If there are issues with the configuration you applied in step 3, you can use automation to restore the device to its previous state. Create a "Restore patch backup" job template to revert any changes and load the backup you generated in step 1. 

The Ansible automation dashboard, which will be generally available in October, aggregates results of our automation and can be easily exported to a PDF so auditors can see which jobs executed and you can share your success with your team and manager. You can also create dynamic documentation to see specifically what CVEs were remediated and what applications were updated.

Bonus step: Apply patches based on events instead of schedules

Finally, with event-driven automation, you can advance beyond schedule-based patching during specific maintenance windows for even greater IT efficiency. Event-Driven Ansible can automatically initiate patching processes when specific triggers occur, such as the identification of a new vulnerability, a compliance notification, or the release of a critical patch. By acting upon events from monitoring tools and ITSM systems, Event-Driven Ansible can create a highly responsive and efficient patching workflow that adapts to the real-time needs of your environment.

Explore more advanced infrastructure automation use cases

As you expand your adoption of automation, the value and benefits actually increase while the amount of effort required to maintain your systems decrease. 

Once you have tackled these basic patch management tasks, you're ready to expand into more advanced forms of automation:

• Explore 5 great infrastructure automation use cases.
• Orchestrate existing these automation tasks into a seamless workflow.
• Implement event-driven server provisioning and free yourself from manual, time-consuming setup processes.
• Learn how to scale automation adoption across your organization.