Introduction

For Project 3 in my DevOps journey, I set out to automate an EC2 instance setup with Ansible—installing Nginx and securing it by disabling root SSH login. What seemed like a straightforward task turned into a learning adventure, especially since I’m on Windows and had to wrestle with WSL quirks. Here’s how I pulled it off, stumbles and all.

The Plan

My goal was clear: use Ansible to configure an EC2 instance efficiently. The steps were:

  1. Install Ansible on my local machine.
  2. Launch a fresh Amazon Linux 2 EC2 instance with SSH access.
  3. Set up an Ansible inventory file to connect to the instance.
  4. Write a playbook to install Nginx and disable root SSH login.
  5. Run the playbook and verify the automation worked — Nginx running, root access blocked.

How It Went

Here’s what I did to make it happen:

  • Installing Ansible: Since I’m on Windows, I installed WSL (Windows Subsystem for Linux) and Ubuntu. Then, I ran:
sudo apt update
  sudo apt-get install ansible

Ansible was ready after confirming with ansible --version.

  • New EC2 Instance: I created an Amazon Linux 2 instance in AWS with a t3.micro, a security group for SSH (port 22, my IP), and a key pair (my-ansible-key.pem). SSH worked fine:
ssh -i my-ansible-key.pem [email protected]
  • Inventory Setup: I created inventory.ini with my instance’s IP and key path, but testing the connection hit a snag (more on that later).
  • Playbook Creation: I wrote setup.yml to install Nginx and disable root SSH, but running it revealed more hurdles.
  • Verification: After tweaks, I confirmed Nginx at http:// and tested SSH—root was denied, ec2-user worked.

Challenges & Solutions

Challenge 1: WSL and Inventory File Permissions

When I ran ansible -m ping -i inventory.ini ec2, I got errors about parsing inventory.ini and an "unprotected private key" warning. The issue? My .pem file was in /mnt/c/... (Windows file system), and WSL couldn’t enforce proper permissions (0555 was too open).

  • Solution: I copied the key to /root/my-ansible-key.pem in WSL:
cp /mnt/c/Users/deepa/downloads/devops/project2/my-ansible-key.pem /root/my-ansible-key.pem
chmod 0600 /root/my-ansible-key.pem

Updated inventory.ini:

[ec2]
13.60.41.232 ansible_user=ec2-user ansible_ssh_private_key_file=/root/my-ansible-key.pem

The ping worked: pong!

Challenge 2: Nginx Not Found in Playbook

Running ansible-playbook -i inventory.ini setup.yml failed with "No package matching 'nginx' found." Amazon Linux 2 doesn’t include Nginx in its default repos—I needed amazon-linux-extras.

  • Solution: I tweaked setup.yml to enable Nginx first.
- name: Enable Nginx in amazon-linux-extras
  command: amazon-linux-extras enable nginx1
  args:
    creates: /var/lib/amazon-linux-extras/nginx1

Reran the playbook, and Nginx installed successfully.

Challenge 3: No HTTP Access

After Nginx installed, http:// didn’t load—my security group only allowed SSH (port 22), not HTTP (port 80).

  • Solution: Added an inbound rule in AWS:
  • Type: HTTP
  • Port: 80
  • Source: 0.0.0.0/0 (for testing) The Nginx welcome page appeared!

Takeaways

  • WSL Workarounds: Moving files to WSL’s file system avoids permission headaches with Windows paths.
  • Package Dependencies: Automation needs to account for OS-specific repos — amazon-linux-extras was my savior.
  • Security Groups Are Key: Forgetting HTTP access reminded me to align network rules with app needs.
  • Automation Wins: Seeing Nginx pop up and root SSH get blocked with one command felt like magic.

This project was a grind, but it taught me how Ansible simplifies server setup—and how to troubleshoot when things go sideways. What’s your go-to fix for Ansible hiccups?