Ansible OEL 8 DevOps · OEL 8 · Beginner

Ansible — Introduction & Architecture

What Ansible is, why it became the default config-management choice, and how a control node orchestrates dozens of managed nodes over plain SSH — with no agent installed on the target.

Architecture Overview

Ansible is an agent-less, push-based automation engine. You write what the desired end state looks like in YAML, run ansible-playbook from your laptop or CI runner (the control node), and Ansible reaches out over SSH to one or more managed nodes to make reality match the declaration.

There is nothing to install on the managed nodes beyond what comes with a stock OEL 8 image — Python 3 ships in the base install. Ansible compiles each task into a small Python script, copies it over SSH, executes it, captures the result, and removes it. The remote machine doesn't run any persistent daemon, doesn't open any extra ports, and doesn't need an Ansible-specific account.

Why Ansible (vs Chef / Puppet / Salt)

Dimension	Ansible	Chef / Puppet / Salt
Architecture	Agent-less, push-based	Agent-based, pull-based
Language	YAML (declarative)	Ruby DSL / custom DSL
Bootstrap	SSH + Python 3 (already on OEL 8)	Install agent on every node first
Learning curve	Hours	Days
Best for	App config, orchestration, ad-hoc fixes	Long-running fleet management

Core Concepts You'll See Throughout This Series

Term	What it is
Control node	The machine that runs `ansible-playbook`. Your laptop or a CI runner.
Managed node	A target server Ansible configures over SSH (the OEL 8 boxes in our labs).
Inventory	List of hosts and groups Ansible can talk to. INI or YAML file, or a dynamic plugin.
Module	The unit of work. `ansible.builtin.user`, `community.mysql.mysql_db`, etc.
Task	One invocation of a module with arguments.
Play	A mapping of which hosts to which tasks.
Playbook	A YAML file containing one or more plays.
Role	A reusable bundle of tasks, variables, templates, and files.
Collection	A namespaced bundle of roles + modules + plugins, distributed via Galaxy.

How a Single Play Executes

Walking through what happens when you run ansible-playbook site.yml:

Read playbook — Ansible parses the YAML and resolves any imports or includes.
Resolve hosts — host patterns (e.g. databases:&production) are matched against the inventory.
Gather facts — runs the setup module on each host to collect OS, network and hardware info.
Per task per host — compile module to Python, ship it via SSH, execute it remotely, clean up.
Recap — at the end every host gets a one-line summary: ok / changed / unreachable / failed.

Try the One-Liner First

You don't need a playbook to use Ansible. The simplest possible thing is an ad-hoc command:

BASH — Ad-hoc ping all hosts in inventory

# install ansible on the control node (OEL 8)
sudo dnf install -y python3-pip
pip3 install --user ansible

# create a tiny inventory
echo "[oel8]
192.168.56.11
192.168.56.12" > hosts.ini

# ping every host (uses Python, not ICMP)
ansible -i hosts.ini oel8 -m ansible.builtin.ping

✅ Tip: If you get SUCCESS => ping: pong back from each host, you have a working Ansible setup. Everything else in this series builds on that.

What's Next in This Series

The next 8 pages of Section 1 — Basics walk you through installation, SSH key setup, the ansible.cfg reference, ad-hoc commands, the YAML primer, your first real playbook, the most-used modules, and the meaning of idempotency. By page 9 you'll be writing playbooks comfortably; the database-heavy lab content starts in Section 5.