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.
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 --versionansible [core 2.13.4]config file = Noneconfigured 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/ansibleansible collection location = /Users/lberton/.ansible/collections:/usr/share/ansible/collectionsexecutable location = /opt/homebrew/bin/ansiblepython 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.2libyaml = True
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
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: winrmansible_winrm_transport: basicansible_user: LocalUsernameansible_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: winrmansible_winrm_transport: certificateansible_winrm_cert_pem: /path/to/certificate/public/key.pemansible_winrm_cert_key_pem: /path/to/certificate/private/key.pem