This role helps with managing partitions, encrypted (LUKS) devices, LVM volume
groups, LVM volumes, filesystems and mountpoints from Ansible variables. Role variable
storage_config
defines a list of tasks which will be run by this role. Each task calls an Ansible module similar to
tasks in roles or playbooks except that only few keywords such as when
are supported. For
example, to create an ext4 primary partition on device /dev/sdb
, define variable storage_config
in
group_vars
or host_vars
as such:
storage_config:
- # Create ext4 primary partition on device /dev/sdb
community.general.parted:
device: /dev/sdb
fs_type: ext4
number: 1
state: present
When this role is executed, it will run all tasks listed in storage_config
one after another. When storage_config
includes meta: flush_handlers
and storage_reboot
evaluates to true
, then this role will reboot the system
immediately and continue with remaining tasks in storage_config
once the host has come up again. Once all tasks have
finished, if anything has changed and storage_reboot
evaluates to true
, then the system will be rebooted
automatically.
Tested OS images
- Cloud image (
amd64
) of Debian 10 (Buster) - Cloud image (
amd64
) of Debian 11 (Bullseye) - Cloud image (
amd64
) of Debian 12 (Bookworm) - Cloud image (
amd64
) of Debian 13 (Trixie) - Cloud image (
amd64
) of CentOS 7 (Core) - Cloud image (
amd64
) of CentOS 8 (Stream) - Cloud image (
amd64
) of CentOS 9 (Stream) - Cloud image (
amd64
) of Fedora Cloud Base 40 - Cloud image (
amd64
) of Ubuntu 18.04 LTS (Bionic Beaver) - Cloud image (
amd64
) of Ubuntu 20.04 LTS (Focal Fossa) - Cloud image (
amd64
) of Ubuntu 22.04 LTS (Jammy Jellyfish) - Cloud image (
amd64
) of Ubuntu 24.04 LTS (Noble Numbat)
Available on Ansible Galaxy in Collection jm1.cloudy.
This role uses module(s) from collection jm1.ansible
. To install this collection you may follow
the steps described in README.md
using the provided requirements.yml
.
Name | Default value | Required | Description |
---|---|---|---|
storage_config |
[] |
false | List of tasks to run 1 2 3 |
storage_reboot |
false |
false | Whether the system should be rebooted on meta: flush_handlers or after all changes have been applied |
None.
- hosts: all
become: true
vars:
# Variables are listed here for convenience and illustration.
# In a production setup, variables would be defined e.g. in
# group_vars and/or host_vars of an Ansible inventory.
# Ref.:
# https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html
# https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html
storage_config:
- # Create ext4 primary partition on device /dev/sdb
community.general.parted:
device: /dev/sdb
fs_type: ext4
number: 1
state: present
# reboot system after changes have been applied
storage_reboot: true
roles:
- name: Manage partitions, encrypted (LUKS) devices, LVM volume groups, LVM volumes, filesystems and mountpoints
role: jm1.cloudy.storage
tags: ["jm1.cloudy.storage"]
For instructions on how to run Ansible playbooks have look at Ansible's Getting Started Guide.
GNU General Public License v3.0 or later
See LICENSE.md to see the full text.
Jakob Meng @jm1 (github, galaxy, web)
Footnotes
-
Useful Ansible modules in this context could be
crypttab
,mount
,luks_device
,lvg
,lvol
andparted
. ↩ -
Tasks will be executed with
jm1.ansible.execute_module
which supports keywordwhen
only. ↩ -
Tasks will be executed with
jm1.ansible.execute_module
which supports modules and action plugins only. Some Ansible modules such asansible.builtin.meta
andansible.builtin.{include,import}_{playbook,role,tasks}
are core features of Ansible, in fact not implemented as modules and thus cannot be called fromjm1.ansible.execute_module
. Doing so causes Ansible to raise errors such asMODULE FAILURE\nSee stdout/stderr for the exact error
. (Only exception ismeta: flush_handlers
which is fully supported). In addition, Ansible does not support free-form parameters for arbitrary modules, so for example, change from- debug: msg=""
to- debug: { msg: "" }
. ↩