Ansible Tutorial for Beginners: Automate Your First Server in 30 Minutes

You've SSH'd into a server at 2am to fix a config typo. Again. You've run the same 15 commands across 10 servers, praying you don't miss one. That's not DevOps — that's manual labor. Ansible kills that pain. It's the simplest automation tool I've used in 15 years, and it's the first thing I teach every junior. By the end of this, you'll write a playbook that installs a web server, deploys a static site, and ensures it stays running — all with one command. No agents, no daemons, just SSH and YAML.

What Problem Does Ansible Solve?

Before Ansible, you had two choices: SSH into each server and type commands by hand (error-prone, slow), or use tools like Puppet/Chef that required agents installed on every node (complex, heavy). Ansible came along and said: what if we just use SSH and a simple YAML file? No agents, no daemons, no PKI infrastructure. Just your SSH keys and a playbook. That's why it won. You write a playbook once, run it against 10 or 10,000 servers, and every one ends up in the same state. It's idempotent — run it twice, nothing changes. That's the superpower.

# io.thecodeforge — DevOps tutorial
---
- name: Ensure nginx is installed and running
  hosts: webservers
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
    - name: Ensure nginx is running
      service:
        name: nginx
        state: started
        enabled: yes

Installing Ansible and Setting Up Your First Inventory

Install Ansible with pip: pip install ansible. That's it. No server setup, no database. Now create an inventory file — a list of servers Ansible will talk to. Inventory can be INI or YAML. I prefer INI for simplicity. Here's a basic one: [webservers] web1.example.com web2.example.com. You can also use IPs. Test connectivity with ansible all -i inventory.ini -m ping. That module just checks SSH works and Python is available. If you get a pong, you're ready.

# io.thecodeforge — DevOps tutorial
[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com ansible_user=admin ansible_ssh_private_key_file=/path/to/key

Writing Your First Playbook: Install and Configure Nginx

A playbook is a YAML file with one or more plays. Each play targets a group of hosts and runs tasks in order. Let's write one that installs nginx, copies a custom index.html, and ensures the service is running. The become: yes tells Ansible to use sudo. Tasks are modules — apt, copy, service. Each module is idempotent: it checks the current state and only makes changes if needed. Run it with ansible-playbook -i inventory.ini nginx.yml.

# io.thecodeforge — DevOps tutorial
---
- name: Configure nginx web server
  hosts: webservers
  become: yes
  vars:
    http_port: 80
    server_name: example.com
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
        update_cache: yes
    - name: Create website directory
      file:
        path: /var/www/{{ server_name }}
        state: directory
        owner: www-data
        group: www-data
        mode: '0755'
    - name: Copy index.html
      copy:
        src: index.html
        dest: /var/www/{{ server_name }}/index.html
        owner: www-data
        group: www-data
        mode: '0644'
    - name: Configure nginx site
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/sites-available/{{ server_name }}
      notify: restart nginx
    - name: Enable site
      file:
        src: /etc/nginx/sites-available/{{ server_name }}
        dest: /etc/nginx/sites-enabled/{{ server_name }}
        state: link
      notify: restart nginx
  handlers:
    - name: restart nginx
      service:
        name: nginx
        state: restarted

Using Variables and Templates for Dynamic Configs

Hardcoding values in playbooks is a rookie move. Use variables. You can define them in the playbook (under vars), in separate files, or in the inventory. Templates use Jinja2 syntax — they're files with .j2 extension that get rendered with variables. For example, an nginx config template that uses {{ server_name }} and {{ http_port }}. This lets you reuse the same playbook for different environments: dev, staging, prod — just change the variables.

# io.thecodeforge — DevOps tutorial
server {
    listen {{ http_port }} default_server;
    server_name {{ server_name }};

    root /var/www/{{ server_name }};
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Ansible Modules: The Tools in Your Belt

Modules are the building blocks. Each module does one thing: apt installs packages, copy transfers files, service manages daemons, command runs arbitrary commands. There are hundreds. The most common ones for beginners: apt/yum (package management), copy/template (file management), service/systemd (service management), user (user management), file (file/directory attributes). Always prefer a specific module over command or shell — they're idempotent and give better error messages. Use command only as a last resort.

# io.thecodeforge — DevOps tutorial
---
- name: Demonstrate common modules
  hosts: all
  become: yes
  tasks:
    - name: Install git (apt)
      apt:
        name: git
        state: present
    - name: Create deploy user
      user:
        name: deploy
        groups: sudo
        shell: /bin/bash
        create_home: yes
    - name: Clone a repo
      git:
        repo: 'https://github.com/example/repo.git'
        dest: /opt/app
        version: main
    - name: Set file permissions
      file:
        path: /opt/app/config.yml
        owner: deploy
        group: deploy
        mode: '0600'
    - name: Restart service
      systemd:
        name: app
        state: restarted
        daemon_reload: yes

Playbook Structure: Plays, Tasks, and Handlers

A playbook is a list of plays. Each play targets a group of hosts and defines tasks. Tasks run in order. Handlers are special tasks that run only when notified by other tasks, and only once at the end of the play. Use handlers for actions like restarting a service after a config change. The notify keyword triggers a handler. Handlers are defined under handlers at the play level. They're a clean way to separate the 'do this' from 'if needed, do that'.

# io.thecodeforge — DevOps tutorial
---
- name: Update app config and restart
  hosts: appservers
  become: yes
  tasks:
    - name: Update config file
      template:
        src: app.conf.j2
        dest: /etc/app/app.conf
      notify: restart app
    - name: Update another config
      copy:
        src: other.conf
        dest: /etc/app/other.conf
      notify: restart app
  handlers:
    - name: restart app
      service:
        name: app
        state: restarted

Running Playbooks: Ad-Hoc Commands vs Playbooks

For one-off tasks, use ad-hoc commands: ansible all -i inventory.ini -m command -a 'uptime'. For repeatable automation, write playbooks. Ad-hoc is great for quick checks: ansible all -m ping, ansible all -m shell -a 'df -h'. But anything you'll run more than once belongs in a playbook. Playbooks are version-controlled, documented, and idempotent. Always use --check before running a playbook against production. Use --diff to see what changes will be made.

# io.thecodeforge — DevOps tutorial

# Check uptime on all servers
ansible all -i inventory.ini -m command -a 'uptime'

# Install htop on all webservers
ansible webservers -i inventory.ini -m apt -a 'name=htop state=present' --become

# Dry-run a playbook
ansible-playbook -i inventory.ini nginx.yml --check

# See what would change with diff
ansible-playbook -i inventory.ini nginx.yml --check --diff

Idempotency: The Superpower You Must Understand

Idempotency means running the same playbook multiple times produces the same result. No unintended side effects. Ansible modules are designed to be idempotent: apt: name=nginx state=present checks if nginx is installed; if yes, it does nothing. This is why you can run a playbook daily as a cron job to enforce state. The opposite is a script that blindly runs apt install nginx — it would reinstall or error. Always write tasks that check state before acting. Use state: present or state: absent rather than state: latest unless you want upgrades.

# io.thecodeforge — DevOps tutorial
---
- name: Idempotent user management
  hosts: all
  become: yes
  tasks:
    - name: Ensure deploy user exists
      user:
        name: deploy
        state: present
        groups: sudo
    - name: Ensure old temp user is removed
      user:
        name: tempuser
        state: absent