DEV Community

Cover image for Getting Started with Ansible: A Practical Guide for DevOps Newcomers
Scott Gordon
Scott Gordon

Posted on

Getting Started with Ansible: A Practical Guide for DevOps Newcomers

Introduction

DevOps emphasizes automation to make infrastructure management more efficient and consistent. Ansible is a super-star in the automation realm, known for its simplicity and effectiveness. In this tutorial, we'll dive into the fundamentals of Ansible and walk through a practical demonstration.

Prerequisites

  • A basic grasp of Linux/Unix command-line environments.
  • A control machine (your laptop/desktop) with Python installed.
  • One or more remote Linux servers you can SSH into.

Benefits of Ansible

  • Agentless: No need to install software on your managed servers.
  • Simple Syntax: Human-readable YAML playbooks define your tasks.
  • Idempotent: Tasks can be run repeatedly, desiring the same end state.
  • Extensible: Hundreds of built-in modules to interact with common systems.

Use Cases

  • Configuration Management: Keep servers in a consistent, defined state.
  • Software Deployment: Install and update applications across many servers.
  • Orchestration: Automate complex tasks spanning multiple systems.
  • Server Provisioning: Set up new servers quickly and consistently.

Tutorial

Install Ansible (Control Machine)

pip install ansible
Enter fullscreen mode Exit fullscreen mode

Create an Inventory File called hosts in your working directory
(hosts)

[webservers]
<SERVER1_IP_ADDRESS_GOES_HERE>
<SERVER2_IP_ADDRESS_GOES_HERE>
Enter fullscreen mode Exit fullscreen mode

Test Connectivity

ansible all -m ping
Enter fullscreen mode Exit fullscreen mode

Make sure you have SSH access to remote servers (using keys or password).

Create Your First Playbook
(demo.yml)

---
- hosts: webservers
  become: true  # Use sudo privileges if needed
  tasks:
    - name: Install Apache Web Server
      apt:
        name: apache2
        state: latest
    - name: Ensure Apache is running
      service:
        name: apache2
        state: started
Enter fullscreen mode Exit fullscreen mode

Run the Playbook

ansible-playbook demo.yml -i hosts 
Enter fullscreen mode Exit fullscreen mode

Double check that Apache is running on each server by SSHing into each and running

sudo systemctl status apache2
Enter fullscreen mode Exit fullscreen mode

Explanation

  • Playbooks are YAML files expressing your configuration "plays".
  • hosts targets groups of servers from your inventory.
  • become provides superuser privileges for commands if necessary.
  • tasks are individual units of work (uses Ansible modules).
  • modules (like apt and service) manage packages, services, files, etc. Next Steps

Explore more Ansible modules: Modules
Learn about variables and templates for dynamic configuration. Templating
Dive into Ansible roles for organizing complex playbooks. Roles

Takedown Instructions

To reverse the changes made during this tutorial, consider these steps:

1. Undoing Package Installations

  • If you installed packages using Ansible's apt (Debian/Ubuntu) or yum (RedHat/CentOS) modules, use the following commands to remove them:

    ansible-playbook -i hosts rollback.yml 
    

    Create a rollback.yml file:

    ---
    - hosts: webservers 
      become: true
      tasks:
        - name: Remove Apache Web Server
          apt:
            name: apache2
            state: absent 
    

    (Customize based on installed packages)

2. Stopping Services

  • If you started services:

    - name: Ensure Apache is stopped
      service:
        name: apache2
        state: stopped
    

3. Reverting Configuration Files

  • If you modified configuration files, it's best to:
    • Restore from backups if you created them before applying Ansible changes.
    • Manually edit the files to revert changes (this requires specific knowledge of your configurations).

Important Notes

  • Carefully review the original playbook to identify all the actions performed.
  • Create Ansible tasks tailored to reverse these actions when possible.
  • Always test takedown procedures in a non-production environment first!

Photo by Growtika on Unsplash

Top comments (0)