📘 Ansible Learning Journey - From Manual SSH to Automation Thinking

CloudWithHorla | Cloud & DevOps Engineer (Learning in Progress 🚀)

Automation looks simple from the outside — until you try to build it yourself.

Recently, I worked on an Ansible hands-on project as part of my continuous learning in Cloud and DevOps engineering. The goal was simple on paper:

set up a controller node and manage multiple target nodes using Ansible.

In reality, the journey taught me far more than just commands.

---

🏗️ Project Overview

I built a small but realistic infrastructure on AWS consisting of:

• * 1 EC2 Controller (Ansible Master)
• * 3 EC2 Target Nodes
• * Ubuntu-based servers
• * SSH key-based authentication
• * Ansible ad-hoc commands and playbooks

This setup mirrors what actually happens in real-world environments — not just labs.

---

🔧 What I Implemented (Step-by-Step)

1. Provisioned EC2 instances

• 1 controller
• 3 managed nodes

1. Installed core dependencies

• Python3
• Pip
• Ansible on the controller

1. Created Ansible configuration

• Custom ansible.cfg
• Inventory file defining all target nodes

1. SSH Key-Based Authentication

• Generated SSH key pair on the controller
• Injected the controller’s public key into each node’s authorized_keys

• Learned the difference between:
  

   >>  # append (safe)
   >   # overwrite (dangerous)
  

You are adding a new line of Public Key which is safe.

echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCppACFB47TRDuT8YXSSxL+T9jxirz0yC04avxRB8nAOnVcz5xXpyT0mhYbhcLCbI2D4pcWkSb1NqGyUwF3OeHGtur+0MkDq7/9jhPG0amrFbk+RBQM+WZ7UaEzopiK7ZB8MUKwtMGVhR9wgtIiSK6+fgmzNaCpfj13B9aH7iiMRn4sHCwr81zCAskb79DnhCmB8Y7NU2VAqlMnW5NIFEujv3aixmPSZbIKomNotGT2ljtOV5EoMuFFqq3DqA/kZVM1WJjBMEAlWtdQTn2UM5dTAi5BNvPMYJcdzEfc4fXvkp11rFYLiEc9ZUFkYi6APg1Ju5bPgh0Yp+9YOhlCMEuEPlAdxUIHE4Ih3HoNhLOB622c+a6lNK5SF7Y76gB5cdK8Rar/tRQqF6kxqy852SLfZbLnXkfIOuktF4XGemMMt13F7yw1k980vwcwCgfAK4zOZ2hmaDypmG0Rd/lhsIpC+4i6s4T8a+AB3BSKt9KH/Dn9cxUM0BVgxgM1hWyk7Hs= ubuntu@ip-10-0-8-231" >> .ssh/authorized_keys

Caveat: Best practise

You are removing an existing "Public Key" which is not safe.

echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCppACFB47TRDuT8YXSSxL+T9jxirz0yC04avxRB8nAOnVcz5xXpyT0mhYbhcLCbI2D4pcWkSb1NqGyUwF3OeHGtur+0MkDq7/9jhPG0amrFbk+RBQM+WZ7UaEzopiK7ZB8MUKwtMGVhR9wgtIiSK6+fgmzNaCpfj13B9aH7iiMRn4sHCwr81zCAskb79DnhCmB8Y7NU2VAqlMnW5NIFEujv3aixmPSZbIKomNotGT2ljtOV5EoMuFFqq3DqA/kZVM1WJjBMEAlWtdQTn2UM5dTAi5BNvPMYJcdzEfc4fXvkp11rFYLiEc9ZUFkYi6APg1Ju5bPgh0Yp+9YOhlCMEuEPlAdxUIHE4Ih3HoNhLOB622c+a6lNK5SF7Y76gB5cdK8Rar/tRQqF6kxqy852SLfZbLnXkfIOuktF4XGemMMt13F7yw1k980vwcwCgfAK4zOZ2hmaDypmG0Rd/lhsIpC+4i6s4T8a+AB3BSKt9KH/Dn9cxUM0BVgxgM1hWyk7Hs= ubuntu@ip-10-0-8-231" > .ssh/authorized_keys

Caveat: Not a best practise

Sample

1. Privilege Escalation

• Used become: true for system-level tasks
• Ensured sudo access without breaking security

1. Ansible Ad-Hoc Commands

   ansible -m apt -a "name=git state=present" all -b

1. Ansible Playbook Execution

• Installed and removed packages
• Copied files to remote nodes
• Managed services across multiple machines in parallel

---

📄 Sample Playbook used in my project:

---
- name: Installing nginx playbook
  hosts: all
  become: true
  tasks:
    - name: First Task
      apt:
        name: nginx
        state: absent

    - name: Second Task
      apt:
        name: nginx
        state: present

    - name: Copy file with owner and permissions
      ansible.builtin.copy:
        src: ./index.html
        dest: /var/www/html/index.html
        owner: root
        group: root
        mode: '0777'

    - name: Third Task
      apt:
        name: apache2
        state: present

---

⚠️ Challenges I Faced (and What I Learned)

1️⃣ “Permission denied (publickey)”

I initially thought Ansible could manage nodes without SSH access.
Through research and troubleshooting, I learned a critical truth:

Ansible always uses SSH. There is no automation without an initial trust path.

Key-based authentication must be established at least once — either at instance creation or manually.

---

2️⃣ PasswordAuthentication Confusion

I tried disabling password authentication before confirming key-based access.

That was a big lesson:

❌ Disabling PasswordAuthentication does NOT give access
✅ It only removes password login after SSH keys already work

Correct order matters:

1. Establish SSH key access
2. Test connectivity
3. Then disable password authentication

---

3️⃣ APT Lock Errors (unattended-upgrades)

One node failed while others succeeded.

Cause:

• Ubuntu auto-updates were running in the background

Lesson:

Infrastructure is not deterministic — nodes behave independently.

Solution:

• Wait and retry
• Or design playbooks with retries and checks

---

Screenshot Output

This is when I ping of the node

This is when I ping all the node

This is the first page output of my Playbook

This is the second page output of my Playbook

Node 01

Node 02

Node 03

---

4️⃣ Wrong Package Names

I attempted to install apache instead of apache2.

Lesson:

Automation does exactly what you tell it — not what you mean.

Small naming errors can break entire workflows.

---

🧠 Key Takeaways I Want Others to Learn

• 🔑 SSH is foundational — Ansible cannot bypass it
• 🔁 Automation is about idempotency and retries
• 🧪 Always test with --syntax-check and ping yourself (localhost) for test.

• 🔐 Never overwrite authorized_keys
• 🛠️ Real learning happens when things break

---

🌱 Growth Mindset

This project reinforced my core belief:

Never stop learning.

Every error I faced forced me to:

• Research deeper
• Read documentation
• Understand why things work — not just how

I’m still learning.
I’m still breaking things.
And I’m still getting better — one tool at a time.

---

📌 Final Thought

Automation isn’t about avoiding work —
it’s about doing the work once, correctly and at scale.

CloudWithHorla ☁️
Cloud & DevOps Engineer | Always Learning