DEV Community: Richard Atodo

Leveling Up: Provisioning EKS with Terraform for My DevOps Project

Richard Atodo — Thu, 08 May 2025 08:33:36 +0000

Following the successful containerization and CI/CD setup for my TV Shows application (as detailed in my previous post, “From CosmosDB to DynamoDB: Migrating and Containerizing a FastAPI + React App”), the next logical step in my “Learn to Cloud” adventure was to embrace a more robust and scalable orchestration platform: Amazon Elastic Kubernetes Service (EKS). To manage this new layer of infrastructure as code (IaC), I turned to Terraform. This post chronicles the experience, the hurdles encountered while setting up EKS with Terraform, and the solutions that paved the way.

Why EKS? The Push for Orchestration

While running Docker containers on a single EC2 instance with Docker Compose worked for the initial phase, the goal was always to explore true cloud-native practices. Kubernetes (and EKS as its managed AWS offering) promised:

Scalability: Easily scale my application pods up or down based on demand.
Resilience: Automatic recovery of pods and better fault tolerance.
Service Discovery & Load Balancing: Integrated mechanisms for inter-service communication and exposing applications.
Declarative Configuration: Defining my desired application state with Kubernetes manifests.

Terraform: The Tool for the Job

Manually clicking through the AWS console to set up an EKS cluster, VPC, node groups, and all associated IAM roles and security groups is complex and error-prone. With its declarative IaC approach, Terraform was the clear choice to automate this provisioning, ensuring repeatability and version control for my infrastructure. I decided to leverage the official terraform-aws-modules/eks/aws module, which significantly simplifies EKS setup.

Challenge 1: Mastering Terraform Remote Backend State

Before starting on EKS, best practice dictates setting up a remote backend for Terraform state. This is crucial for collaboration and preventing state loss. I opted for S3 with DynamoDB for locking.

The Stumble: I ran into a really weird issue. My initial mistake was including the resource definitions for the S3 bucket and DynamoDB table within the same Terraform configuration that was also defining the EKS cluster and using that S3 bucket as its backend.
The Symptom: When I ran terraform apply for my EKS cluster, it seemed to be destroying the very S3 bucket and DynamoDB table that held my Terraform state! Terraform would start creating EKS resources, then attempt to "manage" (and destroy) the S3 bucket it was actively using. This caused the apply to fail spectacularly mid-operation, as Terraform couldn't save its state to a bucket it had just deleted, or release a lock from a DynamoDB table that no longer existed. The errors were clear: NoSuchBucketand ResourceNotFoundException for the lock table. As you can imagine, this was causing a mess, losing my Terraform state, and leading to issues with Terraform locks.

The Solution (Initial Part): The key was strict separation.

Create a completely separate Terraform configuration (e.g., in a remote-backend subdirectory) whose sole purpose is to define and create the S3 bucket (with versioning and encryption) and the DynamoDB table for state locking. This configuration uses the default local backend.
Run terraform apply on this backend-only configuration, once to provision these resources.
Then, in my main EKS Terraform configuration, I only included the backend "s3" {} block in providers.tf, pointing to the pre-existing bucket and table. The EKS configuration itself contained no resource blocks for the backend components.

A Lingering Ghost (The Full Solution): Even after separating the code, when I ran terraform plan from the eks-cluster directory, I noticed it still had plans to destroy 4 resources, which I knew were my state resources! The issue was that a previous (failed) apply had recorded those backend resources in the EKS configuration's state file. When I ran terraform state list, the 4 resources on display were indeed the resources for the state. Terraform compared my current code (no backend resources defined) with the state file (backend resources were recorded) and concluded that since the code no longer defined them, they should be destroyed according to the state file it was managing. The fix was explicitly removing these resources from the EKS cluster's state file by running terraform state rm <resource_name> for each of the four backend resources. After doing this, terraform plan correctly showed 0 to destroy, acknowledging they are managed elsewhere.

Challenge 2: VPC Configuration — To Create or To Use?

The EKS module can create a new VPC or use an existing one.

Initial Approach: I let the module create a new VPC. This approach is often cleaner and ensures that all EKS tagging requirements are met automatically.
The “VpcLimitExceeded” Wall: During one terraform apply, I encountered the VpcLimitExceeded error. My AWS account had reached its default limit of 5 VPCs per region. This was because Terraform created some resources, including VPCs, during my failed terraform apply.

