Zero-Downtime Deployment Strategies: Keep Your Application Running During Updates

Implement zero-downtime deployments with blue-green, rolling, and canary strategies. Covers database migrations, health checks, and automated rollback patterns.

E
ECOSIRE Research and Development Team
|16 مارچ، 20268 منٹ پڑھیں1.7k الفاظ|

زیرو-ڈاؤن ٹائم تعیناتی کی حکمت عملی: اپ ڈیٹس کے دوران اپنی ایپلیکیشن چلتی رہیں

منصوبہ بند ڈاؤن ٹائم کاروبار پر اوسطاً $5,600 فی منٹ خرچ کرتا ہے۔ اس کے باوجود 43% کمپنیاں اب بھی تعیناتی کے دوران اپنی درخواستیں آف لائن لے جاتی ہیں۔ زیرو ڈاؤن ٹائم تعیناتی کوئی عیش و آرام نہیں ہے --- یہ ایک توقع ہے۔ گاہک، سرچ انجن، اور انضمام کے شراکت دار سبھی ان ایپلیکیشنز کو سزا دیتے ہیں جو آف لائن ہوتی ہیں، یہاں تک کہ مختصر طور پر۔

یہ گائیڈ تین بنیادی صفر-ڈاؤن ٹائم تعیناتی کی حکمت عملیوں، ڈیٹا بیس کی منتقلی کی تکنیکوں کا احاطہ کرتی ہے جو اپ ٹائم کو محفوظ رکھتی ہیں، اور خودکار رول بیک میکانزم۔

اہم ٹیک ویز

  • نیلے سبز کی تعیناتی سب سے محفوظ حکمت عملی ہے: ٹریفک کو پچھلے ورژن میں تبدیل کرکے فوری رول بیک
  • ڈیٹا بیس کی منتقلی پسماندہ مطابقت پذیر ہونی چاہیے --- پرانے ایپلیکیشن ورژن کو نئے اسکیما کے ساتھ کام کرنا چاہیے
  • صحت کی جانچ اور تیاری کی تحقیقات ایسے پوڈوں تک ٹریفک کو روٹ کرنے سے روکتی ہیں جو پیش کرنے کے لیے تیار نہیں ہیں۔
  • غلطی کی شرح کی نگرانی پر مبنی خودکار رول بیک ریکوری کا اوسط وقت 2 منٹ سے کم کر دیتا ہے

حکمت عملی کا موازنہ

حکمت عملیپیچیدگیرول بیک سپیڈانفراسٹرکچر لاگتکے لیے بہترین
نیلے سبزکمفوری (سیکنڈ)تعیناتی کے دوران 2xاہم ایپلی کیشنز، کبھی کبھار تعیناتیاں
رولنگ اپ ڈیٹمیڈیممنٹتعیناتی کے دوران 1.25xKubernetes، بار بار تعیناتی
کینریہائیتیز (سیکنڈ)تعیناتی کے دوران 1.05xزیادہ ٹریفک، خطرے سے متعلق حساس
نمایاں پرچممیڈیمفوری1xبتدریج فیچر رول آؤٹ

بلیو گرین تعیناتی۔

فن تعمیر

Load Balancer
    |
    |--- [ACTIVE] Blue environment (v2.0.0) <-- receives 100% traffic
    |
    |--- [IDLE] Green environment (v2.1.0) <-- deployed, tested, waiting

تعیناتی پر:

  1. v2.1.0 کو بیکار (سبز) ماحول میں تعینات کریں۔
  2. سبز کے خلاف دھواں ٹیسٹ چلائیں۔
  3. لوڈ بیلنسر کو سبز پر تبدیل کریں۔
  4. نیلا بیکار ہو جاتا ہے (فوری رول بیک کے لیے دستیاب ہے)

Nginx کے ساتھ عمل درآمد

# /etc/nginx/conf.d/app.conf
upstream blue {
    server 10.0.1.10:3000;
    server 10.0.1.11:3000;
}

