Ansible Lesson 4 – Control Node and Managed Node | Dataplexa

Ansible Course

I. Ansible Fundamentals
1. What is Ansible 2. Why Configuration Management Matters 3. Ansible Architecture 4. Control Node and Managed Nodes 5. Installation and Setup 6. Ansible Configuration Files 7. Inventory Files Explained 8. Ansible Ad-hoc Commands 9. Ansible Modules Overview 10. Beginner Best Practices
II. Playbooks & Core Concepts
11. YAML Basics for Ansible 12. Playbooks Introduction 13. Writing Your First Playbook 14. Tasks, Handlers and Variables 15. Facts and Gathering Facts 16. Conditionals and Loops 17. Templates with Jinja2 18. File and Package Management 19. Service Management 20. User and Permission Management 21. Error Handling 22. Tags and Selective Execution 23. Roles Introduction 24. Creating and Using Roles 25. Playbook Best Practices
III. Security, Roles & Automation
26. Ansible Galaxy 27. Role Directory Structure 28. Ansible Vault 29. Managing Secrets Securely 30. Application Deployment 31. Server Hardening 32. Ansible with Docker 33. Ansible with Kubernetes 34. Troubleshooting 35. Performance Optimization
IV. Advanced Ansible & Real-World
36. Ansible at Scale 37. Ansible in CI/CD Pipelines 38. Ansible with Jenkins 39. Ansible Anti-Patterns 40. Mini Project
Section I · Lesson 4

Control Node and Managed Nodes

In this lesson

Control node requirements Managed node requirements SSH & privilege escalation Forks & parallelism Windows managed nodes

The control node is the machine where Ansible is installed and from which all automation is initiated — it is the brain of every playbook run. The managed nodes are the servers, cloud instances, or network devices that Ansible configures on your behalf. Understanding the requirements, responsibilities, and constraints of each side of this relationship is fundamental to designing reliable Ansible automation, because every connection problem, permission error, and performance limit in Ansible traces back to how these two sides interact.

The Control Node in Detail

The control node is where you write playbooks, run ansible-playbook commands, and store your inventory. It is the only machine in your infrastructure that needs Ansible installed. In small teams this is often a developer's laptop; in production environments it is typically a dedicated bastion host or a CI/CD runner such as a GitHub Actions worker or a Jenkins agent.

OS

Linux or macOS

Windows is not supported as a control node. Windows users must run Ansible inside WSL 2 or on a remote Linux host. This is a hard architectural constraint.

Runtime

Python 3.9+

Ansible itself is written in Python. The control node needs Python 3.9 or later. Most modern Linux distributions ship with a compatible version already installed.

Network

SSH outbound access

The control node must be able to reach every managed node over SSH (port 22 by default). Firewall rules must permit outbound connections from the control node to managed node IPs.

Storage

Playbooks & inventory

All YAML playbooks, inventory files, roles, and variable files live on the control node — typically inside a Git repository. Managed nodes store nothing permanently.

The Air Traffic Control Analogy

The control node is an air traffic control tower. It has complete visibility of everything happening, issues precise instructions to each aircraft (managed node), and tracks the outcome of every instruction. The aircraft do the actual flying — the tower never leaves the ground. If the tower goes offline, no new instructions can be issued, but aircraft already airborne continue on their current heading. Similarly, Ansible tasks already running on managed nodes will complete even if the control node loses connectivity mid-run.

Managed Node Requirements

One of Ansible's most compelling features is how little it demands of managed nodes. There is no agent to install, no daemon to keep running, and no port to open beyond standard SSH. This makes Ansible usable on virtually any existing Linux or Unix server without any preparation work.

What every managed node needs

SSH server running The managed node must have an SSH server (sshd) running and accepting connections. This is the default state on virtually all Linux servers.
Python installed Python 2.7 or Python 3.5+ must be available on the managed node. Ansible transfers modules as Python scripts and executes them remotely — Python is the runtime that runs them.
A valid user account Ansible connects using a regular user account with SSH key authentication. The account needs either sudo access or root login for tasks that require elevated privileges.
Network reachability The managed node must be reachable from the control node over the network on SSH port 22 (or a configured alternative port). VPNs, bastion hosts, or jump servers can bridge network gaps.

SSH and Privilege Escalation

Ansible connects to managed nodes using standard SSH. For most tasks — installing packages, restarting services, editing system files — the connecting user needs elevated privileges. Ansible handles this through privilege escalation, most commonly via sudo. Here is how a typical privileged connection flows:

