Learn Ansible - Pre-Requisites Skills & Environment Setup

#Introduction

Welcome to the Learn Ansible series! This series will take you from zero to production-ready Ansible, covering fundamental concepts, writing playbooks, and integrating with modern ecosystems such as CI/CD and the cloud. But as the saying goes, "a tree cannot thrive without strong roots". Before you touch ansible-playbook or write beautiful YAML, there are a few basic skills and tools you must have and prepare first.

Why are these prerequisites so important? Ansible is not an application you can use right away without preparation. Ansible is a configuration management tool that runs on top of SSH, is written in Python, and is configured using YAML. That means if you are not yet familiar with these three, your learning journey will feel sluggish and confusing. Imagine wanting to be a ship captain but not knowing how to read a compass — no matter how great the ship is, you will still get lost.

Episode 0 is your roadmap to make sure everyone is ready. We will cover three fundamental skills (Linux CLI, networking & SSH concepts, and YAML), then set up all the software and hardware you need, and finish with installing Ansible and verifying it. Once this episode is done, you will be fully ready to move on to episode 1, which covers the history and background of why Ansible is needed.

#Basic Skills You Must Have

Let's start with skills. Without these, no matter how sophisticated your tool setup is, it will be useless. Here are three pillars of skills you should master at least at a basic level.

#Linux & CLI Basics

Ansible was born and grew up in the Linux ecosystem. Although Ansible can technically manage Windows (via WinRM), the majority of real-world use cases are managing Linux servers. That is why being able to operate Linux through the CLI (Command Line Interface) is a hard requirement.

What should you master?

1. Navigation & file management. You should be comfortable moving between directories, viewing contents, and creating, copying, and deleting files. This is the most basic ability you will use every day, including when placing your Ansible playbook files.

Navigasi & manajemen file

pwd                        # print current working directory
ls -la                     # list directory contents (including hidden files)
cd /etc/ansible            # move to /etc/ansible directory
mkdir -p ~/lab-ansible     # create nested directories
cp inventory.yml backup/   # copy a file

2. User & group. Ansible is often run with a specific user account, and managing user permissions on managed nodes is an administrator's daily job. You need to know commands like useradd, usermod, groupadd, id, and whoami.

3. File permissions (chmod & chown). This is what most confuses beginners. Every file in Linux has an owner, a group, and access permissions for three groups: owner, group, and others. Those permissions are represented as r (read), w (write), and x (execute).

chmod & chown

chmod 644 script.sh      # owner: rw-, group: r--, others: r--
chmod 755 deploy.sh      # owner: rwx, group: r-x, others: r-x
chmod +x deploy.sh       # add execute permission (symbolic)
chown ansible:ansible /opt/app/config.yml   # change owner & group
ls -l                    # verify the result of your changes

4. Sudo (privilege escalation). Many automation tasks (such as installing packages or changing services) require root privileges. In Ansible, this mechanism is known as become — and on the CLI side, you know it as sudo.

Sudo

sudo apt update              # run a command as root
sudo -i                      # enter an interactive root shell
sudo -u www-data whoami      # run as a specific user
sudo visudo                  # edit the sudoers configuration

#Computer Networking & SSH Concepts

Ansible does not manage servers locally — it manages servers remotely. Every time Ansible runs a task, it establishes a connection to the managed node. Therefore, a basic understanding of networking and especially SSH (Secure Shell) is non-negotiable.

Some networking concepts you need to understand:

1. IP Address: the unique address of a device on a network (IPv4/IPv6). Managed nodes must have an IP reachable from the Control Node.
2. Port: the application's entry point, e.g., port 22 for SSH, 80 for HTTP, 443 for HTTPS.
3. DNS: mapping domain names to IPs, so we can type server1.example.com instead of memorizing an IP.
4. Firewall: access-limiting rules. If port 22 is blocked by a firewall, Ansible will never be able to connect.

#SSH Key Authentication

