Ansible: first steps

Last January, I announced my resolutions for 2025, one of which was to look into Ansible to figure out how to automate and manage my servers more efficiently. After a few weeks of exploring, it’s time for a quick debrief and to share what I’ve learned so far, especially about setup and using real playbooks.

Why I chose Ansible

I mentioned it before, but the main reason I started learning Ansible is its simplicity:

  • Agentless: no need to install anything on the target servers, everything happens over SSH.
  • YAML playbooks: a readable format, easy to maintain, where it feels natural to describe the desired state of machines.
  • Managing several servers in parallel: perfect for avoiding repetitive, tedious tasks.

The idea, for me, is to be able to standardize and make the configuration of my environments more reliable, whether for a small personal project or, eventually, production deployments.

My first discoveries

Since I started getting my hands into Ansible, here’s what I’ve already been able to try out:

  1. Installation and basic setup On a Debian/Ubuntu distro, nothing simpler:
    sudo apt-get update
sudo apt-get install ansible

A few seconds later, Ansible is already up and running.

  1. Configuration management After installation, the config is super simple. You generally just need to define:

    • An inventory file to list your servers and group them by role or environment.
    • Playbook files to describe your tasks and the target configuration.

  2. Simple playbooks I started with basic tasks: installing a package, copying a config file, restarting a service. It quickly gives you a sense of control over your infrastructure.

  3. Custom inventory To describe my servers, I created an inventory file where I can organize my machines by role (e.g. prod, Cluster Proxmox, etc.). It makes life a lot easier when running commands.

  4. Backup and documentation Describing everything in YAML files lets me keep a clear record of every action taken. I no longer need to remember some parameter I configured by hand, everything is centralized.

Configuration and playbook example (Nginx security)

Inventory example (hosts)

[all]
web-nginx1 ansible_host=192.168.1.10 ansible_user=root
web-nginx2 ansible_host=192.168.1.11 ansible_user=root

[prod]
web-nginx1
web-nginx2

Playbook example (secure_nginx.yml)

---
- name: Install and configure Nginx with security best practices
  hosts: prod
  become: yes

  tasks:
    - name: Install Nginx
      apt:
        name: nginx
        state: latest

    - name: Copy the secure configuration file
      copy:
        content: |
          server_tokens off;
          add_header X-Frame-Options SAMEORIGIN;
          add_header X-Content-Type-Options nosniff;
          add_header X-XSS-Protection "1; mode=block";
        dest: /etc/nginx/conf.d/security.conf

    - name: Restart and enable Nginx
      service:
        name: nginx
        state: restarted
        enabled: true

To apply this playbook:

ansible-playbook -i hosts secure_nginx.yml

What I like most

  • Readability of YAML.
  • Quick to set up.
  • Peace of mind about the configuration applied.

What I liked less

  • Compatibility can sometimes be tricky with old systems or poorly maintained environments.

Next things to explore

  • Ansible roles.
  • Best practices for structuring.
  • Integration with other tools (CI/CD, monitoring).

Conclusion

These first weeks with Ansible have already saved me time, and above all, reliability. There’s still some friction with older environments, but for automating and standardizing my configs, it’s exactly what I needed.