[{"data":1,"prerenderedAt":166},["ShallowReactive",2],{"seo-verification":3,"blog-أفضل-ممارسات-تحديث-docker-compose-على-vps-ar":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-أفضل-ممارسات-تحديث-docker-compose-على-vps-ar",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":109,"ctaBody":110,"ctaButton":111,"ctaUrl":112,"relatedPosts":113},427,"أفضل-ممارسات-تحديث-docker-compose-على-vps",{"fr":12,"en":13,"ar":10,"es":14},"docker-compose-mise-a-jour-best-practices-vps","docker-compose-update-best-practices-vps","docker-compose-actualizacion-buenas-practicas-vps","تحديث stack Docker Compose في الإنتاج بأمان","بروتوكول كامل لتحديث stacks Docker Compose دون توقف أو فقدان بيانات: تثبيت الإصدار، نسخ احتياطي للأقراص، والتراجع خلال دقيقتين.",9,0,false,"2026-10-09T00:00:00+00:00","2026-10-09T22:36:09+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},3,"النشر","deploiement","bg-success\u002F10 text-success",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdocker-compose-mise-a-jour-best-practices-vps-poster.svg","أمر `docker compose pull` متبوعاً بـ `up -d` كان يعمل دائماً — حتى اليوم الذي توقف فيه. التغييرات الجذرية الأخيرة في Meilisearch‏ v1.54، وSupabase‏ PostgreSQL 15→17، وLangfuse‏ v3→v4، وNocoDB 2026.09 أثبتت ذلك بشكل مؤلم — خوادم إنتاج مستقرة منذ أشهر، تعطلت بعد تحديث غير مُعدَّ له. يمنحك هذا الدليل بروتوكولاً قابلاً للتكرار: احتفظ بنسخة احتياطية قبل السحب، تحقق من ملاحظات الإصدار قبل إعادة التشغيل، وارجع إلى الصورة السابقة في أقل من دقيقتين إذا حدث خطأ.",[34,38,46,49,68,72,75,103,106],{"type":35,"title":36,"body":37},"h2","لماذا تُعدّ `latest` المشكلة الحقيقية","عندما تُحدَّث صورة Docker المُوسَمة بـ `latest` في سجل الصور، يقوم `docker compose pull` بتنزيلها بصمت. لا تحذير، لا فرق. تُعيد تشغيل الـ stack فتكتشف أن الحاوية الجديدة لا تستطيع قراءة البيانات التي تركتها القديمة.\n\nهذا بالضبط ما حدث مع **Meilisearch‏ v1.54**. قدّم هذا الإصدار تنسيق تخزين متجهات جديداً افتراضياً (الانتقال من arroy إلى HNSW) يجعل مجلد البيانات غير متوافق مع الإصدارات السابقة. عند بدء التشغيل، يرفض Meilisearch فتح قاعدة البيانات ويدخل في حلقة تعطل مستمرة. المسار الوحيد للخروج النظيف هو إنشاء dump قبل التحديث — وهو أمر مستحيل بمجرد أن تتوقف الحاوية.\n\nوسم `latest` لا يحل إلى نفس الصورة بحسب وقت السحب. مطوران يُشغّلان `docker compose pull` بفارق اثنتي عشرة ساعة قد يسحبان إصدارين مختلفين. على stack إنتاجية، هذا الغموض غير مقبول. الحل ليس تجنب التحديثات: بل **التحكم الصريح في الإصدار الذي يعمل** والقرار الواعي بموعد الانتقال إلى الإصدار التالي.",{"type":39,"title":40,"items":41},"ul","ما يغطيه هذا الدليل — وما لا يغطيه",[42,43,44,45],"**ما يغطيه هذا الدليل**: بروتوكول خطوة بخطوة لتحديث 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 وأقراص بيانات دائمة.",{"type":35,"title":47,"body":48},"الخطوة 1 — ثبّت جميع صورك","الإجراء الأول قبل أي تحديث هو استبدال كل `image: meili\u002Fmeilisearch:latest` أو `image: supabase\u002Fpostgres` بإصدار محدد.\n\nشكلان مقبولان:\n\n- **وسم الإصدار**: `image: getmeili\u002Fmeilisearch:v1.53.0` — مقروء، قابل للتتبع في git، سهل التصحيح.\n- **ملخص SHA256**: `image: getmeili\u002Fmeilisearch@sha256:abc123…` — ثابت، يضمن سحب نفس القطعة بالضبط في كل نشر، حتى لو أُعيدت كتابة الوسم.\n\nللحصول على ملخص صورة تعمل بالفعل:\n\n```bash\ndocker inspect --format='{{index .RepoDigests 0}}' getmeili\u002Fmeilisearch:v1.53.0\n```\n\nبعد تثبيت صورك، احفظ ملف `docker-compose.yml` في git. كل رفع إصدار يصبح commit واحداً — سجل واضح وتراجع سهل (`git revert` + `docker compose up -d`).",{"type":50,"title":51,"steps":52},"steps","بروتوكول التحديث — الخطوات الخمس",[53,56,59,62,65],{"title":54,"body":55},"اقرأ ملاحظات الإصدار قبل السحب","أولاً، راجع ملاحظات الإصدار الجديد. ابحث عن كلمات `breaking`، `migration`، `incompatible`، `pg_upgrade`، `dump`. هذا ليس اختيارياً: وثّق Supabase صراحةً أن الترقية من PostgreSQL 15 إلى 17 **تستلزم `pg_upgrade` يدوياً** — حاوية PG 17 ترفض الإقلاع على قرص PG 15، وعملية التهيئة لا تُهجّر البيانات تلقائياً.\n\nبالنسبة لـ Langfuse‏ v4 (الإصدار العام بتاريخ 17 أغسطس 2026)، تُرفض SDK‏ Python v2 والإصدارات الأقدم **عند الاستيعاب** من طرف الـ stack الجديدة — تغيير جذري يؤثر على جميع الخدمات العميلة التي تتتبع عبر الـ API القديمة.\n\nثلاث دقائق من القراءة توفر عليك ساعات من استعادة البيانات.",{"title":57,"body":58},"احتفظ بنسخة احتياطية للأقراص قبل السحب","لا تسحب أبداً قبل أن يكون لديك نسخة احتياطية صالحة للاستخدام. بالنسبة للأقراص المسماة، هناك مقاربتان:\n\n**تصدير تطبيقي (موصى به لقواعد البيانات)** — يجب أن تكون الخدمة في حالة `healthy` قبل التصدير:\n\n```bash\ndocker compose exec db pg_dump -U postgres -Fc mydb > backup_$(date +%Y%m%d_%H%M%S).dump\n```\n\n**لقطة قرص خام** — مفيدة للتخزينات الثنائية (Meilisearch،‏ Redis، MinIO):\n\n```bash\ndocker run --rm \\\n  --volumes-from $(docker compose ps -q meilisearch) \\\n  -v $(pwd)\u002Fbackups:\u002Fbackup \\\n  alpine tar czf \u002Fbackup\u002Fmeili_$(date +%Y%m%d_%H%M%S).tar.gz \u002Fmeili_data\n```\n\nتحقق من أن النسخة الاحتياطية قابلة للقراءة قبل المتابعة. ملف dump تالف يُكتشف أثناء الاستعادة هو أكثر السيناريوهات تكلفةً.",{"title":60,"body":61},"اسحب الصورة الجديدة واختبرها خارج الإنتاج","حدّث الوسم في `docker-compose.yml`، ثم اسحب الصورة دون إعادة تشغيل الخدمة:\n\n```bash\ndocker compose pull meilisearch\n```\n\nإذا أتاحت بيئتك ذلك، اختبر الصورة الجديدة على نسخة مستنسخة من القرص في بيئة ddev أو VM تجريبي قبل المساس بالإنتاج. تحقق من سجلات الإقلاع بحثاً عن أي أخطاء تهجير:\n\n```bash\ndocker compose up -d meilisearch\ndocker compose logs -f meilisearch\n```\n\nانتظر حتى يصل healthcheck إلى حالة `healthy` قبل التحقق من النجاح. خدمة تبدأ لكنها ليست `healthy` بعد ليست خدمة جاهزة.",{"title":63,"body":64},"تحقق من healthchecks","healthcheck مُهيَّأ جيداً هو خط الكشف الأول. يجب أن يكون موجوداً على كل خدمة حيوية في الـ stack، بصيغة Compose‏ v2:\n\n```bash\nhealthcheck:\n  test: [\"CMD-SHELL\", \"curl -sf http:\u002F\u002Flocalhost:7700\u002Fhealth || exit 1\"]\n  interval: 10s\n  timeout: 5s\n  retries: 5\n  start_period: 30s\n```\n\nحقل `start_period` حاسم للخدمات التي تستغرق وقتاً في الإقلاع (قواعد البيانات، محركات البحث): يمنع Docker من إعلان الحاوية `unhealthy` أثناء مرحلة التهيئة وتشغيل إعادة تشغيل مبكرة.\n\nراجع `docker-compose-depends-on-healthcheck` للإعداد الكامل لـ `service_healthy` على PostgreSQL — نفس المبدأ ينطبق على أي خدمة تحتاج وقتاً للتهيئة.",{"title":66,"body":67},"التراجع في حال حدوث مشكلة","إذا فشل الإصدار الجديد في الإقلاع أو أنتج أخطاء، يجب أن يستغرق التراجع أقل من دقيقتين. الإجراء:\n\n1. عُد إلى الوسم السابق في `docker-compose.yml` (أو `git revert` إذا حفظت الرفع).\n2. أعِد تشغيل الخدمة المعنية فقط، دون إعادة إنشاء الأقراص:\n\n```bash\ndocker compose up -d --no-deps --force-recreate meilisearch\n```\n\n3. تحقق من السجلات فوراً:\n\n```bash\ndocker compose logs -f meilisearch\n```\n\nعلامة `--no-deps` ضرورية: تُعيد تشغيل الخدمة المستهدفة دون المساس بالحاويات الأخرى (قاعدة البيانات، الذاكرة المؤقتة، الوكيل). بدونها، قد يُعيد `docker compose up -d` إنشاء الـ stack بأكملها.\n\n⚠️ إذا هاجر الإصدار الجديد تنسيق البيانات على القرص (Meilisearch‏ v1.54، Supabase‏ PG17)، فإن التراجع عن الصورة وحده لا يكفي — وهذا بالضبط لماذا النسخة الاحتياطية للقرص شرط مسبق لا خيار.",{"type":69,"title":70,"body":71},"tip","احتفظ بالإصدار السابق متاحاً محلياً","قبل سحب الصورة الجديدة، قم بوسم الصورة الحالية في الإنتاج باسم احتياطي:\n\n```bash\ndocker tag getmeili\u002Fmeilisearch:v1.53.0 getmeili\u002Fmeilisearch:rollback\n```\n\nيتيح لك ذلك العودة إلى الحالة الدقيقة للإنتاج في حالات الطوارئ، حتى إذا لم يعد لديك وصول إلى السجل أو كان الاتصال بطيئاً. على VPS بعرض نطاق ترددي محدود، يوفر لك هذا الوسم المحلي دقائق عدة من التنزيل في أسوأ وقت ممكن.",{"type":35,"title":73,"body":74},"التغييرات الجذرية الأخيرة التي أوقفت تشغيل الخوادم","هذه الأمثلة الأربعة توضح لماذا البروتوكول أعلاه ليس نظرياً.\n\n**Meilisearch‏ v1.53 ‎→‎ v1.54** (2026): إدخال مخزن متجهات HNSW كتنسيق افتراضي. يرفض Meilisearch فتح فهرس أُنشئ بالتنسيق القديم arroy. يدخل الإقلاع في حلقة تعطل مع رسالة `Your database version is incompatible with your current engine version`. المخرج الوحيد النظيف هو تصدير dump قبل التحديث — استيراده في الإصدار الجديد يستعيد بياناتك.\n\n**Supabase‏ Docker PostgreSQL 15 ‎→‎ 17** (التهجير نشط منذ 17 يونيو 2026): حاوية `supabase\u002Fpostgres:17` لا تستطيع قراءة قرص أُهيِّئ بواسطة PG‏ 15. وثّق Supabase صراحةً أن هذه القفزة تستلزم `pg_upgrade` عبر سكريبت مخصص — عملية تهيئة الحاوية لا تفعل ذلك تلقائياً. دون تهجير مسبق، لا تبدأ قاعدة البيانات.\n\n**Langfuse‏ v3 ‎→‎ v4** (الإصدار العام 17 أغسطس 2026): تتخلى v4 عن نقاط النهاية القديمة لاستيعاب الدفعات لصالح OpenTelemetry. تُرفض SDK‏ Python v2 والأقدم وSDK‏ JS\u002FTS v3 والأقدم **عند الاستيعاب** منذ لحظة إقلاع الـ stack‏ v4. إذا لم تُهجَّر خدماتك العميلة قبل تحديث الخادم، تفقد جميع تتبعاتها بصمت.\n\n**NocoDB‏ 2026.09.x**: تُعيد سلسلة 2026.09 بناء صور Docker للتخلص من الاعتماديات الضعيفة. التثبيتات التي تستخدم bind-mounts (`.\u002Fpostgres`، `.\u002Fnocodb`) بدلاً من أقراص مسماة قد تبدأ على قاعدة بيانات فارغة بعد السحب — لا يجد NocoDB بياناته إذا تغير مسار التحميل بين الإصدارات. يُنصح بالترحيل إلى الأقراص المسماة قبل التحديث.",{"type":76,"title":77,"headers":78,"rows":83},"comparison","استراتيجيات التحديث: مقارنة",[79,80,81,82],"الاستراتيجية","أمان البيانات","وقت التحضير","التراجع",[84,89,94,99],[85,86,87,88],"`docker compose pull` + `up -d` مباشرة","لا ضمان — التغييرات الجذرية غير مكتشفة","أقل من دقيقة","صعب في حال هجرة البيانات",[90,91,92,93],"رفع وسم مُصدَّر + نسخة احتياطية للأقراص","عالٍ — البيانات محفوظة قبل أي تغيير","10 إلى 20 دقيقة","سهل: تراجع الوسم + `up -d --no-deps`",[95,96,97,98],"اختبار على بيئة تجريبية قبل الإنتاج","أقصى مستوى — التغييرات الجذرية مكتشفة خارج الإنتاج","متغير حسب البيئة","غير ضروري إذا نجح الاختبار",[100,101,102,102],"صورة مثبتة بملخص SHA256","عالٍ — محصّن ضد إعادة كتابة الوسم","مثل وسم الإصدار",{"type":35,"title":104,"body":105},"دمج هذا البروتوكول في سير عملك","بروتوكول يبقى في دليل لا فائدة منه. لتطبيقه بشكل منهجي، أخرج الإصدار إلى ملف `.env` مُصدَّر في git:\n\n```bash\n# .env\nMEILISEARCH_VERSION=v1.53.0\nPOSTGRES_VERSION=15.6\n```\n\n```bash\n# docker-compose.yml\nservices:\n  meilisearch:\n    image: getmeili\u002Fmeilisearch:${MEILISEARCH_VERSION}\n```\n\nتحديث إصدار يصبح حينئذٍ commit واحد على `.env` — مقروء في `git log`، قابل للعكس بـ `git revert`، وقابل للنشر عبر CI\u002FCD دون تعديل ملف Compose الرئيسي.\n\nبالنسبة للوكالات التي تدير stacks متعددة لعملاء مختلفين، أنشئ ملف `CHANGELOG_INFRA.md` لكل عميل: كل تحديث موثق بالإصدار السابق، والتاريخ، والنسخة الاحتياطية المنجزة، والنتيجة. هذا أيضاً ما يحميك تعاقدياً في حال حدوث حادث لاحق.",{"type":69,"title":107,"body":108},"الأتمتة دون فقدان التحكم","إذا أردت الإخطار بالإصدارات الجديدة دون السحب التلقائي، تراقب **Diun** (Docker Image Update Notifier‏) سجلك وترسل لك إشعاراً (Slack، بريد إلكتروني، webhook) عند توفر صورة جديدة. تظل صاحب قرار موعد التحديث.\n\nهذا هو الفرق الجوهري عن Watchtower: Diun‏ تُخطر، Watchtower‏ تتصرف. على stack إنتاجية مع أقراص دائمة، الإخطار هو المستوى الصحيح من الأتمتة — الفعل يبقى يدوياً ومسبوقاً بالبروتوكول أعلاه.","VPS بوصول root لتطبيق هذا البروتوكول","تصدير كامل، لقطات قبل التحديث، تراجع إلى صورة سابقة: هذا البروتوكول يستلزم وصول root وتخزين محلي قابل للتحكم. الاستضافة المشتركة لا تمنحك هذا المستوى من التحكم في أقراص Docker.","اكتشف خطط VPS Cloud","\u002Fvps-cloud",[114,130,146],{"id":115,"slug":116,"slugs":117,"title":121,"excerpt":122,"readTime":123,"views":18,"isPinned":19,"publishedAt":124,"updatedAt":125,"category":126,"categories":127,"featuredImage":29,"bgImage":30,"posterImage":129,"relatedSolution":29},229,"docker-compose-في-الإنتاج-قائمة-التحقق-من-10-نقاط",{"fr":118,"en":119,"ar":116,"es":120},"docker-compose-production-checklist","docker-compose-in-production-10-point-checklist","checklist-docker-compose-en-produccion","Docker Compose في الإنتاج: قائمة التحقق من 10 نقاط","‏قائمة تحقق Docker Compose للإنتاج: 10 إعدادات أساسية، فحوصات صحية، أسرار بدون توقف، استراتيجية التراجع، استكشاف الأخطاء الشائعة.",12,"2026-08-06T00:00:00+00:00","2026-09-29T14:40:45+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[128],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",{"id":131,"slug":132,"slugs":133,"title":137,"excerpt":138,"readTime":139,"views":18,"isPinned":19,"publishedAt":140,"updatedAt":141,"category":142,"categories":143,"featuredImage":29,"bgImage":30,"posterImage":145,"relatedSolution":29},282,"depends-on-لا-يكفي-healthcheck-لـ-postgresql-في-compose",{"fr":134,"en":135,"ar":132,"es":136},"docker-compose-depends-on-healthcheck","depends-on-is-not-enough-postgresql-healthcheck-in-compose","docker-compose-healthcheck-postgresql","depends_on لا يكفي: healthcheck لـ PostgreSQL في Compose","لماذا لا يضمن `depends_on` وحده جاهزية PostgreSQL، وكيف تُعدّ healthcheck موثوقاً باستخدام `service_healthy` لتجنب race conditions عند الإقلاع.",8,"2026-08-19T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[144],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdocker-compose-depends-on-healthcheck-poster.svg",{"id":147,"slug":148,"slugs":149,"title":153,"excerpt":154,"readTime":155,"views":18,"isPinned":19,"publishedAt":156,"updatedAt":157,"category":158,"categories":163,"featuredImage":29,"bgImage":30,"posterImage":165,"relatedSolution":29},382,"تحديثات-أمان-تلقائية-vps-debian-ubuntu",{"fr":150,"en":151,"ar":148,"es":152},"securite-vps-mises-a-jour-automatiques-debian-ubuntu","vps-automatic-security-updates-debian-ubuntu","actualizaciones-seguridad-vps-debian-ubuntu","تحديثات الأمان التلقائية على VPS بنظام Debian\u002FUbuntu","قم بتكوين unattended-upgrades على خوادم VPS الخاصة بك لأتمتة تصحيحات الأمان وتقليل سطح الهجوم عبر أسطول عملائك.",10,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":139,"name":159,"slug":160,"color":161,"icon":162},"الأمان والمراقبة","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[164],{"id":139,"name":159,"slug":160,"color":161,"icon":162},"\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg",1791585578215]