bongoDev

Ansible is easiest to learn when you stop thinking of it as “SSH plus YAML” and instead see it as an automation engine that turns inventory + intent into controlled actions on systems.

The architecture

Text

Git repository / automation project
            |
            v
      Ansible control node
      - ansible-core
      - inventory
      - playbooks
      - collections/plugins
            |
      connection plugins
   SSH / WinRM / API / network CLI
            |
            v
       Managed targets
 Servers | cloud APIs | network devices | platforms

Ansible is commonly called agentless because you normally do not install a long-running Ansible agent on every Linux server. The control node connects using existing management protocols. That does not mean “no prerequisites”: many POSIX modules require a usable Python interpreter on the target, Windows commonly uses WinRM/PowerShell, and network/cloud automation may execute through APIs or specialized connection plugins.

Core vocabulary

Term	Meaning
Inventory	The hosts, groups and variables Ansible can target
Play	Maps a set of hosts to tasks, roles and execution settings
Task	One automation step
Module	The unit that performs work, such as package, service, copy or user management
Plugin	Extends behavior such as connections, lookups, callbacks, inventory or filters
Collection	Versioned distribution unit containing modules, plugins, roles and sometimes playbooks
Role	Reusable project structure for tasks, defaults, handlers, templates and related content
Fact	Data discovered about a managed target
Handler	A task triggered by a change, often used for controlled restarts

Desired state and idempotency

A good configuration task describes the state you want:

YAML

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

Run it once: Nginx may be installed. Run it again: a well-behaved module should report no change if the target already matches the requested state.

That property is idempotency. It is essential for repeatable automation, but it is not magic. A shell command such as this changes state every run:

YAML

- name: Bad repeatability example
  ansible.builtin.shell: echo "run" >> /tmp/history.log

Push model

A common Ansible workflow is push-oriented:

Text

Engineer / CI
    ↓
ansible-playbook
    ↓
Select inventory targets
    ↓
Gather context/facts if requested
    ↓
Run tasks in order
    ↓
Collect changed/failed/skipped results

Where Ansible fits

Use Ansible when you need to automate things such as:

OS configuration and package management
application deployment
service configuration
user and permission management
post-provisioning after Terraform/cloud creation
network device configuration
cloud API operations
operational runbooks
rolling changes across fleets

Terraform and Ansible can complement each other:

Text

Terraform: create infrastructure
      ↓
Ansible: configure systems and applications
      ↓
Observability: verify production behavior