upstream green {
    server 10.0.2.10:3000;
    server 10.0.2.11:3000;
}

# Active environment - change this during deployment
map $host $active_upstream {
    default blue;  # Change to 'green' to switch
}

server {
    listen 443 ssl;
    server_name app.example.com;

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

تعیناتی اسکرپٹ

#!/bin/bash
set -e

CURRENT=$(cat /etc/nginx/active-env)  # "blue" or "green"
TARGET=$( [ "$CURRENT" = "blue" ] && echo "green" || echo "blue" )

echo "Current: $CURRENT, deploying to: $TARGET"

# Deploy to inactive environment
ssh "deploy@$TARGET-1" "cd /opt/app && git pull && pnpm install --frozen-lockfile && pnpm build && pm2 restart all"
ssh "deploy@$TARGET-2" "cd /opt/app && git pull && pnpm install --frozen-lockfile && pnpm build && pm2 restart all"

# Wait for health checks
for i in 1 2; do
  echo "Checking $TARGET-$i health..."
  for attempt in $(seq 1 30); do
    if curl -sf "http://$TARGET-$i:3000/health" > /dev/null; then
      echo "$TARGET-$i is healthy"
      break
    fi
    sleep 2
  done
done

# Run smoke tests
pnpm test:smoke --base-url "http://$TARGET-1:3000"

# Switch traffic
sed -i "s/default $CURRENT/default $TARGET/" /etc/nginx/conf.d/app.conf
nginx -s reload
echo "$TARGET" > /etc/nginx/active-env

echo "Traffic switched to $TARGET. Rollback: change active-env back to $CURRENT"

رولنگ اپ ڈیٹ

رولنگ اپ ڈیٹس بتدریج مثالوں کی جگہ لے لیتے ہیں، اس بات کو یقینی بناتے ہوئے کہ کچھ صلاحیت ہمیشہ دستیاب ہے۔

Kubernetes رولنگ اپ ڈیٹ

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Create 1 extra pod during update
      maxUnavailable: 0   # Never reduce below desired replicas
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 3001
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 3001
            initialDelaySeconds: 15
            periodSeconds: 10

maxSurge: 1 اور maxUnavailable: 0 کے ساتھ رولنگ اپ ڈیٹ کا عمل:

  1. v2.1.0 کے ساتھ 1 نیا پوڈ بنائیں (کل 6 پوڈ: 5 پرانے + 1 نیا)
  2. پوڈ کی تیاری کی نئی تحقیقات کے پاس ہونے کا انتظار کریں۔
  3. 1 پرانے پوڈ کو ختم کریں (5 پوڈز: 4 پرانے + 1 نیا)
  4. ایک اور نئی پوڈ بنائیں (6 پوڈز: 4 پرانے + 2 نئے)
  5. دہرائیں جب تک کہ تمام پوڈز v2.1.0 نہ ہوجائیں

کینری تعیناتی۔

ٹریفک کی تقسیم

# Istio VirtualService for canary routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-canary
spec:
  hosts:
    - api.example.com
  http:
    - route:
        - destination:
            host: api-stable
            port:
              number: 3001
          weight: 95
        - destination:
            host: api-canary
            port:
              number: 3001
          weight: 5

پروگریسو کینری رول آؤٹ

مرحلہکینری ٹریفکدورانیہکامیابی کا معیار
11%10 منٹخرابی کی شرح <0.1%، تاخیر <500ms
25%30 منٹخرابی کی شرح <0.1%، تاخیر <500ms
325%1 گھنٹہخرابی کی شرح <0.5%، تاخیر <1s
450%2 گھنٹےخرابی کی شرح <0.5%، تاخیر <1s
5100%مکمل رول آؤٹ24 گھنٹے کے لیے مستحکم

ڈیٹا بیس کی منتقلی بغیر ڈاؤن ٹائم کے

صفر ڈاؤن ٹائم تعیناتی میں سب سے بڑا چیلنج ڈیٹا بیس اسکیما میں تبدیلیاں ہیں۔ پرانے ایپلیکیشن ورژن کو نئے اسکیما کے ساتھ کام کرنا چاہیے، اور اس کے برعکس۔

توسیعی معاہدے کا پیٹرن

مرحلہ 1: پھیلائیں (اسکیما کی تبدیلی کو تعینات کریں)

-- Add new column (nullable, no default)
ALTER TABLE orders ADD COLUMN shipping_method VARCHAR(50);

پرانا ایپلیکیشن کوڈ نئے کالم کو نظر انداز کرتا ہے۔ نیا ایپلیکیشن کوڈ پرانے اور نئے کالموں میں لکھتا ہے۔

فیز 2: ڈیٹا منتقل کریں

-- Backfill existing data
UPDATE orders SET shipping_method = 'standard' WHERE shipping_method IS NULL;

مرحلہ 3: معاہدہ (تعینات کوڈ جو خصوصی طور پر نئے کالم کا استعمال کرتا ہے)

ایپلیکیشن کی تمام مثالوں کے بعد نیا کالم استعمال کریں:

-- Make column required
ALTER TABLE orders ALTER COLUMN shipping_method SET NOT NULL;
ALTER TABLE orders ALTER COLUMN shipping_method SET DEFAULT 'standard';

ہجرت کے خطرناک نمونے۔

پیٹرنخطرہمحفوظ متبادل
کالم کا نام تبدیل کریںپرانے کوڈ کو توڑتا ہےنیا کالم شامل کریں، منتقل کریں، پرانا چھوڑ دیں
ڈراپ کالمپرانے کوڈ کو توڑتا ہےاستعمال کرنا بند کریں، پھر اگلی ریلیز میں چھوڑیں
NOT NULL کالم شامل کریںتالے کی میزکالعدم، بیک فل، NOT NULL میں تبدیل کریں
کالم کی قسم کو تبدیل کریںٹیبل کو لاک کرتا ہے، سوالات کو توڑ دیتا ہےنئی قسم کے ساتھ نیا کالم شامل کریں، منتقلی
منفرد انڈیکس شامل کریںبڑی میزوں پر میز کو تالےCREATE INDEX CONCURRENTLY

خودکار رول بیک

خرابی کی شرح پر مبنی رول بیک

#!/bin/bash
# post-deploy-monitor.sh

DEPLOY_TIME=$(date +%s)
MONITOR_DURATION=300  # 5 minutes
ERROR_THRESHOLD=0.02  # 2%

while [ $(($(date +%s) - DEPLOY_TIME)) -lt $MONITOR_DURATION ]; do
  ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_requests_total{status=~'5..'}[2m])/rate(http_requests_total[2m])" | jq -r '.data.result[0].value[1]')

  if (( $(echo "$ERROR_RATE > $ERROR_THRESHOLD" | bc -l) )); then
    echo "ERROR: Rate $ERROR_RATE exceeds threshold $ERROR_THRESHOLD"
    echo "Initiating rollback..."
    kubectl rollout undo deployment/api
    exit 1
  fi

  sleep 15
