Although Linux systems can access several well-regarded configuration management tools like Chef and Puppet, these can be more complicated than necessary for some users. As an alternative, Ansible stands out because its straightforward architecture eliminates the need to install specific software on nodes. It leverages SSH for performing automation tasks and utilizes YAML files to outline provisioning specifics.
In this post, we will install Ansible across various Operating Systems such as Ubuntu, RHEL, CentOS, MacOS, and Windows.
What we will cover:
Ansible lets you perform configuration management, task automation, security/compliance tasks, orchestration, cloud provisioning, and application deployment easily and in an automated fashion. In simple terms, Ansible follows a master-slave architecture — you have an Ansible control node, where you will trigger and manage your jobs (playbooks), and managed nodes, the machines you want to run the playbooks on (inventory).
Ansible only needs SSH connectivity to establish connectivity to the managed nodes. For Windows, Ansible utilizes WinRM. These playbooks contain anything you want to perform on your managed nodes, such as installing an application, copying files over, ensuring certain config files are set up properly, removing unwanted files, etc. You can utilize inventory files to specify the managed nodes on which you want to run these playbooks.
Ansible was designed in a way that does not require many dependencies; the only application needed on each machine (control node and managed nodes) is Python and a few support libraries.
Ansible uses a declarative language, YAML and focuses on keeping everything idempotent, ensuring that nothing changes when the same playbook is run multiple times, keeping the state intact.
To learn more, check out our Ansible tutorial.
Pip is the Python package installer. Ansible can be installed with pip, which is very straightforward to use and install any other Python package with. This also ensures that all Python dependencies are installed.
#Install python3 and pip on CentOS:
Sudo yum install epel-release
Sudo yum install python3-pip
#Install python3 and pip on RHEL:
sudo dnf install --assumeyes python3-pip
#Install python3 and pip on MacOS:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install python
#Install python3 and pip on Ubuntu:
sudo apt update
sudo apt install python3-pip
#Install python3 and pip on Windows:
Run the Python installer for Windows and select "Add Python 3.x to PATH", this will ensure pip is callable from cmd.
#Validate you have python and pip installed:
Python3 ---version
pip ---version
#Install Ansible using pip:
pip install ansible
#Validate Ansible
Ansible ---version
Ubuntu uses the APT package manager to install applications. Run the following commands to install Ansible on any Ubuntu Linux box:
sudo apt update && sudo apt upgrade -y
sudo apt install software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible
#Install Ansible
sudo apt install ansible -y
#Validate Ansible:
ansible ---version
Red Hat Enterprise Linux (RHEL) is a subscription-based product and provides Ansible as part of its software repository, ensuring enterprise-level stability and support.
To install Ansible on RHEL run:
sudo yum update -y
sudo dnf install -y ansible-core
#Validate Ansible:
ansible ---version
CentOS utilizes the YUM package manager as well, and you can install Ansible directly from the EPEL repository:
sudo yum update -y
sudo yum install epel-release
sudo yum install ansible
#Validate Ansible:
ansible ---version
MacOS uses a homebrew package manager, so it’s as simple as running the following command:
brew update
brew install ansible
#Validate Ansible:
ansible ---version
Windows is a bit more complex compared to all the Unix-like distributions.
Can Ansible run on Windows?
There is no direct way to make a Windows machine into an Ansible control node. Ansible is designed to run on Unix-like operating systems such as Linux and MacOS. The main reason behind this is that Ansible depends on Python and certain Unix/Linux-specific functionalities like SSH for its operation, which does not natively integrate with Windows in the same manner.
However, you can still have Windows machines as a managed node. Ansible is able to communicate with Windows-managed nodes using WinRM instead of SSH. Ansible supports managing Windows desktops OS 7, 8.1, 10, and 11, and for Windows Servers OS, 2008 R2, 2012, 2012 R2, 2016, 2019, 2022. You also need to have .NET 4.0, Powershell 3.0, or newer installed and have WinRM listener enabled.
It’s also important to note that there are special Windows modules that need to be used against these Windows-managed nodes that are specific to Windows tasks instead of Linux tasks.
If you have Windows-heavy environment, there are a few workarounds you can utilize in order to make a Windows machine into an Ansible control node. You can use:
Windows Subsystem for Linux (WSL)
WSL allows you to run a Linux distribution directly on Windows, offering you to run any Linux application (such as Ansible) on your Windows machine, without the overhead of a traditional VM. You can install a Ubuntu Linux Distribution from the Microsoft Store for Windows Desktops, and for servers, you can install the distribution manually.
Once you have the Linux Environment up and running on your WSL, you can then install Ansible within this Linux Environment. We will go over this in more detail in the coming steps.
Docker for Windows
Docker allows you to run Docker containers on your Windows machine. The containers will run on a Linux distribution, and you can then install Ansible on it. This method is efficient and provides a high degree of portability and reproducibility for Ansible environments.
Virtual Machine
You can utilize VMware Workstation, VMware Player, or Virtual Box on your Windows machine. You just need to install the OS on a virtual machine in one of the listed virtual platforms. This is listed as the third option since it tends to utilize a lot of system resources compared to WSL and Docker.
For this tutorial, we will cover installing Ansible on a Windows OS using WSL. At the time of this article, Ansible only supports Windows Server 2019 (manual) and 2022 WSL, Windows Desktop 10, and 11 to run as an Ansible Control node. If you want to install it on older versions of Windows Server, such as 2019, you will need to follow the steps described here.
Installation Steps (Windows Server 2022 and Windows Desktop 10 & 11)
- Open Powershell as Administrator and run the following to Enable WSL (Windows Subsystem for Linux). This, by default, will install Ubuntu as your Linux distribution.
wsl --install
- If you want to install a different Linux Distribution, you can run the following commands:
#To view available distributions for Linux:
wsl —-list
wsl --install -d Debian
- Once you have the Linux distribution installed, you will be prompted to create a user account and password.
- After this, you should now be able to run commands on your WSL Linux Box.
In this example, we installed the Ubuntu Linux distribution and ran the following to install Ansible:
sudo apt update && sudo apt upgrade -y
sudo apt install ansible -y
#Validate Ansible installation
ansible --version
1. Linux managed nodes
Prerequisites
In order to successfully test your Ansible setup, you need to have the following prerequisites:
- One Ansible Control node, will serve as the central point from which we’ll manage and communicate with Ansible managed nodes via SSH. It can be your local machine or a dedicated server for running Ansible.
A non-root user with sudo rights and SSH keypair linked to this user on the control node. Create an SSH key pair on the control node using ssh-keygen if you haven’t done this by now.
- Ansible managed nodes configuration, these are the machines that the control node will automate and run playbooks on. You will also need the same non-root user with sudo rights on the managed nodes so the control node can authenticate properly
Add the public SSH key of the control node in the non-root user’s ~/.ssh/authorized_keys
1. Configure the Inventory file
Let’s start off by configuring the Inventory file. This is a directory for the managed nodes you’ll oversee using Ansible. It can include a range from a single to hundreds of servers and allows for organization into groups and subgroups.
To modify your default Ansible inventory, access the /etc/ansible/hosts file on your Ansible control node with your preferred text editor:
sudo vi /etc/ansible/hosts
Note: While Ansible defaults to creating an inventory file at /etc/ansible/hosts, you have the flexibility to create inventory files and use the -i option with Ansible commands and playbooks to specify the file’s path. Adopting per-project inventories is recommended and can reduce the risk of executing a playbook on an incorrect set of servers. (See other Ansible best practices.)
Ansible’s default inventory file includes various examples as guidance for your setup. Below is an example that outlines a group named [ubuntu] containing two managed nodes with unique aliases: vm1 and vm2. Update the IP addresses to match those of your managed nodes.
The [all:vars] subgroup globally assigns the ansible_python_interpreter variable, ensuring all listed nodes use Python 3 (/usr/bin/python3), which supersedes Python 2.7 (/usr/bin/python) not found in recent Ubuntu distributions.
To save modifications, exit the editor by pressing ESC and typing :wq to Save and Quit.
2. Review your inventory setup
To review your inventory setup, run:
ansible-inventory --list -y
The output will display your server configuration as defined in the inventory file, resembling the provided example but tailored to your infrastructure.
Now, let’s jump into testing Ansible’s connectivity and command execution capabilities over SSH. Utilize the -u option to specify the remote system user (the non-root sudo user we created as part of the pre-requisites). If you don’t specify this option, Ansible attempts to connect using the control node’s current system user.
3. Perform a connectivity test
Run the following from your local machine or Ansible control node:
ansible all -m ping
This command uses Ansible’s ping module to perform a connectivity test on all managed nodes in your default inventory.
The ping module checks for:
- Accessibility of the nodes
- Validity of SSH credentials
- Nodes capability to execute Ansible modules via Python
A successful response will look like this:
Output
vm1 | SUCCESS => {
"changed": false,
"ping": "pong"
}
vm2 | SUCCESS => {
"changed": false,
"ping": "pong"
}
If this is your first SSH connection attempt to these servers, you’ll need to confirm the authenticity of each managed node when prompted by typing yes and pressing ENTER.
Receiving a “pong” response indicates readiness for running Ansible commands and playbooks on the server.
Windows managed nodes
To successfully test your Ansible setup with Windows machines, you’ll need to ensure that your environment is properly configured to manage Windows as managed nodes. This involves setting up Windows Remote Management (WinRM), the primary protocol Ansible uses to communicate with Windows nodes.
Below are the steps to prepare your Windows machines for Ansible management and to conduct a connectivity test using Ansible.
1. Prepare Windows managed nodes
First, ensure that WinRM is enabled on your Windows managed nodes. WinRM is enabled by default on Windows Server 2012/2016/2019, but if you’re working with Windows desktop versions or need to verify the configuration. You can enable WinRM by running the following command in PowerShell as an administrator:
Enable-PSRemoting -Force
2. Configure WinRM for Ansible
For Ansible to manage your Windows nodes securely, you’ll need to configure WinRM to use Basic authentication over HTTPS. While there are various ways to configure WinRM, you can use the ConfigureRemotingForAnsible.ps1 script, provided in the Ansible documentation. This script sets up WinRM with reasonable defaults for Ansible usage.
Download and run the script on each Windows managed node by executing the following command in PowerShell as an administrator:
$url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
$file = "$env:temp\ConfigureRemotingForAnsible.ps1"
(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
powershell.exe -ExecutionPolicy ByPass -File $file
3. Set up Windows firewall (optional)
If you have a firewall enabled, ensure that it allows connections over the port WinRM is configured to use (default is 5986 for HTTPS).
4. Update your Ansible inventory file
Add your Windows managed nodes to your Ansible inventory file (/etc/ansible/hosts). You will specify the WinRM connection details here. For example:
[windows]
winvm1 ansible_host=xx.xx.xx.xx
[windows:vars]
ansible_user=YourWindowsUser
ansible_password=YourWindowsPassword
ansible_connection=winrm
ansible_winrm_transport=basic
ansible_winrm_server_cert_validation=ignore
Replace xx.xx.xx.xx with the IP address of your Windows managed node, and update the ansible_user and ansible_password with your Windows credentials.
5. Test connectivity to Windows managed nodes
After preparing your Windows managed nodes, you can test the Ansible setup by executing a simple connectivity test. This will verify that Ansible can communicate with the Windows nodes via WinRM.
Unlike Linux/Unix nodes, where the ping module is used, Ansible provides the win_ping module for testing connectivity with Windows nodes.
Execute the following command from your Ansible control node:
ansible windows -m win_ping
This command targets all hosts in the [windows] group of your inventory file and uses the win_ping module to test connectivity.
Expected Outcome:
If the setup is correct, you’ll receive a SUCCESS message for each Windows managed node, indicating that Ansible can communicate with the Windows nodes via WinRM. The output will look similar to this:
winvm1 | SUCCESS => {
"changed": false,
"ping": "pong"
}
Receiving a “pong” response confirms that your Windows managed nodes are correctly configured and ready for Ansible to run playbooks and tasks against them. This successful test ensures that you can proceed with automating your Windows infrastructure using Ansible.
Spacelift’s vibrant ecosystem and excellent GitOps flow can greatly assist you in managing and orchestrating Ansible. By introducing Spacelift on top of Ansible, you can then easily create custom workflows based on pull requests and apply any necessary compliance checks for your organization. Another great advantage of using Spacelift is that you can manage different infrastructure tools like Ansible, Terraform, Pulumi, AWS CloudFormation, and even Kubernetes from the same place and combine their Stacks with building workflows across tools.
If you want to learn more about Spacelift working with Ansible, check our documentation, read our Ansible guide or book a demo with one of our engineers.
Ansible’s design minimizes dependencies, requiring only Python and a few support libraries on both control nodes and managed nodes (which most Linux machines have pre-installed), streamlining its setup process.
You can easily install Ansible on a range of operating systems, including Ubuntu, RHEL, CentOS, MacOS, and Windows, regardless of your platform. Although Windows cannot directly serve as an Ansible control node due to its reliance on Python and SSH, the are some workarounds, like using Windows Subsystem for Linux (WSL), Docker, or a virtual machine to manage Windows as a managed node.
Manage Ansible Better with Spacelift
Spacelift helps you manage the complexities and compliance challenges of using Ansible. It brings with it a GitOps flow, so your infrastructure repository is synced with your Ansible Stacks, and pull requests show you a preview of what they’re planning to change. It also has an extensive selection of policies, which lets you automate compliance checks and build complex multi-stack workflows.