First Pipeline

Before You Start

এই page সরাসরি পড়তে এলে নিচের জিনিসগুলো তৈরি থাকতে হবে:

• Server-এ Docker আছে, /opt/myapp folder আছে এবং আপনার user-এর মালিকানায়
• GitHub-এ তিনটি secret আছে — SERVER_HOST, SERVER_USER, SSH_PRIVATE_KEY
• Server-এ docker login ghcr.io করা আছে

কোনোটি না থাকলে Setup page-এ সব দেওয়া আছে।

What Goes Where

শুরুতেই পরিষ্কার করে নিই কোন file কোথায় থাকবে। এই ছবিটি মাথায় থাকলে বাকি ধাপগুলো পরিষ্কার লাগবে।

GitHub repository-তে (আপনি যা লেখেন):

myapp/
├── .github/workflows/
│   ├── ci.yml
│   └── deploy.yml
├── Dockerfile
├── .dockerignore
├── next.config.mjs
└── package.json

Server-এ (মাত্র দুটি file):

/opt/myapp/
├── compose.yaml
└── .env

Server-এ কোনো code নেই। কোনো Dockerfile নেই। কোনো node_modules নেই।

const nextConfig = {
  output: 'standalone',
}
 
export default nextConfig

# ধাপ ১: শুধু dependency install
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
 
# ধাপ ২: build
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
 
# ধাপ ৩: শুধু চালানোর জন্য যা লাগে
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
 
# root হিসেবে না চালানোর জন্য একটি সাধারণ user
RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001
 
COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
 
USER nextjs
EXPOSE 3000
ENV PORT=3000
ENV HOSTNAME=0.0.0.0
CMD ["node", "server.js"]

node_modules
.next
.git
.env
.env.*
README.md
Dockerfile
.dockerignore

name: CI
 
on:
  pull_request:
    branches: [main]
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - uses: docker/setup-buildx-action@v3
 
      - name: Build image
        uses: docker/build-push-action@v6
        with:
          context: .
          push: false
          cache-from: type=gha
          cache-to: type=gha,mode=max

nano /opt/myapp/compose.yaml

services:
  web:
    image: ghcr.io/your-username/myapp:${TAG}
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      NODE_ENV: production

nano /opt/myapp/.env

TAG=latest

chmod 600 /opt/myapp/.env

name: Deploy
 
on:
  push:
    branches: [main]
 
# একসাথে দুইটি deploy চলতে দেবে না
concurrency:
  group: production-deploy
  cancel-in-progress: false
 
env:
  IMAGE: ghcr.io/your-username/myapp
 