done

echo "Deployment healthy for $MONITOR_DURATION seconds"

اکثر پوچھے گئے سوالات

ہمیں کس حکمت عملی سے شروع کرنا چاہیے؟

نیلے سبز کی تعیناتی کے ساتھ شروع کریں۔ یہ لاگو کرنے کے لئے سب سے آسان ہے، فوری رول بیک فراہم کرتا ہے، اور کسی بھی ایپلیکیشن آرکیٹیکچر کے ساتھ کام کرتا ہے۔ رولنگ اپ ڈیٹ بہت سے نقلوں کے ساتھ Kubernetes ماحول کے لیے بہتر ہیں۔ کینری تعیناتیاں ہائی ٹریفک ایپلی کیشنز کے لیے ہیں جہاں آپ مکمل رول آؤٹ سے پہلے حقیقی ٹریفک کے ساتھ تبدیلیوں کی توثیق کرنا چاہتے ہیں۔

تعیناتی کے دوران ہم طویل عرصے سے چلنے والی پس منظر کی ملازمتوں کو کیسے سنبھالتے ہیں؟

خوبصورت شٹ ڈاؤن استعمال کریں۔ جب کسی پوڈ کو برطرفی کا اشارہ ملتا ہے، تو نئی ملازمتوں کو قبول کرنا بند کر دیں، جاری ملازمتیں ختم کریں (وقت ختم ہونے کے ساتھ)، پھر بند کر دیں۔ In Kubernetes, configure terminationGracePeriodSeconds to allow enough time for jobs to complete. ایسی ملازمتوں کے لیے جن میں رعایتی مدت سے زیادہ وقت لگتا ہے، ملازمت کی قطار (Redis، RabbitMQ) استعمال کریں جو زندہ رہنے والے کارکنوں پر ناکام ملازمتوں کی دوبارہ کوشش کریں۔

