Ansible Lesson 1 – What Is Ansible | Dataplexa

Ansible Course

I. Ansible Fundamentals
1. What is Ansible 2. Why Configuration Management Matters 3. Ansible Architecture 4. Control Node and Managed Nodes 5. Installation and Setup 6. Ansible Configuration Files 7. Inventory Files Explained 8. Ansible Ad-hoc Commands 9. Ansible Modules Overview 10. Beginner Best Practices
II. Playbooks & Core Concepts
11. YAML Basics for Ansible 12. Playbooks Introduction 13. Writing Your First Playbook 14. Tasks, Handlers and Variables 15. Facts and Gathering Facts 16. Conditionals and Loops 17. Templates with Jinja2 18. File and Package Management 19. Service Management 20. User and Permission Management 21. Error Handling 22. Tags and Selective Execution 23. Roles Introduction 24. Creating and Using Roles 25. Playbook Best Practices
III. Security, Roles & Automation
26. Ansible Galaxy 27. Role Directory Structure 28. Ansible Vault 29. Managing Secrets Securely 30. Application Deployment 31. Server Hardening 32. Ansible with Docker 33. Ansible with Kubernetes 34. Troubleshooting 35. Performance Optimization
IV. Advanced Ansible & Real-World
36. Ansible at Scale 37. Ansible in CI/CD Pipelines 38. Ansible with Jenkins 39. Ansible Anti-Patterns 40. Mini Project
Section I · Lesson 1

What is Ansible

In this lesson

What Ansible is Agentless automation Idempotency Core use cases Ansible vs shell scripts

Ansible is an open-source IT automation tool that lets you configure systems, deploy software, and orchestrate complex workflows — all without installing any agent software on the machines you manage. It was created by Michael DeHaan in 2012, acquired by Red Hat in 2015, and is now one of the most widely adopted automation platforms in the industry. Ansible matters because it transforms manual, error-prone infrastructure tasks into repeatable, version-controlled code that any engineer on your team can run, review, and trust.

The Problem Ansible Solves

Before automation tools existed, operations teams managed servers by logging in one at a time, typing commands, and hoping each machine ended up in the right state. A team managing 50 servers might run the same command 50 times. A team managing 500 servers faced a genuine crisis every time a configuration needed to change.

Shell scripts helped, but they were brittle, hard to read, impossible to safely re-run, and offered no way to verify whether a change actually succeeded. What the industry needed was a tool that could express desired state — "I want all my web servers to have Nginx installed and running" — and handle the details of getting there safely. Ansible was built to solve exactly that problem.

5,000+

built-in modules covering cloud providers, network devices, databases, and more

Zero

agents required on managed nodes — only SSH and Python are needed

YAML

human-readable language for writing automation — no special programming knowledge required

1 SSH

connection is all Ansible needs to manage a remote host — the same one you already use

The Recipe Book Analogy

Think of Ansible like a professional recipe book for your infrastructure. A recipe (a playbook) describes exactly what a dish should look like when finished. The chef (Ansible) follows the recipe step by step, checks whether each ingredient is already present, and only adds what is missing. Run the same recipe twice and you get the same dish — no duplicates, no chaos.

Core Principles of Ansible

Ansible is built around four design decisions that make it fundamentally different from other automation tools. Understanding these principles early will help everything else in this course make sense.

Principle 1

Agentless

No software needs to be installed on the machines you manage. Ansible connects over SSH (or WinRM for Windows) and runs tasks remotely — your servers stay clean.

Principle 2

Idempotent

Running the same Ansible task twice produces the same result as running it once. If the desired state already exists, Ansible skips the step and reports ok.

Principle 3

Declarative

You describe what you want — "Nginx should be installed and running" — not how to get there. Ansible figures out the steps required.

Principle 4

Human-readable

Automation is written in YAML — a plain-text format that reads almost like English. A non-programmer can understand a playbook at a glance.

Idempotency Explained

Idempotency is the single most important concept to understand about Ansible. It means that running your automation multiple times is perfectly safe — and in fact encouraged. Ansible checks the current state of each resource before touching it. If a package is already installed, Ansible skips the install step and reports ok instead of changed.

