Chapter 1: Introduction to Ansible

Learning Objectives

By the end of this chapter, you will be able to:

• Define what Ansible is and explain its core purpose in IT automation
• Describe Ansible's agentless architecture and understand why it matters
• Explain the concepts of idempotency and why Ansible operations are safe to repeat
• Differentiate Ansible from other automation tools like Chef, Puppet, and Terraform
• Identify and define key Ansible terminology: playbooks, modules, inventory, tasks, roles, and facts

Explanation

What Is Ansible?

Ansible is an open-source automation tool that simplifies complex infrastructure management. It allows you to define the desired state of your systems in configuration files, and Ansible ensures that state is achieved—no more manual configuration or forgotten setup steps.

Think of Ansible as a highly reliable robot that follows your instructions precisely. You tell it what to do (install a package, create a user, deploy an application), and Ansible figures out how to do it on your behalf. Unlike scripts that assume everything is already set up, Ansible understands the current state of your systems and only makes necessary changes.

The primary use cases for Ansible include:

• Configuration Management: Defining and maintaining consistent configurations across all servers
• Application Deployment: Automating the deployment of applications to multiple environments
• Provisioning: Setting up new infrastructure components
• Orchestration: Coordinating multi-tier applications and complex workflows

A Brief History

Ansible was created by Michael DeHaan in 2012 and acquired by Red Hat in 2015. It quickly gained popularity because of its simplicity and agentless design. Today, Ansible is the de facto standard for configuration management in countless organizations, from startups to Fortune 500 companies.

The Agentless Architecture

Unlike many other automation tools, Ansible does not require an agent to be installed on the target machines. This is one of Ansible's greatest strengths. Here's how it works:

1. You run Ansible from a control node (your laptop, a server, or a CI/CD system)
2. Ansible connects to managed hosts via SSH (for Linux/Unix) or WinRM (for Windows)
3. Ansible sends small programs called "modules" to the managed hosts
4. These modules make the actual changes on the target systems
5. After execution, Ansible removes these modules from the targets

This approach means:

• No daemon to manage or update on target systems
• No security vulnerabilities in agent software
• Minimal resource usage on managed hosts
• Easy adoption—you already have SSH access to most systems

Pro Tip: For Windows targets, Ansible uses PowerShell Remoting (WinRM) which must be configured beforehand. This is a common stumbling block for beginners managing Windows infrastructure.

Idempotency: The Safety Feature

Idempotency is a mathematical property meaning an operation produces the same result regardless of how many times it runs. In practical terms, Ansible playbooks can be run repeatedly and will only make changes when necessary to reach the desired state.

Consider this example: If your playbook specifies that the ntp package should be installed, Ansible will:

• Install ntp if it's not present
• Do nothing if ntp is already installed
• Report "changed": false in the second case

This behavior makes Ansible safe to run in production. You can execute the same playbook daily to ensure compliance without worrying about unintended modifications. This is fundamentally different from traditional shell scripts that might install software multiple times or create duplicate entries.

Ansible vs. Other Tools

Here's how Ansible compares to other popular automation and infrastructure tools:

Feature	Ansible	Chef	Puppet	Terraform
Architecture	Agentless	Agent-based	Agent-based	Agentless (stateful)
Language	YAML	Ruby DSL	Ruby DSL	HCL/JSON
Learning Curve	Low	Medium-High	Medium-High	Medium
State Management	Configuration	Configuration	Configuration	Infrastructure
Primary Use	Config + Deploy	Config + Deploy	Config	Provision + Config
Execution Model	Push	Pull	Pull	Push

Key Distinctions:

• Ansible vs. Chef/Puppet: Ansible uses a push model (you initiate actions) while Chef and Puppet use a pull model (agents periodically check for updates). Ansible's push model gives you more immediate control.

• Ansible vs. Terraform: Terraform is primarily an infrastructure provisioning tool. It excels at creating cloud resources (VMs, networks, storage). Ansible excels at configuring those resources once created. Many organizations use both: Terraform to provision, Ansible to configure.

Pro Tip: Use Ansible for configuration management and application deployment. Use Terraform (or similar IaC tools) for infrastructure provisioning. These tools are complementary, not competing.

Key Ansible Terminology

Understanding these terms is essential before diving deeper:

Inventory: A file (or dynamic source) that lists all the hosts Ansible manages. The inventory defines hosts, groups, and variables that apply to specific machines.

Modules: The units of work Ansible executes. Modules are pre-built, reusable scripts that perform specific tasks like installing packages, creating users, or copying files. Ansible ships with hundreds of built-in modules.

Tasks: Individual units of work within a playbook. Each task calls a specific module with desired parameters.

Playbooks: YAML files that organize tasks into a coherent workflow. Playbooks define what to do (tasks) and on which hosts (inventory).

Roles: A way to organize playbooks, tasks, variables, files, and templates into a reusable structure. Roles promote code reuse and modularity.

Facts: Information Ansible automatically collects from managed hosts (operating system, IP addresses, disk space, etc.). Facts are stored in variables prefixed with ansible_ and can be used in playbooks.

Handlers: Special tasks that only run when triggered by a notify directive. Handlers are typically used for actions that need to happen after changes, like restarting a service after a configuration file modification.

Examples

Understanding the Ansible Ecosystem

