Getting into the world of Ansible

Title: Getting into the world of Ansible

Ansible, a powerful automation tool, has long been my go-to solution for managing server setups. Its ability to scale web services and maintain stable uptime has always appealed to me. However, the tool's steep learning curve and prohibitive costs for additional servers discouraged me from exploring its full potential. Recently, advancements in AI tools have lowered the barrier to entry for Ansible, making it more accessible for experimentation.

After deciding to migrate my current apps and manage them with Ansible, I began by asking an AI tool to outline the essential concepts I needed to understand. Key topics included tasks, playbooks, vaults, variables, and inventories. While roles proved beneficial for managing complexity, I initially opted for a flat structure, similar to C projects, to keep things simple.

Modules, another crucial aspect of Ansible, initially overwhelmed me with their vast number. However, most of what I needed was within the ansible.builtin namespace, reducing the need for third-party modules. I decided to migrate Uptime Kuma, a simple app in my stack, as the test subject for my Ansible migration.

To set up the project, I needed a master node (my primary PC), SSH access to all servers, and a Tailscale connection for secure routing. I created an inventory.yml file listing my servers, an ansible.cfg configuration file, and a main playbook (site.yml) to run tasks. My first task, ping.yml, verified connectivity to the servers. The home_nodes.yml playbook managed the home infrastructure apps.

I then migrated Uptime Kuma, leveraging my previous use of Podman Quadlets for declarative deployments. The migration plan involved copying Quadlet files, creating application directories, performing a dry-run, reloading systemd, and starting or restarting the application service. This approach allowed me to manage Uptime Kuma's state without causing data loss or disrupting its operation.