ڈاؤن ٹائم کے بغیر کنٹینرز کی اپ ڈیٹ

کنٹینر کو اپ ڈیٹ کرنا "نئی امیج پل کرنا" نہیں بلکہ "چلتی ہوئی ورژن کو نئی سے بدلنا اور واپس پرانی پر آنے کے قابل ہونا" ہے۔ فرق صرف ایک بار نظر آتا ہے: جب نئی ورژن شروع ہی نہ ہو۔

ایک طریقہ جو کام کرتا ہے

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 مسائل میں۔