┌─────────────────────────────────────────────────────────────┐
│                    Your Control Node                         │
│  ┌─────────────┐  ┌──────────────┐  ┌───────────────────┐  │
│  │ Inventory   │  │ Playbooks    │  │ Ansible Config    │  │
│  │ (hosts.yml) │  │ (deploy.yml) │  │ (ansible.cfg)     │  │
│  └─────────────┘  └──────────────┘  └───────────────────┘  │
└─────────────────────────────────────────────────────────────┘
                              │
                              │ SSH / WinRM
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                    Managed Hosts                             │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐       │
│  │Server 1 │  │Server 2 │  │Server 3 │  │Server N │       │
│  │(web)    │  │(app)    │  │(db)     │  │(cache)  │       │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘       │
└─────────────────────────────────────────────────────────────┘

What Ansible Code Looks Like

Here's a preview of what Ansible configuration looks like. Don't worry if this seems complex—you'll understand every part by the end of Chapter 5.

Inventory (hosts.ini):

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com

Playbook (deploy.yml):

---
- name: Deploy web application
  hosts: webservers
  become: yes
  tasks:
    - name: Install Nginx
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: Start Nginx service
      ansible.builtin.service:
        name: nginx
        state: started

Fact Collection Example

When Ansible connects to a host, it automatically gathers information about that system:

---
# Ansible collects facts automatically; you can use them in templates or conditionals
- name: Display system information
  hosts: all
  tasks:
    - name: Show hostname
      ansible.builtin.debug:
        var: ansible_facts['hostname']

    - name: Show operating system
      ansible.builtin.debug:
        var: ansible_facts['os_family']

    - name: Show total memory in MB
      ansible.builtin.debug:
        var: ansible_facts['memtotal_mb']

Running this playbook would produce output like:

TASK [Show hostname]
ok: [webserver1] => {
    "ansible_facts['hostname']": "webserver1"
}
TASK [Show operating system]
ok: [webserver1] => {
    "ansible_facts['os_family']": "Debian"
}
TASK [Show total memory in MB]
ok: [webserver1] => {
    "ansible_facts['memtotal_mb']": "2048"
}

Hands-On Exercises

Exercise 1: Identify Your Learning Environment

Objective: Verify you understand the basic Ansible architecture by identifying your control node and managed hosts.

Expected Outcome: Document your understanding of which machine will run Ansible and which machines it will manage.

Hint: The control node is where you install Ansible and run commands. Managed hosts are the machines you configure. In a typical learning setup, your laptop might be the control node and 1-2 virtual machines are managed hosts.

---

Exercise 2: List Ansible Key Terms

Objective: Create a reference document that defines each of the following terms in your own words: inventory, modules, tasks, playbooks, roles, facts, handlers.

Expected Outcome: A written explanation of each term demonstrating understanding of what it represents in the Ansible ecosystem.

Hint: Try explaining each term to someone without technical background. If you struggle, re-read the "Key Ansible Terminology" section and translate each term into a one-sentence explanation.

---

Exercise 3: Research Your Infrastructure

Objective: Identify 3-5 servers or systems you might want to manage with Ansible in a real scenario.

Expected Outcome: A list of target systems with their connection methods (SSH for Linux/Unix, WinRM for Windows), operating systems, and what configuration tasks you would automate on each.

Hint: Consider what repetitive tasks you currently do manually. Installing updates, configuring users, deploying applications, and managing firewall rules are common candidates for Ansible automation.

---

Exercise 4: Compare Ansible to Scripts

Objective: Write a comparison between an Ansible playbook and a bash script that both accomplish the same task (e.g., creating a user).

Expected Outcome: A side-by-side comparison showing the bash approach and Ansible approach, highlighting differences in idempotency, readability, and error handling.

Hint: A bash script creating a user might run useradd every time. An Ansible task using the user module checks if the user exists first. Notice how Ansible naturally handles the "already exists" case.

---

Exercise 5: Explore Ansible Documentation

Objective: Navigate to the official Ansible documentation at https://docs.ansible.com and find the list of available modules.

Expected Outcome: Identify at least 3 module categories (e.g., system, packaging, files) and list 2-3 specific modules from each category that seem useful.

Hint: The "Module Index" link on the Ansible documentation homepage organizes modules by category. Pay attention to the ansible.builtin namespace for core modules that ship with Ansible.

Summary

• Ansible is an open-source automation tool for configuration management, application deployment, and infrastructure provisioning
• Its agentless architecture means no software needs to be installed on managed hosts—Ansible connects via SSH or WinRM
• Idempotency ensures Ansible operations are safe to repeat, only making changes when necessary to reach desired state
• Ansible uses YAML for configuration files, making it accessible to non-programmers
• Key terminology includes: inventory (host list), modules (work units), tasks (individual actions), playbooks (task collections), roles (organized reusable components), facts (system information), and handlers (triggered actions)
• Ansible complements tools like Terraform: use Terraform for infrastructure provisioning, Ansible for post-provision configuration

Additional Resources

1. Official Ansible Documentation: https://docs.ansible.com/ The comprehensive guide to Ansible, including module references, best practices, and tutorials.

2. Ansible GitHub Repository: https://github.com/ansible/ansible The open-source codebase. Explore the community modules and contribute if you have fixes or improvements.

3. Ansible Blog - Getting Started: https://www.ansible.com/blog/getting-started Red Hat's curated resources for Ansible beginners, including webinars, whitepapers, and practical guides.

---

← Back to Home

First Module Next: Installation →