I remember the exact moment I realized I needed Ansible. It was a Saturday night, I had eight Proxmox VMs in my homelab, and I was SSH-ing into each one to apply the same security update. By server number five, I thought: there has to be a better way. There was. If you want to learn how to use Ansible on Linux, this guide walks you through everything from installation to your first playbook. No fluff, just the stuff I wish someone had shown me years ago.
Quick Answer: What Does Ansible Do?
Ansible lets you configure and manage multiple Linux servers from a single control machine using simple YAML files called playbooks. It connects over SSH, requires no software on managed nodes, and turns hours of manual work into a single command.
What Is Ansible (And Why I Stopped Writing Bash Scripts for Everything)
Look, I love writing bash scripts. They got me through years of sysadmin work. But once I was managing more than a handful of servers, those scripts turned into a tangled mess of SSH loops and fragile error handling.
Ansible is an open-source automation tool that lets you define your server configuration in human-readable YAML files. You run those files from one machine (the control node), and Ansible pushes the changes out to every server you specify. It currently holds 31.7% of the configuration management market, and adoption grew 45% year-over-year with the release of Ansible Automation Platform 2.6. In late 2024, Forrester named Ansible the leader in infrastructure automation.
Get a VPS from as low as $11/year! WOW!
The Agentless Advantage: No Daemons, No Drama
Here’s what sold me instantly. Ansible is agentless. It talks to your servers over plain SSH. No daemon running on every node, no agent to update, no ports to open beyond 22. Your managed nodes just need SSH access and Python 3 (which ships by default on Ubuntu 22.04+ and most modern distros).
Compare that to Puppet, which needs an agent installed on every managed node, or Chef, which requires a Ruby runtime. Ansible keeps things simple.
Ansible vs Bash Scripts, Puppet, and Terraform
The question I get most is: “Why not just write a bash script?” Fair question. Here’s the short version:
- Bash scripts work great for single-server tasks, but they break down across many hosts. Error handling, idempotency, and rollback get ugly fast.
- Puppet uses a custom DSL and requires agents. Steeper learning curve for sysadmins who already know YAML.
- Terraform is for provisioning infrastructure (spinning up VMs, networks, cloud resources). Ansible is for configuring what’s inside those VMs. The modern best practice is to use both together.
For a deeper dive into how these tools compare, check out Red Hat’s breakdown of automation tools.
Installing Ansible on Your Linux Control Node
You only install Ansible on one machine: the control node. This is the computer you’ll run commands from. Your managed servers don’t need Ansible installed at all.
Ubuntu and Debian
sudo apt update
sudo apt install ansible -y
ansible --versionYou can also install via pip if you want the latest version:
pip3 install ansibleRHEL, CentOS, Fedora, and Arch
# RHEL / CentOS
sudo dnf install ansible-core
# Fedora
sudo dnf install ansible
# Arch (btw)
sudo pacman -S ansibleAfter installation, run ansible --version to confirm everything is working. The official Ansible documentation covers edge cases for older distros if you run into trouble.
Setting Up SSH Key Authentication First
Before you touch a single playbook, get SSH key authentication working. Ansible relies on SSH to reach your managed nodes, and password prompts will make your life miserable.
If you haven’t already, generate a key pair and copy it to each server:
ssh-keygen -t ed25519
ssh-copy-id user@your-server-ipTest the connection manually first:
ssh user@your-server-ipIf that drops you into a shell without asking for a password, you’re good. I’ve lost count of how many times I’ve seen people skip this step and then wonder why Ansible throws authentication errors. For a full walkthrough, check out our guide on generating SSH keys on Linux.
Creating Your Ansible Inventory File
The inventory file tells Ansible which servers to manage. Think of it as your address book for infrastructure.
Writing a Static Inventory
The default location is /etc/ansible/hosts, but I always create a project-specific inventory file instead. Here’s a simple INI-format example:
[webservers]
192.168.1.10
192.168.1.11
web03.example.com
[databases]
192.168.1.20
192.168.1.21Organizing Hosts into Groups
Groups are powerful. They let you target specific subsets of your infrastructure. In the example above, you could run a command against only your web servers or only your database servers. You can also nest groups:
[production:children]
webservers
databasesFor complex setups with variables and dynamic sources, the Ansible inventory guide is worth bookmarking. My advice: keep separate inventory files for dev, staging, and production. Future you will be grateful.
Running Your First Ad-Hoc Commands
Before writing playbooks, let’s start with ad-hoc commands. These are one-off instructions you fire from the command line. Great for quick checks and simple tasks.
Testing Connectivity with the Ping Module
ansible all -i inventory.ini -m pingThis doesn’t send an ICMP ping. It verifies that Ansible can connect via SSH and that Python works on each managed node. If you see green “pong” responses, your setup is solid.
Practical Ad-Hoc Commands That Save Real Time
# Check uptime on all servers
ansible all -i inventory.ini -m shell -a 'uptime'
# Install nginx on web servers
ansible webservers -i inventory.ini -m apt -a 'name=nginx state=present' --become
# Gather all system facts
ansible all -i inventory.ini -m setupAd-hoc commands are perfect for quick wins. But for anything you’ll run more than once, you want a playbook.
Writing Your First Ansible Playbook
This is where Ansible goes from “handy tool” to “I can’t live without this.” A playbook is a YAML file that defines a series of tasks to run on your servers. It’s your server automation recipe.
Playbook YAML Structure Explained
Every playbook has three core pieces:
- hosts: Which group from your inventory to target
- become: Whether to use sudo for privilege escalation
- tasks: The ordered list of actions to perform
Real-World Example: Install and Start Nginx Across 10 Servers
Here’s a complete playbook that installs and starts Nginx on every web server in your inventory. If you’ve been setting up Nginx on Linux manually, prepare to feel liberated:
---
- name: Deploy Nginx web servers
hosts: webservers
become: yes
tasks:
- name: Install Nginx
apt:
name: nginx
state: present
update_cache: yes
- name: Start and enable Nginx
service:
name: nginx
state: started
enabled: yes
- name: Copy custom index page
copy:
src: ./files/index.html
dest: /var/www/html/index.html
owner: www-data
mode: '0644'Run it with:
ansible-playbook -i inventory.ini site.ymlWant to preview changes without applying them? Add the --check flag for a dry run. I always do a dry run first. I learned that lesson the hard way when a misconfigured playbook wiped a config file across three production boxes. Not fun.
If you prefer Apache over Nginx, the same pattern applies. Check out our guide on installing Apache on Linux to see the manual steps you’d be automating.
Essential Ansible Modules Every Linux Sysadmin Should Know
Modules are the building blocks of every task. Each one handles a specific piece of system management. Here are the ones I use constantly:
- apt / dnf / yum: Install, update, or remove packages across distros
- service: Start, stop, or enable systemd services (pairs well with managing services with systemctl)
- copy: Push files from your control node to remote servers
- template: Use Jinja2 templates to generate config files with variables
- user: Create and manage Linux user accounts (the automated version of adding users in Linux)
- ufw: Manage firewall rules without touching each server (see configuring UFW firewall on Linux)
- cron: Schedule tasks remotely (automates what you’d do when managing cron jobs in Linux)
- file: Set permissions, ownership, and create directories
What I love about modules is that they’re idempotent. Run the same playbook twice, and nothing changes the second time. That’s a huge deal compared to bash scripts, where running the same commands again might break things. You can also automate creating systemd services with the template and service modules together.
Ansible Best Practices Before You Hit Production
I’ve made enough mistakes over the years to fill a whole article. Here’s what I wish I’d known from day one:
Production Safety Checklist
- Always dry-run first: Use
ansible-playbook site.yml --checkbefore applying changes. - Test on one host: Use
--limit server01to target a single machine before rolling out everywhere. - Version control everything: Store your inventory, playbooks, and variables in Git. Treat infrastructure as code.
- Use ansible-vault for secrets: Never hardcode passwords in playbooks. Vault encrypts sensitive data at rest.
- Name every task: Descriptive task names turn your playbook output into an audit log you can actually read.
- Be careful with become: Privilege escalation with
become: yesruns tasks as root. Make sure your sudoers config is correct. Our guide on editing the sudoers file covers this in detail.
“Ansible holds a unique place in the market, combining broad capabilities, a deep technology ecosystem and a clear vision for how automation can transform IT management.” — Sathish Balakrishnan, VP and GM of Ansible, Red Hat
What to Learn After Ansible Basics
Once you’ve got playbooks running smoothly, here’s where to go next:
- Ansible Roles: Break large playbooks into reusable, shareable components. Roles give your automation real structure.
- Ansible Galaxy: A community hub of pre-built roles. Need a hardened SSH config or a complete LAMP stack? Someone’s probably already written the role.
- Variables and Vault: Parameterize your playbooks so the same code works across dev, staging, and production. Use Vault to encrypt secrets.
- Dynamic Inventory: Pull host lists from AWS, GCP, or your own CMDB instead of maintaining static files.
- Docker integration: Ansible pairs beautifully with containers. If you’re already using Docker on Linux, you can use Ansible to automate container deployments at scale.
You can also use Ansible to orchestrate setting up automatic backups across your entire fleet. That’s one of those tasks that feels tedious when done manually but becomes effortless with a well-written playbook.
Start Automating Today
Learning how to use Ansible on Linux changed the way I manage every server I touch. What used to take me an entire Saturday afternoon now runs in under a minute. The initial learning curve is real, but it’s gentler than almost any other configuration management tool out there. Start small: install Ansible, set up your inventory, ping your servers, and write one playbook. You’ll wonder how you ever lived without it.
If you’re building up your Linux skills alongside Ansible, these guides will help fill in the gaps: our walkthrough on writing bash scripts gives you the scripting foundation Ansible builds on, and our guide to generating SSH keys on Linux covers the authentication layer that makes it all work. Happy automating.