This is the fundamental difference between Ansible and a shell script. A shell script that runs apt install nginx will attempt the installation every time, regardless of whether Nginx is already present. An Ansible task using the ansible.builtin.package module checks first, acts only when needed, and tells you exactly what it did.

# A single Ansible task — the simplest unit of automation.
# "state: present" is the declarative intent: Nginx must exist.
# Ansible checks whether it already does before doing anything.
- name: Ensure Nginx is installed
  ansible.builtin.package:
    name: nginx
    state: present   # install if missing; skip if already there

Common Use Cases

Ansible is general-purpose automation. It is used across industries for a wide range of tasks — all sharing one thing: a human used to do them by hand.

Use Case 1

Configuration Management

Keep every server in your fleet configured identically. Push a playbook that enforces your security baseline, timezone, NTP settings, and installed packages — across 10 or 10,000 servers in one command.

Use Case 2

Application Deployment

Deploy a new version of your application to all production servers simultaneously: pull the code, restart services, run health checks, and roll back automatically if something goes wrong — all defined in a single playbook.

Use Case 3

Cloud Provisioning

Spin up cloud resources — EC2 instances, Azure VMs, GCP buckets — and configure them immediately after creation. Ansible has modules for every major cloud provider and handles the full lifecycle from creation to teardown.

Use Case 4

Security & Compliance

Enforce CIS benchmarks, rotate credentials, manage firewall rules, and audit running services — all with auditable YAML that your security team can review in a pull request before it ever runs.

Use Case 5

Orchestration

Coordinate multi-step operations across multiple systems in a defined order — drain a load balancer, upgrade the app tier, run smoke tests, re-enable traffic. Ansible handles the sequencing so you don't have to.

Ansible vs Shell Scripts

Shell scripts are the most common comparison people make when first encountering Ansible. Both automate tasks — so why choose Ansible? The answer comes down to scalability, safety, and readability at scale.

Shell Scripts
Not idempotent — re-running can cause duplicate entries or errors
Requires extra work to run across many hosts in parallel
Error handling is manual and easy to forget
Hard to read and audit for anyone who didn't write it
Ansible
Idempotent by design — safe to run as many times as needed
Runs across thousands of hosts in parallel with a single command
Built-in error detection, failure thresholds, and rollback support
YAML is readable by devs, ops, and security reviewers alike

Don't Confuse Ansible with a Scripting Language

Ansible is not a general-purpose programming language or a replacement for Python or Bash when you need complex logic. It is an automation and orchestration tool that calls specialised modules on your behalf. Trying to force Ansible to do things that belong in a real programming language leads to unmaintainable playbooks — a trap that Lesson 39 (Ansible Anti-Patterns) covers in detail.

Key Takeaways

✓
Ansible is agentless — it connects over SSH and requires no software installation on managed nodes, keeping your infrastructure clean and simple.
✓
Idempotency is the core safety guarantee — running the same playbook multiple times is safe and always produces consistent, predictable results.
✓
Ansible uses YAML — human-readable automation that developers, ops engineers, and security reviewers can all understand and contribute to.
✓
Ansible scales from one host to thousands — the same command and playbook that configures a single dev server works identically across an entire production fleet.
✓
Ansible is declarative, not procedural — you describe the desired end state, and Ansible determines the steps required to reach it safely.

Teacher's Note

If idempotency clicks, the rest of this course will feel logical — keep that word front of mind as we build more complex automation. When in doubt, run your playbook twice and check that the second run reports zero changes.

Practice Questions

1. What word describes an operation that produces the same result whether it is run once or a hundred times?



2. What single word describes Ansible's approach of requiring no software to be installed on managed nodes?



3. Which protocol does Ansible use by default to connect to and manage Linux hosts?



Quiz

1. An Ansible task uses state: present to ensure a package is installed. The package is already installed. What does Ansible do?


2. What are the only two things Ansible needs on a managed node to function?


3. Ansible is described as declarative rather than procedural. What does this mean in practice?


Up Next · Lesson 2

Why Configuration Management Matters

Discover why manually managing servers at scale breaks down — and how configuration management restores order, consistency, and reliability.

Course Index Next →