Automating Webserver Deployment with Ansible, AWS, and Azure

By Abey Mathew

🔍 Overview

Manual web server deployments are time-consuming and prone to human error. That’s why I built IWBA (Integrated Webserver Build Automation) — a powerful, automated solution for provisioning and configuring Apache Tomcat servers using AWS Lambda, Azure-hosted Ansible, and Python (Paramiko).

This project helps users deploy a Tomcat server with just a few inputs — no manual SSH or server login needed.

🎯 Objective

The core aim of IWBA is to automate Tomcat deployment based on parameters submitted through a web form.

✅ User submits parameters (e.g., Tomcat name, instance type).
✅ AWS Lambda spins up a Red Hat Linux EC2 instance.
✅ Second Lambda function (triggered via SNS) connects to an Azure-hosted Ansible server.
✅ Tomcat is installed, configured, and fully set up via an Ansible playbook.
✅ A README file with setup details is sent to the user via email.

🧠 How It Works – Architecture Breakdown

📌 User Flow

Frontend (Flask Web App): User submits a form with Tomcat name, instance type, and email.
Lambda #1: Stores data in DynamoDB and provisions an EC2 instance (RHEL).
Lambda #2: Triggered via SNS, uses Paramiko to SSH into the Azure server.
Ansible Playbook: Executes full Tomcat installation & configuration on the EC2.

🛠️ Technologies Used

AWS Lambda: Automates EC2 provisioning.
Amazon EC2: Hosts the target RHEL server.
DynamoDB: Stores submitted parameters.
Azure VM: Hosts the Ansible control server.
Ansible: Automates Tomcat configuration.
Paramiko: Enables remote command execution from Lambda to Azure.
OpenJDK: Java runtime for Tomcat.
Python: Backend logic for both Lambda functions.
Tomcat: Java-based application server.

⚙️ Infrastructure Requirements

Ansible Core Server: Azure-hosted CentOS 8.5 VM with 4GB RAM.
Target EC2 Instance: RHEL on AWS.
Test Servers: VirtualBox + CentOS Stream 9 (for testing playbooks).

📋 Build Process Breakdown

✅ Lambda #1 (AWS)

Accepts user input from the web interface.
Writes to DynamoDB.
Provisions EC2 instance based on instance type.

✅ Lambda #2 (Triggered via SNS)

Uses Paramiko to SSH into the Ansible master server (Azure).
Sends Tomcat configuration parameters.

✅ Ansible Playbook (Azure)

Creates directories under /local/apps.
Adds user/group.
Installs OpenJDK.
Downloads & configures Tomcat.
Edits server.xml (incremental port config).
Generates a README.txt with startup scripts and port details.

🧪 Real Output & Screenshots

Here are some of the screenshots from the project:

Input Screen: User fills form with Tomcat name, AWS instance type, and email.
EC2 Creation: Console shows dynamically created EC2 instance.
DynamoDB Entry: DB entry logs all submitted parameters.
Playbook Execution Logs: Real-time log output from Ansible server.
Tomcat Status: Multiple Tomcat instances running on unique ports.
README.txt Output: Contains configuration summary and startup scripts.

🧾 Conclusion

IWBA offers a fully automated, error-free, and scalable way to deploy Tomcat instances on the cloud.

Key Benefits:

⏱️ Reduces deployment time.
🛡️ Minimizes manual errors.
⚙️ Ensures consistency across environments.
📧 Auto-emails complete setup details to the user.

🚀 Future Scope

🔁 Support for Other Servers: WebLogic, WebSphere, JBoss.
🧩 Public REST API: For third-party integrations.
🛠️ Self-Healing: Auto-restart or recreate failed instances.
🧪 Drift Detection: Alert on unintentional server configuration changes.

🙏 Thanks for Reading

If you’re passionate about cloud automation, check out the GitHub repo and feel free to fork or contribute.

Let’s simplify server deployments, one playbook at a time.

Automating Webserver Deployment with Ansible, AWS, and Azure – Project IWBA

🔍 Overview

🎯 Objective