// learn · linux · rhce · 10 min

Ansible control node & inventory.

Ansible is agentless — one control node pushes Python modules to a whole fleet over SSH, with nothing to install on the targets. Watch the model go from `dnf install ansible-core` to a live ad-hoc command fanning out across grouped hosts.

Ansible control node and inventory animated tutorial. Agentless push architecture over SSH, installing ansible-core, writing INI and YAML inventories, host ranges, groups and group_vars, testing connectivity with the ping module, ad-hoc commands with -m and -a, privilege escalation, and project defaults in ansible.cfg. RHCE EX294 ready.
// ansible · control node & inventory

Ansible is agentless: one control node pushes work to a fleet over SSH. Watch the model go from install → inventory → groups → a live ad-hoc command fanning out across hosts.

// before you start
you should know
  • ·Comfortable with SSH and SSH key auth
  • ·Basic Linux shell + package management (dnf)
  • ·Know what YAML looks like (helps, not required)
by the end you'll

Install Ansible on a control node, write an inventory with groups, prove connectivity with the ping module, and run ad-hoc commands across a fleet.

pace: 10 minutes

ansible — step 1 / 6 · the model
🛰️ control · ansible-corepushes over ssh →
🛰️ control node
│ ssh + python │
[webservers]
🖥️ servera○ idle
🖥️ serverb○ idle
[dbservers]
🖥️ serverc○ idle

Agentless push — how Ansible reaches a fleet

Ansible has no agent. The CONTROL NODE opens an SSH connection to each MANAGED NODE, copies a tiny Python module over, runs it, captures the result, and deletes it. Managed nodes need only an SSH server and Python — nothing to install, no daemon to keep alive. That's the whole architecture: push over SSH, run, clean up. Every module is written to be idempotent, so re-running a play changes nothing if the system already matches.

$dnf install ansible-core
$ansible --version
$ssh servera 'python3 --version'
// key insight

Everything in Ansible flows from one idea: the control node pushes Python over SSH and the managed nodes stay dumb. The inventory names the fleet, groups carve it into targets, the ping module proves the path, and ad-hoc commands let you act now — but the moment a task is worth repeating, it belongs in a playbook so it's idempotent and reviewable.

// exam-ready · control node, inventory & ad-hoc
$dnf install ansible-core
$ansible --version
$ansible all -m ping
$ansible all --list-hosts
$ansible GROUP --list-hosts
$ansible-inventory --graph
$ansible all -m setup
$ansible all -a "CMD"
$ansible H -m shell -a "a | b"
$ansible H -m dnf -a "name=X state=present" -b
$ansible H -m service -a "name=X state=started enabled=true" -b
$ansible H -m copy -a "src=… dest=…"
$-i inventory
$-u USER -b --become-user=root
$./ansible.cfg [defaults]
$ansible-config dump --only-changed
// check yourself
4 quick questions
Q1

What does a managed node need installed for Ansible to manage it?

Q2

`ansible all -m ping` returns SUCCESS → pong. What did that actually prove?

Q3

You want to install httpd on the webservers group, just once, right now, as root. Best ad-hoc command?

Q4

You run Ansible from a project directory that has its own ./ansible.cfg, and /etc/ansible/ansible.cfg also exists. Which wins?

These aren't graded — they're just for active recall, which is what actually makes the lesson stick.

🔑
// the thing Ansible rides on

SSH key authentication

Ansible is only as smooth as your SSH. Set up key-based auth to every managed node and `ansible all -m ping` just works — no passwords, no prompts.

open →