Solutions & Considerations:

Delete Unused VPCs: The quickest fix was to log into the AWS console and delete old, unused VPCs.

Challenge 3: “Resource Already Exists” — Cleaning Up After Failed Runs

EKS cluster creation is a lengthy process. If an apply fails midway, some resources might be created while others aren't, and Terraform might not have recorded their creation in the state file if it crashed before saving, just like what happened with the VPCs.

The Problem: On subsequent terraform apply attempts, I encountered errors like AlreadyExistsException for a KMS Alias (alias/eks/ltc-eks-cluster) and a CloudWatch Log Group (/aws/eks/ltc-eks-cluster/cluster). Terraform was trying to create these, but they already existed from a previous partial run.

The Solution:

Manual Deletion (Use with Caution): For the KMS alias, since I was certain it was a remnant and not in use, I manually deleted it via the AWS console before re-running apply was the option I took. This is riskier if you're unsure of the resource's origin.

Ideally, Terraform modules are idempotent, but sometimes with complex, multi-step creations like EKS, partial failures can leave things in a state that requires manual intervention.

The Sweet Success: A Running EKS Cluster

After navigating these hurdles, terraform apply finally completed, and the outputs.tf provided the command to configure kubectl. Seeing kubectl get nodes return the worker nodes from my new EKS cluster was a very satisfying moment!

Key Learnings from EKS & Terraform:

Backend State is Sacred: Treat its setup carefully and keep it separate. Understand how state inconsistencies can lead to unexpected plans.
Understand Module Defaults & Requirements: The EKS module is powerful but has expectations (like VPC subnet tagging for load balancers).
AWS Service Limits are Real: Be aware of them, especially for resources like VPCs.
Failed Applies Need Cleanup/Import: Don’t just keep re-running apply. Investigate "already exists" errors and either import the resource or safely delete it if it's an orphaned remnant.
Patience: EKS cluster provisioning takes time.

You can find the repository here.

Next Steps: Deploying the Application

With the EKS cluster provisioned by Terraform and my CI/CD pipeline pushing images to ECR, the next phase is to write the Kubernetes YAML manifests (Deployments, Services, ConfigMaps, Secrets) to deploy my React frontend and FastAPI backend onto the cluster. This will involve configuring Ingress for external access and IRSA for secure AWS service access from my backend pods. The journey to a fully orchestrated application continues!

From CosmosDB to DynamoDB: Migrating and Containerizing a FastAPI + React App

Richard Atodo — Mon, 21 Apr 2025 13:19:30 +0000

Building and deploying a full-stack application involves more than just writing code. It's a journey through infrastructure, automation, and inevitable troubleshooting. As part of the Learn to Cloud initiative, I recently expanded on a previous Phase 2 Capstone Project (a Serverless Movies API) to focus on applying core DevOps practices like containerization, CI/CD, and eventually observability/monitoring. The target was a simple TV show application (a sample is available here. The path from local development to a containerized deployment on AWS using CI/CD was filled with valuable lessons. Here's a look at the experience, the hurdles, and how I overcame them.

The Goal: A DevOps-Focused TV Show App

The application idea was straightforward: a web app where users could browse TV shows and view details about their seasons and episodes. The core goal, however, was applying modern DevOps techniques using this stack:

Backend: FastAPI (Python) for its speed and ease of use.
Frontend: React for building the user interface.
Database: Initially Azure Cosmos DB, but migrated to AWS DynamoDB.
Deployment: Docker containers running on an AWS EC2 instance.
Automation: GitHub Actions for CI/CD.

Challenge 1: Migrating the Backend (Cosmos DB to DynamoDB)
One of the first major tasks was switching the database. Moving from Azure Cosmos DB’s SQL API to DynamoDB required more than just changing connection strings.

