For a production Ubuntu fleet, use Ansible to define and apply a deliberate package policy, and AWX to stage, approve, and audit its execution. Validate on a small cohort before promotion; schedule service restarts and reboots explicitly; and treat application health—not a successful SSH reconnect—as the test for a good patch run. Keep Ubuntu’s unattended updates in view too: an AWX workflow does not, by itself, prevent them from acting independently.
Decide what “patching” means for your fleet
Before creating a job, record the Ubuntu releases and repository origins in scope, the packages you intend to update, the maintenance window, and who may authorize disruptive actions. A security-only policy is not the same as upgrading all installed packages, and neither is the same as a distribution upgrade. Make the playbook’s behavior match the policy rather than relying on an ambiguous label such as “patch.”
As an Amazon Associate I earn from qualifying purchases.
- Scope: Identify whether the run is limited to security fixes or includes other available package updates. Decide how package holds and exceptional packages are handled; review exceptions rather than treating a permanent exclusion list as a patch strategy.
- Sources: Ubuntu’s default
unattended-upgradesconfiguration uses official archive origins and, where available, ESM origins. Third-party repositories and PPAs need separate configuration. Review which origins each host actually uses before assuming a policy covers them. Ubuntu’s automatic updates documentation explains the unattended-upgrades configuration. - Ownership and overlap: Decide whether AWX owns a particular maintenance run and whether unattended-upgrades continues operating separately. An AWX job does not automatically disable or coordinate with unattended updates; detect or prevent overlaps using your operational controls.
- Disruption: Set when service restarts may occur and who approves reboots. Avoid assuming that a package task is harmless simply because it does not explicitly invoke a reboot.
Ubuntu backports security fixes for supported releases rather than generally introducing new features through security updates. Support varies by release and repository component—Main, Restricted, Universe, or Multiverse—so verify coverage for the packages and release in your fleet. Ubuntu Pro’s Expanded Security Maintenance (ESM) and Canonical Livepatch address different needs; neither should be treated as a blanket substitute for normal package maintenance. Ubuntu Security’s update guidance and Ubuntu Pro’s service overview describe the relevant support context.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Build the Ansible update job around an explicit policy
The ansible.builtin.apt module provides explicit controls for refreshing package metadata and selecting an upgrade operation. For example, the task below refreshes the cache when it is older than an hour and requests the module’s dist upgrade mode, documented as apt-get dist-upgrade. That is a broader package operation, not a security-only guarantee. The cache age is an example configuration value; choose one that fits your repository and maintenance practices. fail_on_autoremove makes the task fail rather than proceed when the operation would remove packages.
#1 Best Overall
- name: Refresh metadata and apply the approved package scope
ansible.builtin.apt:
update_cache: true
cache_valid_time: 3600
upgrade: dist
fail_on_autoremove: trueUse this only if a distribution-style upgrade is the intended scope. Select and test the operation that matches your policy; do not infer “security-only” behavior from upgrade: dist or from state: latest. Review the current ansible.builtin.apt module documentation for the semantics of the options used by your playbook and Ansible version.
Check mode is useful for previewing changes when the relevant tasks support it, but it is a prediction aid—not a compatibility test. It does not prove that an application will work after package changes or simulate a real reboot. Test the playbook on a representative non-production host as well.
ansible-playbook patch-ubuntu.yml --check --diff --limit ubuntu_patch_canaryThis command is an Ansible CLI example for a canary inventory group; it does not launch an AWX job. Review the proposed changes, then run the actual update through the chosen execution path during the approved window.
Validate access and target membership before changing packages
Make preflight a distinct stage so that a bad inventory, credential, or privilege-escalation setup fails before package tasks begin. Confirm that the selected hosts are the intended Ubuntu systems, are reachable, and report expected releases. Keep credentials in AWX credential objects and limit who can launch jobs according to operational responsibility.
- Check inventory membership and the project revision or source selected for the run.
- Confirm connectivity, credentials, privilege escalation, and expected Ubuntu versions.
- Review the check-mode prediction and test a representative host outside production.
- Retain AWX job results so the operator can establish which project, inventory, and hosts were used.
AWX distinguishes job-template permissions from workflow permissions, so check the access rules for both when a workflow can launch maintenance. The details should be verified against the AWX version in use; the workflow and template references here are for AWX 24.6.1. AWX 24.6.1 job templates
Stage the rollout as an AWX workflow
In AWX 24.6.1, a workflow can connect job templates, other workflow templates, project syncs, and inventory syncs. Model patching as a chain of independently visible stages rather than one fleet-wide task: preflight, a limited first cohort, subsequent service or regional cohorts, reboot handling where required, and post-run validation. The AWX workflow graph records the run and constituent job statuses; it does not decide what “healthy” means for your application. See the AWX 24.6.1 workflows guide and workflow template guide.
- Preflight: Sync or select the intended project and inventory, validate hosts and access, then stop the workflow if checks fail.
- First cohort: Target a deliberately limited, low-risk set of hosts. Choose its size according to redundancy, service criticality, maintenance windows, and recovery capability; there is no universal safe batch size.
- Promotion: Define success and failure paths. Promote only after the actual service and fleet checks pass. Investigate failed hosts before retrying rather than automatically treating them as ordinary successes.
- Later cohorts: Run subsequent groups in the order that matches service dependencies and regional or maintenance boundaries.
- Reboot and validation: Keep reboot handling and health checks visible stages. Where the service supports it, drain a node from traffic before patching and return it only after application-level checks pass.
AWX workflow behavior and permissions are version-sensitive. The cited interface documentation is specifically for AWX 24.6.1; confirm labels and capabilities against the version deployed in your environment.
Plan for service restarts as well as host reboots
Package updates can require affected services to restart. On Ubuntu 24.04 LTS and later, needrestart restarts affected services automatically by default, with configured exceptions. That behavior can interrupt a critical workload outside its intended maintenance window. Decide how service restarts will be handled before rollout; if needed, configure exceptions using supported drop-in mechanisms, or block a known problematic package only when there is a sound operational reason. Do not confuse an unattended-upgrades reboot setting with service-restart behavior: Ubuntu’s unattended-upgrades reboot setting defaults to false, while package-triggered service restarts are a separate concern. Ubuntu’s automatic updates documentation
When an approved update requires a reboot, make it an explicit workflow stage and use a timeout appropriate to the host and its update workload. For example, after deciding that rebooting the selected hosts is authorized, a separate play can check for Ubuntu’s reboot-required marker and call the reboot module:
- name: Reboot approved hosts when an update requires it
hosts: ubuntu_patch_canary
become: true
tasks:
- name: Check whether a reboot is required
ansible.builtin.stat:
path: /var/run/reboot-required
register: reboot_required
- name: Reboot and wait for the host to return
ansible.builtin.reboot:
reboot_timeout: 1800
when: reboot_required.stat.existsThe 1,800-second timeout above is an example, not a fleet-wide recommendation. The reboot module waits for the host to go down and become responsive again; its timeout applies separately to reboot detection and test-command success, so total elapsed time can be up to twice the configured value. Choose the timeout based on observed host behavior and the workload being updated. A responsive host or recovered SSH connection is not proof that its application is healthy. Consult the ansible.builtin.reboot documentation for the module’s current options and timeout semantics.
Verify the service and record exceptions
After each cohort, verify both the operating-system result and the outcome that matters to the service. Capture the AWX workflow result and per-host package task outcomes, then check that systems are on the intended release and expected packages changed. Where relevant, inspect reboot-required state, service status, application health, monitoring, and load-balancer membership.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors- Confirm the intended hosts ran the intended package operation.
- Check service-specific health indicators and monitoring before restoring a node to traffic.
- Record failed hosts and exceptions in the compliance view; do not silently skip them.
- Use rollout results to adjust cohort order, maintenance windows, and reboot timeouts.
Keep conventional kernel maintenance in the plan
Canonical Livepatch covers high- and critical-severity kernel vulnerabilities without rebooting and is part of Ubuntu Pro. It can narrow the interval before applicable kernel fixes are installed, but it does not cover every kernel issue or replace normal kernel updates. Ubuntu Pro documentation says to keep using normal tools to install available standard kernel updates, including fixes outside Livepatch’s scope. Plan conventional kernel upgrades and the reboots they require alongside Livepatch coverage. See Canonical’s Livepatch documentation and Ubuntu Pro’s service overview.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
