Node #

In Ansible automation terminology, the word node refers to a computing system entity — whether a physical server, virtual machine (VM), container, or network device. Ansible divides your infrastructure into two functionally very different node categories: the Control Node and the Managed Node. Understanding the role boundaries, system requirements, and security interactions between these two node types is essential for designing reliable, secure automation architecture ready for production-scale needs.

Control Node: The Orchestration Hub #

The Control Node is the operational heart of the entire Ansible ecosystem. This machine acts as the control center where you install the Ansible application, store inventory configuration, and write and run automation scenarios (playbooks). All logical decisions, task compilation, and result evaluation happen exclusively on this machine.

Control Node System Requirements: #

  • Operating System: Must be a Unix-like OS. This includes various Linux distributions (such as Ubuntu, Debian, RHEL, Rocky Linux), macOS, or BSD.
  • Python Interpreter: Requires a modern Python version (3.9 or later) because Ansible’s core engine is written in Python.
  • Network Access: Must be able to open outbound connections to target servers (usually via port 22 for SSH or port 5986 for WinRM).

Why Isn’t Native Windows Supported as a Control Node? #

Ansible relies on several internal Unix system calls (like fcntl, fork, and POSIX signal handling) to efficiently manage parallel task execution. Since Windows doesn’t have these native POSIX libraries, you can’t install Ansible core directly on the Windows operating system.

Windows Workaround: #

If you use a Windows-based laptop or workstation, you can use WSL (Windows Subsystem for Linux). WSL lets you run a complete Linux environment inside Windows without needing a heavy traditional virtual machine. Just install Ubuntu from the Microsoft Store inside WSL, then install Ansible inside it using pip3 or the system package manager.

# Example Ansible installation steps inside WSL (Ubuntu)
sudo apt update
sudo apt install -y python3-pip python3-venv
pip3 install ansible-core

Managed Node: The Automation Target #

A Managed Node is a target server whose configuration you manage with Ansible. These machines are often identified as application servers (web servers), database servers, cache servers, or even firewall devices in your inventory.

Unlike the Control Node, the system requirements for a Managed Node are minimal thanks to Ansible’s agentless architecture:

  • Active SSH Service: For Linux/Unix servers, the OpenSSH server service must be running and configured to accept connections from the Control Node.
  • Python Interpreter: Must have at least Python 3.x installed. Python is used to execute the temporary module scripts sent by the Control Node.
  • User Permissions: You need an SSH user account on the Managed Node with authority to run your automation tasks.

You don’t need to install Ansible on the Managed Node. This makes onboarding new servers very easy. Just make sure the SSH port is open and your SSH public key is registered on the target — the server is immediately ready to manage.

Privilege Escalation #

When managing target servers, many administrative tasks require superuser (root) access, such as installing packages, changing system configuration in /etc/, or restarting system services. Ansible handles this privilege escalation safely using the become parameter.

Behind the scenes, the become mechanism uses the target OS’s built-in escalation helper (by default sudo for Linux or enable for network devices).

Here’s an example of implementing privilege escalation in a playbook:

---
- name: Scenario with root privilege escalation
  hosts: webservers
  become: true          # Enables privilege escalation for all tasks in this play
  become_method: sudo   # Specifies the escalation method (sudo is the default)
  become_user: root     # Specifies the target user after escalation (root is the default)

  tasks:
    - name: Install a system package that requires root access
      apt:
        name: curl
        state: present

    - name: Task run as a regular user (without sudo)
      command: whoami
      become: false     # Disables escalation for this task only

Managing Sudo Authentication: #

There are two common ways to configure sudo authentication on Managed Nodes in your production environment:

  1. Passwordless Sudo (Recommended): Configure the Ansible user on the target so it can run sudo commands without being asked for a password (NOPASSWD). This method is strongly recommended for automation without human interaction (non-interactive CI/CD pipelines).
    # Configuration in the target's /etc/sudoers file:
ansible_user ALL=(ALL) NOPASSWD:ALL
  2. Sudo Password Prompt: If company security policy requires a password for every sudo access, you must include the --ask-become-pass argument (or -K) when running the playbook so Ansible prompts you for the sudo password before execution starts.
    ansible-playbook -i inventory.ini site.yml --ask-become-pass

Concurrency Management: forks and Batch Execution #

By default, Ansible executes tasks in parallel across many Managed Nodes simultaneously. This parallelism capacity is controlled by the forks parameter in the ansible.cfg configuration file. The default forks value is 5.