Read this lesson as text6 chapters · quiz answers

  1. 01Agentless push — how Ansible reaches a fleet

    Ansible has no agent. The CONTROL NODE opens an SSH connection to each MANAGED NODE, copies a tiny Python module over, runs it, captures the result, and deletes it. Managed nodes need only an SSH server and Python — nothing to install, no daemon to keep alive. That's the whole architecture: push over SSH, run, clean up. Every module is written to be idempotent, so re-running a play changes nothing if the system already matches.

    • $ dnf install ansible-core — install on the CONTROL node only
    • $ ansible --version — confirm + see config path used
    • $ ssh servera 'python3 --version' — managed node just needs ssh + python

  2. 02The inventory — who you manage

    An inventory lists the managed hosts. The default is /etc/ansible/hosts, but real projects keep a project-local file and pass it with -i inventory. It can be INI or YAML. Hosts are names or IPs; ranges collapse repetition — server[a:c] expands to servera, serverb, serverc. Two groups always exist implicitly: all (every host) and ungrouped (hosts in no group).

    • $ [webservers]\nserver[a:b].lab.example.com — INI: a group + a host range
    • $ ansible all --list-hosts -i inventory — what does Ansible think exists?
    • $ ansible-inventory -i inventory --graph — tree of groups → hosts

  3. 03Groups & group_vars — organise the fleet

    Group hosts by role, location, or stage — a host can belong to many groups at once. Nest groups with [parent:children] in INI (or children: in YAML) so all → production → webservers cascades. Variables that apply to a whole group live in group_vars/GROUPNAME (and per-host overrides in host_vars/HOST). Ansible loads them automatically — no -e needed.

    • $ ansible webservers --list-hosts — resolve a group to its hosts
    • $ group_vars/webservers.yml — vars auto-applied to the group
    • $ host_vars/servera.yml — per-host overrides win over group

  4. 04Test connectivity — the ping module

    ansible all -m ping is the first thing you run. It is NOT an ICMP ping — the ping module logs in over SSH, runs Python on the far side, and replies pong only if the whole path works. A green SUCCESS → pong proves SSH auth, Python, and (if used) privilege escalation are all healthy. Connection details come from vars: ansible_host, ansible_user, and --become/-b for sudo.

    • $ ansible all -m ping — SSH + Python reachability, not ICMP
    • $ ansible all -m ping -u devops -b — as user devops, escalate with sudo
    • $ ansible all -m setup — dump all gathered facts about a host

  5. 05Ad-hoc commands — one-off tasks, no playbook

    For a quick, one-shot action you don't need a playbook — ansible GROUP -m MODULE -a "ARGS". The default module is command (so -a "uptime" just runs uptime). Use shell when you need pipes or redirects. Add -b to escalate. Ad-hoc shines for checks and emergencies; anything you'll repeat belongs in a playbook so it's idempotent and reviewable.

    • $ ansible all -a "uptime" — command module is the default
    • $ ansible webservers -m dnf -a "name=httpd state=present" -b — install a package, as root
    • $ ansible all -m service -a "name=firewalld state=started enabled=true" -b — start + enable

  6. 06ansible.cfg — stop repeating yourself

    Typing -i inventory -u devops -b every time gets old. A project-local ansible.cfg sets those defaults. Precedence (first wins): ANSIBLE_CONFIG env var → ./ansible.cfg in the current dir → ~/.ansible.cfg → /etc/ansible/ansible.cfg. The project-local file is the convention — keep it beside your playbooks so the whole team gets the same inventory, remote_user, and become behaviour for free.

    • $ [defaults]\ninventory = ./inventory\nremote_user = devops — no more -i / -u flags
    • $ [privilege_escalation]\nbecome = true — escalate by default
    • $ ansible-config dump --only-changed — what did my cfg actually override?

Quiz — answers

What does a managed node need installed for Ansible to manage it?
→Only an SSH server and Python — Ansible is agentless and pushes modules over SSH, runs them, then removes them.Ansible's defining feature is that it's agentless. The control node copies a small Python module over SSH, executes it on the target, and cleans up. Nothing persistent runs on managed nodes.
ansible all -m ping returns SUCCESS → pong. What did that actually prove?
→SSH login worked, Python ran on the far side, and the result came back — the full management path is healthy. It is not an ICMP ping.The ping module is a connectivity test for the whole Ansible path: SSH transport + Python execution (+ privilege escalation if you pass -b). A normal ICMP ping would tell you none of that.
You want to install httpd on the webservers group, just once, right now, as root. Best ad-hoc command?
→ansible webservers -m dnf -a "name=httpd state=present" -bUse the dnf module (idempotent) with -b to escalate. The bare -a "dnf install httpd" runs the command module, which isn't idempotent and won't escalate without -b. There's no host called 'webservers' for plain ssh.
You run Ansible from a project directory that has its own ./ansible.cfg, and /etc/ansible/ansible.cfg also exists. Which wins?
→The project-local ./ansible.cfg wins — precedence is ANSIBLE_CONFIG env → ./ansible.cfg → ~/.ansible.cfg → /etc/ansible/ansible.cfg.The first match in that order is used wholesale (configs don't merge). A project-local ansible.cfg is the convention precisely because it overrides the system file for everyone working in that directory.
// more in systems

keep going — these pair well with what you just learned.

see all systems →
📜

Ansible playbooks & YAML

Plays, tasks, and idempotency. Watch a playbook run task-by-task — ok, changed, skipped — then run it again and watch everything go green with 0 changed. RHCE-ready.

12 min · interactiveopen →
🧩

Ansible core modules

file, user, copy, dnf, service — the modules that do the real work. Declare the desired state and let Ansible converge to it, idempotently. RHCE-ready.

10 min · interactiveopen →
🔢

Ansible variables & facts

Which value wins when the same variable is set in five places? Variable precedence, gathered facts, and ansible_facts — visualized as a ladder. RHCE-ready.

10 min · interactiveopen →

See also

back to RHCSA / RHCE trackall lessons