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 is 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 in depth. 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, Ansible simply does not exist as far as your servers are concerned.

One hard limit before you get ideas about your work laptop: 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 using 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. Burn in the consequence now: state does not persist between tasks. Whatever the previous task’s process knew died with it. 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 that reaches out, targets that just answer SSH or WinRM, modules that visit and leave. So when a colleague asks whether “Ansible is down” or where the Ansible service runs on a server, you already know the answer: there isn’t one. The only place Ansible lives is the control node — and building one is exactly where Unit 2 starts.