Ansible Server Migration

Overview

I migrated my bare-metal Debian 12 webserver to an Alma 10 VM and Dockerized key services

The migration was automated with Ansible and the downtime was mere seconds

Motivation

Before the migration tobiastime was ran on a bare-metal Debian 12 server, with all services being handled via systemd

Debian 12 itself reached official EOL security support on the 10th of June 2026, which was 4 days ago at the time of writing this

In addition to the OS now being out of official support, I felt my infrastructure was beginning to suffer from architectural design decisions made when I was less familiar with virtualization and containerization

For example, if I wanted to implement a new service or upgrade an existing one I had no means of taking a snapshot or rolling back

If I wanted to fully back the system up it required taking the entire server offline to clone the disk

If a bad update caused an incompatibility, or failed start up, I had to troubleshoot and patch during the service's downtime

In light of this I decided I needed to migrate to another OS, virtualize the server and Dockerize my most crucial services

Alma 10 was attractive due to being an enterprise-grade, free and open source operating system, offering long-term security support until the 31st of May 2035

I decided to handle the migration primarily via Ansible playbooks and a staging VM

My intent was to minimize the downtime as much as possible for the services I and others rely on

This goal was successfully met as the only downtime tobiastime faced was the time it took me to point the port forwarding on my router to a different backend IP

Successfully migrated

• Nginx/PHP/static website, updated all relevant config files for a RHEL-based distro
• Gitea, Calibre, Jellyfin, all Dockerized with related SQL databases ported
• custom picoshare systemd service
• UFW -> firewalld
• unattended upgrades -> dnf-automatic, security only
• ssmtp -> msmtp
• certbot
• mounts/fstab
• configs (SSH, Cron, MOTD)
• users/home directories
• custom scripts (rewritten/modified)

Server Migration Methodology

Initially I cloned my Debian drive with dd to serve as a perpetual, virtualized, reference point

I installed an AlmaLinux VM, and created a snapshot of the fresh install

I exported the RAID drives connected to the bare-metal server as a NFS share, and created a playbook to mount them on the Alma staging VM

After this I built and tested further Ansible playbooks, line by line

I continued testing until server's deployment, configuration and data migration was completely automated and repetable from the fresh snapshot

Once all services were confirmed functional within the LAN, I pointed my router to the new Alma VM

I monitored and verified live functionality after the migration for another hour, then stopped services on the old bare-metal Debian server as the migration was successful and a rollback was not needed

Dockerization Methodology

I inventoried the existing services on the bare-metal server, looking at things such as

• configuration files
• the systemd unit including the environment/variables
• databases
• the service's version

With tools such as,

 systemctl cat gitea
 gitea --version
 locate / find

After I built a Docker compose file matching the image that is to be pulled's version with the version on the bare-metal server

I built an Ansible playbook which migrates data, pulls the correct image and makes relevant directory and configuration changes

I tested piece by piece, making changes to playbook, configuration files, directories and Docker image file until complete functionality of the containerized service was verified

Compromises

I did not migrate my RAID drives as there was not enough physical space in my Proxmox host to fit the PCIe card

I decided to do some work manually, after the server was running,

• changing the hostname
• porting SSH keys
• tarring my old user's home directories, copying them over the network, then untarring them in the relevant directories

I am not displaying every playbook involved in the migration nor every configuration publicly on my Git instance, for obvious privacy and security related reasons

Future plans

After an acceptable long-term period of stability I plan remove Debian 12 entirely from old bare-metal server, replace it with Proxmox, install the relevant RAID CLI tools (as Proxmox is Debian based), then migrate the Alma VM over which would avoiding having to mount the drives over the network

I plan to Virtualize my other bare metal server utilizing the same procedure

I intend to move BashDDNS to it's own dedicated LXC container, as currently it sits on the Alma VM