/
/
Ansible role that deployss my nas configuration. It mostly handles nfs configurations and exports that are tailored to the hardware and service configuration.
NFS server, optional RAID, network bonding, and storage performance tuning.
| Variable | Default | Description |
|---|---|---|
nas_nfs_enabled |
true |
Install and configure NFS server |
nas_nfs_exports |
[] |
NFS export definitions (path, network, options) |
nas_raid_enabled |
false |
Configure mdadm RAID array |
nas_raid_level |
5 |
RAID level (0/1/5/6/10) |
nas_raid_devices |
[] |
Block devices for the array |
nas_bonding_enabled |
false |
Configure network interface bonding |
nas_performance_tuning_enabled |
true |
Apply network/filesystem performance tweaks |
nas_runner_*_path |
various | Storage paths exported for runner services |
nas_docker_mount_ordering_enabled |
true |
Order docker.service after the storage mount |
nas_docker_mount_ordering_dropin |
wait-for-storage-mount.conf |
Drop-in filename under docker.service.d |
/etc/exports and reload NFSnas_storage_base is mounted with nofail, and docker.service ships with no
ordering dependency on it. After an unclean shutdown, mdadm assembly is slow
enough that Docker can start containers before the array is mounted. Any
container bind-mounting that path then binds the empty pre-mount directory on
the root filesystem instead of the array â silently. Containers keep running,
but read and report the root LV rather than the array, so monitoring shows the
wrong capacity and writes land on the wrong filesystem.
docker-mount-ordering.yml installs a drop-in with RequiresMountsFor= so
systemd orders Docker after the generated mount unit. It is skipped on hosts
without Docker, and warns during a run if the storage base is currently backed
by something other than an /dev/md* device â the signature of this race.
To recover a host that already booted in the bad state:
mount /mnt/rstorage
docker restart $(docker ps -q) # re-resolves stale bind mounts