Problem: Different SDKs (azure-cosmos vs. boto3) and fundamentally different query models (SQL-like queries vs. DynamoDB's key-value/document operations like scan and get_item). AWS authentication also needed handling.
Solution: I refactored the backend’s data access layer to use boto3. Listing all shows involved a scan operation (noting its potential performance impact on large tables), while fetching specific show details used the efficient get_item. For authentication, I transitioned from potential key-based access to using an IAM Role attached to the EC2 instance, which is much more secure. This involved ensuring the role had the correct DynamoDB permissions (dynamodb:Scan, dynamodb:GetItem, etc.).

Challenge 2: Containerizing the Stack
Dockerizing the FastAPI backend and the React frontend (using an Nginx server) seemed standard, but ensuring they worked together smoothly within Docker Compose required careful configuration. The multi-stage build for the React/Nginx frontend was key to keeping the final image small.

Challenge 3: Setting Up the EC2 Environment
I chose Amazon Linux 2023 on a t4g.medium instance (for that Graviton price-performance!). Getting the environment ready for Docker threw up some unexpected curveballs.

Problem: Installing Docker Compose. My initial attempts (sudo dnf install docker-compose) failed because the package name corresponds to the deprecated V1. Trying the correct V2 package (sudo dnf install docker-compose-plugin) also failed initially!
Solution: After some head-scratching, I realized the dnf package manager's cache was likely stale. Running sudo dnf clean all before retrying the docker-compose-plugin installation resolved the issue. This was a good reminder that package managers aren't infallible and sometimes need a refresh.

Challenge 4: “Unable to Connect” — The Dreaded Networking Hurdle
With the containers seemingly running via docker compose up, I tried accessing the frontend from my browser using the EC2 instance's public IP and the mapped port (3000). Result: "Unable to connect."

Problem: The connection wasn’t even reaching the application. This almost always points to a firewall issue.
Solution: The culprit was the EC2 Security Group. It acts as a stateful firewall, and I hadn’t created an inbound rule to allow traffic on TCP port 3000 from my IP address (or 0.0.0.0/0 for testing). Adding this rule immediately fixed the connection issue. Testing connectivity locally on the instance (curl localhost:3000) also helped confirm the containers were running and mapped correctly, isolating the problem to the external firewall (the Security Group).

Challenge 5: Docker Compose Runtime Issues
Even after connecting, the application wasn’t fully working. docker compose ps showed the frontend running, but the backend was missing.

Problem: Docker Compose logs (docker compose logs api-backend) revealed the backend container was failing to start because required environment variables (AWS_REGION, DYNAMODB_TABLE_NAME) were missing.
Solution: I had created a .env file, but I had to double-check:

Was it in the same directory as docker-compose.yml? (Checked with ls -a).
Did it contain the correct variable names and values? (Checked with cat .env).
Was the docker-compose.yml correctly referencing these variables using the ${VAR} syntax in the environment section for the backend service? Correcting a small mistake here and restarting with docker compose down && docker compose up -d brought the backend online.

Challenge 6: Automating Builds with GitHub Actions & AWS OIDC
Manually building and deploying gets tedious fast. Setting up a CI/CD pipeline using GitHub Actions to build images and push them to AWS ECR was the next goal. This involved securely authenticating GitHub Actions with AWS using OpenID Connect (OIDC).

Problem: The workflow failed during the AWS authentication step with Error: Could not assume role with OIDC: No OpenIDConnect provider found.... Even after creating the OIDC provider in AWS IAM, further errors occurred when debugging the IAM Role's Trust Policy.
Solution: This required careful configuration in AWS IAM:

Creating the OIDC Provider: Explicitly adding token.actions.githubusercontent.com as an identity provider in IAM.
Configuring the Role Trust Policy: This was tricky. The initial policy was wrong (it trusted EC2, not GitHub OIDC). The correct policy needed:

Principal: Set to "Federated" referencing the OIDC provider's ARN.
Action: Set to "sts:AssumeRoleWithWebIdentity".
Condition: Carefully crafting the sub claim condition to match the repo:ORG/REPO:ref... format, ensuring I didn't mistakenly include the https://github.com/ prefix. Getting the trust policy exactly right allowed the workflow to assume the role and push images to ECR successfully.

Key Takeaways

Cloud Services Have Nuances: Migrating between databases or setting up authentication requires understanding the specific service’s model (e.g., DynamoDB queries, AWS IAM roles).
Firewalls are Foundational: Security Groups are often the first place to look for connectivity issues to EC2 instances.
Container Orchestration Needs Precision: Docker Compose relies heavily on correct file paths (.env, docker-compose.yml), environment variable syntax, and networking between containers. Logs are essential (docker compose logs <service>).
Package Managers Can Be Quirky: Sometimes, a simple cache clean (dnf clean all) is all you need. Know the difference between V1 and V2 (e.g., docker-compose vs docker compose).
Secure CI/CD Requires Careful Setup: OIDC is powerful for keyless authentication but demands precise configuration of the IAM provider and role trust policies in AWS.
Iterative Debugging is Key: Very rarely does everything work on the first try. Systematically checking logs, configurations, and documentation is crucial.

Conclusion & Next Steps

This project provided a rich learning experience across backend development, cloud database migration, containerization, EC2 instance management, and CI/CD automation within the “Learn to Cloud” framework. Encountering and solving issues with package management, security groups, environment variables, and IAM policies was invaluable. The application now runs on EC2, with deployments automated via GitHub Actions pushing to ECR. See repo here

This provides a solid foundation. The next exciting phase involves using Infrastructure as Code (IaC) with Terraform to provision the AWS resources automatically. This could set the stage for deploying the application onto Amazon Elastic Kubernetes Service (EKS) for enhanced scalability, resilience, and management, further deepening the exploration of DevOps practices on AWS.

Setting Up an Automated Java Build and Deployment Pipeline with AWS CodeArtifact

Richard Atodo — Fri, 14 Mar 2025 19:44:51 +0000

Introduction

In this guide, I will walk you through how I set up an EC2 instance to compile, package, and publish a Java-based Maven project to AWS CodeArtifact. This setup ensures a robust and reusable package management process in a cloud-native CI/CD pipeline.

Step 1: Setting Up the EC2 Instance

1.1 Launching an EC2 Instance

I started by launching an Amazon Linux 2023 t3.micro EC2 instance with the following specifications:

AMI: Amazon Linux 2023
Instance Type: t3.micro
Storage: 8 GB (default)
Security Group: Allowed SSH (port 22) and HTTP (port 80)

1.2 Connecting to the EC2 Instance

After launching the instance, I connected via SSH using:

ssh -i my-key.pem ec2-user@<EC2-Public-IP>

This provided direct access to the instance for software installation.

Step 2: Installing Java and Maven

Maven is required to build and manage Java projects, while Java is needed to run Maven-based applications.

2.1 Installing Java Amazon Corretto 8

Amazon Corretto 8 is a free, production-ready distribution of OpenJDK. I installed it with:

sudo dnf install -y java-1.8.0-amazon-corretto-devel

Then, I set environment variables to ensure Java was properly recognized:

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64
export PATH=$JAVA_HOME/bin:$PATH

To make this change permanent, I added the paths to ~/.bashrc:

echo 'export JAVA_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64' >> ~/.bashrc
echo 'export PATH=$JAVA_HOME/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

I verified the installation with:

java -version

2.2 Installing Maven 3.5.2

Maven 3.5.2 was required to build the Java web app. I downloaded and extracted it manually:

wget https://archive.apache.org/dist/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz
sudo tar -xzf apache-maven-3.5.2-bin.tar.gz -C /opt

Then, I added it to my system PATH:

echo "export PATH=/opt/apache-maven-3.5.2/bin:$PATH" >> ~/.bashrc
source ~/.bashrc

I confirmed Maven was installed by running:

mvn -version

Step 3: Cloning and Configuring the Java Project

I initialized a Git repository on my EC2 instance and connected it to my GitHub repository:

git init
git remote add origin https://github.com/richardatodo/nextwork-web-project.git
git pull origin main

Inside the project directory, I ensured the required dependencies were defined in pom.xml:

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>3.8.1</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Then, I built the project to verify everything was working:

mvn compile

Step 4: Setting Up AWS CodeArtifact

4.1 Creating a CodeArtifact Repository and Domain

Got it! I'll update the blog post to reflect that you created the CodeArtifact domain and repository via the AWS Console instead of using the AWS CLI.

Here’s the revised section:

Step 4: Setting Up AWS CodeArtifact

I created the CodeArtifact domain and repository via the AWS Management Console:

Navigate to AWS CodeArtifact:
- Open the AWS Console and go to CodeArtifact.
Create a CodeArtifact Domain:
- Click Create domain.
- Enter the domain name: nextwork.
- Click Create domain.
Create a CodeArtifact Repository:
- Click Create repository.
- Enter the repository name: nextwork-devops-cicd.
- Select the domain nextwork.
- (Optional) Enable Upstream repositories if needed.
- Click Create repository.

4.2 Configuring IAM Permissions

To allow EC2 to interact with CodeArtifact, I created an IAM policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codeartifact:GetAuthorizationToken",
                "codeartifact:GetRepositoryEndpoint",
                "codeartifact:ReadFromRepository",
                "codeartifact:PublishPackageVersion",
                "codeartifact:PutPackageMetadata"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "sts:GetServiceBearerToken",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "sts:AWSServiceName": "codeartifact.amazonaws.com"
                }
            }
        }
    ]
}

