Ansible Architecture

Get an overview of Ansible configurations for different operating systems and the architecture of Ansible control and target nodes.

Ansible typically requires two hosts, one that executes the automation—called the Ansible control node—and one that receives the action—called the Ansible target node.

The Ansible control node directs the automation and effectively requires Ansible to be fully installed inside. The Ansible target node only requires a valid login to connect.

Ansible architecture
Ansible architecture

The Ansible control node uses the Ansible playbook and inventories for the execution. The Ansible playbook is the automation blueprint and has a step-by-step list of tasks to execute against the target hosts. The Ansible inventory is the list of target hosts. For simplicity, we can group the hosts using a common name. In doing so, we can easily specify the group name for the execution.

Configure a control node in Unix

We can configure the Ansible control node in a large variety of Unix operating systems, such as Linux distributions, macOS, and Unix (FreeBSD, OpenBSD, etc.).

The supported Ansible control nodes include the current Unix-compliant desktop and server release.

We can simply install ansible or ansible-core in our package manager or use the Python pip tool.

We use the following command on Red Hat, Fedora, CentOS, Oracle, or Amazon systems with root privileges to install Ansible:

yum install ansible

On Debian and Ubuntu systems, the command we should use (root privileges required) is the following:

apt-get install ansible

Using the Python pip tool, the command (root privileges required) to install Ansible is the following:

pip3 install ansible

After installation, the command ansible --version can be used to check whether the installation was successful.

ansible --version
ansible [core 2.13.4]
config file = None
configured module search path = ['/Users/lberton/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /opt/homebrew/Cellar/ansible/6.4.0/libexec/lib/python3.10/site-packages/ansible
ansible collection location = /Users/lberton/.ansible/collections:/usr/share/ansible/collections
executable location = /opt/homebrew/bin/ansible
python version = 3.10.6 (main, Aug 30 2022, 04:58:14) [Clang 13.1.6 (clang-1316.0.21.2.5)]
jinja version = 3.1.2
libyaml = True
Output of the ansible --version command

Configuring a target node in Unix

We can configure the Ansible target node in Unix operating systems. For example, Linux distributions, macOS, and Unix (FreeBSD, OpenBSD, etc.).

The supported Ansible target nodes include all the current releases of Unix-compliant desktops and servers.

Ansible only requires that OpenSSH and Python be installed. OpenSSH is used for connection and one login user. Using SSH keys instead of passwords is strongly encouraged. The local Python interpreter in the target node executes the Ansible commands.

Configuring a target node in Windows

The supported Ansible target node includes all the modern Windows desktop and server releases. The list includes Windows 7, 8.1, 10, 11, and Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016, 2019, and 2022.

The Windows host requires PowerShell 3.0 or newer and at least .NET 4.0 installed. We only need to upgrade the old Windows 7 and Windows Server 2008 nodes.

The WinRMWinRM is a Microsoft protocol used by Ansible for remote management and communication with Windows-based systems. listener receives and executes the commands between the Ansible controller and the Ansible target node.

Ansible 2.8 has added an experimental SSH connection for Windows-managed nodes for Windows 10+ clients and Windows Server 2019+.

The easier, more straightforward configuration is using the WinRM connection method with the basic authentication. We can specify more advanced authentication methods, such as Basic, Certificate, NTLM, Kerberos, and CredSSP, for a local user account, Active Directory account, credential delegation, and HTTP encryption.

WinRM Authentication Methods

Option

Local Accounts

Active Directory Accounts

Credential Delegation

HTTP Encryption

Basic

Yes

No

No

No

Certificate

Yes

No

No

No

Kerberos

No

Yes

Yes

Yes

NTLM

Yes

Yes

No

Yes

CredSSP

Yes

Yes

Yes

Yes

Basic authentication is the simplest authentication option to use but also the most insecure because it transmits the password encrypted with base64 encoding.

The following example shows the WinRM host variables configured for basic authentication in the Ansible inventory:

ansible_connection: winrm
ansible_winrm_transport: basic
ansible_user: LocalUsername
ansible_password: Password

WinRM certificate authentication uses certificates as public/private key pairs in PEM format.

The following example shows how to configure WinRM host variables for certificate authentication in the Ansible inventory:

ansible_connection: winrm
ansible_winrm_transport: certificate
ansible_winrm_cert_pem: /path/to/certificate/public/key.pem
ansible_winrm_cert_key_pem: /path/to/certificate/private/key.pem