Ansible Fundamentals · Module 01 of 12

Why automation?

Understand the operational problem Ansible solves: repetition, inconsistency, drift and lack of repeatable evidence.

Learning objectives

By the end of this module, you should be able to:

Explain why manual administration becomes risky as systems grow.
Define automation, desired state and idempotence in practical terms.
Recognize when a task is a good candidate for Ansible.

The real problem is not typing speed

Imagine ten Linux servers need the same user, package and service configuration. Doing the work manually may succeed once, but every extra server increases the chance of skipped steps, different commands, missed verification and poor auditability.

Automation turns an administrator's intention into a repeatable procedure. Instead of remembering what to type on every host, you describe what should be true and let the automation apply that intent consistently.

Repetition creates human error.
Manual changes are difficult to reproduce.
Configuration drift appears when servers are changed differently over time.
Automation gives you a reviewable artifact that can be stored in source control.

Idempotence: safe repetition

A well-designed Ansible task usually describes a desired state. If a package is already installed or a service is already running, rerunning the playbook should report that the system is already correct instead of making unnecessary changes.

This property is called idempotence. It is one of the reasons configuration-management automation is safer than a long sequence of shell commands that blindly changes a system every time it runs.

Where Ansible fits

Ansible is commonly used for configuration management, application deployment, provisioning workflows, patch orchestration, compliance changes and repeatable operational tasks. It is especially useful when many systems need the same controlled change.

Worked examples

See the idea in practice.

Manual repetition

ssh web01 sudo dnf install -y nginx
ssh web02 sudo dnf install -y nginx
ssh web03 sudo dnf install -y nginx

The same intention is repeated three times.
A missed host or command variation creates drift.
There is no reusable description of the desired fleet state.

Ansible expresses the desired state

- name: Ensure nginx is installed
  ansible.builtin.package:
    name: nginx
    state: present

The task states the outcome, not a distro-specific install command.
If nginx is already present, the task should normally remain unchanged.
The same task can be applied to a group of hosts.

Hands-on lab

Lab — Identify automation candidates

Goal: Practice deciding which administration tasks should be automated before writing any Ansible code.

STEP 1

List five tasks

Write five Linux tasks you perform more than once, such as user creation, package installation, service configuration, log collection or configuration-file deployment.

STEP 2

Classify each task

Mark whether the task is repetitive, deterministic, verifiable and safe to rerun. Tasks with all four properties are strong automation candidates.

STEP 3

Define the desired state

For one task, write the result you want rather than the command you normally type. Example: 'nginx is installed, enabled and running'.

Verify

Can you state the desired outcome without mentioning a shell command?
Can the task be safely repeated?
Can you define how you would verify success?

Expected outcome

At least one candidate task is described as a desired state.
The learner distinguishes a repeatable operational goal from a one-off exploratory action.

If it fails

If a task depends on judgement every time, split the judgement step from the deterministic implementation step.
If rerunning a task could destroy data, add safeguards before considering automation.

Real-world connection

Teams often begin automation by converting frequent, well-understood manual runbooks into reviewed playbooks.

Avoid these traps

Common mistakes

Automating a poorly understood manual process without first defining the desired result.
Assuming automation automatically makes a dangerous task safe.
Writing shell commands when a purpose-built Ansible module can express the desired state.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1Why is configuring twenty servers manually riskier than configuring one?

Because repetition increases the chance of skipped steps, inconsistent commands and configuration drift.

2What does idempotence mean here?

Rerunning automation should keep the system in the desired state without unnecessary repeated changes.

3What should you define before choosing an Ansible module?

The desired operational result and how success will be verified.