If you have 50 target servers and keep the default forks = 5, Ansible splits execution into 10 sequential batches:

flowchart TD
    Start["Run Playbook (Target = 6 Servers, forks = 3)"] --> B1["Batch 1 (web-01, web-02, web-03)"]
    B1 -->|"Parallel Task Execution"| R1["Wait for all Batch 1 nodes to finish"]
    R1 --> B2["Batch 2 (web-04, web-05, web-06)"]
    B2 -->|"Parallel Task Execution"| R2["Wait for all Batch 2 nodes to finish"]
    R2 --> End["Done"]

If one server in Batch 1 runs slower than the others, Ansible still waits until every server in Batch 1 finishes responding before triggering execution for Batch 2.

Optimizing forks in Production: #

If you have a Control Node with capable CPU and RAM specs plus adequate network bandwidth, you’re strongly encouraged to raise the forks value to shorten automation execution time.

# Edit the ansible.cfg file to optimize concurrency
[defaults]
forks = 50  # Allows 50 servers to be managed in parallel at once

Managed Node Variety Support #

Ansible isn’t limited to managing Linux operating systems. Ansible’s power extends across many other IT infrastructure platforms:

1. Windows Server #

Windows is managed without using SSH (although modern OpenSSH versions are now supported). Ansible uses the WinRM (Windows Remote Management) protocol communicating over HTTPS (port 5986). Module code is sent not as Python scripts but as PowerShell script modules.

2. Network Devices #

You can use Ansible to configure routers, switches, and firewalls from major vendors like Cisco, Juniper, and Arista. Because network devices usually don’t allow local Python installation, Ansible switches to Local Execution behavior:

  • Modules run locally on the Control Node.
  • Modules compile CLI commands or XML/JSON payloads.
  • They send those commands to the target network device via a raw SSH connection or API (port 443).

3. Cloud Providers and Cluster APIs #

Ansible can manage cloud resource lifecycles (such as AWS, GCP, Azure) and Kubernetes clusters by communicating directly with the cloud provider’s API endpoints from the Control Node.

Modern Production Architecture #

In large-scale enterprise environments, running Ansible directly from a personal laptop for production is not recommended due to credential security concerns and the lack of an audit trail. You should build a centralized automation architecture.

An ideal production architecture typically uses:

  • Bastion/Jump Host: An intermediary server placed in the demilitarized zone (DMZ). The Control Node routes its SSH connections through the Bastion Host using the ProxyJump option to reach internal production servers on private networks.
  • Automation Controller (AWX / Tower): A centralized web platform that wraps Ansible core. AWX provides role-based access control (RBAC), encrypted credential storage, and execution log dashboard visualization.
  • CI/CD Runner: Integrating Ansible playbook execution into Git pipelines (such as GitLab CI or GitHub Actions runners) that act as automatic Control Nodes when they detect infrastructure code changes being pushed.

Here’s an overview of a modern production architecture mediated by a Bastion Host:

flowchart TD
    subgraph "Developer Zone"
        Dev["Developer Pushes Git Code"] --> Git["Git Repository"]
    end

    subgraph "Centralized Control Zone"
        Git --> Runner["CI/CD Runner (Control Node)"]
    end

    subgraph "Demilitarized Zone (DMZ)"
        Runner -->|1. SSH Tunneling| Bastion["Bastion Host (Jump Box)"]
    end

    subgraph "Private Production Zone"
        Bastion -->|2. Forward SSH Connection| MN1["Managed Node 1 (Web)"]
        Bastion -->|2. Forward SSH Connection| MN2["Managed Node 2 (DB)"]
    end

Summary #

  • Control Node — The centralized Unix-like machine (Linux/macOS) where Ansible is installed to compile and control automation task execution.
  • WSL for Windows — Windows isn’t natively supported as a Control Node, but you can work around it using the Windows Subsystem for Linux (WSL).
  • Managed Node — The managed target server (Linux, Windows, Network Devices) that only needs SSH/WinRM and Python without requiring an Ansible installation.
  • become (Privilege Escalation) — The Ansible parameter for elevating to superuser (sudo) access levels to perform administrative tasks.
  • forks (Parallel Concurrency) — The configuration parameter for determining how many managed nodes are executed simultaneously at one time.
  • Centralized Architecture — At enterprise scale, automation is integrated through a Bastion Host, automation controller (AWX), or centralized CI/CD runners.

← Previous: Agentless Next: Inventory →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact