🚀 Auto‑Healing with Ansible: Restart Apache on a WHM VPS (the right way)

Mihir SavlaMihir Savla
3 min read

built a tiny but powerful Ansible playbook that connects to my WHM VPS over SSH and safely manages Apache (httpd). It’s idempotent, auditable, and production‑friendly. This post shows the why, the how⚙️


🤔 What’s an Ansible Playbook (in one line)?

A YAML file that describes desired state (not just commands) so servers converge to “correct” automatically—repeatably and safely.


âś… What I built

  • Inventory that targets my WHM VPS

  • Playbook to manage Apache (httpd)

  • Dry‑run first, then execute with logs to /var/log/ansible_autoheal.log

  • Designed to be idempotent and secure (SSH keys)


đź§© Prerequisites

  • Ansible installed on your local machine

  • SSH key‑based access to your VPS (root or a sudoer)

  • WHM/CentOS/AlmaLinux/RHEL with systemd and httpd


🛠️ Step‑by‑Step (copy‑paste ready)

1) Inventory

inventory.ini

[whm_server]
YOUR.SERVER.IP ansible_user=root ansible_ssh_private_key_file=~/.ssh/id_rsa

2) Playbook (simple restart + audit log)

restart-apache.yml

- name: Restart Apache (httpd) and log it
  hosts: whm_server
  become: yes
  tasks:
    - name: Ensure Apache is running (start if stopped)
      ansible.builtin.service:
        name: httpd
        state: started
        enabled: yes

    - name: Restart Apache now (explicit action)
      ansible.builtin.service:
        name: httpd
        state: restarted

    - name: Log Apache restart
      ansible.builtin.lineinfile:
        path: /var/log/ansible_autoheal.log
        create: yes
        line: "Apache restarted at {{ ansible_date_time.iso8601 }}"

3) Dry run (no changes)

ansible-playbook -i inventory.ini restart-apache.yml --check

4) Execute with verbosity

ansible-playbook -i inventory.ini restart-apache.yml -vvv

5) Verify on the server

systemctl status httpd
tail -n 5 /var/log/ansible_autoheal.log

đź§  Smarter version (restart only if needed)

Use handlers so you start Apache if it’s down and only restart when something changes (e.g., a config update later).

apache-manage.yml

- name: Manage Apache the right way (idempotent)
  hosts: whm_server
  become: yes
  tasks:
    - name: Ensure Apache is installed
      ansible.builtin.package:
        name: httpd
        state: present

    - name: Ensure Apache is enabled and started
      ansible.builtin.service:
        name: httpd
        state: started
        enabled: yes

    # Example of a “change” that would trigger a restart:
    - name: Drop a minimal Apache conf (demo)
      ansible.builtin.copy:
        dest: /etc/httpd/conf.d/zz-demo.conf
        content: |
          # demo config to prove handler runs only on change
        owner: root
        group: root
        mode: '0644'
      notify: Restart Apache

    - name: Log converge
      ansible.builtin.lineinfile:
        path: /var/log/ansible_autoheal.log
        create: yes
        line: "Apache converged at {{ ansible_date_time.iso8601 }}"

  handlers:
    - name: Restart Apache
      ansible.builtin.service:
        name: httpd
        state: restarted

Run:

ansible-playbook -i inventory.ini apache-manage.yml

🎯 Why this matters

Automation‑first mindset: I don’t “click ops”; I codify ops.

  • Idempotency & safety: Playbooks re‑run cleanly—no snowflake servers.

  • Linux + WHM fluency: Real work on real services (systemd, httpd).

  • Observability awareness: Playbooks complement my Prometheus/Grafana work.

  • Security best‑practices: Key‑based SSH, least surprise changes, audit logs.


🧭 Extensions I’m adding next

  • đź”– Tags (e.g., --tags apache / --tags mysql) to target roles cleanly

  • 📦 Role structure (roles/apache/...) for production hygiene

  • đź§Ş CI (GitHub Actions to lint YAML with ansible-lint)

  • 🛡️ Safe config deploys (template + syntax check + handler)

  • đź”” Alert‑driven runs (later: Alertmanager → Ansible webhook)


📸 What you can expect to see

  • Terminal output showing ok/changed states

  • systemctl status httpd verifying service health

  • Log entries in /var/log/ansible_autoheal.log


🔚 Conclusion

This is another milestone in my #PathToTheBox journey.
Automation isn’t just about convenience—it’s about reliability, scale, and making sysadmins future-ready.

đź’ˇ Keep following me on LinkedIn and my website for more updates as I continue building hands-on DevOps projects that solve real hosting problems.

0
Subscribe to my newsletter

Read articles from Mihir Savla directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Mihir Savla
Mihir Savla