Blog

  • How I Built and Automated This Website with Ansible Navigator

    This website runs on a server I built twice: first by hand, then again with Ansible. Here is what I did and what I learned along the way.

    The goal

    The task was to host a WordPress site on a Linux server, with the site served from a dedicated folder, secure file access over SFTP, phpMyAdmin for the database, and a free SSL certificate. I treated it as a learning project, so I wanted to understand every step before I automated anything.

    Round one: doing it by hand

    I started on Amazon Linux in AWS, with a domain bought separately and pointed at the server with DNS records. I installed Nginx, PHP and MariaDB, created a site user whose files live in /home/username/websitename/public, locked that user into SFTP only, and added HTTPS with a Let’s Encrypt certificate. Along the way I hit real problems: a pasted command that split across two lines, a database user created twice, a typo in an Nginx file that took the whole site down. Fixing each of them taught me more than any tutorial would have.

    Round two: a clean RHEL 10 server and Ansible

    For the second round I used two machines: a control node that runs Ansible, and a managed node that becomes the web server. I used Ansible Navigator, which runs Ansible inside a container so everyone gets the same tools, and I organised the work into roles, one for each part of the job:

    • common: swap space and system basics
    • mariadb: the database, with the WordPress user and database
    • sftp: the site user and a locked-down SFTP login
    • php_fpm: a PHP pool that runs as the site user
    • nginx: the web server configuration
    • wordpress: the WordPress files and configuration
    • phpmyadmin: database management in the browser
    • ssl: the certificate and automatic renewal

    Passwords are stored in an encrypted Ansible Vault file, so none of them sit in plain text in the project.

    What I learned

    • Idempotency is the best feature. Running a playbook a second time and seeing zero changes is how you know it works.
    • SELinux matters. RHEL blocks things by default, and each fix (web folders, SFTP, PHP) became its own task.
    • Handlers can surprise you. A reload that never ran taught me to read the output carefully instead of assuming.
    • Doing it manually first pays off. Because I’d built every piece by hand, the roles made sense to me instead of feeling like magic.

    What’s next

    I want to keep building on this: backups, monitoring, and maybe a second server. I’ll write about the mistakes as well as the successes, because that’s where I learn the most.

    Thanks for reading. — Dhanish

  • Hello world!

    Welcome to WordPress. This is your first post. Edit or delete it, then start writing!