शून्य-डाउनटाइम परिनियोजन रणनीतियाँ: अपडेट के दौरान अपने एप्लिकेशन को चालू रखें

योजनाबद्ध डाउनटाइम में व्यवसायों को प्रति मिनट औसतन $5,600 का खर्च आता है। फिर भी 43% कंपनियां अभी भी तैनाती के दौरान अपने आवेदन ऑफ़लाइन लेती हैं। शून्य-डाउनटाइम परिनियोजन कोई विलासिता नहीं है --- यह एक अपेक्षा है। ग्राहक, खोज इंजन और एकीकरण भागीदार सभी उन अनुप्रयोगों को दंडित करते हैं जो ऑफ़लाइन हो जाते हैं, भले ही थोड़े समय के लिए।

यह मार्गदर्शिका तीन प्राथमिक शून्य-डाउनटाइम परिनियोजन रणनीतियों, डेटाबेस माइग्रेशन तकनीकों को शामिल करती है जो अपटाइम को संरक्षित करती हैं, और स्वचालित रोलबैक तंत्र।

मुख्य बातें

ब्लू-ग्रीन परिनियोजन सबसे सुरक्षित रणनीति है: ट्रैफ़िक को पिछले संस्करण पर वापस स्विच करके त्वरित रोलबैक

डेटाबेस माइग्रेशन बैकवर्ड-संगत होना चाहिए --- पुराने एप्लिकेशन संस्करण को नई स्कीमा के साथ काम करना चाहिए

स्वास्थ्य जांच और तत्परता जांच उन पॉड्स पर ट्रैफ़िक भेजने से रोकती है जो सेवा के लिए तैयार नहीं हैं

त्रुटि दर निगरानी के आधार पर स्वचालित रोलबैक पुनर्प्राप्ति के औसत समय को 2 मिनट से कम कर देता है

रणनीति तुलना

| रणनीति | जटिलता | रोलबैक स्पीड | बुनियादी ढांचे की लागत | के लिए सर्वश्रेष्ठ | |---|---||----------------|-------------------|-| | नीला-हरा | निम्न | तत्काल (सेकंड) | तैनाती के दौरान 2x | महत्वपूर्ण अनुप्रयोग, कम तैनाती | | रोलिंग अपडेट | मध्यम | मिनट | तैनाती के दौरान 1.25x | कुबेरनेट्स, लगातार तैनाती | | कैनरी | उच्च | तेज़ (सेकंड) | तैनाती के दौरान 1.05x | उच्च यातायात, जोखिम के प्रति संवेदनशील | | फ़ीचर झंडे | मध्यम | तुरंत | 1x | धीरे-धीरे फीचर रोलआउट |

नीला-हरा परिनियोजन

वास्तुकला

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

तैनाती पर:

निष्क्रिय (हरे) वातावरण में v2.1.0 तैनात करें
हरे रंग के विरुद्ध धुआं परीक्षण चलाएँ
लोड बैलेंसर को हरे रंग में बदलें
नीला निष्क्रिय हो जाता है (तत्काल रोलबैक के लिए उपलब्ध)

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"

रोलिंग अपडेट

रोलिंग अपडेट इंस्टेंस को धीरे-धीरे बदलते हैं, यह सुनिश्चित करते हुए कि कुछ क्षमता हमेशा उपलब्ध रहती है।

कुबेरनेट्स रोलिंग अपडेट

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 के साथ रोलिंग अद्यतन प्रक्रिया:

v2.1.0 के साथ 1 नया पॉड बनाएं (कुल 6 पॉड: 5 पुराने + 1 नया)
नई पॉड तत्परता जांच के पारित होने की प्रतीक्षा करें
1 पुराने पॉड को समाप्त करें (5 पॉड: 4 पुराने + 1 नया)
एक और नया पॉड बनाएं (6 पॉड: 4 पुराने + 2 नए)
तब तक दोहराएं जब तक कि सभी पॉड्स 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

प्रगतिशील कैनरी रोलआउट

चरण	कैनरी यातायात	अवधि	सफलता मानदंड
1	1%	10 मिनट	त्रुटि दर <0.1%, विलंबता <500ms
2	5%	30 मिनट	त्रुटि दर <0.1%, विलंबता <500ms
3	25%	1 घंटा	त्रुटि दर <0.5%, विलंबता <1s
4	50%	2 घंटे	त्रुटि दर <0.5%, विलंबता <1s
5	100%	पूर्ण रोलआउट	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';

खतरनाक प्रवासन पैटर्न

