Text size
On My Radar5 min read

Is Ansible still worth learning?

Terraform and Kubernetes took the spotlight. Where Ansible still wins.

Is Ansible still worth learning?
AI-generated editorial illustration

Ten years ago, Ansible was everywhere. Configuration management was the heart of DevOps: Puppet, Chef, Salt and Ansible battled for servers. Then containers arrived, immutable infrastructure became fashionable, Terraform took over provisioning, and Kubernetes took over running applications.

People keep asking me: is Ansible still worth learning in 2026? My answer is yes, but for different reasons than before.

Where it fits today

Think of the layers of modern infrastructure:

  • Terraform / OpenTofu: creates infrastructure. Networks, VMs, databases, clusters.
  • Kubernetes: runs containerised applications.
  • Ansible: configures things and runs procedures. Operating systems, network devices, software that isn't containerised, and multi-step operational tasks.

There's still a lot of that third category. Not everything runs in containers, and not every server is cattle.

What it's still great at

Configuring operating systems. Hardening Linux servers, managing users and SSH keys, installing agents, configuring time sync and logging. Especially in on-premises environments, VMs that live for years, or bare metal.

Network automation. This is where Ansible is arguably stronger than ever. Switches, routers, firewalls and load balancers from Cisco, Juniper, Arista, F5, Palo Alto and many more have Ansible collections. Network teams use it heavily.

Day-2 operations. Rolling restarts, patching servers in batches, rotating certificates on old systems, running the same command across a hundred machines. The "orchestration of procedures" that doesn't fit Terraform's declarative model.

Bootstrapping. Preparing machines before Kubernetes or another platform takes over, like building a homelab or an on-prem cluster.

Legacy and hybrid environments. Most companies have them, and they need automating too.

Terraform builds the house, Kubernetes runs the apps inside, and Ansible is still the handyman who fixes everything else.

Why people like it

  • Agentless. It connects over SSH (or WinRM, or APIs). Nothing to install on the managed machines.
  • YAML playbooks that are fairly easy to read, even for people who aren't programmers.
  • Huge collection of modules for almost any system.
  • Idempotent modules: running a playbook twice gives the same result.

A simple playbook:

- name: Harden web servers
  hosts: web
  become: true
  tasks:
    - name: Ensure unattended upgrades are installed
      ansible.builtin.apt:
        name: unattended-upgrades
        state: present

    - name: Disable SSH password login
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^#?PasswordAuthentication'
        line: 'PasswordAuthentication no'
      notify: Restart ssh

  handlers:
    - name: Restart ssh
      ansible.builtin.service:
        name: ssh
        state: restarted

Event-Driven Ansible

A newer addition worth knowing: Event-Driven Ansible lets you trigger playbooks automatically from events, like a monitoring alert, a webhook or a message on a queue. For example: when a disk-full alert fires, run a playbook that cleans up old logs and opens a ticket.

It's a nice bridge between observability and automation, especially in traditional IT environments.

Good habits

If you use Ansible, use it well:

  • Roles and collections for reusable, shareable code instead of giant playbooks.
  • Inventory from your cloud (dynamic inventory plugins) rather than hand-maintained host lists.
  • Ansible Vault or an external secret manager for secrets. Never plain text.
  • ansible-lint in CI.
  • Molecule for testing roles in containers or VMs before running them against real machines.
  • Fully qualified module names like ansible.builtin.copy.
  • Run it from CI or a controller (like AWX or Ansible Automation Platform) for production, not from laptops.

When I wouldn't use it

  • Provisioning cloud resources: Terraform or OpenTofu is better at tracking state.
  • Deploying apps to Kubernetes: use Helm, Kustomize and GitOps instead.
  • Configuring containers: bake configuration into images or use Kubernetes ConfigMaps.

So, should you learn it?

If you work with Linux servers, on-premises infrastructure, network devices or hybrid environments: absolutely. It's quick to learn and immediately useful. If your world is 100% cloud-native Kubernetes, it's a nice-to-have rather than a must.

My take: Ansible isn't the star anymore, but it's still the most practical tool for the messy, real-world parts of infrastructure.

— Desly