I attached this policy to an IAM role and associated it with my EC2 instance.

4.3 Generating an Authorization Token

To authenticate Maven with CodeArtifact, I generated a token and stored it in an environment variable:

export CODEARTIFACT_AUTH_TOKEN=$(aws codeartifact get-authorization-token --domain nextwork --query authorizationToken --output text)

Step 5: Configuring Maven to Use CodeArtifact

I created a settings.xml file in my project directory:

<settings>
  <servers>
    <server>
      <id>nextwork-nextwork-devops-cicd</id>
      <username>aws</username>
      <password>${env.CODEARTIFACT_AUTH_TOKEN}</password>
    </server>
  </servers>
  <profiles>
    <profile>
      <id>nextwork-nextwork-devops-cicd</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <repositories>
        <repository>
          <id>nextwork-nextwork-devops-cicd</id>
          <url>https://nextwork-617439230997.d.codeartifact.us-east-1.amazonaws.com/maven/nextwork-devops-cicd/</url>
        </repository>
      </repositories>
    </profile>
  </profiles>
</settings>

Then, Run the Maven compile command, which uses the settings.xml file we just configured::

mvn -s settings.xml compile

Step 6: Publishing the Package to CodeArtifact

I updated my pom.xml to include distributionManagement:

<distributionManagement>
  <repository>
    <id>nextwork-nextwork-devops-cicd</id>
    <url>https://nextwork-617439230997.d.codeartifact.us-east-1.amazonaws.com/maven/nextwork-devops-cicd/</url>
  </repository>
