تحديث الحاويات دون توقف

تحديث الحاوية ليس «سحب صورة جديدة» بل «استبدال النسخة قيد التشغيل بأخرى جديدة مع القدرة على التراجع». يظهر الفرق مرة واحدة بالضبط: عندما تفشل النسخة الجديدة في الإقلاع.

إجراء فعّال

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 مثبتًا على النظام.

أخطاء شائعة

• pull بدون up -d. تُنزَّل الصورة الجديدة، لكن الحاوية القديمة لا تزال تعمل.
• القرص ممتلئ بالصور القديمة. شغّل docker image prune مرة شهريًا — لكن ليس مباشرة بعد تحديث. راجع مساحة القرص.
• حدّثت كل شيء دفعة واحدة. يتعطل شيء ما — ولا تستطيع تحديد ما هو. حدّث خدمة واحدة في كل مرة.
• لم تقرأ ملاحظات الإصدار. ملف الإعدادات غير المتوافق هو السبب الأكثر شيوعًا للفشل بعد تغيير الإصدار الرئيسي؛ راجع التفصيل في مشكلات Docker الشائعة.