107 lines
5.0 KiB
Markdown
107 lines
5.0 KiB
Markdown
# Ansible Server Migration
|
|
|
|
## Overview
|
|
|
|
I migrated my bare-metal Debian 12 webserver used in production to an Alma 10 VM hosted on Proxmox and Dockerized key services
|
|
|
|
The migration was orchestrated with Ansible and the downtime limited to seconds, with zero data loss
|
|
|
|
The entire environment is now reproducible from a fresh Linux install
|
|
|
|
## Successfully migrated
|
|
|
|
- OS: Debian 12 -> AlmaLinux 10
|
|
- Web stack: Nginx/PHP/static website, updated all relevant config files for a RHEL-based distro
|
|
- Services: Gitea, Calibre, Jellyfin, all Dockerized with SQL databases ported
|
|
- Firewall: UFW -> firewalld
|
|
- Updates: unattended upgrades -> dnf-automatic, security only
|
|
- Mail: ssmtp -> msmtp
|
|
- Packages: apt -> dnf
|
|
- Certificates: certbot
|
|
- Storage: fstab
|
|
- Configs: SSH, Cron, MOTD
|
|
- Users: home directories and files preserved
|
|
- Custom scripts: rewritten and modified
|
|
|
|
## 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
|
|
|
|
## Server Migration Methodology
|
|
|
|
Initially I created a full Debian disk clone with dd to preserve a reference point for the original system
|
|
|
|
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,
|
|
|
|
``` bash
|
|
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](https://git.tobiastime.xyz/Tobias/Breakout-ATX-RAID) 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](https://git.tobiastime.xyz/Tobias/BashDDNS) to it's own dedicated LXC container, as currently it sits on the Alma VM |