Ansible Lesson 5 – Installation and Setup | Dataplexa
Section I · Lesson 5

Installation and Setup

In this lesson

Installing Ansible Verifying the install SSH key setup First ping test Common install errors

Installing Ansible is the process of getting the Ansible package and its dependencies onto your control node so you can begin running automation against managed nodes. Unlike most server software, Ansible requires no installation on the machines it manages — setup is a one-time task on your control node only. This lesson walks through every step: installing Ansible, configuring SSH key authentication, writing a minimal inventory, and confirming your setup works with a live ping test.

Installing Ansible by Platform

Ansible is installed on the control node only. Pick the path that matches your operating system — each card below links directly to any prerequisite you need to download first.

🐧

Ubuntu / Debian

via apt + official Ansible PPA

Get Ubuntu ↗
# Add the official Ansible PPA for the latest stable release
sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible

# Install Ansible
sudo apt install -y ansible

# Confirm the installation
ansible --version
🎩

RHEL / CentOS / Fedora

via dnf + EPEL repository

Get RHEL ↗
# Enable the EPEL repository first
sudo dnf install -y epel-release

# Install Ansible
sudo dnf install -y ansible

# Confirm the installation
ansible --version
🐍

macOS / WSL 2 / Any Linux Recommended

via pip inside a Python virtual environment — always the latest version, works on every platform

# Create and activate a Python virtual environment
python3 -m venv ~/ansible-env
source ~/ansible-env/bin/activate   # run this in every new terminal session

# Install Ansible via pip (always installs the latest stable release)
pip install ansible

# Confirm the installation
ansible --version

# To re-activate in future sessions:
# source ~/ansible-env/bin/activate

Verifying the Installation

Once installed, run ansible --version to confirm Ansible is on your PATH and to see which version you have. The output also shows where Ansible reads its configuration from — useful context for Lesson 6.

ansible --version
ansible [core 2.17.0]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/user/.ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /home/user/.ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.12.3 (main, Apr 10 2024, 05:33:47)
  jinja version = 3.1.2
  libyaml = True

What just happened?

Ansible printed its version, the path to its config file, the Python version it is using, and where it looks for modules and collections. If you see this output, Ansible is correctly installed. If you see command not found, activate your virtual environment first: source ~/ansible-env/bin/activate.

SSH Key Authentication Setup

Ansible connects to managed nodes using standard SSH. The most secure and automation-friendly method is SSH key authentication — no passwords typed at the terminal, no passwords stored in playbooks. Follow these four steps to wire your control node to a managed node.

Prerequisite: OpenSSH must be installed on both control node and managed node. Most Linux distributions and macOS include it by default. Windows users on WSL 2 already have it available.

OpenSSH docs ↗

Step 1

Generate an SSH key pair on the control node

# Generate a new ED25519 key pair — more secure and faster than RSA
# Press Enter to accept the default path (~/.ssh/id_ed25519)
ssh-keygen -t ed25519 -C "ansible-control-node"

Step 2

Copy the public key to the managed node

# Replace 'youruser' and '192.168.1.10' with your actual username and node IP
# This appends your public key to ~/.ssh/authorized_keys on the remote host
ssh-copy-id youruser@192.168.1.10

Step 3

Test the connection manually before using Ansible

# You should connect without a password prompt
# If asked for a password, SSH key auth is not configured correctly — revisit Step 2
ssh youruser@192.168.1.10

Step 4

Create a minimal inventory file

# Save this as inventory.ini in your project directory
# The simplest possible inventory — one host in one group
[webservers]
192.168.1.10 ansible_user=youruser

No spare server? Use Vagrant to spin up local Linux VMs on your machine to act as managed nodes — free, isolated, and disposable. Perfect for practising without a cloud account.

Get Vagrant ↗

Running Your First Ansible Command