Step 1

SSH key authentication

Ansible connects using an SSH private key on the control node. The corresponding public key must be in the managed node's ~/.ssh/authorized_keys file. Password authentication is supported but strongly discouraged in automation.

Step 2

Connect as a non-root user

Best practice is to connect as a dedicated automation user — not root. This gives you an audit trail of which tasks ran under which account, and follows the principle of least privilege. Set this in your inventory with ansible_user.

Step 3

Escalate with become

For tasks that require root — installing packages, modifying system files — add become: true to your play or task. Ansible will run sudo on the managed node to elevate privileges automatically. become_user lets you escalate to any specific user, not just root.

Step 4

Execute and clean up

The module runs under the escalated user, completes its task, returns a JSON result to the control node, and removes any temporary files it created. The SSH connection closes once all tasks for that host are finished.

- name: Install and start Nginx
  hosts: webservers
  become: true          # escalate to root for all tasks in this play
  tasks:
    - name: Install Nginx
      ansible.builtin.package:
        name: nginx
        state: present  # Ansible runs this as root via sudo

Forks and Parallelism

One of Ansible's practical strengths is that it manages multiple hosts simultaneously. This is controlled by the forks setting — the number of managed nodes Ansible connects to and tasks in parallel at any one time.

The default fork count is 5. With 100 managed nodes and 5 forks, Ansible processes the first 5 nodes, waits for all 5 to finish each task, moves to the next 5, and so on. Increasing forks speeds up large playbook runs but increases load on the control node and network. The right number depends on your infrastructure size and the control node's resources.

5

Default forks — fine for small to medium fleets

50+

Common in large environments with a powerful control node

-f N

CLI flag to override forks at runtime without editing config

Windows as a Managed Node

Windows cannot be a control node, but it can be a managed node. Instead of SSH, Ansible uses WinRM (Windows Remote Management) to connect to Windows hosts. The module names differ too — Windows modules use the ansible.windows or community.windows collection prefix rather than ansible.builtin.

Linux / Unix managed node
Connects via SSH (port 22)
Requires Python on the managed node
Uses ansible.builtin.* modules
Privilege escalation via sudo / become
Windows managed node
Connects via WinRM (port 5985/5986)
Requires PowerShell 3.0+ and .NET 4.0+
Uses ansible.windows.* modules
Privilege escalation via runas / Windows credentials

Never Connect as Root Directly

Configuring Ansible to SSH directly as the root user is a serious security risk and bad practice. If your automation account is ever compromised, an attacker has immediate root access to every managed node in your inventory. Always connect as a non-root user and use become: true only for the specific tasks that require elevated privileges. Most cloud providers disable root SSH login by default for exactly this reason.

Key Takeaways

✓
The control node needs Python 3.9+ and Linux or macOS — it is the only machine in your infrastructure that requires Ansible to be installed, and Windows is not a supported control node OS.
✓
Managed nodes only need SSH and Python — no agent, no daemon, no special preparation beyond what a standard Linux server already has out of the box.
✓
Use become: true for privilege escalation — connect as a non-root user and escalate only for tasks that require root, following the principle of least privilege.
✓
Forks control parallelism — the default of 5 is conservative; increase it for large fleets, but balance it against your control node's capacity and network bandwidth.
✓
Windows is a valid managed node — it uses WinRM instead of SSH and a different module collection, but the playbook structure and Ansible concepts remain identical.

Teacher's Note

Set up SSH key authentication between your control node and at least one managed node this week — every practical lesson from Lesson 8 onwards depends on it, and debugging SSH issues mid-lesson slows everyone down.

Practice Questions

1. What Ansible keyword do you add to a play or task to enable privilege escalation via sudo?



2. What is Ansible's default number of forks — the number of managed nodes it connects to in parallel?



3. What connection protocol does Ansible use to manage Windows nodes instead of SSH?



Quiz

1. What is the recommended way to handle privilege escalation when Ansible needs to run tasks as root?


2. Ansible has 100 managed nodes and a fork count of 10. How does it process the nodes?


3. A freshly provisioned Linux server has SSH enabled but no Python installed. What happens when Ansible tries to run a task on it?


Up Next · Lesson 5

Installation and Setup

Install Ansible on your control node, verify the setup, and run your very first command against a managed node.

← Previous Course Index Next →