ডাউনটাইম ছাড়াই কনটেইনার আপডেট

কন্টেইনার আপডেট করা মানে “নতুন ইমেজ পুল করা” নয়, বরং “চলমান ভার্সনকে নতুনটি দিয়ে প্রতিস্থাপন করা এবং প্রয়োজনে রোলব্যাক করতে পারা।” পার্থক্যটা ঠিক একবারই ধরা পড়ে: যখন নতুন ভার্সনটি চালু হতে ব্যর্থ হয়।

যে পদ্ধতিটি কাজ করে

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 সমস্যা।