Deploying EPicbook with Production-Grade Terraform

Deploying EpicBook with Production-Grade Terraform
From Manual Setup to Automated Perfection: Building EpicBook with Production-Grade Terraform

After working on multiple Terraform-based deployments across AWS and Azure, I wanted to push further — to structure infrastructure like a true production environment.
The goal: Deploy EpicBook (a Node.js + MySQL app) using Terraform modules, workspaces, and remote backends, all in a way that scales cleanly between development and production.

🎯 Objective

To build a complete, secure, and repeatable Terraform stack for EpicBook that includes:

Modularized infrastructure (network, database, compute)

Dynamic variables and environment-aware configurations

Remote backend with state locking

Independent dev and prod environments managed through workspaces

🧩 1️⃣ Building the Network Module

I started with a VNet (10.0.0.0/16) and two subnets:

public-subnet for the VM

mysql-subnet for the private Flexible Server

The Network Security Groups (NSGs) were set up for strict access control:

Public NSG: only port 22 from my IP and 80 from the internet

Private NSG: only 3306 from the app subnet

This structure provided a solid foundation for secure and isolated networking.

🛢️ 2️⃣ Private Database Module

Next, I deployed Azure Database for MySQL – Flexible Server with private access (VNet integration).
The database credentials and configurations were managed through Terraform variables — no hardcoding — and a Private DNS Zone linked the DB endpoint to the VNet.

🖥️ 3️⃣ Compute / App Module

The compute module handled:

Creating an Ubuntu VM (B1s)

Installing Node.js, Nginx, npm, git, and MySQL client

Cloning and deploying the EpicBook app

Configuring Nginx to serve the frontend and proxy /api to the backend service

This ensured both the SPA and API were accessible from the same endpoint.

🧮 4️⃣ Workspaces, Backends & Locking

One of the key production features was separating environments via Terraform Workspaces:

terraform workspace new dev
terraform workspace new prod

Each workspace used the same root module, with dynamic naming handled through locals and maps.

The remote backend was configured on AWS S3 with state locking enabled via DynamoDB.
This setup prevents conflicts when multiple engineers work on infrastructure simultaneously — a must-have for collaborative DevOps.

🌐 5️⃣ Deployment and Verification

After applying both dev and prod workspaces, I confirmed:

Separate, isolated resources were created

Terraform state was properly locked when accessed concurrently

The EpicBook application loaded successfully in the browser

The API routes responded correctly via Nginx reverse proxy

🧠 Reflections

This assignment pulled together everything I’ve learned about Terraform — and pushed it to production-level rigor.
The key takeaways:

Modular design keeps infrastructure clean and maintainable

Workspaces + backends make multi-environment management effortless

State locking ensures team-safe deployments

Security and automation go hand-in-hand in every IaC project

⚡ Next Step

The natural next move is to integrate this stack into a CI/CD pipeline (GitHub Actions or Azure DevOps) so each environment can deploy automatically — versioned, tested, and monitored.

In short:
Terraform isn’t just about provisioning resources — it’s about building reliable, reusable, and secure infrastructure at scale.