With Ansible installed, SSH keys configured, and an inventory file in place, you are ready to run your first real Ansible command. The ansible.builtin.ping module is the standard connectivity test — it verifies that Ansible can connect to a host and that Python is available on the remote side. It is not an ICMP ping — it opens an SSH connection, transfers a tiny Python script, runs it, and returns pong if everything is working.

# Run the ping module against all hosts in the webservers group
# -i  points to your inventory file
# -m  specifies the module to run
ansible webservers -i inventory.ini -m ansible.builtin.ping
192.168.1.10 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

What just happened?

Ansible opened an SSH connection to 192.168.1.10, transferred the ping module, executed it using the Python interpreter it auto-discovered on the remote host, and returned "ping": "pong" with "changed": false. SSH is working, Python is present, and your Ansible setup is complete.

Common Installation Errors

Most setup problems fall into a small number of categories. Here are the errors you are most likely to hit and exactly how to fix each one.

Error → Cause → Fix

command not found Ansible binary is not on your $PATH. If you installed via pip in a virtual environment, activate it first: source ~/ansible-env/bin/activate.
Permission denied (publickey) The SSH public key has not been copied to the managed node, or the wrong username is used. Re-run ssh-copy-id and verify ansible_user in your inventory.
UNREACHABLE! Connection timed out The managed node is not reachable on port 22. Check firewall rules, cloud security groups, and that the IP in your inventory is correct.
/usr/bin/python: not found Python is not installed on the managed node or is at a non-standard path. Install Python 3, or add ansible_python_interpreter=/usr/bin/python3 to your inventory.
sudo: a password is required The automation user needs passwordless sudo for become: true to work unattended. Add the user to /etc/sudoers with NOPASSWD: ALL.

Recommended: Install ansible-lint now to catch YAML and best-practice errors before they reach managed nodes. It integrates directly into VS Code via the Ansible extension.

ansible-lint docs ↗

The Master Key Analogy

SSH key authentication is like having a master key that opens every door in a building without needing to know each lock's combination. The public key you copy to each managed node is the lock; the private key on your control node is your master key. Anyone who obtains the private key can open every door it is registered with — which is exactly why you must never share, expose, or commit it to version control.

Never Store SSH Private Keys Without a Passphrase in Production

It is tempting to generate passphrase-free SSH keys so Ansible can run completely unattended. In production, always protect private keys with a passphrase and use ssh-agent to cache the decrypted key in memory. A passphrase-free private key on a compromised control node gives an attacker immediate, passwordless access to every managed node that key is registered on.

Key Takeaways

Ansible is installed on the control node only — managed nodes need nothing beyond SSH and Python, regardless of which installation path you chose.
pip in a virtual environment is the most portable install method — it works on macOS and any Linux distribution, always installs the latest stable version, and keeps Ansible isolated from system Python packages.
SSH key authentication is the correct connection method — use ssh-keygen to generate a key pair and ssh-copy-id to register the public key on each managed node before running any Ansible command.
ansible.builtin.ping is the standard verification step — a pong response confirms SSH connectivity, Python availability, and correct inventory configuration in a single command.
Most connection failures fall into five categories — PATH issues, SSH key problems, network/firewall blocks, missing Python, and sudo configuration — each with a clear, specific fix.

Teacher's Note

Do not move to Lesson 6 until you have seen "ping": "pong" in your terminal — every lesson from here on assumes a working Ansible setup, and debugging installation issues mid-course costs far more time than getting it right now.

Practice Questions

1. What is the full module name used to verify Ansible connectivity to a managed node?



2. Which command copies your SSH public key to a managed node's authorized_keys file?



3. What command confirms Ansible is installed and displays the version number?



Quiz

1. What does ansible.builtin.ping actually do when you run it?


2. You run your first Ansible ping and receive Permission denied (publickey). What is the most likely cause?


3. Which installation method is most portable across macOS and different Linux distributions?


Up Next · Lesson 6

Ansible Configuration Files

Learn how ansible.cfg controls Ansible's behaviour — default inventory paths, SSH settings, privilege escalation, and how configuration precedence works.