Forem: Shongkor Talukdar

Addressing Single Point of Failure Concerns

Shongkor Talukdar — Sun, 01 Mar 2026 16:51:19 +0000

The risk of a Single Point of Failure (SPOF) has become a critical concern in interconnected modern businesses and technologies. The concept represents a part of a system that, if it fails, will stop the entire system from working. It can be software, hardware, human resources, or any aspect critical to operations. For example,

## FrontEnd ----> Backend(Deployed on single EC2) ----> DataBase

If we deploy a backend on one server, when we add a feature, and when we deploy it, that causes an interruption for the active end user. Think about streaming platforms like Netflix, e-commarce system like Amazon. A single moment of failure will cost millions of dollars.

Avoiding a single point of failure (SPOF) in cloud-based systems is critical for ensuring high availability, fault tolerance, and resilience. To mitigate the risks associated with SPOF, systems should be designed with redundancy and fault tolerance in mind. Here are some best practices to minimize the risk of SPOFs:

Redundant Components and Geographic Distribution: Enhance the resilience of cloud architecture by implementing redundancy for all critical components, such as servers, databases, and load balancers.

Today, I am going to develop a pipeline that will mitigate SPOF for the Backend.

Here, NGINX acts as a load balancer, distributing user requests to both servers. This Architecture will solve :
Redundancy: If Instance 1 fails during the update, Instance 2 is still live, serving user requests.
Automatic Rollback: If the deployment fails (e.g., the app fails to start on Instance 1), CodeDeploy can be configured to automatically roll back to the previous version, ensuring no permanent downtime.

Implementation:

The deployment flow in this context will work as follows. GitHub Actions builds and pushes your Docker image to Docker Hub as it does today. It then notifies CodeDeploy to begin a deployment. CodeDeploy pulls your repository code (specifically the appspec.yml and deployment scripts) from an S3 bucket, then executes the deployment on each EC2 instance in a rolling fashion — one instance at a time — so your application remains available throughout.

Developer pushes code to GitHub
         ↓
GitHub Actions (Build & Test)
         ↓
Docker Image pushed to Docker Hub
         ↓
Deployment bundle uploaded to S3
         ↓
CodeDeploy triggered
         ↓
Instance A deregistered from ALB
         ↓
Scripts run on Instance A (stop old → pull new → start → validate)
         ↓
Instance A re-registered to ALB
         ↓
Same process repeats for Instance B
         ↓
Both instances running the latest code ✓

Phase 1 — Project Folder Structure

trust-estate-server/
├── .github/
│   └── workflows/
│       └── pipeline.yml
├── scripts/
│   ├── before_install.sh
│   ├── after_install.sh
│   ├── start_application.sh
│   └── validate_service.sh
├── src/
│   └── index.js
├── .env.example
├── .gitignore
├── appspec.yml
├── docker-compose.yml
├── Dockerfile
└── package.json

Phase 2 — Application Files

src/index.js

const express = require('express')
const app = express()
const port = process.env.PORT || 3000

app.use(express.json())

// Health check endpoint for ALB and CodeDeploy
app.get('/health', (req, res) => {
  res.status(200).json({
    status: 'healthy',
    app: 'trust-estate-server',
    timestamp: new Date().toISOString()
  })
})

app.get('/', (req, res) => {
  res.status(200).json({
    message: 'Trust Estate API is running',
    version: '1.0.0'
  })
})

app.listen(port, () => {
  console.log(`Trust Estate Server running on port ${port}`)
})

then

.env.example

PORT=3000
NODE_ENV=production

`.gitignore`

node_modules/
.env
.env.*
!.env.example
*.log
coverage/
dist/

Phase 3 — Docker Files

Dockerfile

FROM node:18-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install --omit=dev

COPY . .

EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=10s --start-period=30s --retries=3 \
  CMD wget --quiet --tries=1 --spider http://localhost:3000/health || exit 1

CMD ["node", "src/index.js"]

docker-compose.yml

