تحديث stack Docker Compose في الإنتاج بأمان

لماذا تُعدّ `latest` المشكلة الحقيقية

ما يغطيه هذا الدليل — وما لا يغطيه

• ما يغطيه هذا الدليل: بروتوكول خطوة بخطوة لتحديث stack‏ Docker Compose على VPS — تثبيت الإصدار، نسخ احتياطي للأقراص، مراجعة ملاحظات الإصدار، التراجع السريع، healthchecks كشبكة أمان.
• مُغطى في أدلة أخرى: قائمة التدقيق الأولية (docker-compose-production-checklist)، وإعداد depends_on وservice_healthy (docker-compose-depends-on-healthcheck)، ومقارنة أدوات التحديث التلقائي كـ Watchtower أو Diun.
• ما لا يوصي به هذا الدليل: Watchtower أو أي أداة auto-pull في الإنتاج — هذا هو بالضبط النمط المضاد الذي توضحه حالات التغييرات الجذرية.
• الجمهور المستهدف: المطورون والوكالات التي تدير stack‏ واحدة أو أكثر من Docker Compose في الإنتاج على VPS، مع وصول root وأقراص بيانات دائمة.

الخطوة 1 — ثبّت جميع صورك

docker inspect --format='{{index .RepoDigests 0}}' getmeili/meilisearch:v1.53.0

بروتوكول التحديث — الخطوات الخمس

1. 01

   اقرأ ملاحظات الإصدار قبل السحب

   أولاً، راجع ملاحظات الإصدار الجديد. ابحث عن كلمات breaking، migration، incompatible، pg_upgrade، dump. هذا ليس اختيارياً: وثّق Supabase صراحةً أن الترقية من PostgreSQL 15 إلى 17 تستلزم pg_upgrade يدوياً — حاوية PG 17 ترفض الإقلاع على قرص PG 15، وعملية التهيئة لا تُهجّر البيانات تلقائياً.

   بالنسبة لـ Langfuse‏ v4 (الإصدار العام بتاريخ 17 أغسطس 2026)، تُرفض SDK‏ Python v2 والإصدارات الأقدم عند الاستيعاب من طرف الـ stack الجديدة — تغيير جذري يؤثر على جميع الخدمات العميلة التي تتتبع عبر الـ API القديمة.

   ثلاث دقائق من القراءة توفر عليك ساعات من استعادة البيانات.

2. 02

   احتفظ بنسخة احتياطية للأقراص قبل السحب

   لا تسحب أبداً قبل أن يكون لديك نسخة احتياطية صالحة للاستخدام. بالنسبة للأقراص المسماة، هناك مقاربتان:

   تصدير تطبيقي (موصى به لقواعد البيانات) — يجب أن تكون الخدمة في حالة healthy قبل التصدير:

   docker compose exec db pg_dump -U postgres -Fc mydb > backup_$(date +%Y%m%d_%H%M%S).dump

   لقطة قرص خام — مفيدة للتخزينات الثنائية (Meilisearch،‏ Redis، MinIO):

   docker run --rm \
     --volumes-from $(docker compose ps -q meilisearch) \
     -v $(pwd)/backups:/backup \
     alpine tar czf /backup/meili_$(date +%Y%m%d_%H%M%S).tar.gz /meili_data

   تحقق من أن النسخة الاحتياطية قابلة للقراءة قبل المتابعة. ملف dump تالف يُكتشف أثناء الاستعادة هو أكثر السيناريوهات تكلفةً.

3. 03

   اسحب الصورة الجديدة واختبرها خارج الإنتاج

   حدّث الوسم في docker-compose.yml، ثم اسحب الصورة دون إعادة تشغيل الخدمة:

   docker compose pull meilisearch

   إذا أتاحت بيئتك ذلك، اختبر الصورة الجديدة على نسخة مستنسخة من القرص في بيئة ddev أو VM تجريبي قبل المساس بالإنتاج. تحقق من سجلات الإقلاع بحثاً عن أي أخطاء تهجير:

   docker compose up -d meilisearch
   docker compose logs -f meilisearch

   انتظر حتى يصل healthcheck إلى حالة healthy قبل التحقق من النجاح. خدمة تبدأ لكنها ليست healthy بعد ليست خدمة جاهزة.

4. 04

   تحقق من healthchecks

   healthcheck مُهيَّأ جيداً هو خط الكشف الأول. يجب أن يكون موجوداً على كل خدمة حيوية في الـ stack، بصيغة Compose‏ v2:

   healthcheck:
     test: ["CMD-SHELL", "curl -sf http://localhost:7700/health || exit 1"]
     interval: 10s
     timeout: 5s
     retries: 5
     start_period: 30s

   حقل start_period حاسم للخدمات التي تستغرق وقتاً في الإقلاع (قواعد البيانات، محركات البحث): يمنع Docker من إعلان الحاوية unhealthy أثناء مرحلة التهيئة وتشغيل إعادة تشغيل مبكرة.

   راجع docker-compose-depends-on-healthcheck للإعداد الكامل لـ service_healthy على PostgreSQL — نفس المبدأ ينطبق على أي خدمة تحتاج وقتاً للتهيئة.

5. 05

   التراجع في حال حدوث مشكلة

   إذا فشل الإصدار الجديد في الإقلاع أو أنتج أخطاء، يجب أن يستغرق التراجع أقل من دقيقتين. الإجراء:

   1. عُد إلى الوسم السابق في docker-compose.yml (أو git revert إذا حفظت الرفع).
   2. أعِد تشغيل الخدمة المعنية فقط، دون إعادة إنشاء الأقراص:

   docker compose up -d --no-deps --force-recreate meilisearch

   3. تحقق من السجلات فوراً:

   docker compose logs -f meilisearch

   علامة --no-deps ضرورية: تُعيد تشغيل الخدمة المستهدفة دون المساس بالحاويات الأخرى (قاعدة البيانات، الذاكرة المؤقتة، الوكيل). بدونها، قد يُعيد docker compose up -d إنشاء الـ stack بأكملها.

   ⚠️ إذا هاجر الإصدار الجديد تنسيق البيانات على القرص (Meilisearch‏ v1.54، Supabase‏ PG17)، فإن التراجع عن الصورة وحده لا يكفي — وهذا بالضبط لماذا النسخة الاحتياطية للقرص شرط مسبق لا خيار.

التغييرات الجذرية الأخيرة التي أوقفت تشغيل الخوادم

استراتيجيات التحديث: مقارنة

مرّر الجدول أفقيًا

دمج هذا البروتوكول في سير عملك

# .env
MEILISEARCH_VERSION=v1.53.0
POSTGRES_VERSION=15.6

# docker-compose.yml
services:
  meilisearch:
    image: getmeili/meilisearch:${MEILISEARCH_VERSION}