Building a Zero-Downtime Deployment DevOps Project

This project is a hands-on DevOps engineering project focused on building a zero-downtime deployment pipeline from scratch.

The goal is to take an ASP.NET Core API and deploy it on AWS using modern DevOps practices such as Infrastructure as Code, containerization, Amazon ECS, Amazon ECR, Terraform, Docker, and eventually blue/green deployment strategies.

Instead of only learning the theory, this project is being built step by step to understand how real cloud infrastructure, application containers, and deployment workflows connect together in practice.

The long-term goal is to build a production-style deployment workflow where application updates can be released without interrupting users or causing downtime.

GitHub repository: https://github.com/Victordeliverer/devops-zero-downtime-deployment

Step 1: Project Setup and Architecture Planning

The first step focused on setting up the foundation of the project.

This involved creating the project repository and organizing the folder structure for the application code, Terraform infrastructure code, documentation, diagrams, scripts, and future GitHub Actions workflows.

The project structure included:

.github/workflows
app
diagrams
docs
scripts
terraform

This structure is important because a clean repository makes the project easier to maintain, scale, and explain. In real DevOps projects, the organization of the repository matters because infrastructure code, application code, deployment scripts, and documentation all need to be easy to find.

The ASP.NET Core API project was also created and tested locally. This helped confirm that the application could run before introducing Docker, AWS, Terraform, ECS, or deployment automation.

This step was mainly about answering the question:

What are we building, and how should the project be organized?

Key Actions

✅ Created the project repository
✅ Set up the base folder structure
✅ Added the ASP.NET Core API project
✅ Ran the API locally
✅ Started documenting the project purpose
✅ Defined the initial zero-downtime deployment direction

Key Learning

The biggest lesson from this step was that DevOps projects should start with clear structure and architecture thinking before adding too much automation.

A good project foundation makes the later stages easier, especially when working with Terraform, Docker, ECS, CI/CD, and deployment strategies.

Step 2: Building Base Infrastructure with Terraform

The second step focused on creating the foundational AWS infrastructure using Terraform.

The goal was to provision the cloud resources that the application would eventually need in order to run on AWS.

Terraform was used because it allows infrastructure to be written as code. Instead of manually clicking through the AWS Console, the infrastructure can be defined, reviewed, version-controlled, and recreated consistently.

The base infrastructure included:

VPC
Public subnets
Internet Gateway
Route tables
Security groups
ECS cluster
ECS task execution role
ECR repository

The VPC acts as the private network for the project. Public subnets were created so that internet-facing resources could later be deployed. An Internet Gateway and route table allowed traffic to flow between the public subnets and the internet.

Security groups were added to control inbound and outbound traffic. This is important because security groups act like cloud firewalls for AWS resources.

An Amazon ECR repository was created to store Docker images for the ASP.NET Core API. This is where the container image would later be pushed after being built locally.

An ECS cluster and task execution role were also created. The ECS cluster provides the logical environment where containers will run, while the task execution role allows ECS to pull images from ECR and write logs to CloudWatch.

This step also included an important real-world troubleshooting moment. During terraform apply, AWS blocked some actions because an access key had been quarantined with the AWSCompromisedKeyQuarantineV3 policy. This showed the importance of protecting AWS credentials, rotating exposed keys, and understanding IAM security controls.

Key Actions

✅ Created Terraform modules
✅ Built the networking module
✅ Created a custom VPC
✅ Created public subnets
✅ Added an Internet Gateway
✅ Configured public route tables
✅ Created security groups
✅ Created an Amazon ECR repository
✅ Created an ECS cluster
✅ Created an ECS task execution IAM role
✅ Fixed Terraform output configuration
✅ Retrieved infrastructure outputs successfully

Key Learning

The biggest lesson from this step was understanding how cloud infrastructure components connect together.

The VPC provides the network, the subnets provide placement for resources, the Internet Gateway enables internet access, security groups control traffic, ECR stores container images, and ECS provides the container runtime environment.

This was the point where the project moved from planning into real cloud infrastructure.

Step 3: Containerizing the ASP.NET Core API and Running It on ECS

The third step focused on containerizing the ASP.NET Core API and preparing it to run on Amazon ECS.

Since ECS runs containers, the application first needed to be packaged as a Docker image.

A Dockerfile was created using Microsoft’s official .NET 8 images. The Dockerfile used a multi-stage build approach:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build

for building and publishing the application, and:

FROM mcr.microsoft.com/dotnet/aspnet:8.0

for running the final application.

This approach is useful because the SDK image contains the tools needed to build the application, while the ASP.NET runtime image is smaller and only contains what is needed to run the application.

After creating the Dockerfile, the image was built locally:

docker build -t aspnet-api .

The container was then run locally. During this step, there were some practical Docker issues to troubleshoot, including Docker Desktop not running, port 8080 already being used, and container name conflicts.

Eventually, the container ran successfully and the ASP.NET Core application started with Kestrel listening on port 8080.

The next step was connecting Docker to AWS. Terraform outputs were used to retrieve the ECR repository URL. The local Docker image was then tagged with the ECR repository URL and prepared to be pushed to Amazon ECR.

After that, the ECS configuration was expanded with a task definition and ECS service.

The ECS task definition described how the container should run, including:

Container image
CPU
Memory
Port mappings
Environment variables
Logging configuration

The ECS service was created to keep one running task active. This is important because an ECS service helps maintain the desired number of running containers. If a task stops, ECS can attempt to replace it.

By the end of this step, the project had moved from local application code to a containerized application that could run locally and be deployed through ECS.

Key Actions

✅ Created a Dockerfile
✅ Used .NET 8 SDK and ASP.NET runtime images
✅ Built the Docker image locally
✅ Ran the container locally
✅ Troubleshot Docker daemon issues
✅ Resolved local port conflicts
✅ Checked Docker logs
✅ Confirmed the ASP.NET app started inside the container
✅ Retrieved ECR repository URL from Terraform outputs
✅ Prepared image tagging for ECR
✅ Updated ECS Terraform module
✅ Added ECS task definition
✅ Added ECS service
✅ Confirmed ECS task creation

Key Learning

The biggest lesson from this step was understanding how Docker, ECR, ECS task definitions, and ECS services work together.

The workflow became clearer:

Application code
↓
Docker image
↓
Amazon ECR
↓
ECS task definition
↓
ECS service
↓
Running container task

This was an important milestone because the project moved from only creating infrastructure to actually running a containerized workload.

Summary of Steps 1–3

The first three steps created the foundation of the zero-downtime deployment project.

Step 1 focused on planning, repository structure, and running the ASP.NET Core API locally.

Step 2 focused on provisioning AWS infrastructure with Terraform, including networking, ECR, ECS, and IAM.

Step 3 focused on containerizing the application with Docker, testing it locally, pushing toward ECR, and preparing the ECS task/service configuration.

Together, these three steps represent the foundation of a real DevOps deployment workflow:

Plan the project
↓
Create the cloud infrastructure
↓
Containerize the application
↓
Prepare the app to run on ECS

This project is still ongoing. The next stages will focus on improving the deployment workflow, adding load balancing, enabling more reliable application updates, and eventually implementing a zero-downtime deployment strategy such as blue/green deployments.

The long-term goal is to make this project more production-grade by adding areas such as:

Application Load Balancer
Private subnets
CloudWatch logging and monitoring
CI/CD with GitHub Actions
ECS service deployment automation
Blue/green deployment strategy
Health checks
Rollback strategy
Security improvements

This project has already provided practical experience with AWS, Terraform, Docker, ECS, ECR, IAM, networking, and troubleshooting real deployment issues.