Ansible archive and unarchive Modules
unarchive is built in; archive is not - it lives in community.general, which is the kind of asymmetry that costs marks. Both turn out to be properly idempotent, including the one that writes a tarball, which is not what most people expect.
Automating Administration Guide 36 of 45 Intermediate
- OSUbuntu 26.04 LTS
- ansible-core2.20.1
- Python3.14.4
- TimeAbout 15 min
unarchive needs the matching tool on the target - tar for tarballs, unzip for zips. A zip extraction on a minimal image fails for a missing unzip, not for anything to do with Ansible.
| 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 |
| ANS-B01 | 192.168.0.38 | Ubuntu 26.04 LTS | Managed Node (group: db) | 2 Core | 3 GB | 50 GB |
This guide includes
Use this when a directory has to be packaged or unpacked on a managed host. This matters because one of the two modules is built in and the other is not - and remote_src is what decides which machine the archive is read from.
- finding the two modules live in two different collections
- archiving a directory where it lives, on the managed node
- running it again and getting
changed=False - unpacking on the same host, where
remote_src: truedecides everything - going the other direction - pushing an archive from the control node, and what a zip needs
Before you start
- A control node configured as shown in the first step.
community.generalinstalled - it ships with theansiblepackage.
-
The configuration this guide assumes
-
Two modules, two collections
-
Something to archive
-
Archive it where it lives
-
Run it again
-
Unpack it on the same host
-
The other direction: a file from the control node
-
A zip, and what the target needs
-
Put the hosts back