تعیناتی کے دوران WebSocket کنکشن کا کیا ہوگا؟

WebSocket کنکشن دیرپا ہوتے ہیں اور انہیں احتیاط سے ہینڈل کیا جانا چاہیے۔ رولنگ اپ ڈیٹ کے دوران، پرانے پوڈ پر موجودہ کنکشن اس وقت تک فعال رہتے ہیں جب تک کہ پوڈ ختم نہ ہو جائے۔ کلائنٹس کو خودکار دوبارہ کنکشن منطق کو لاگو کرنا چاہئے۔ نیلے سبز کی تعیناتیوں کے لیے، نئے کنکشنز کو نئے ماحول میں تبدیل کریں جبکہ موجودہ کنکشنز کو وقت ختم ہونے کے ساتھ پرانے ماحول میں ختم ہونے کی اجازت دیں۔

ہم صفر-ڈاؤن ٹائم تعیناتیوں کی جانچ کیسے کرتے ہیں؟

تعیناتی کے دوران لوڈ ٹیسٹ چلائیں۔ مسلسل ٹریفک پیدا کرنے کے لیے k6 یا اس سے ملتا جلتا ٹول استعمال کریں، پھر تعیناتی کو متحرک کریں۔ رول اوور کے دوران کسی بھی خرابی، تاخیر میں اضافہ، یا گرا ہوا کنکشن چیک کریں۔ عمل درآمد کی تفصیلات کے لیے ہماری لوڈ ٹیسٹنگ گائیڈ دیکھیں۔


آگے کیا آتا ہے۔

بار بار، پراعتماد ریلیز کے لیے زیرو ڈاؤن ٹائم تعیناتی ایک شرط ہے۔ اسے مکمل تعیناتی پائپ لائن کے لیے CI/CD آٹومیشن اور پوسٹ تعیناتی کی تصدیق کے لیے مانیٹرنگ کے ساتھ جوڑیں۔

ECOSIRE سے رابطہ کریں تعیناتی کی حکمت عملی سے متعلق مشاورت کے لیے، یا مکمل انفراسٹرکچر روڈ میپ کے لیے ہماری DevOps گائیڈ کو دریافت کریں۔


ECOSIRE کے ذریعہ شائع کیا گیا -- کاروباروں کو بغیر کسی رکاوٹ کے تعینات کرنے میں مدد کرنا۔

E

تحریر

ECOSIRE Research and Development Team

ECOSIRE میں انٹرپرائز گریڈ ڈیجیٹل مصنوعات بنانا۔ Odoo انٹیگریشنز، ای کامرس آٹومیشن، اور AI سے چلنے والے کاروباری حل پر بصیرت شیئر کرنا۔

Chat on WhatsApp