</distributionManagement>

Then, I deployed the package:

mvn -s settings.xml deploy

Conclusion

This guide covered how I set up an AWS CodeArtifact repository, configured an EC2 instance to authenticate with it, and successfully deployed a Maven package. This process forms the foundation for integrating package management into a CI/CD pipeline, ensuring secure and scalable software delivery.

HNG Stage 2: Deploying a FastAPI Application with a CI/CD Pipeline

Richard Atodo — Sun, 16 Feb 2025 09:23:22 +0000

Introduction

As part of the HNG DevOps internship, Stage 2 required deploying a FastAPI application using Docker and setting up a CI/CD pipeline via GitHub Actions. This was an exciting challenge that tested my skills in cloud infrastructure, automation, and debugging under real-world conditions.

Project Requirements Overview

The project had several key requirements:

Implement a missing endpoint for book retrieval
Set up CI/CD pipelines using GitHub Actions
Containerize the application using Docker
Deploy and serve the application through Nginx

Building the Book API

The first challenge was implementing the missing endpoint to retrieve a book by ID. The solution required careful consideration of error handling and response formatting:

@router.get("/{book_id}", response_model=Book)
async def get_book(book_id: int) -> Any:
    books = db.get_books()
    if book_id not in books:
        return JSONResponse(
            status_code=status.HTTP_404_NOT_FOUND,
            content={"detail": "Book not found"}
        )
    return books[book_id]

Setting Up GitHub Actions for CI/CD

The CI/CD setup was fascinating. I used GitHub Actions to create two essential workflows:

`test.yml` (CI Pipeline)

name: Test FastAPI Application

on:
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
          pip install pytest pytest-cov

      - name: Run pytest
        run: |
          pytest

`deploy.yml` (CD Pipeline)

name: Deploy FastAPI Application

on:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run tests
        run: pytest

  deploy:
    needs: test
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Configure SSH
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          SSH_HOST: ${{ secrets.SSH_HOST }}
          SSH_USERNAME: ${{ secrets.SSH_USERNAME }}
        run: |
          mkdir -p ~/.ssh/
          echo "$SSH_PRIVATE_KEY" > ~/.ssh/deploy_key
          chmod 600 ~/.ssh/deploy_key
          ssh-keyscan -H $SSH_HOST >> ~/.ssh/known_hosts

      - name: Deploy to AWS EC2
        env:
          SSH_HOST: ${{ secrets.SSH_HOST }}
          SSH_USERNAME: ${{ secrets.SSH_USERNAME }}
        run: |
          ssh -i ~/.ssh/deploy_key $SSH_USERNAME@$SSH_HOST << 'ENDSSH'
            # Create project directory if it doesn't exist
            mkdir -p ~/fastapi-book-project

            # Navigate to project directory
            cd ~/fastapi-book-project || exit 1

            # Check if repository exists, if not clone it
            if [ ! -d .git ]; then
              git clone https://github.com/${{ github.repository }}.git .
            fi

            # Fetch and reset to main
            git fetch --all
            git reset --hard origin/main

            # Check if docker-compose exists
            if [ ! -f docker-compose.yml ]; then
              echo "docker-compose.yml not found!"
              exit 1
            fi

            # Stop running containers
            docker-compose down || true

            # Build and start containers
            docker-compose up -d --build

            # Verify deployment
            docker ps

            # Check if the application is responding
            sleep 10
            curl -f http://localhost:8000/api/v1/books || echo "Warning: Application not responding"
          ENDSSH

Dockerizing the FastAPI Application

A key part of this challenge was containerizing the FastAPI application to ensure consistent deployment. The Dockerfile used was as follows:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

`docker-compose.yml`:

version: '3.8'

services:
  fastapi:
    build: .
    container_name: fastapi_app
    ports:
      - "8000:8000"

  nginx:
    image: nginx:latest
    container_name: nginx_reverse_proxy
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
    ports:
      - "80:80"
    depends_on:
      - fastapi

Configuring Nginx as a Reverse Proxy

To make the application accessible on port 80, I configured Nginx as a reverse proxy:

Installed Nginx:

   sudo apt update && sudo apt install nginx -y

Created a new configuration file at /etc/nginx/sites-available/fastapi:

   server {
       listen 80;
       server_name _;

       location / {
           proxy_pass http://localhost:8000;
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
       }
   }

Enabled the configuration and restarted Nginx:

   sudo ln -s /etc/nginx/sites-available/fastapi /etc/nginx/sites-enabled/
   sudo rm /etc/nginx/sites-enabled/default
   sudo systemctl restart nginx

Debugging and Fixing Issues

During deployment, I encountered several challenges, including:

Port Conflict Errors: Docker was already binding to port 8000. Solved by stopping previous instances with docker stop $(docker ps -q).
Systemd Service Failure: FastAPI failed due to an address bind issue. Fixed by ensuring no other processes were using port 8000.
GitHub Actions Deployment Failures: Resolved by properly configuring SSH keys and setting up secrets in GitHub.

Conclusion

This experience strengthened my ability to deploy containerized applications with automation and troubleshoot real-world deployment issues. The hands-on challenge provided deep insights into CI/CD best practices, making it a valuable learning experience.

Deploying the Number Classification API Using AWS Lambda Function URL

Richard Atodo — Wed, 05 Feb 2025 11:16:50 +0000

Introduction

After completing my Number Classification API for Stage 1 of the HNG DevOps Internship, I deployed it. The goal was to make my API publicly accessible while ensuring seamless integration with AWS Lambda. Instead of using API Gateway, I deployed the API using AWS Lambda Function URLs, which provided a simpler and more direct approach to serving HTTP requests.

What is the Number Classification API?

The Number Classification API is a FastAPI-based service that classifies numbers based on their mathematical properties. It can determine if a number is:

Prime
Armstrong
Perfect
Odd or even
Sum of its digits
Fun facts about the number (retrieved from an external API)

This API was designed to handle both positive and negative numbers, as well as floating-point inputs, which are converted to integers. see my GitHub Repo

Choosing AWS Lambda Function URL Over API Gateway

Initially, I considered deploying my FastAPI application using API Gateway and Lambda. However, I decided to use AWS Lambda Function URLs instead for the following reasons:

Simplicity: Lambda Function URLs provide a built-in HTTP endpoint, reducing the need for additional API Gateway configurations.
Direct Invocation: Function URLs allow direct access to the Lambda function without needing an API Gateway mapping.
Lower Cost: Since API Gateway incurs additional costs, using Lambda Function URLs helped reduce expenses.

