डाउनटाइम के बिना कंटेनर अपडेट करना

कंटेनर अपडेट करना “नई इमेज pull करना” नहीं, बल्कि “चल रहे वर्ज़न को नए से बदलना और ज़रूरत पड़ने पर वापस लौट पाना” है। यह फ़र्क ठीक एक बार दिखता है: जब नया वर्ज़न शुरू ही न हो।

एक तरीका जो काम करता है

cd /opt/myapp
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f --tail 100

Compose सिर्फ़ उन्हीं सर्विसेज़ को फिर से बनाता है जिनकी इमेज बदली है, बाक़ी को वैसे ही छोड़ देता है। डाउनटाइम सिर्फ़ उतना ही होता है जितने सेकंड में कंटेनर रीस्टार्ट होता है।

लेकिन यह करने से पहले दो शर्तें पूरी करें।

पहली: वर्ज़न पिन किए हुए हों। फ़ाइल में postgres:17.2 लिखा होना चाहिए, postgres:latest नहीं। वरना एक दिन pull कोई मेजर वर्ज़न ले आएगा जो डेटा फ़ॉर्मैट ही बदल देगा, और रोलबैक नामुमकिन हो जाएगा।

दूसरी: बैकअप ताज़ा हो। ऐसा अपडेट जो डेटाबेस तोड़ देता है, उसे वापस नहीं लाया जा सकता। मेजर वर्ज़न बदलने से पहले डंप ले लें — देखें क्या-क्या बैकअप लें।

बिना रुकावट बदलना

रिवर्स प्रॉक्सी के पीछे चल रही वेब सर्विस के लिए, अगर कंटेनर में हेल्थ चेक हो तो डाउनटाइम लगभग शून्य हो जाता है: प्रॉक्सी रिक्वेस्ट सिर्फ़ तैयार इंस्टेंस को भेजना शुरू करेगा।

services:
  app:
    image: ghcr.io/example/app:1.5.0
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:8080/health"]
      interval: 5s
      timeout: 3s
      retries: 6
      start_period: 20s

docker inspect -f '{{.State.Health.Status}}' <container>

हेल्थ चेक के बिना Compose कंटेनर को तैयार तभी मान लेता है जब प्रोसेस शुरू हो जाता है — जबकि ऐप अभी अपनी सेटिंग्स पढ़ रहा होता है और माइग्रेशन लगा रहा होता है।

पुरानी इमेज तब तक न हटाएँ जब तक नया वर्ज़न कम से कम एक घंटे न चल जाए। रोलबैक का मतलब है image: ...:1.4.2 वापस करके docker compose up -d चलाना, लेकिन यह तभी काम करेगा जब पुरानी इमेज अब भी डिस्क पर हो। अपडेट के तुरंत बाद docker image prune -a चलाना आपसे यह विकल्प छीन लेता है।

रोलबैक

sed -i 's|app:1.5.0|app:1.4.2|' compose.yaml
docker compose up -d app
docker compose logs -f --tail 50 app

अगर नए वर्ज़न ने डेटाबेस स्कीमा पहले ही बदल दिया है, तो सिर्फ़ इमेज वापस करना काफ़ी नहीं — आपको बैकअप से रीस्टोर करना पड़ेगा। इसीलिए मेजर अपडेट शांत समय पर और जाँचे हुए बैकअप के साथ किए जाते हैं: देखें रीस्टोर ड्रिल।

ऑटोमेशन: सावधान रहें

Watchtower अपने आप कंटेनर अपडेट कर सकता है। घरेलू सर्विसेज़ के लिए यह सुविधाजनक है; प्रोडक्शन के लिए यह जोखिम है: अपडेट रात में आता है, डेटाबेस तोड़ देता है, और किसी को पता नहीं चलता। एक समझदार समझौता सिर्फ़ नोटिफ़िकेशन रखना है:

services:
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --monitor-only --schedule "0 0 6 * * *"

आपको पता चल जाता है कि नया वर्ज़न आ गया है, और आप अपने हिसाब से सही समय पर मैन्युअली अपडेट कर लेते हैं।

मशीन रीबूट करना

सिस्टम पैकेज कंटेनर से अलग अपडेट होते हैं। कर्नल अपडेट के बाद रीबूट ज़रूरी है, और restart: unless-stopped वाले कंटेनर अपने आप वापस चालू हो जाते हैं। इसे पहले से टेस्ट करें — शांत समय पर sudo reboot से, किसी इंसिडेंट के बीच में नहीं। पैनल से सॉफ़्ट रीबूट तब तक काम करता है जब तक सिस्टम पर qemu-guest-agent इंस्टॉल हो।

आम गलतियाँ

• up -d के बिना pull। नई इमेज डाउनलोड हो जाती है, लेकिन पुराना कंटेनर अब भी चल रहा होता है।
• डिस्क पुरानी इमेज से भरी हुई। महीने में एक बार docker image prune चलाएँ — लेकिन अपडेट के तुरंत बाद नहीं। देखें डिस्क स्पेस।
• आपने सब कुछ एक साथ अपडेट कर दिया। कुछ टूटता है — और पता नहीं चलता कि क्या। एक बार में एक ही सर्विस अपडेट करें।
• आपने रिलीज़ नोट्स नहीं पढ़े। मेजर वर्ज़न बदलने के बाद फ़ेल होने की सबसे आम वजह इनकम्पैटिबल कॉन्फ़िग फ़ाइल होती है; जानकारी के लिए देखें आम Docker समस्याएँ।