Ansible Package Management
Package management is the most common thing a playbook does. There is a generic module that works anywhere and a specific one with all the options, a list form that is much faster than a loop, and a state that quietly makes your playbook non-idempotent. This covers all four, and how to ask a host what it has.
Automating Administration Guide 29 of 45 Beginner
- OSUbuntu 26.04 LTS
- ansible-core2.20.1
- Python3.14.4
- TimeAbout 15 min
This lab is Ubuntu 26.04 and EX294 is a RHEL exam. ansible.builtin.apt here is ansible.builtin.dnf there, and apt_repository is yum_repository. ansible.builtin.package works on both by dispatching on ansible_pkg_mgr, at the cost of the distribution-specific options.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| ANS-CTL01 | 192.168.0.36 | Ubuntu 26.04 LTS | Ansible Control Node | 2 Core | 3 GB | 50 GB |
| ANS-A01 | 192.168.0.37 | Ubuntu 26.04 LTS | Managed Node (group: web) | 2 Core | 3 GB | 50 GB |
This guide includes
Use this for the most common thing a playbook does. This matters because the generic package module reads a fact to pick the right one - and one state is not idempotent, which is a choice to make deliberately.
- installing something twice, and reading changed and then ok
- comparing the generic
packagemodule against the specific one - installing several packages in a single task
- asking what is installed, using package facts
Before you start
- A control node configured as shown in the first step, and a managed node with working package repositories.
- The session installs
tree,jqandncduon thewebhost and removes them.
-
The configuration this guide assumes
-
Install something, twice
-
The generic module versus the specific one
-
Several packages at once
-
Asking what is installed