SSH authentication can be done with a password, but the best practice is to use an SSH key pair. The main reasons: it is more secure (the private key is never sent over the network) and it enables automation without human intervention — something that is crucial because Ansible must connect to dozens or even thousands of servers without being asked for a password one by one.

Buat SSH key di Control Node

# 1. Generate key pair (public + private)
ssh-keygen -t ed25519 -C "devops@example.com" -f ~/.ssh/id_ed25519
 
# 2. View the public key (this is what you can share)
cat ~/.ssh/id_ed25519.pub
 
# 3. Copy the public key to the managed node (once only)
ssh-copy-id -i ~/.ssh/id_ed25519.pub devops@10.0.0.11
 
# 4. Test the connection without a password
ssh devops@10.0.0.11

#known_hosts

The first time you SSH into a server, you will see a warning like this:

The authenticity of host '10.0.0.11 (10.0.0.11)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

When you type yes, that server's fingerprint is stored in the ~/.ssh/known_hosts file. This is a protection mechanism against man-in-the-middle attacks — where a fake server impersonates the real one. Because Ansible runs without human interaction, automation often disables this verification on local labs (not in production!) using the host_key_checking = False option in ansible.cfg, or registers host keys beforehand.

#sshd Configuration on the Managed Node

On the server side (managed node), SSH configuration is managed in the /etc/ssh/sshd_config file. The directives you will adjust most often:

/etc/ssh/sshd_config (potongan)

Port 22
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

#Understanding the YAML Format