services:
  node-app:
    image: ${DOCKER_USERNAME}/trust-estate-server:latest
    container_name: trust-estate-server
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - PORT=3000
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--tries=1", "--spider", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Phase 4 — CodeDeploy Files

appspec.yml

version: 0.0
os: linux

files:
  - source: /
    destination: /home/ubuntu/app
    overwrite: true

permissions:
  - object: /home/ubuntu/app/scripts
    pattern: "**"
    owner: ubuntu
    group: ubuntu
    mode: 755
    type:
      - file

hooks:
  BeforeInstall:
    - location: scripts/before_install.sh
      timeout: 300
      runas: root

  AfterInstall:
    - location: scripts/after_install.sh
      timeout: 300
      runas: root

  ApplicationStart:
    - location: scripts/start_application.sh
      timeout: 300
      runas: root

  ValidateService:
    - location: scripts/validate_service.sh
      timeout: 300
      runas: root

Next for the Scripts Folder

scripts/before_install.sh

#!/bin/bash
set -e

echo "========================================="
echo "BEFORE INSTALL - Cleanup old deployment"
echo "========================================="

echo "Stopping existing container..."
docker stop trust-estate-server || true

echo "Removing existing container..."
docker rm trust-estate-server || true

echo "Removing old Docker images..."
docker rmi $(docker images -q) -f || true

echo "Cleanup complete."

scripts/after_install.sh

#!/bin/bash
set -e

echo "========================================="
echo "AFTER INSTALL - Pulling new Docker image"
echo "========================================="

cd /home/ubuntu/app

echo "Pulling latest image..."
docker pull $DOCKER_USERNAME/trust-estate-server:latest

echo "Image pulled successfully."

scripts/validate_service.sh

#!/bin/bash
set -e

echo "========================================="
echo "VALIDATE SERVICE - Health check"
echo "========================================="

MAX_RETRIES=10
RETRY_INTERVAL=10
HEALTH_URL="http://localhost:3000/health"

echo "Checking health at: $HEALTH_URL"

for i in $(seq 1 $MAX_RETRIES); do
  echo "Attempt $i of $MAX_RETRIES..."

  HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" $HEALTH_URL)

  if [ "$HTTP_STATUS" -eq 200 ]; then
    echo "✓ Health check passed - trust-estate-server is healthy"
    exit 0
  fi

  echo "✗ Status: $HTTP_STATUS. Retrying in ${RETRY_INTERVAL}s..."
  sleep $RETRY_INTERVAL
done

echo "✗ trust-estate-server failed health checks after $MAX_RETRIES attempts"
exit 1

Phase 5 — GitHub Actions Pipeline

.github/workflows/pipeline.yml

name: CI/CD Pipeline - Trust Estate Server

on:
  push:
    branches: ['main']

env:
  DOCKER_IMAGE: ${{ secrets.DOCKER_USERNAME }}/trust-estate-server

