DEV Community: Whuatorhe Tejiri

RideShare Pro Production-Grade Microservices Deployment on Azure Kubernetes Service (AKS)

Whuatorhe Tejiri — Mon, 14 Jul 2025 13:00:16 +0000

Project Overview

RideShare Pro is a microservices-based ride-sharing platform designed for scalability, fault tolerance, and high availability on Azure Kubernetes Service (AKS). This project simulates a real-world DevOps scenario for a fast-growing African ride-sharing startup.

Architecture Overview

Core Services

Service Name	Description
User Service	Handles registration, authentication, profiles
Ride Matching	Matches riders with available drivers
Payment Service	Processes payments and manages billing
Notification Service	Sends SMS, push, and email notifications

Supporting Infrastructure

PostgreSQL (StatefulSet) – Primary + Replica with persistent volumes
Redis (StatefulSet) – Clustered for caching, session, and pub/sub
Nginx Ingress Controller – API Gateway for external routing
Azure Container Registry (ACR) – Private container registry
AKS Cluster – Orchestrator with autoscaling enabled

Tools & Prerequisites

Azure CLI
kubectl
Docker
Git
Azure Subscription (with Contributor access)

Getting Started

Clone the Repositories

git clone https://github.com/YOUR_USERNAME/rideshare-user-service.git
git clone https://github.com/YOUR_USERNAME/rideshare-ride-matching-service.git
git clone https://github.com/YOUR_USERNAME/rideshare-payment-service.git
git clone https://github.com/YOUR_USERNAME/rideshare-notification-service.git
git clone https://github.com/YOUR_USERNAME/rideshare-infrastructure.git

Provision Infrastructure

Create Resource Group

RESOURCE_GROUP="teleios-tejiri-rg"
LOCATION="centralus"
az group create --name $RESOURCE_GROUP --location $LOCATION

Create ACR

ACR_NAME="teleiostejiriacr"

az acr create --resource-group $RESOURCE_GROUP --name $ACR_NAME --sku Standard

Authenticate with Azure & Configure CLI

az login
This will open a browser for authentication.

Set your desired subscription (if you have multiple):

az account set --subscription "YOUR_SUBSCRIPTION_NAME"

Create AKS Cluster

CLUSTER_NAME="rideshare-aks"

az aks create \ --resource-group $RESOURCE_GROUP \ --name $CLUSTER_NAME \ --node-count 2 \ --node-vm-size Standard_B2ls_v2 \ --enable-cluster-autoscaler \ --min-count 2 \ --max-count 6 \ --generate-ssh-keys \ --attach-acr $ACR_NAME \ --location $LOCATION

Get AKS Credentials and Set kubectl Context

az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

Verify current context:

kubectl config current-context

Data Layer Deployment

Redis StatefulSet

Create the following files and apply them kubectl apply -f .

redis-statefulset.yaml
redis-headless-service.yaml
redis-configmap.yaml

Validate:

kubectl get statefulset redis-cluster

kubectl get pods -l app=redis-cluster

kubectl get pvc

PostgreSQL StatefulSet

Create the following files and apply them with kubectl apply

Files:

postgresql-primary-statefulset.yaml
postgresql-replica-statefulset.yaml
postgresql-headless-service.yaml
postgresql-secret.yaml
postgresql-config-map.yaml

Validate:

kubectl get statefulset

kubectl exec -it postgres-primary-0 -- psql -U postgres -c "\l"

Microservices Deployment

Build and Push Docker Images

Example for User Service

cd rideshare-user-service

docker build -t $ACR_NAME.azurecr.io/user-service:v1.0 .

docker push $ACR_NAME.azurecr.io/user-service:v1.0

Repeat for all services.

Deploy Kubernetes Manifests

Create namespace e.g "microservices" and create the following files for each service:

deployment.yaml
service.yaml
secret.yaml
hpa.yaml
pdb.yaml

Deploy:

kubectl apply -f ./k8s/deployment.yaml

kubectl apply -f ./k8s/service.yaml

kubectl apply -f ./k8s/hpa.yaml

kubectl apply -f ./k8s/pdb.yaml

Validate:

Kubectl get pods -n microservices

Install NGINX Ingress Controller

Apply the official NGINX Ingress manifests:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.9.6/deploy/static/provider/cloud/deploy.yaml

This deploys everything: the ingress controller, service, RBAC, etc.

Wait for the pods to be ready:

kubectl get pods -n ingress-nginx

Once ready, you can get the external IP:

kubectl get service ingress-nginx-controller -n ingress-nginx

We mapped the ingress loadbalancer ip to azure dns to enable persistency when we connect to our dns against changing ip address.

