Ansible Installation & EC2 Setup – My Practical Experience

 

After understanding Ansible modules and the overall architecture, the next thing I wanted to do was actually install Ansible and set up a working environment.
This is the part where theory meets hands-on practice — and honestly, this is where everything started making sense for me.

In this blog, I’ll share how I installed Ansible on a Linux EC2 instance and connected it with other EC2 servers to run automation.

⭐ Where I Installed Ansible

I installed Ansible on a Linux-based EC2 instance, which acted as my control node.
You can use:

  • Amazon Linux 2

  • Ubuntu

  • CentOS

All work fine.
I mostly used Amazon Linux 2 and Ubuntu in my practice.

🔧 Installing Ansible on Amazon Linux 2

These are the exact steps I followed:

1️⃣ Update the system

sudo yum update -y

2️⃣ Install Ansible using Amazon Extras

sudo amazon-linux-extras install ansible2 -y

3️⃣ Verify installation

ansible --version

Once I saw the version output, I knew Ansible was installed successfully.

🔧 Installing Ansible on Ubuntu (Alternative Method)

If you use Ubuntu as your controller:

sudo apt update -y
sudo apt install ansible -y
ansible --version

Both operating systems work smoothly.

⭐ Setting Up the Managed Nodes (Target Servers)

Once Ansible was installed on the controller, I launched additional EC2 instances to use as managed nodes.

To allow Ansible to connect:

  • I kept port 22 (SSH) open

  • I ensured the private key (.pem) file was on the controller machine

  • I SSH’d into the controller and copied my key there

Example:

scp -i mykey.pem mykey.pem ec2-user@<controller-public-ip>:/home/ec2-user/

After that, I set correct permissions:

chmod 400 mykey.pem

⭐ Creating a Custom Inventory File

This is the file where I tell Ansible which servers to manage.

I created a file named inventory.ini:

[webservers]
web1 ansible_host=54.123.45.67 ansible_user=ec2-user ansible_ssh_private_key_file=mykey.pem
web2 ansible_host=54.123.55.21 ansible_user=ec2-user ansible_ssh_private_key_file=mykey.pem

What these mean:

  • ansible_host → EC2 public IP

  • ansible_user → default login user (ec2-user / ubuntu)

  • ansible_ssh_private_key_file → key file path

This is where I finally understood how Ansible identifies and connects to servers.

⭐ Testing SSH Connectivity Using Ansible

Before running any automation, I tested connection using the ping module:

ansible webservers -i inventory.ini -m ping

A successful output looked like:

web1 | SUCCESS => {"changed": false, "ping": "pong"}
web2 | SUCCESS => {"changed": false, "ping": "pong"}

Seeing this “pong” output gave me confidence that everything was working correctly.

📦 Final Setup Flow (My Practical Workflow)

✔ Ansible installed on EC2 controller

✔ Private key copied with correct permissions

✔ Inventory file created

✔ Ping test successful

After this setup, I was ready to:

  • run ad-hoc commands

  • write playbooks

  • deploy apps

  • automate server configuration

This was the point where my real Ansible learning started.

⭐ Quick Example After Setup

Here’s the first real command I ran:

ansible webservers -i inventory.ini -m apt -a "name=nginx state=present" --become

And within seconds, nginx was installed across all my servers — fully automated.

That felt like a true DevOps moment.

⭐ Final Thoughts

Setting up Ansible on a controller and connecting it to EC2 instances was a simple but powerful experience.
Once the SSH connection and inventory file were in place, everything else became very easy.

This setup is the foundation for:

  • ad-hoc commands

  • playbooks

  • inventory configurations

  • roles

  • automation workflows

In the next blog, I’ll write about:

👉 Ansible Ad-Hoc Commands
(the fastest way to run automation without creating playbooks)

Comments

Post a Comment

Popular posts from this blog

Ansible Playbooks – How I Learned to Automate Complete Tasks

 After getting comfortable with ad-hoc commands, I moved on to the most important part of Ansible — Playbooks . This is where the real automation happens. Ad-hoc commands are good for quick tasks, but playbooks allow me to write repeatable, structured, and complete automation scripts . In this blog, I’ll explain playbooks in the simplest way possible, based on how I understood and practiced them. ⭐ What Are Ansible Playbooks? (In My Own Words) Playbooks are YAML files where I define: what tasks I want to run on which servers in what order with what configurations Playbooks allow me to automate full workflows like: installing packages configuring services deploying applications managing files creating users restarting services For me, a playbook is basically: “A step-by-step automation recipe written in YAML.” ⭐ Basic Structure of a Playbook Here’s the structure I internalised: - name: <description> hosts: <target_serv...
Read more

Understanding Ansible Modules

 As I continued learning Ansible, one of the most important concepts I came across was Modules . They are the core of how Ansible performs automation. Once I understood modules clearly, writing playbooks and running ad-hoc commands became much easier and more meaningful. In this blog, I’m sharing what Ansible modules are and how I understood them through hands-on practice. ⭐ What Are Ansible Modules? (In My Own Words) Modules are the actual actions Ansible performs on a server. If I want to: install a package create a file add a user start a service copy a configuration Ansible uses a module to do it. So for me: “Modules are the building blocks of every automation task in Ansible.” Every ad-hoc command and every task inside a playbook uses a module. ⭐ How I Understand the Working of Modules Whenever I run Ansible: Ansible connects to the server through SSH The selected module runs on the remote machine It performs the action I defined I...
Read more

“What is Ansible? – My Understanding as a DevOps Learner”

  What is Ansible? – My Understanding as a DevOps Learner When I started my DevOps journey, Ansible was one of the first automation tools I learned. At the beginning, I only knew that Ansible “automates tasks,” but after going through my training sessions and hands-on practice, I understood how powerful and simple it actually is. In this blog, I want to explain what Ansible means in my own words , exactly how I understood it as a beginner. ⭐ How I Understand Ansible Ansible is an open-source automation tool that helps us manage servers without doing everything manually. Instead of logging into each machine and running commands one by one, I can write instructions in a simple YAML file, and Ansible applies them to any number of servers at the same time. So for me, Ansible is basically: “Write once → run anywhere → automate everything.” That’s the beauty of it. ⭐ Why Ansible is Very Useful From my learning, these are the main reasons: 1. It is agentless This was the ...
Read more