Ansible Fundamentals

Concept Overview Many configuration management tools -- Puppet, Chef, SaltStack in its traditional mode -- require you to install a persistent agent daemon on every managed server. That agent has to be installed, kept patched, and kept running, and it typically phones home to a central master server on a schedule. Ansible takes a different approach: it is agentless. There is no daemon running on the servers it manages. Instead, Ansible connects to each target host over standard SSH, copies a small Python script (the 'module' that implements whatever task you asked for, such as installing a package) to a temporary location on the target, executes it, captures the result, and then removes it.

This has real operational consequences. You don't need to pre-provision every new server with an agent before Ansible can manage it -- if a server has SSH access and Python installed, Ansible can manage it today. There's no extra attack surface from a long-running daemon, and no agent version-compatibility matrix to track across your fleet. The control node -- the machine you run Ansible from -- is the only place Ansible itself needs to be installed.

Internal Working

• Ansible uses SSH (or WinRM for Windows targets) as its transport; it reuses your existing SSH keys and configuration, including ProxyJump/bastion setups.
• For each task, Ansible generates a small Python program embedding the module logic and the parameters you gave it, pushes it over SFTP/SCP, executes it remotely, parses the JSON result it prints, then cleans up.
• Connections can be pipelined and parallelized -- Ansible runs tasks across many hosts concurrently (controlled by the forks setting), rather than one host at a time.
• Because everything travels over SSH, the same authentication, logging, and bastion-host practices you already use for manual access apply directly to Ansible's access.

Why It Matters Agentless design lowers the barrier to adopting Ansible -- there's no fleet-wide agent rollout project before you can start -- and it keeps the attack surface and operational overhead on managed servers close to zero.

Concept Overview An inventory file tells Ansible which hosts exist and how they're grouped. In its simplest form it's an INI-style text file with hostnames or IP addresses under group headers in square brackets. A host can belong to multiple groups -- for example, a server can be in both [webservers] and [production] -- and you can target either group independently when you run a playbook or command. Groups can also be nested using [group:children], so [production:children] could pull in both webservers and databases.

Inventories aren't limited to static text files. For cloud environments where servers come and go, Ansible supports dynamic inventory -- a script or plugin that queries a cloud provider's API (AWS, Azure, GCP) at run time and builds the host list automatically, so you never hand-maintain IP addresses that change on every deploy.

Internal Working

• The default inventory location is /etc/ansible/hosts, but in practice almost every team keeps an inventory.ini (or inventory/ directory) inside their project repo and points Ansible at it with -i inventory.ini or an ansible.cfg setting.
• Variables can be attached directly in the inventory (web1 ansible_host=10.0.0.5 ansible_user=deploy) or, more commonly, in separate group_vars/ and host_vars/ directories that Ansible loads automatically based on group and host names.
• The special group all always exists and matches every host in the inventory.
• ansible-inventory --list -i inventory.ini prints the fully resolved inventory, including group membership and variables, which is the fastest way to debug 'why didn't my playbook target that host'.

Why It Matters The inventory is the single source of truth for 'what servers do we have and how are they grouped' -- every playbook and ad-hoc command targets a pattern against this file, so getting its structure right is the foundation everything else builds on.

Concept Overview Not every task needs a full playbook. Ansible's ad-hoc command mode lets you run a single module against a group of hosts directly from the command line, which is ideal for quick operational questions: 'is this service running everywhere?', 'what's the disk usage on all web servers?', 'reboot every host in the staging group'. The basic form is ansible <pattern> -m <module> -a '<arguments>', where the pattern selects hosts from your inventory (a group name, all, a wildcard, or a comma-separated list) and the module is the specific unit of work to perform.

Ad-hoc commands use exactly the same modules that playbooks use -- there's no separate 'ad-hoc' module set -- so what you learn running ansible webservers -m ping transfers directly to writing playbook tasks later. The most common starting point is the ping module, which doesn't send an ICMP ping at all; it verifies that Ansible can connect over SSH and that Python is available on the target, which is the standard first health check after setting up a new inventory.

Internal Working

• ansible webservers -m ping checks connectivity; ansible all -m setup gathers and prints full facts (OS, memory, network interfaces) about every host.
• ansible webservers -a "uptime" with no -m flag defaults to the command module, running a raw shell command -- useful for diagnostics, but not idempotent, so it's a poor substitute for playbook tasks in real automation.
• ansible webservers -b -m service -a "name=nginx state=restarted" demonstrates -b (become, i.e. use sudo) combined with a real module for a privileged one-off action.
• Ad-hoc commands don't get saved or version-controlled by default, which is exactly why they're for quick exploration and incident response, not for anything you want to be repeatable or reviewable -- that's what playbooks are for.

Why It Matters Ad-hoc commands are how most people's first successful Ansible run happens, and they remain the fastest tool for one-off fleet-wide questions and actions throughout day-to-day operations.