What I did to get rid of my mess, was to containerize service after service using podman. I mount all volumes in a unified location and define all containers as quadlets (systemd services). My backup therefore consists of the base directory where all my container volumes live in subdirectories and the directory with the systemd units for the quadlets.

That way I was able to slowly unify my setup without risking to break all at once. Plus, I can easily replicate it on any server that has podman.

I went through this about 6 months ago.

Just build playbooks from basic to specific. I did so in three parts:

1. Container creation
2. Basic settings common to all my hosts
3. Specific service config & software

Ansible assumes you have a hierarchy of roles to apply for each service, so layering playbooks this way should help

You will need many iterations of trial and error. No way.

You can speed up testing your playbook by using Molecule or something similar. Don't touch your working VMs until you get a service (role) set up correctly in your test environment. If you need to set up multiple services in a single VM, you can automate their deployment sequentially, of course.

P. S. I don't like Ansible and won't recommend it because it is full of bugs and non-obvious behavior. However I didn't investigate alternatives and can't suggest a better one.

Ducking around

giggle

@Cyber Yeah it's gonna be pretty manual as others have mentioned. Some areas to look at:
- Filesystem provisioning, mounts, etc.
- Packages
- Users, groups
- Time zone, locale language, time format etc.
- /etc/
- /root/ and /home/
- SSH settings
- Services
- Cron jobs/systemd timers

There is a bit of overlap between some of those categories. Some bits are going to see more or less use on VMs vs physical. And remember that in ansible there are built in modules for a lot of functionality.

@Cyber If you have some old wiki notes on how the system was setup originallythen it night be easier to ignore the current system and translate the wiki instructions into ansible. Still manual, but easier than reverse engineering. Another thing you can look at is bash history. Apart from backing up/cloning the system before you start I would also get a copy of the bash history for the various users and add it to a wiki or issue too. It will be useful.

I would copy the existing system onto a new system:

1. Update system to the latest packages
2. Create a new base system using the same distro
3. Check which packages are not on the new system, add them to your playbook
4. Install packages on new system
5. This will take some time. Run a find of all files and pass them to md5sum or sha512sum to get a list of files with their checksum. Compare the list from the old system to the new system.
6. Update your playbook with these findings. Template is probably the way to go, Lineinfile might be good as well, use copy if nothimg else works.
7. Check firewall settings and update your playbook.

Anyhow this will take some iterations, but while you have a copy of your ‘production’ system, you can test on your ‘test’ machine until you have the same functionality.

the first step is workout what you did, what did you install and where from. Then what config files got edited.

Much like a playbook for a disaster recovery test

Next is using some of the builtin modules like package and copy, make a very noddy playbook that will install stuff and copy up the config. if you have vms, you can use a test vm to see if the playbook works.

If you've not played ansible than this might help 👉 https://www.jeffgeerling.com/project/ansible-101-youtube-series

afaik, there's no way "convert" a running system into a playbook. I'd recommend looking at what your systems have in common (installed packages, timezone etc...) and create playbooks based on that and work your way up from there.