jobs:

  build:
    name: Build & Push Docker Image
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Login to Docker Hub
        run: |
          echo "${{ secrets.DOCKER_HUB_TOKEN }}" | \
          docker login -u "${{ secrets.DOCKER_USERNAME }}" --password-stdin

      - name: Build Docker Image
        run: |
          docker build \
            --tag ${{ env.DOCKER_IMAGE }}:latest \
            --tag ${{ env.DOCKER_IMAGE }}:${{ github.sha }} \
            .

      - name: Push Docker Image
        run: |
          docker push ${{ env.DOCKER_IMAGE }}:latest
          docker push ${{ env.DOCKER_IMAGE }}:${{ github.sha }}

  deploy:
    name: Deploy to EC2 via CodeDeploy
    runs-on: ubuntu-latest
    needs: build

    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-session-token: ${{ secrets.AWS_SESSION_TOKEN }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Create Deployment Bundle
        run: |
          zip -r deployment-bundle.zip . \
            -x "*.git*" \
            -x "node_modules/*" \
            -x ".env*" \
            -x ".github/*"

      - name: Upload Bundle to S3
        run: |
          aws s3 cp deployment-bundle.zip \
            s3://${{ secrets.S3_BUCKET_NAME }}/deployments/deployment-${{ github.sha }}.zip

      - name: Trigger CodeDeploy Deployment
        run: |
          DEPLOYMENT_ID=$(aws deploy create-deployment \
            --application-name trust-estate \
            --deployment-group-name production-group \
            --s3-location bucket=${{ secrets.S3_BUCKET_NAME }},bundleType=zip,key=deployments/deployment-${{ github.sha }}.zip \
            --deployment-config-name CodeDeployDefault.OneAtATime \
            --description "Commit: ${{ github.sha }} by ${{ github.actor }}" \
            --query 'deploymentId' \
            --output text)

          echo "Deployment ID: $DEPLOYMENT_ID"
          echo "DEPLOYMENT_ID=$DEPLOYMENT_ID" >> $GITHUB_ENV

      - name: Wait for Deployment to Complete
        run: |
          echo "Waiting for deployment ${{ env.DEPLOYMENT_ID }}..."
          aws deploy wait deployment-successful \
            --deployment-id ${{ env.DEPLOYMENT_ID }}
          echo "✓ Deployment completed successfully."

Now,

Go to https://github.com and:

Click + (top right)
→ New Repository
→ Repository name: trust-estate-server
→ Visibility: Public or Private (your choice)
→ Do NOT check "Add README"
→ Click Create Repository

Push Your Code to GitHub
In your terminal, **inside the trust-estate-server folder**:

`
bash# Initialise git
git init

# Stage all files
git add .

# First commit
git commit -m "initial project setup with CI/CD pipeline"

# Connect to your GitHub repo
# Replace YOUR_USERNAME with your actual GitHub username
git remote add origin https://github.com/YOUR_USERNAME/trust-estate-server.git

# Push to main branch
git branch -M main
git push -u origin main

Go to GitHub and refresh the page. You should see all your files there.

Next Step — Add GitHub Secrets

This is where you store all sensitive values so they never appear in your code.

GitHub → Your Repository
       → Settings (top menu)
       → Secrets and Variables (left sidebar)
       → Actions
       → New Repository Secret

Add these secrets one by one. Click New Repository Secret for each one:

Secret 1:

Name:  DOCKER_USERNAME
Value: your Docker Hub username

Secret 2:

Name:  DOCKER_HUB_TOKEN
Value: the token you copied in Step A2

Secret 3:

Name:  AWS_REGION
Value: eu-west-1
       (use YOUR actual region — check your EC2 instances)

Secret 4:

Name:  S3_BUCKET_NAME
Value: leave this empty for now
       (you will come back and add this after Step D3)

The AWS credential secrets (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN) will be added after you get them from the Learner Lab in Part D.

Next PART — AWS SETUP

(This is the biggest part — take it one step at a time)

Step on AWS-1 — Get Your AWS Credentials from Learner Lab

Open your AWS Academy Learner Lab and:

Click: Start Lab (wait until the circle goes green)
Click: AWS Details
Click: Show (next to AWS CLI)

You will see three values:

aws_access_key_id     = ASIA...
aws_secret_access_key = xxxx...
aws_session_token     = xxxx... (very long string)

Copy each one and go back to GitHub → Settings → Secrets → Actions and add:

Secret 5:

Name:  AWS_ACCESS_KEY_ID
Value: paste aws_access_key_id value

Secret 6:

Name:  AWS_SECRET_ACCESS_KEY
Value: paste aws_secret_access_key value

Secret 7:

Name:  AWS_SESSION_TOKEN
Value: paste aws_session_token value

Remember: Every time you start a new Learner Lab session, you must update these 3 secrets with fresh values.


## Now, enter your AWS homepage. Our next step is create two instances using a single security group.

The Order We Will Follow

Step 1: Create Security Group ← Rules for what traffic is allowed
Step 2: Create EC2 Instance A ← First server
Step 3: Create EC2 Instance B ← Second server
Step 4: Install software on both ← Docker + CodeDeploy agent
Step 5: Create Target Group ← Groups both servers together
Step 6: Create Load Balancer ← Distributes traffic to both servers
Step 7: Create S3 Bucket ← Stores deployment files
Step 8: Create CodeDeploy App ← Manages deployments
Step 9: Tag EC2 Instances ← Labels for CodeDeploy to find them

_**STEP 1 — Create a Security Group**_

A Security Group is a firewall that controls what traffic can reach your EC2 instances. Think of it as a bouncer at a door — it decides who gets in and who does not.Navigate to Security Groups
AWS Console → EC2
           → Security Groups (left sidebar, under Network & Security)
           → Create Security Group
Add Inbound Rules

Inbound rules control traffic coming into your server. Click Add Rule for each of the following:
Rule 1 — SSH (for you to connect to the server):
Type: SSH
Protocol: TCP
Port: 22
Source: My IP
(AWS automatically fills your current IP address)

Rule 2 — HTTP (for web traffic):

Type: HTTP
Protocol: TCP
Port: 80
Source: Anywhere IPv4 (0.0.0.0/0)

Rule 3 — Your App Port:

Type: Custom TCP
Protocol: TCP
Port: 3000
Source: Anywhere IPv4 (0.0.0.0/0)

Outbound Rules

Leave outbound rules as the default. The default allows all outbound traffic, which your instances need to pull Docker images and communicate with AWS services. Click Create the Security Group.

STEP 2 — Create EC2 Instance A

Navigate to EC2 Launch
AWS Console → EC2 → Instances (left sidebar) → Launch Instances (orange button, top right)

Section 1 — Name and Tags
Name: trust-estate-server-A

Section 2 — Application and OS Image (AMI)
Search: Ubuntu Select: Ubuntu Server 22.04 LTS (HVM), SSD Volume Type (make sure it says Free tier eligible) Architecture: 64-bit (x86)

Section 3 — Instance Type
Select: t2.micro (Free tier eligible — enough for learning and testing)

Section 4 — Key Pair
This is how you SSH into your server. This is very important — do not skip this.
Click: Create new key pair A dialog box appears: Key pair name: trust-estate-key Key pair type: RSA Private key file format: .pem (for Mac/Linux) .ppk (for Windows with PuTTY) Click Create key pair. A file will automatically download to your computer.

Save this file somewhere safe. If you lose it, you can never SSH into your instances again. Put it in a folder you will remember, such as ~/aws-keys/trust-estate-key.pem.

Section 5 — Network Settings
Click Edit on the Network Settings section: VPC: default VPC Subnet: select any available subnet (note which Availability Zone it is in e.g. eu-west-1a) Auto-assign public IP: Enable For Firewall (Security Groups): Select: Select existing security group Choose: trust-estate-sg (the one you created in Step 1)

Section 6 — Configure Storage
Size: 8 GiB (default is fine) Type: gp2
Section 7 — Advanced Details
`Scroll all the way down to Advanced Details. Find the IAM instance profile field:
IAM instance profile: LabRole

This gives your EC2 instance permission to communicate with CodeDeploy and S3.`

Launch Instance A
Click Launch Instance. AWS will show a success screen with your Instance ID. Click View All Instances to go back to the instances list.
Wait until Instance A shows:
Instance State: running Status Checks: 2/2 checks passed

STEP 3 — Create EC2 Instance B

Repeat the exact same process as Step 2 with these differences:

`Name: trust-estate-server-B
Subnet: select a DIFFERENT subnet from Instance A
(different Availability Zone e.g. eu-west-1b)

`
Why a different subnet? Placing instances in different Availability Zones means if one AWS data centre has a problem, your other instance in a different location keeps running. This is what makes your application highly available.

STEP 4 — Install Software on Both Instances

Get access to both of your instances(instance A & instance B) and install the required software.
Install CodeDeploy Agent

# Update the package list
sudo apt-get update -y

# Install required tools
sudo apt-get install ruby wget curl -y

# Move to home directory
cd /home/ubuntu

# Download the CodeDeploy installer
# IMPORTANT: Replace eu-west-1 with YOUR actual AWS region
wget https://aws-codedeploy-eu-west-1.s3.eu-west-1.amazonaws.com/latest/install

# Make it executable
chmod +x ./install

# Run the installer
sudo ./install auto

# Start the CodeDeploy agent service
sudo systemctl start codedeploy-agent

# Make it start automatically when instance reboots
sudo systemctl enable codedeploy-agent

Now verify it is running:

sudo systemctl status codedeploy-agent

You should see this output:
● codedeploy-agent.service - LSB: AWS CodeDeploy Host Agent
   Active: active (running) since ...

Install Docker

# Download and run the official Docker install script
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# Add ubuntu user to docker group
# This allows running docker without sudo
sudo usermod -aG docker ubuntu

# Install Docker Compose plugin
sudo apt-get install docker-compose-plugin -y

Verify Docker works:
docker --version docker compose version

Next — Create the Target Group

Where are we right now?????

✓ Step 1: Security Group created
✓ Step 2: EC2 Instance A created
✓ Step 3: EC2 Instance B created
✓ Step 4: Software installed on both instances
→ Step 5: Create Target Group          ← YOU ARE HERE
  Step 6: Create Load Balancer
  Step 7: Create S3 Bucket
  Step 8: Create CodeDeploy Application
  Step 9: Tag EC2 Instances

A Target Group is simply a list of your servers that the Load Balancer will send traffic to. Think of it like this:

****Navigate to Target Groups
AWS Console → EC2 → Scroll down the LEFT sidebar → Under "Load Balancing" → Click: Target Groups → Click: Create Target Group (top right)

Page 1 — Basic Configuration
You will see a form. Fill in each field exactly:
Choose a target type:
● Instances ← select this one
○ IP addresses
○ Lambda function
○ Application Load Balancer
Target group name:
trust-estate-tg
Protocol:
HTTP
Port:
3000

This must be 3000 because your Express app runs on port 3000 inside Docker.

IP address type:
IPv4
VPC:
Select: default VPC
(the same VPC your EC2 instances are in)
Protocol version:
HTTP1

Health Checks Section
This is very important. The Load Balancer uses health checks to decide if an instance is healthy enough to receive traffic.
Health check protocol: HTTP
Health check path: /health
Now click Advanced health check settings to expand it:
Port: Traffic port
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 30
Success codes: 200

You should see it finally like this.

┌─────────────────────────────────────┐
│ Health check path:  /health         │
│ Healthy threshold:  2 checks        │
│ Unhealthy threshold: 2 checks       │
│ Timeout:            5 seconds       │
│ Interval:           30 seconds      │
│ Success codes:      200             │
└─────────────────────────────────────┘

Click Next.

Page 2 — Register Targets
This is where you add your two EC2 instances into the group.
You will see a table listing your available instances:

Assign(marked checked) both these instances to the target group named trust-estate-tg .
then Click Create Target Group.

Next step is to create the Application Load Balancer

Navigate to Load Balancers
AWS Console → EC2 → Left sidebar under "Load Balancing" → Click: Load Balancers → Click: Create Load Balancer

Section 1 — Basic Configuration
Load balancer name: trust-estate-alb Scheme: Internet-facing ← This means it accepts traffic from the internet IP address type: IPv4

Section 2 — Network Mapping
VPC: Select: default VPC Availability Zones and Subnets: You must select at least two Availability Zones. This is a requirement for a Load Balancer. ☑ eu-west-1a → select the subnet shown ☑ eu-west-1b → select the subnet shown

Match these to the Availability Zones where you launched your EC2 instances. You can check this by going to EC2 → Instances and looking at the Availability Zone column.

Section 3 — Security Groups
Remove: default (click the X next to it) Add: trust-estate-sg ← the one you created earlier Click in the security groups dropdown and select trust-estate-sg.

Section 4 — Listeners and Routing
This tells the Load Balancer what to do with incoming traffic: Protocol: HTTP Port: 80 Default action: Forward to → trust-estate-tg
Your listener should look like:

┌────────────────────────────────────────────────┐
│ HTTP : 80  →  Forward to: trust-estate-tg      │
└────────────────────────────────────────────────┘

Section 5 — Summary and Create
Leave everything else as default. Scroll to the bottom and click Create Load Balancer.
AWS will show a success screen. Click View Load Balancer.

Save Your Load Balancer DNS Name
Click on trust-estate-alb in the list. In the details panel below, find:
DNS name: trust-estate-alb-123456789.eu-west-1.elb.amazonaws.com
Copy and save this URL. This is the public address of your application. Once everything is deployed, this is what you open in the browser to see your app running.

Create the S3 Bucket

Navigate to S3
AWS Console → S3 → Create Bucket (top right)
AWS Region:
Select the SAME region your EC2 instances are in
Object Ownership:
ACLs disabled (default)
Block Public Access:
☑ Block all public access ← leave this ON
Versioning:
Disable (default)
Everything else leave as default. Click Create Bucket.

Update Your GitHub Secret
Now go back to GitHub and update the S3 secret:
GitHub → trust-estate-server repository → Settings → Secrets and Variables → Actions → Find S3_BUCKET_NAME → Click Edit (pencil icon) → Enter your bucket name → Click Save

Create the CodeDeploy Application

Navigate to CodeDeploy
AWS Console → search "CodeDeploy" in the top search bar
→ Click: CodeDeploy
→ Click: Applications (left sidebar)
→ Click: Create Application
Fill in the Details
Application name: trust-estate
Compute platform: EC2/On-Premises
Click Create Application.
Now Create the Deployment Group
You will be taken inside the trust-estate application. Click:
Create Deployment Group

Fill in each section:
Section 1 — Name and Role:
Deployment group name: production-group
Service role: LabRole

Click the dropdown for Service role and search for LabRole.

Section 2 — Deployment Type:
● In-place ← select this
○ Blue/green
Section 3 — Environment Configuration:
● Amazon EC2 instances ← select this

Tag group 1:
Key: App
Value: trust-estate
After typing the tag, you should see:
1 unique matched instance
Wait — this shows only 1 because you have not tagged both instances yet. That is fine. We do the tagging in Step 9 and come back to verify.

Section 4 — Agent Configuration:
Install AWS CodeDeploy Agent: Never

Select Never because you already installed it manually on both instances.

Section 5 — Deployment Settings:
Deployment configuration: CodeDeployDefault.OneAtATime
Section 6 — Load Balancer:
☑ Enable load balancing ← check this box

Load balancer:
● Application Load Balancer or Network Load Balancer

Target group: trust-estate-tg
Click Create Deployment Group.

Tag Both EC2 Instances
Now you attach the labels that CodeDeploy uses to find your instances.

Key: App
Value: trust-estate

Click: Save

Tag Instance B
Go back to Instances list
Click: trust-estate-server-B
Tags tab → Manage Tags → Add Tag

Key: App
Value: trust-estate

Click: Save

Verify CodeDeploy Found Both Instances
CodeDeploy → Applications → trust-estate
→ production-group
→ Click Edit (top right)
→ Scroll to Environment Configuration
You should now see:
Key: App
Value: trust-estate
Matching instances: 2 ✓
If you see 2 — everything is connected correctly.

Now

Congratulation

You have completed your CI/CD pipeline with CodeDeploy. Now, if you push your code to the main branch of your repository. You can see, in the action section github action is working automatically.

Github Link : https://github.com/Shongkor/trust-estate-server/actions/runs/22524715828

Deploy a Node Application on an AWS EC2 Instance using CI/CD Pipeline.

Shongkor Talukdar — Sun, 22 Feb 2026 20:12:22 +0000

Project Overview

This is a minimal Node.js/Express backend server. The application itself is straightforward — a single Express 5 app (index.js) that listens on port 3000 and returns "Hello World in AWS EC2!" at the root route. The real substance of the project lies in its deployment infrastructure.

CI/CD Pipeline

The pipeline is split across two GitHub Actions workflows that chain together to form a complete automated delivery process from code commit to live deployment on AWS EC2.

There are two parts of these settings. In your root directory, create a file named Dockerfile

`
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
COPY . .
RUN npm install
EXPOSE 3000
RUN ["chmod", "+x", "./entrypoint.sh"]
ENTRYPOINT [ "sh","./entrypoint.sh" ]

`

For best practice, run your project using the entrypoint.sh:


 #!/bin/bash
 node index.js

then in order to set DOCKER_HUB_TOKEN & DOCKER_USER_NAME ,

First register on https://app.docker.com
Create a repository named the same as Github repository.
Go to settings and generate a new access token and copy that token.
Go to your created GitHub repository settings section. In the secret and variable section, you will find Action and create a repository secret key named DOCKER_HUB_TOKEN --> paste your copied dockerhub tocken. In the same way, create another variable named DOCKER_USER_NAME --> copy the username of your Dockerhub account and paste here.

Stage 1 — Build and Publish to Docker Hub (docker_registry.yml)
This workflow triggers on every push to the main branch.

(docker_registry.yml)
`
name: Publish Docker Image to Docker Hub

on:
  push:
    branches: ['main']

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Login to docker hub
        run: echo "${{secrets.DOCKER_HUB_TOKEN}}" | docker login -u "${{secrets.DOCKER_USER_NAME}}" --password-stdin

      - name: Build Docker Image
        run: docker build . --file Dockerfile --tag "${{secrets.DOCKER_USER_NAME}}"/study-abroad-agency-server:latest

      - name: Push Docker Image
        run: docker push "${{secrets.DOCKER_USER_NAME}}"/study-abroad-agency-server:latest

`

It runs on a GitHub-hosted Ubuntu runner and performs three steps: it checks out the code, logs into Docker Hub using stored secrets (DOCKER_HUB_TOKEN and DOCKER_USER_NAME), builds a Docker image from the Dockerfile, and pushes it to Docker Hub tagged as latest.
The Dockerfile itself is lean — it uses the node:18-alpine base image, copies the application files, installs dependencies via npm install, exposes port 3000, and delegates startup to entrypoint.sh, which simply runs node index.js.

Finally, you need to set up your newly created AWS EC2 instance. Get access to your instance. Install Docker on your EC2 instance by following https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-22-04.

Following this documentation, you can install Docker on your EC2 server. Then:
using the below command logIn to your Docker that is installed on your EC2 server.

sudo passwd ${USER}

Set a password for using Docker on your EC2 for administration(don't need to use sudo for executing commands)

Now, before you get into the next stage. In your GitHub project repository, go to the Settings ** section, find the **Action from the sidebar, click on Runners, and create a new self-hosted runner.

Then run all of those commands that you found from the GitHub self-hosted runner section on your EC2 instance.
Note: when you run the last command from GitHub self-hosted
./run.sh
This will accept your code as long as the terminal is open. If you want that functionality all the time, whenever you push to GitHub, the runner will accept the code and execute the command.

sudo ./svc.sh install sudo ./svc.sh start sudo ./svc.sh status
You will see listening for job.
Stage 2 — Deploy to AWS EC2 (awsec2deploy.yml)
This workflow is triggered not by a git event, but by the completion of the first workflow (workflow_run trigger).

(awsec2deploy.yml)

`
name: Publish Docker Images to AWS EC2

on:
  workflow_run:
    workflows: ['Publish Docker Image']
    types: [completed]

jobs:
  build:
    runs-on: self-hosted

    steps:
      - name: Stop the old container
        run: docker stop study-abroad-agency-server || true

      - name: Delete the old container
        run: docker rm study-abroad-agency-server || true

      - name: Delete the old image
        run: docker rmi ${{secrets.DOCKER_USER_NAME}}/study-abroad-agency-server:latest || true

      - name: Pull the image from dockerhub
        run: docker pull ${{secrets.DOCKER_USER_NAME}}/study-abroad-agency-server:latest

      - name: Run the image
        run: docker compose up -d

`

This is the key architectural decision — it creates a sequential dependency between the two pipelines, ensuring deployment only proceeds after a successful image publish.
This workflow runs on a self-hosted runner, meaning GitHub Actions is executing directly on the EC2 instance itself. This is how it achieves direct deployment without needing SSH or additional tooling like CodeDeploy. The steps follow a clean replace-and-redeploy pattern: stop and remove the old container, delete the old image, pull the fresh latest image from Docker Hub, and finally bring the container back up using docker compose up -d.
The docker-compose.yml is minimal — it references the published image, names the container, and uses network_mode: host so the container shares the EC2 instance's network stack directly, making the app accessible on port 3000 without port mapping.

Runner will show an error "no configuration file provided" when deploying on EC2. This is for not having the compose file. On your EC2 root.

sudo nano docker-compose.yml
It will open an input terminal push the below code on that file
services: app: image: shongkor/study-abroad-agency-server:latest container_name: study-abroad-agency-server network_mode: 'host'
for save --> ctrl + X then Ctrl + c

End-to-End Flow

In summary, a developer pushing to main sets off the following chain:
_Git push → GitHub Actions builds Docker image → Pushes to Docker Hub → EC2 self-hosted runner pulls new image → Restarts container via Docker Compose
This is a practical and cost-effective CI/CD setup for a single-server deployment. _

The main trade-off is that network_mode: host and a self-hosted runner introduce some operational coupling to the specific EC2 instance, which would need to be revisited if the architecture scaled to multiple instances or required zero-downtime deployments.

Github Code link : [https://github.com/Shongkor/study-abroad-agency-server]

try/catch/finally,Arrow-Function,Semicolon,Coding-Style,Comment,Spread operator,Caching,Cross Browser Testing,Data Types.

Shongkor Talukdar — Mon, 10 Mar 2025 17:25:42 +0000

Caching:
Consuming APIs is every day's meal in JavaScript, this also has its limitations, amount of requests per second is the most common, in this case, we are going to implement an algorithm to cache data based on time. Let's say we are sure that the data we are going to fetch is not going to change in a certain period of time then we can cache the data for that span. Some data can be cached by seconds, minutes, or even days.
Spread Operator:
Three very powerful dots, that allow you to expand arrays or iterable objects in places where array elements or key-value pairs would be expected.
const arr1 = ['one', 'two'];
const arr2 = [...arr1, 'three', 'four', 'five'];//['one', 'two','three', 'four', 'five']
Comment:
Comments in JavaScript enable the developer to add notes about the script or comment out sections of script that should not be executed by the interpreter.

Comments can be single line comments (using the // marker)
or
multi-line (beginning with /* and ending with */).
Commenting is considered to be good practice. Regardless of how well you understand the logic of some JavaScript, there is a good chance you may one day have to return to that script and modify it. Often this can be months, or even years later and what seemed obvious to you at the time you wrote it may seem less obvious in the future. Also, it is often likely that some other person will have to work on your scripts in the future. For both these reasons it is a good idea to provide at least some basic amount of commenting in your scripts.

Coding Style:

From: JAVASCRIP.INFO

Semicolons:
Semicolons should be written after each line of statement.
Arrow functions:
The core structure looks like this:
(argument1, argument2, ... argumentN) => {
// function body
}

try/catch/finally:

try/catch/finally syntax:
=> try...catch only works for runtime errors.
=> try...catch works synchronously.

Cross Browser Testing:
Cross-browser testing is simply what its name means - that is, to test your website or application in multiple browsers- and making sure that it works consistently and as in intended without any dependencies, or compromise in Quality.
Data Types:
JavaScript has total nine types of data or you may say values in two major categories. The primitive types and the Objects and Functions. Primitive types are values which we can use only not modify them.
Objects and Functions
● Objects ({} and others), used to group related data and code.
● Functions (x => x * 2 and others), used to refer to code.
Anything else than those above types falls into the Objects Category.
Primitive Types
● Undefined (undefined), used for unintentionally missing values.
● Null (null), used for intentionally missing values.
● Booleans (true and false), used for logical operations.
● Numbers (-100, 3.14, and others), used for math calculations.
● Strings ("hello", "something", and others), used for text.
● Symbols (uncommon), used to hide implementation details.
● BigInts (uncommon and new), used for math on big numbers.