We write our ingress rule based on what path the services are expecting, some services expects /api/payments/* while some just need /*, so we have two ingress rule files that does a rewrite by striping the request sent by the browser from /api/service/* to just / and then a service that do not rewrite but just sends the request directly.

Install cert-manager (manually)

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.yaml

Wait for the pods:

kubectl get pods --namespace cert-manager

You should see:

cert-manager
cert-manager-cainjector
cert-manager-webhook

Create Let's Encrypt Issuer

Create a ClusterIssuer (for all namespaces):
Apply it

kubectl apply -f letsencrypt-clusterissuer.yaml

Add TLS + Certificate to Ingress rule

Apply the Ingress rules

Wait for TLS Certificate
Check the certificate status:

kubectl describe certificate notification-tls -n microservices

You should see Ready=True once it's provisioned.

Run the following commands

kubectl get certificates -n microservices

kubectl get secrets -n microservices

You’ll see a secret used by the Ingress for HTTPS.

Test your dns using Https to confirm if it has worked.
https://your-dns-name/api/notifications/docs which leads to the swagger ui.

CI/CD Pipeline (GitHub Actions)

Each repo contains .github/workflows/deploy.yml

Stages:

Checkout code

Build Docker image

Push to ACR

Deploy to AKS (main/release only)

Triggers:

Push to any branch

Pull request creation

Manual workflow trigger

Access Microservice

Links to the individual repos having all our /k8s folders are attached with all files

Deploying Nginx on AWS: A Beginner-Friendly Guide(HNG DevOps Stage 0)

Whuatorhe Tejiri — Wed, 29 Jan 2025 14:50:28 +0000

Introduction

Configuring an Nginx web server on AWS is a fundamental skill for anyone diving into cloud computing and DevOps. This project focuses on setting up an Ubuntu-based EC2 instance to host a simple HTML page using Nginx. Through this process, I gained practical experience in server provisioning, web server configuration, and basic networking.

In this blog, I’ll walk you through the steps I took to achieve this, the challenges encountered, and key takeaways.

Project Goal

The objective of this project was to:

Launch an Ubuntu EC2 instance on AWS.
Install and configure Nginx to serve a custom HTML page.
Ensure accessibility via a public IP address.

Step-by-Step Implementation

1. Launching an EC2 Instance

I started by launching an Ubuntu EC2 t3.micro instance, which falls under the AWS free tier. While setting up the instance, I allocated 8GB of EBS storage and attached a pre-configured security group allowing traffic on port 80 (HTTP). Additionally, I deployed the instance in a public subnet and ensured my existing key pair was attached for SSH access.

2. Connecting to the Instance

Once the instance was running, I connected to it using SSH:

ssh -i "my-key.pem" ubuntu@

After successfully logging in, I updated the package lists to ensure my system had the latest software packages:

sudo apt update

3. Installing and Configuring Nginx

Next, I installed Nginx, started the service, and ensured it would automatically start on boot:

sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx

At this point, Nginx was running, and I could confirm this by visiting the public IP address of my EC2 instance in a web browser.

4. Deploying a Custom HTML Page

To serve a personalized webpage, I created a new index.html file with custom HTML and CSS content:

sudo vim /var/www/html/index.html

I then added a simple HTML page with basic styling, saved the file, and exited the editor.

5. Restarting Nginx and Testing the Deployment

After modifying the index.html file, I restarted Nginx to apply the changes:

sudo systemctl restart nginx

Finally, I accessed my public IP address in a browser, and my custom webpage loaded successfully.

Challenges and Solutions

While this was a straightforward task, I encountered a few minor challenges:

Security Group and NACL Configuration: Initially, I couldn’t access the webpage. After troubleshooting, I realized I had to allow inbound HTTP traffic on port 80 in both the Security Group and Network ACL settings.

Permission Issues: While editing the index.html file, I encountered permission errors. Using sudo resolved the issue, ensuring I had the necessary privileges.

Reflections and Key Takeaways

This task served as a great refresher on AWS EC2, security configurations, and web server deployment. Some key lessons learned include:

Always ensure security group rules and NACL settings permit required traffic.

Using systemctl enable nginx ensures the service starts automatically after a reboot.

Proper file permissions are crucial when modifying files in /var/www/html/.

For beginners, this exercise provides a solid foundation in cloud computing and DevOps practices.

Further Resources

Looking for professional DevOps and Cloud Engineers? Check out:

DevOps Engineers - https://hng.tech/hire/devops-engineers

Cloud Engineers - https://hng.tech/hire/cloud-engineers

Conclusion

Deploying a basic Nginx server on AWS is a simple yet essential skill in cloud computing. Whether you're learning DevOps or just starting your cloud journey, practicing such hands-on projects will help reinforce your knowledge.

Feel free to drop any questions in the comments or share your own experience with setting up Nginx on AWS!

🚀 Happy Coding!