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 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.
- ·Comfortable with SSH and SSH key auth
- ·Basic Linux shell + package management (dnf)
- ·Know what YAML looks like (helps, not required)
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
🛰️ control · ansible-corepushes over ssh →🖥️ servera○ idle🖥️ serverb○ idle🖥️ serverc○ idleAgentless 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'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.
$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-changedWhat does a managed node need installed for Ansible to manage it?
`ansible all -m ping` returns SUCCESS → pong. What did that actually prove?
You want to install httpd on the webservers group, just once, right now, as root. Best ad-hoc command?
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.
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.
keep going — these pair well with what you just learned.
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.
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.
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.