पैटर्न	जोखिम	सुरक्षित विकल्प
कॉलम का नाम बदलें	पुराना कोड तोड़ता है	नया कॉलम जोड़ें, माइग्रेट करें, पुराना छोड़ें
ड्रॉप कॉलम	पुराना कोड तोड़ता है	उपयोग करना बंद करें, फिर अगली रिलीज़ में छोड़ें
शून्य नहीं कॉलम जोड़ें	ताले की मेज	शून्य नहीं करने योग्य, बैकफ़िल जोड़ें, शून्य में परिवर्तन करें
कॉलम प्रकार बदलें	टेबल को लॉक कर देता है, प्रश्नों को तोड़ देता है	नए प्रकार के साथ नया कॉलम जोड़ें, माइग्रेट करें
अद्वितीय अनुक्रमणिका जोड़ें	बड़े टेबल पर टेबल को लॉक करता है	`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"

अक्सर पूछे जाने वाले प्रश्न

हमें किस रणनीति से शुरुआत करनी चाहिए?

नीले-हरे परिनियोजन से प्रारंभ करें. इसे लागू करना सबसे आसान है, यह तुरंत रोलबैक प्रदान करता है और किसी भी एप्लिकेशन आर्किटेक्चर के साथ काम करता है। कई प्रतिकृतियों वाले कुबेरनेट्स परिवेश के लिए रोलिंग अपडेट बेहतर हैं। कैनरी परिनियोजन उच्च-ट्रैफ़िक अनुप्रयोगों के लिए हैं जहाँ आप पूर्ण रोलआउट से पहले वास्तविक ट्रैफ़िक के साथ परिवर्तनों को मान्य करना चाहते हैं।

परिनियोजन के दौरान हम लंबे समय से चल रही पृष्ठभूमि नौकरियों को कैसे संभालते हैं?

सुशोभित शटडाउन का प्रयोग करें. जब पॉड को समाप्ति संकेत मिलता है, तो नई नौकरियों को स्वीकार करना बंद कर दें, प्रगतिरत नौकरियों को समाप्त करें (टाइमआउट के साथ), फिर बंद करें। कुबेरनेट्स में, कार्यों को पूरा करने के लिए पर्याप्त समय देने के लिए terminationGracePeriodSeconds को कॉन्फ़िगर करें। उन नौकरियों के लिए जिनमें अनुग्रह अवधि से अधिक समय लगता है, एक नौकरी कतार (रेडिस, रैबिटएमक्यू) का उपयोग करें जो जीवित श्रमिकों पर विफल नौकरियों का पुन: प्रयास करती है।

परिनियोजन के दौरान वेबसॉकेट कनेक्शन के बारे में क्या?

वेबसॉकेट कनेक्शन लंबे समय तक चलते हैं और इन्हें सावधानी से संभालना चाहिए। रोलिंग अपडेट के दौरान, पुराने पॉड पर मौजूदा कनेक्शन पॉड समाप्त होने तक सक्रिय रहते हैं। ग्राहकों को स्वचालित पुनः कनेक्शन तर्क लागू करना चाहिए। नीले-हरे परिनियोजन के लिए, नए कनेक्शन को नए वातावरण में स्विच करें, जबकि मौजूदा कनेक्शन को टाइमआउट के साथ पुराने वातावरण पर खत्म होने दें।

हम शून्य-डाउनटाइम परिनियोजन का परीक्षण कैसे करते हैं?

परिनियोजन के दौरान लोड परीक्षण चलाएँ। निरंतर ट्रैफ़िक उत्पन्न करने के लिए k6 या समान टूल का उपयोग करें, फिर परिनियोजन ट्रिगर करें। रोलओवर के दौरान किसी भी त्रुटि, बढ़ी हुई विलंबता, या टूटे हुए कनेक्शन की जाँच करें। कार्यान्वयन विवरण के लिए हमारी लोड परीक्षण मार्गदर्शिका देखें।

आगे क्या आता है

लगातार, भरोसेमंद रिलीज़ के लिए शून्य-डाउनटाइम परिनियोजन एक शर्त है। पूर्ण परिनियोजन पाइपलाइन के लिए इसे CI/CD स्वचालन और परिनियोजन के बाद सत्यापन के लिए निगरानी के साथ संयोजित करें।

परिनियोजन रणनीति परामर्श के लिए ECOSIRE से संपर्क करें, या संपूर्ण बुनियादी ढांचे रोडमैप के लिए हमारी DevOps गाइड देखें।

ECOSIRE द्वारा प्रकाशित - व्यवसायों को बिना किसी व्यवधान के तैनात होने में मदद करना।

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