Installation and Inventory

Introduction

In this lab, you will take your first steps into the world of Ansible, a powerful open-source automation tool.

Imagine you have to manage 100 servers. Logging into each one to install software or change settings would be tedious and error-prone. Ansible lets you manage those servers, called managed nodes, from a single control node without installing agents on the targets.

That agentless design is a major reason Ansible became popular in operations teams. It reduces the amount of extra software you must maintain on every host and builds on tools administrators already trust, especially SSH.

Ansible works by:

Connecting to servers using SSH (the same tool you use to log in remotely).
Reading instructions from simple text files (written in YAML).
Pushing small programs (modules) to the servers to do the work.

This agentless model is one reason Ansible became popular. It builds on tools Linux administrators already know, especially SSH and text-based configuration.

In this lab, you will act as both the manager and the managed. You will install Ansible on your environment and configure it to manage itself (localhost). This is a great way to learn the basics safely.

You will learn how to:

Install Ansible using the package manager.
Set up SSH keys so Ansible can log in without a password.
Create an Inventory file to list the computers you want to manage.
Test the connection using the ping module.

Install Ansible

The first step is to install the Ansible software on your machine. Since we are using Ubuntu, we can use the apt package manager, which is like an "App Store" for Linux command-line tools.

First, although the setup script ran an update, it is good practice to ensure your package list is up to date:

sudo apt update

Now, install Ansible by running:

sudo apt install ansible -y

Understanding the command:

sudo: Runs the command with administrator (root) privileges.
apt install: Tells the package manager to install a program.
ansible: The name of the package we want.
-y: Automatically answers "yes" to any confirmation prompts (like "Do you want to continue?").

Once the installation finishes, verify it by checking the version:

ansible --version

You should see output starting with ansible [core 2.x.x]. This confirms that Ansible is installed and ready to go.

Generate SSH Keys

Ansible uses SSH (Secure Shell) to communicate with servers. It's the standard way to access Linux servers remotely.

This is also why inventory matters so much. Ansible needs a clear list of which machines exist, how they are grouped, and how to reach them. The inventory is effectively the address book for your automation system.

By default, SSH requires a password. However, for automation tools like Ansible, typing a password every time it connects to a server is impossible. Instead, we use SSH Keys.

Think of SSH keys like a lock and a key:

Public Key (The Lock): You put this on any server you want to access.
Private Key (The Key): You keep this safe on your control computer.

When Ansible connects, the server checks if your "Key" matches its "Lock". If it does, you get in without a password.

Generate a key pair by running:

ssh-keygen -t rsa -b 2048 -N "" -f ~/.ssh/id_rsa

Understanding the command:

ssh-keygen: The tool to generate keys.
-t rsa: Creates an RSA type key (standard).
-b 2048: Makes the key 2048 bits long (secure enough).
-N "": Sets an empty passphrase. This is crucial! It means "don't ask me for a password to use this key," allowing Ansible to run fully automatically.
-f ~/.ssh/id_rsa: Saves the key to the standard location.

Check that the files were created:

ls -l ~/.ssh/

You should see id_rsa (your secret private key) and id_rsa.pub (your public key).

Authorize Your Key

Now that you have a key, you need to put the Public Key on the server you want to manage. In this lab, we are managing the localhost (the same machine you are on).

This step shows the separation between authentication and automation logic. Before Ansible can automate anything, it first needs a reliable non-interactive way to authenticate to the target.

We need to add the content of your id_rsa.pub into a file named authorized_keys in the .ssh folder.

Normally, you would use a command like ssh-copy-id. However, that command usually asks for a password first (to prove you are you). Since we are in a passwordless lab environment, we will manually copy the key.

Run this command to append your public key to the authorized keys list:

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Understanding the command:

cat ...: Reads your public key.
>>: Appends the output to the end of the target file (instead of overwriting it).
.../authorized_keys: This is the file SSH checks to see who is allowed to login.

Now, set the correct permissions so SSH trusts the file:

chmod 600 ~/.ssh/authorized_keys

Let's test it! Try to SSH into your own machine:

ssh localhost "echo Hello from SSH"

If asked "Are you sure you want to continue connecting?", type yes and press Enter.

You should see "Hello from SSH" printed immediately, without being asked for a password. This means Ansible will also be able to connect without a password.

Create an Inventory File

Ansible needs a list of servers to manage. This list is called an Inventory.

The inventory can be a simple text file. We will create a project directory and an inventory file named hosts.ini.

Create an empty file named hosts.ini:

touch hosts.ini

Right now, Ansible doesn't know about any servers. We will add them in the next step.

Add Host to Inventory

We will now edit the hosts.ini file to add our server. Ansible inventories often use the INI format, which looks like this:

[group_name]
server_address

Grouping servers (like [webservers] or [databases]) allows you to run commands on all servers of that type at once.

Let's add localhost to a group named [webservers]. Run this command to write to the file:

echo -e "[webservers]\nlocalhost" > hosts.ini

Understanding the command:

echo -e: Prints text, allowing special characters like \n (newline).
"[webservers]\nlocalhost": The text we want. It puts [webservers] on the first line and localhost on the second.
> hosts.ini: Overwrites the file with this content.

You can verify the file content:

cat hosts.ini

It should look exactly like this:

[webservers]
localhost

Test Connectivity

Now the moment of truth! We will ask Ansible to connect to all servers in our inventory and check if they are alive.

We use the ansible command (for running one-off tasks) with the ping module.

Run this command:

ansible all -m ping -i hosts.ini

Understanding the command:

all: Matches all hosts in your inventory.
-m ping: Tells Ansible to use the module named ping.
- Note: This is different from the network ping command. Ansible's ping actually logs into the server, checks if Python is available, and returns "pong". It proves you have a working setup.
-i hosts.ini: Tells Ansible to use the inventory file we just created (instead of the system default).

You should see a green "SUCCESS" message:

localhost | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

If you see "ping": "pong", congratulations! You have successfully configured Ansible to manage your server.

Summary

In this lab, you built the foundation for Ansible automation. You learned:

Installation: Getting Ansible ready on your system.
SSH Key Setup: Creating "keys" so Ansible can log in securely without passwords.
Inventory: Creating a list (hosts.ini) of servers to manage.
Connectivity Check: Using the ping module to verify everything is working.

These steps—install, access, inventory, test—are the first steps you will perform in any Ansible project, whether you are managing one server or one thousand.