Agentless, push-based

Every Ansible setup has exactly two kinds of machine. The control node is where Ansible is installed and where every command runs — ansible, ansible-playbook, ansible-inventory. The managed node s are the remote hosts it controls. That’s the entire cast — no server component, no message bus, no registration step:

┌──────────────┐    SSH (OpenSSH)     ┌──────────────┐
│ control node │ ───────────────────▶ │ linux hosts  │
│              │                      └──────────────┘
│  ansible-*   │
│  runs here   │    WinRM/SSH/PSRP    ┌──────────────┐
│              │ ───────────────────▶ │ windows hosts│
└──────────────┘                      └──────────────┘
  # connections go OUT from the control node;
  # nothing on a target listens for Ansible

Two words carry the whole design. agentless means nothing Ansible-specific is installed on managed nodes. Linux targets are reached over OpenSSH, the default connection, which your servers already run. Windows targets connect via WinRM, SSH (officially supported since ansible-core 2.18 ) or PSRP — Unit 8 covers all of that. Push-based means the control node initiates every connection, outward. Nothing on a target polls for changes, checks in with a server, or applies configuration on a schedule. Between runs, your servers don’t know Ansible exists.

One hard limit: the control node cannot be native Windows. The official OS guide is blunt — “Ansible cannot run on Windows as the control node due to API limitations on the platform.” WSL or a container works. Lesson 5 covers that, including a genuine contradiction in the docs about WSL in production.

What a task actually does on the node

For each task, the control node copies the module’s code to the managed node, executes it there, and removes it. Next task: fresh copy, fresh process. The consequence: state does not persist between tasks. The only survivors are registered variables — output you capture explicitly — and facts, the system data Ansible gathers about a host (lesson 17):

- name: Read the running kernel # executes on the managed node...
  ansible.builtin.command: uname -r
  register: kernel # ...and only this survives the task

- name: Use it in a later task
  ansible.builtin.debug:
    msg: 'Kernel: {{ kernel.stdout }}'

That’s the whole machine: one node reaches out, targets answer SSH or WinRM, modules visit and leave. When a colleague asks whether “Ansible is down” or where the service runs on a server: there isn’t one. Ansible lives only on the control node — and building one is where Unit 2 starts.