This is probably the most underestimated skill, yet it is the most frequent source of errors in Ansible. YAML (YAML Ain't Markup Language) is a data serialization format that prioritizes human readability. All Ansible configuration — inventory, playbooks, roles, even ansible.cfg written in YAML — uses this format.

The core YAML concepts you must understand:

1. Key-value pairs: the simplest structure.
2. List/Array: an ordered sequence starting with a - sign.
3. Dictionary/Map: a collection of indented key-value pairs.
4. Indentation: the hierarchy marker. YAML is extremely sensitive to spaces.

# Simple key-value
name: web-server
 
# List / array
packages:
  - nginx
  - curl
  - htop
 
# Dictionary / map
web_server:
  domain: example.com
  port: 80
  tls:
    enabled: true
    cert_path: /etc/ssl/cert.pem
 
# List of dictionaries (most common in Ansible)
users:
  - name: arman
    uid: 1001
  - name: budi
    uid: 1002

To make it easier to tell the concepts apart, here's a quick comparison:

#Hardware & Software to Prepare

Now that the skills are covered, it's time to prepare the equipment. Ansible's architecture splits roles into two sides: the Control Node (the machine where Ansible is installed and commands are executed) and the Managed Nodes (the target servers being managed).

#Control Node

This is the machine where you type ansible-playbook. Its characteristics:

• OS: Linux, macOS, or WSL2 on Windows. WSL2 (Windows Subsystem for Linux) lets Windows run a Linux environment natively — a popular choice for those whose office uses Windows.
• Python 3.9+: the minimum Python version supported by modern Ansible.
• OpenSSH client: already present by default on Linux and macOS; on Windows it can be enabled via Optional Features or is automatically available in WSL2.

Cek prasyarat Control Node

python3 --version        # make sure it's >= 3.9
ssh -V                   # check the OpenSSH client version
uname -a                 # check OS & kernel (Linux)
which pipx               # check whether pipx is installed

#Managed Nodes

These are the "herd" of servers managed by Ansible. For learning, you only need to prepare 2-3 virtual machines (VMs) running Ubuntu, Debian, RHEL, or Rocky Linux. You are free to choose how to create them: you can use VirtualBox (local, free), Proxmox (bare-metal hypervisor), multipass (a simple Ubuntu-style CLI), or a Cloud VPS (DigitalOcean, AWS EC2, Vultr, etc.) if you want to experience a production-like environment.

Also make sure every VM already has the SSH public key from the Control Node installed (using ssh-copy-id) so connections run without a password.

#Text Editor

Ansible is configuration as code — you will write and read a lot of YAML. A good text editor saves you from indentation mistakes and typos. The industry standard recommendation is Visual Studio Code with two extensions:

• Ansible (official from Ansible, now maintained by Red Hat) — autocomplete, linting, and go-to-definition for playbooks.
• Red Hat YAML — syntax highlighting and YAML schema validation that are very helpful.

#Installing Ansible

Now for the most anticipated part: installing Ansible on the Control Node. The method recommended by the official documentation is to use pipx or a Python virtual environment (venv) — not a global pip install, because that would pollute the system Python environment and could trigger dependency conflicts (a phenomenon known as dependency hell).

#Method 1: Using pipx

pipx installs Python applications in an isolated environment but puts their binaries on PATH so they can be run directly from anywhere. This is the cleanest way to handle CLI tools like Ansible.

# Install pipx (Ubuntu/Debian)
sudo apt update
sudo apt install -y pipx
pipx ensurepath
 
# Install Ansible (complete package: ansible-core + popular collections)
pipx install --include-deps ansible
 
# Reload the shell so the new PATH is recognized
exec $SHELL

#Method 2: Using a Python venv

If you are already familiar with venv, this method is also highly recommended — especially if you want per-repository isolated Ansible projects. It is also a standard practice in many companies.

Install Ansible via venv

cd ~/lab-ansible
 
# Create a virtual environment
python3 -m venv .venv
 
# Activate the environment
source .venv/bin/activate
 
# Install Ansible
pip install ansible

#Verifying the Installation

Once installed, verify it with ansible --version. Correct output should show the Ansible version, Python version, and the location of the default configuration file.

ansible --version
ansible [core 2.16.3]
  config file = None
  configured module search path = ['/home/devops/.ansible/plugins/modules']
  ansible python module location = /home/devops/.venv/lib/python3.11/site-packages/ansible
  ansible collection path = /home/devops/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/devops/.venv/bin/ansible
  python version = 3.11.6 (main, Nov 14 2023) [GCC 12.2.0] (/home/devops/.venv/bin/python3)
  jinja version = 3.1.2
  libyaml = True

#First Connection Test (Optional)

As a hands-on finale, let's make sure the Control Node can communicate with managed nodes over SSH. We'll create a simple inventory file and use the ping module (not ICMP ping — this is the Ansible-level ping that tests whether the Control Node can execute Python modules on the target).

[webservers]
10.0.0.11 ansible_user=devops
10.0.0.12 ansible_user=devops
 
[dbservers]
10.0.0.13 ansible_user=devops

ansible -i inventory.ini all -m ping

10.0.0.11 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
10.0.0.12 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
10.0.0.13 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

If all nodes respond with "pong", that means the SSH connection, key authentication, and Python execution on the managed nodes are all working perfectly. You are officially ready to learn Ansible!

#Conclusion

In episode 0 we have laid a solid foundation: mastering three fundamental skills (Linux CLI, networking & SSH, and YAML), preparing the Control Node and Managed Nodes along with their supporting tools, installing Ansible with modern methods (pipx/venv), and even running a first connection test using the ping module.

Key takeaways to carry with you:

• Ansible runs on SSH, Python, and YAML — master all three.
• SSH key authentication is the foundation of secure automation.
• YAML is very sensitive to indentation; don't use tabs.
• Install Ansible in isolation (pipx or venv), not globally via pip.
• Always verify with ansible --version and a ping test before you start.

Make sure all the skills and tools above are ready, because the next episode will go deeper into the concepts. In episode 1, we will discuss the history, background, and why the modern world needs Ansible — from the evolution of automation from manual shell scripting to Infrastructure as Code, why Ansible chose the agentless approach, and how it positions itself against other tools like Puppet, Chef, and Terraform. Keep your enthusiasm up, because the Ansible learning journey has only just begun! 😁