jobs:
  # Job 1: image বানিয়ে registry-তে পাঠানো
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
 
      - uses: docker/setup-buildx-action@v3
 
      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
 
      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            ${{ env.IMAGE }}:${{ github.sha }}
            ${{ env.IMAGE }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max
 
  # Job 2: image তৈরি হলে তবেই server-এ deploy
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to server
        uses: appleboy/ssh-action@v1.2.0
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            set -eE
            cd /opt/myapp
 
            # এখন কোন version চলছে, মনে রাখি — ফিরে আসার জন্য
            OLD_TAG=$(grep '^TAG=' .env | cut -d= -f2)
            NEW_TAG=${{ github.sha }}
            echo "old: $OLD_TAG"
            echo "new: $NEW_TAG"
 
            # যেকোনো ধাপে fail করলে এই function চলবে
            rollback() {
              if [ "$OLD_TAG" = "latest" ] || [ -z "$OLD_TAG" ]; then
                echo "previous tag is not a fixed version — cannot roll back"
                return
              fi
              echo "rolling back to $OLD_TAG"
              sed -i "s|^TAG=.*|TAG=$OLD_TAG|" .env
              docker compose up -d || true
            }
            trap rollback ERR
 
            # নতুন version বসাই
            sed -i "s|^TAG=.*|TAG=$NEW_TAG|" .env
            docker compose pull
            docker compose up -d
 
            # সত্যিই চলছে কিনা দেখি, ৩০ সেকেন্ড পর্যন্ত অপেক্ষা
            for i in $(seq 1 10); do
              if curl -fsS http://localhost:3000 > /dev/null; then
                trap - ERR
                echo "deploy ok"
                # ১৪ দিনের পুরোনো, অব্যবহৃত image মুছে দিই
                docker image prune -af --filter "until=336h"
                exit 0
              fi
              sleep 3
            done
 
            # এখানে পৌঁছানো মানে app উঠল না
            echo "health check failed"
            rollback
            exit 1

How TAG Works

এই pipeline-এর পুরো বুদ্ধিটা .env file-এর ওই একটি লাইনে।

TAG=a3f9c21

Docker Compose নিজে থেকেই একই folder-এর .env file পড়ে নেয়। তাই compose.yaml-এ লেখা ${TAG} জায়গায় সে a3f9c21 বসিয়ে দেয়:

image: ghcr.io/your-username/myapp:${TAG}
                                 ↓
image: ghcr.io/your-username/myapp:a3f9c21

Deploy করার মানে দাঁড়ায় শুধু ওই এক লাইন বদলে docker compose up -d চালানো।

আর rollback করার মানে দাঁড়ায় ওই এক লাইনে পুরোনো নামটি ফিরিয়ে আনা। পুরোনো image সাধারণত আগে থেকেই server-এ নামানো থাকে, তাই কিছু টানতে হয় না — দশ সেকেন্ডের মধ্যেই পুরোনো version ফিরে আসে।

The Health Check

Deploy-এর শেষে ওই for loop-টি বাদ দেবেন না।

মূল কারণ: GitHub-এর সবুজ checkmark-এর মানে শুধু “সব command exit code 0 দিয়েছে”। docker compose up -d container চালু করেই ফিরে আসে — container-টি ভেতরে গিয়ে crash করল কিনা সে জানে না।

App উঠে গিয়ে তিন সেকেন্ড পরে মরে যেতে পারে — .env-এ একটি variable missing থাকলে, port দখল হয়ে থাকলে, বা code-এ কোনো ভুল থাকলে। Docker তখনো “started” বলবে, GitHub সবুজ দেখাবে, আর আপনার site down থাকবে।

curl তাই সরাসরি site-এ গিয়ে দেখে সত্যিই সাড়া আসছে কিনা।

curl flag গুলোর মানে:

• -f — HTTP error (৪০০, ৫০০) পেলে fail করবে। এটি ছাড়া error page-ও “সফল” গণ্য হয়
• -s — progress bar লুকায়
• -S — তবু error message দেখায়

Loop-টি ১০ বার চেষ্টা করে, প্রতিবার ৩ সেকেন্ড অপেক্ষা করে। Next.js উঠতে সাধারণত ৩-৫ সেকেন্ড লাগে, তাই ৩০ সেকেন্ড যথেষ্ট।

Automatic Rollback

Script-এ rollback নামে একটি function আছে আর তার সাথে একটি লাইন:

trap rollback ERR

trap shell-কে বলে — “নিচের যেকোনো command fail করলে আগে rollback চালিয়ে নিও”।

কেন দরকার — script-এর শুরুতেই .env-এ নতুন TAG বসিয়ে দেওয়া হয়। এরপর যদি docker compose pull fail করে (registry-তে ঢুকতে না পারলে, বা image না পেলে), তাহলে set -e-র কারণে script সাথে সাথে থেমে যাবে।

trap না থাকলে তখন যা হতো: .env-এ এমন একটি version লেখা আছে যা কখনো চালুই হয়নি। পরের বার কেউ docker compose up -d দিলে বা server reboot হলে সেই ভুল version উঠতে চাইবে।

trap থাকায় যেখানেই fail করুক, .env আগের অবস্থায় ফিরে যায়।

Health check পাশ করলে trap - ERR দিয়ে trap-টি সরিয়ে দেওয়া হয় — কাজ শেষ, আর দরকার নেই।

Disk Cleanup

Health check পাশ করার পরে script-এর শেষ কাজটি এই লাইনটি:

docker image prune -af --filter "until=336h"

প্রতিটি deploy server-এ একটি নতুন image নামায়, কিন্তু পুরোনোগুলো নিজে থেকে মোছে না। কয়েক মাস পরে disk ভরে যায়, আর তখন no space left on device দিয়ে deploy fail করতে শুরু করে।

Flag তিনটির মানে:

• -a — কোনো container ব্যবহার করছে না, এমন সব image ধরবে
• -f — “সত্যিই মুছব?” জিজ্ঞেস করবে না। Pipeline-এ কেউ উত্তর দেওয়ার নেই
• until=336h — ১৪ দিনের চেয়ে পুরোনো হলেই মুছবে। ৩৩৬ ঘণ্টা = ১৪ দিন

চলমান container যে image ব্যবহার করছে সেটি কখনো মোছে না, তাই এটি নিরাপদ।

Concurrency

concurrency:
  group: production-deploy
  cancel-in-progress: false

ধরুন আপনি push করলেন, তারপর ৩০ সেকেন্ড পরে একটি ছোট typo ঠিক করে আবার push করলেন। concurrency না থাকলে দুটি deploy একসাথে চলবে।

তখন দুটি script একই .env file-এ একই সময়ে লিখতে যাবে। ফলাফল অনুমান করা যায় না — কোন version শেষ পর্যন্ত চলবে কেউ জানে না।

concurrency দ্বিতীয় deploy-কে লাইনে দাঁড় করিয়ে রাখে। cancel-in-progress: false লেখা আছে কারণ deploy মাঝপথে বাতিল করা বিপজ্জনক।

Push and Watch

সব file commit করে push করুন:

git add .
git commit -m "add docker ci cd pipeline"
git push origin main

GitHub-এ Actions tab খুলুন। সাথে সাথেই একটি run শুরু হবে।

• build job চলবে — প্রথমবার ৩-৫ মিনিট (cache খালি), পরের বার থেকে ১-২ মিনিট
• সবুজ হলে deploy job শুরু হবে — প্রায় ৩০ সেকেন্ড

Server-এ গিয়ে মিলিয়ে দেখুন:

cd /opt/myapp
cat .env
docker compose ps

.env-এ TAG=latest-এর বদলে একটি লম্বা commit sha দেখা যাবে। ps-এ container Up অবস্থায় থাকবে।

Up না দেখালে, বা Restarting দেখালে — server-এ থেকেই container-এর ভেতরে কী হচ্ছে দেখুন:

docker compose logs -f

এখানেই আপনার app-এর নিজের error message পাবেন। Pipeline-এর log ভেতরের কথা বলে না — সে শুধু জানে container চালু হয়েছিল কিনা।

Test It for Real

Pipeline সত্যিই কাজ করছে কিনা জানার একটিই উপায় — একটি পরিবর্তন করে দেখা।

Homepage-এর কোনো লেখা বদলান, তারপর:

git add .
git commit -m "update homepage text"
git push origin main

এখন কিছুই করবেন না। শুধু ২ মিনিট অপেক্ষা করে browser refresh দিন। নতুন লেখা দেখা যাবে।

আপনি আর কখনো হাতে deploy করবেন না।

Will It Survive a Reboot

আরেকটি পরীক্ষা বাকি, আর এটি অনেকে বাদ দিয়ে দেন।

Server তো মাঝে মাঝে reboot হবেই — update, maintenance, বা cloud provider-এর কারণে। তখন container নিজে থেকে উঠবে কিনা?

Server-এ দুটি জিনিস ঠিক থাকতে হবে:

systemctl is-enabled docker
docker inspect $(docker compose ps -q) --format '{{.HostConfig.RestartPolicy.Name}}'

প্রথমটি enabled আর দ্বিতীয়টি unless-stopped দেখালে ঠিক আছে।

• enabled না দেখালে — sudo systemctl enable docker চালান
• unless-stopped না দেখালে — compose file-এ ওই লাইনটি বাদ পড়েছে

Reaching It from the Internet

Compose file-এ port লেখা আছে 127.0.0.1:3000:3000। এর মানে container-টি শুধু server-এর ভেতর থেকে পাওয়া যায়। Browser-এ আপনার domain লিখলে এখনো কিছুই আসবে না।

এটি ইচ্ছাকৃত। Node.js সরাসরি internet-এর মুখোমুখি বসার জন্য তৈরি নয় — HTTPS certificate, একাধিক domain, ধীর client — এসব সে ভালোভাবে সামলায় না।

তাই মাঝখানে একটি reverse proxy বসে। বাইরের সব traffic সে নেয়, তারপর ভেতরে container-এর কাছে পাঠায়:

Internet  →  Nginx (port 80, 443)  →  container (127.0.0.1:3000)

সবচেয়ে ছোট Nginx config যা কাজ করে:

server {
    listen 80;
    server_name yourdomain.com;
 
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Server-এ এটি চালু করুন:

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

sudo nginx -t অংশটি config-এ ভুল আছে কিনা দেখে নেয়। ভুল থাকলে reload হবে না, তাই চলমান site ভাঙে না।

তারপর HTTPS বসাতে দুটি command:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d yourdomain.com

Certbot নিজেই certificate এনে Nginx config-এ বসিয়ে দেয়, আর মেয়াদ শেষ হওয়ার আগে নিজে থেকে renew করে।

When a CDN Is in Front

Site-এর সামনে Cloudflare বা অন্য কোনো CDN থাকলে একটি জিনিস জেনে রাখুন।

Deploy সফল, container ঠিক চলছে, server সঠিক উত্তর দিচ্ছে — তবু browser-এ পুরোনো জিনিস দেখাচ্ছে। কারণ CDN মাঝখানে বসে পুরোনো copy দিচ্ছে।

সাধারণত HTML cache হয় না, তাই লেখার পরিবর্তন সাথে সাথেই দেখা যায়। কিন্তু .js, .css আর ছবি cache হয়।

Server সত্যিই কী দিচ্ছে দেখতে চাইলে URL-এর শেষে একটি অর্থহীন query যোগ করুন — CDN তখন এটিকে নতুন ঠিকানা ভেবে server-এ জিজ্ঞেস করবে:

curl -s -o /dev/null -w "cached: %{http_code}\n" https://yoursite.com/app.js
curl -s -o /dev/null -w "fresh:  %{http_code}\n" "https://yoursite.com/app.js?x=123"

দুটি আলাদা উত্তর এলে বুঝবেন সমস্যা আপনার server-এ নয়, CDN-এ। তখন CDN-এর dashboard থেকে cache purge করুন।

Real-World Note

docker history ghcr.io/your-username/myapp:latest --no-trunc

Quick Check

• Pull request খুললে ci.yml নিজে থেকে চলছে?
• main-এ push করলে site নিজে থেকে update হচ্ছে?
• Server-এ এখন কোন দুটি file আছে?
• .env-এর TAG লাইনটি কী কাজ করে?
• Health check না থাকলে কোন সমস্যাটি ধরা পড়বে না?

আপনার Next.js app এখন নিজে থেকে deploy হচ্ছে, আর deploy fail করলে নিজে থেকে ফিরেও যাচ্ছে।

কিন্তু আসল production project-এ সাধারণত একটির বেশি জিনিস চলে — একটি আলাদা API server, একটি database, database-এর schema migration। Migration ভুল সময়ে চললে site ভেঙে যায়, আর তখন শুধু image ফিরিয়ে আনলেই সমস্যা মেটে না।

পরের page-এ এই pipeline-কে বাড়িয়ে সম্পূর্ণ production stack চালাব।

পরবর্তী → Production Pipeline