Deployment Process

Here’s a step-by-step breakdown of how I deployed my FastAPI application on AWS Lambda:

1. Preparing the Deployment Package

To deploy a FastAPI application on AWS Lambda, it must be packaged correctly. I installed the necessary dependencies and zipped the application:

Compress-Archive venv\Lib\site-packages\* lambda.zip 
Compress-Archive .\main.py -Update lambda.zip

2. Creating an AWS Lambda Function

Logged into the AWS Lambda console.
Created a new Lambda function using Python 3.9+ as the runtime.
Uploaded the lambda.zip file as the function’s code.

3. Enabling Lambda Function URL

Navigated to the Function URL section in the Lambda console.
Enabled the Function URL and set the authentication type to NONE to allow public access.
Copied the generated Function URL for testing.

4. Configuring CORS

Since the API was designed to be publicly accessible, I enabled CORS to allow requests from any origin. This was achieved by adding the CORSMiddleware in the FastAPI application:

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

5. Testing the API

To ensure everything was working correctly, I tested the deployed API using curl and a web browser:

curl -X GET "https://your-lambda-function-url/api/classify-number?number=153"

The response returned valid JSON data, confirming a successful deployment!

Challenges Faced

Deploying FastAPI on AWS Lambda wasn’t without its challenges. Some key issues I encountered included:

Import Errors: Initially, I faced ImportModuleError: No module named 'pydantic_core._pydantic_core', which was due to package incompatibilities. Switching to an AWS-supported Python version and ensuring all dependencies were installed inside the Lambda layer resolved this issue.
CORS Issues: The first few API requests were blocked due to missing CORS headers. Adding allow_origins=["*"] in CORSMiddleware fixed this.
Number Validation Errors: The API initially returned 400 Bad Request for negative numbers and floating-point values. After refining the number validation logic, all valid numbers were correctly processed.

Key Takeaways

Deploying a FastAPI application using AWS Lambda Function URLs proved to be an efficient and cost-effective approach. Some important lessons I learned include:

AWS Lambda is powerful for lightweight APIs: It eliminates the need for managing infrastructure.
Function URLs simplify deployment: No need for API Gateway if a simple public endpoint is required.
Proper error handling is crucial: Ensuring valid JSON responses helps in debugging and API usability.
CORS must be configured properly: Without it, web applications may fail to make requests to the API.

Conclusion

This project was a great learning experience and a significant milestone in my cloud journey. It reinforced my understanding of AWS Lambda, FastAPI, and CORS configurations. As I progress in the HNG DevOps Internship, I look forward to tackling more complex deployments and optimizing API performance.

If you’re considering deploying a FastAPI service on AWS Lambda, I highly recommend trying Lambda Function URLs for their ease of use and cost efficiency!

What are your thoughts on this approach? Let’s discuss this in the comments! 🚀

Setting Up NGINX Web Server on AWS EC2: My HNG DevOps Stage 0 Experience

Richard Atodo — Thu, 30 Jan 2025 00:17:17 +0000

Introduction

As part of the HNG DevOps internship program, I was tasked with configuring NGINX on a fresh Ubuntu server to serve a custom HTML page. This exercise tested my ability to set up a basic web server and reinforced my understanding of cloud infrastructure. Let me share my journey with you.

My Approach

The task initially seemed straightforward: set up an NGINX web server on AWS to serve a custom HTML page. However, it quickly became apparent that this project would teach me valuable lessons about system administration and web server configuration.

Here's how I broke down the task:

Infrastructure Setup
I started by launching an Ubuntu-based EC2 instance on AWS. The steps included:

Choosing an Ubuntu 24.04 LTS AMI (Free Tier eligible).
Selecting a t2.micro instance (Free Tier eligible).
Creating a security group to allow SSH (port 22) and HTTP (port 80) access from anywhere (0.0.0.0/0).
Generate an SSH key pair to connect to my instance securely.

Connecting to the Instance and NGINX Installation and Configuration
After launching the EC2 instance, I used SSH to connect:

chmod 400 your-key-pair.pem
ssh -i your-key-pair.pem ubuntu@your-instance-public-ip

Then, I updated the system and installed and configured NGINX:

# Update package list
sudo apt update

# Install NGINX
sudo apt install nginx -y

# Verify NGINX is running
sudo systemctl status nginx

Configuring the Custom HTML Page
Next, I replaced the default index.html file with my custom page:

sudo tee /var/www/html/index.html << EOF
<!DOCTYPE html>
<html>
<head>
    <title>DevOps Stage 0</title>
    <style>
        body {
            display: flex;
            justify-content: center;
            align-items: center;
            height: 100vh;
            margin: 0;
            font-family: Arial, sans-serif;
            background-color: #f0f2f5;
        }
        .message {
            padding: 20px;
            background-color: white;
            border-radius: 8px;
            box-shadow: 0 2px 4px rgba(0,0,0,0.1);
        }
    </style>
</head>
<body>
    <div class="message">
        <h1>Welcome to DevOps Stage 0 - [Your Name]/[SlackName]</h1>
    </div>
</body>
</html>
EOF

Testing the Setup
I tested the NGINX configuration:
sudo nginx -t
I restarted NGINX:
sudo systemctl restart nginx

I opened a web browser and entered http://ec2-public-ip/, confirming that my custom message was displayed.

Challenges and Solutions

I encountered permission errors. Which I fixed allowing the appropriate permissions:

# Set correct ownership and permissions
sudo chown www-data:www-data /var/www/html/index.html
sudo chmod 644 /var/www/html/index.html

How This Task Contributes to My Learning and Career Goals

Completing this task reinforced my understanding of cloud infrastructure, networking, and server administration. It was an essential step in my journey toward becoming a DevOps Engineer. By working hands-on with AWS and NGINX, I improved my troubleshooting skills and deepened my knowledge of cloud-based deployments. This experience also aligns with my long-term goal of mastering cloud automation and infrastructure management.

Conclusion

This experience gave me practical insights into server provisioning, firewall management, and web server configuration. The ability to set up a web server from scratch is a fundamental skill for Cloud Engineers and DevOps professionals. Moving forward, I plan to explore more advanced topics like load balancing, auto-scaling, and CI/CD pipelines.

DEV Community: Richard Atodo

Leveling Up: Provisioning EKS with Terraform for My DevOps Project

From CosmosDB to DynamoDB: Migrating and Containerizing a FastAPI + React App

The Goal: A DevOps-Focused TV Show App

Key Takeaways

Conclusion & Next Steps

Setting Up an Automated Java Build and Deployment Pipeline with AWS CodeArtifact

Introduction

Step 1: Setting Up the EC2 Instance

1.1 Launching an EC2 Instance

1.2 Connecting to the EC2 Instance

Step 2: Installing Java and Maven

2.1 Installing Java Amazon Corretto 8

2.2 Installing Maven 3.5.2

Step 3: Cloning and Configuring the Java Project

Step 4: Setting Up AWS CodeArtifact

4.1 Creating a CodeArtifact Repository and Domain

Step 4: Setting Up AWS CodeArtifact

4.2 Configuring IAM Permissions

4.3 Generating an Authorization Token

Step 5: Configuring Maven to Use CodeArtifact

Step 6: Publishing the Package to CodeArtifact

Conclusion

HNG Stage 2: Deploying a FastAPI Application with a CI/CD Pipeline

Introduction

Project Requirements Overview

Building the Book API

Setting Up GitHub Actions for CI/CD

test.yml (CI Pipeline)

deploy.yml (CD Pipeline)

Dockerizing the FastAPI Application

docker-compose.yml:

Configuring Nginx as a Reverse Proxy

Debugging and Fixing Issues

Conclusion

Deploying the Number Classification API Using AWS Lambda Function URL

Introduction

What is the Number Classification API?

Choosing AWS Lambda Function URL Over API Gateway

Deployment Process

1. Preparing the Deployment Package

2. Creating an AWS Lambda Function

3. Enabling Lambda Function URL

4. Configuring CORS

5. Testing the API

Challenges Faced

Key Takeaways

Conclusion

Setting Up NGINX Web Server on AWS EC2: My HNG DevOps Stage 0 Experience

Introduction

My Approach

Challenges and Solutions

How This Task Contributes to My Learning and Career Goals

Conclusion

`test.yml` (CI Pipeline)

`deploy.yml` (CD Pipeline)

`docker-compose.yml`: