هل يمكن لمشروعين من Compose مشاركة حاوية قاعدة بيانات واحدة بأمان؟
نعم، عندما تكون قاعدة البيانات متصلة بشبكة خارجية مستقرة، وتوجد قواعد بيانات ومستخدمون منفصلون، وملكية واضحة لدورة الحياة، ونسخ احتياطية مستقلة عن أي من مشروعي التطبيق.
يصبح القرار مهمًا عندما ينبغي لتطبيقين مستضافين ذاتيًا إعادة استخدام حاوية PostgreSQL أو MariaDB واحدة لتوفير الذاكرة. والحالتان المتنافستان هما خدمة مشتركة مع عزل المستأجرين، وترقيات وبيانات اعتماد وإعادة تشغيل وتنافس على الموارد مترابطة. ابدأ بتهيئة محفوظة وبيانات قابلة للتخلص منها، وراقب فرعًا واحدًا في كل مرة، وتوقف إذا أدى الاختبار إلى زيادة مخاطر فقدان البيانات أو الصلاحيات أو التوافر.
حدّد الشروط الكامنة وراء قرار مشاركة خدمة قاعدة البيانات عبر مشاريع Compose
سجّل البيئة قبل تغيير أي شيء: إصدارات البرامج والبرامج الثابتة، وهويات الأجهزة، ومسار التحميل أو الشبكة، والمساحة الحرة، والصلاحيات، والعَرَض القابل للملاحظة. يجب أن يحافظ خط الأساس على تفاصيل كافية لإعادة إنتاج حالة استخدام حاوية PostgreSQL أو MariaDB واحدة من قِبل تطبيقين مستضافين ذاتيًا لتوفير الذاكرة.
المرشح الأول هو خدمة مشتركة مع عزل المستأجرين. والثاني هو ترقيات وبيانات اعتماد وإعادة تشغيل وتنافس على الموارد مترابطة. تحدد شبكات Compose الخارجية الحالية الآلية أو حدّ الأوامر المستخدم في الاختبار؛ لكنها لا تحل محل الملاحظة من هذا الخادم المنزلي المحدد.
اكتب شرط القبول وشرط التوقف قبل تشغيل الاختبار الفاصل. يجب أن يغيّر النجاح الدليل الذي يتنبأ به أحد الفرعين مع إبقاء الخدمات غير المرتبطة دون تغيير؛ ويجب أن يعيد الفشل النظام إلى الحالة المحفوظة بدلًا من إطلاق سلسلة من الإصلاحات التخمينية.
اختبر الادعاء دون خفض المتطلب الأصلي
استخدم هذا الاختبار الفاصل: صِل كل مشروع عبر شبكة خارجية، وأنشئ مستخدمين بأقل الصلاحيات، ثم أوقف أحد التطبيقين وحدّثه بينما يعمل الآخر. حافظ على ثبات حمل العمل والعميل والمسار ومجموعة الملفات والتوقيت حتى تُنسب النتيجة إلى المتغير الذي تغيّر.
استخدم دورة حياة شبكة Compose لاختيار الحقل الذي يمكنه فعليًا فصل الفرعين، ثم التقط طابعه الزمني، وحالة الخروج، ونص الخطأ، وهوية الجهاز أو اللقطة، وزمن الاستجابة، والبايتات المنقولة، والصلاحيات، وحالة الاسترداد. لا تكفي نهاية الأمر بنجاح عندما تكون الهوية أو المتانة أو حالة التطبيق هي الادعاء قيد الاختبار.
كرّر الاختبار مرة واحدة بعد إعادة التشغيل أو إعادة الاتصال أو إعادة التحميل أو استخدام ذاكرة تخزين مؤقت باردة عندما يكون ذلك الحدث جزءًا من الشرط الأصلي. إذا كان التشغيل الأول إتلافيًا أو تعذرت استعادة البيئة، فتوقف وأعد الإنتاج على نسخة قابلة للتخلص منها بدلًا من ذلك.
networks:
database-net:
external: true
# تعود دورة حياة قاعدة البيانات إلى مشروع بنية تحتية منفصلفسّر نتائج النجاح والفشل والاستثناء
نجاح: يصل كل تطبيق إلى مخططه أو قاعدة بياناته فقط، ويمكن لمشروع واحد إعادة النشر دون إعادة إنشاء قاعدة البيانات المشتركة. سجّل الإصدار والهوية وحمل العمل الدقيق الذي نجح حتى يظل الاستنتاج مشروطًا بدلًا من أن يتحول إلى ادعاء شامل.
فشل: يزيل Compose down الحالة المشتركة، أو يستطيع مستخدم واحد قراءة قاعدة بيانات مستخدم آخر، أو تؤثر عمليات الترحيل وارتفاعات الموارد في كليهما. لا يثبت الفشل تلقائيًا الفرع المقابل عندما يمكن للشبكة أو الذاكرة أو الصلاحيات أو اتساق المصدر أن تؤثر في كليهما؛ اعزل تلك التبعيات المشتركة قبل التصعيد.
نتيجة استثنائية أو ملتبسة: افصل قواعد البيانات أو انشر مشروع Compose مخصصًا للبنية التحتية يتولى الخدمة المشتركة. احتفظ بالسجلات، ولا تشغّل أوامر الإصلاح أو التنظيف أو الإتلاف أو إعادة التقسيم أو الملكية التكرارية حتى تتوفر نسخة قابلة للاسترداد.
أكّد القرار تحت حمل العمل الأصلي
طبّق الإجراء المطابق للفرع المرصود، ثم كرّر الشرط الأصلي بدلًا من بديل مخفّض. لا يصح القرار إلا عندما يصل كل تطبيق إلى مخططه أو قاعدة بياناته فقط، ويمكن لمشروع واحد إعادة النشر دون إعادة إنشاء قاعدة البيانات المشتركة خلال دورتين أو أثناء إعادة التشغيل أو السكون أو الانقطاع أو انتقال الحمل ذي الصلة.
استخدم شبكات Docker المخصصة للتحقق من أقرب سير عمل تابع، لكن أبقِ المحفز الأصلي دون تغيير. يجب أن تحتفظ مجموعات البيانات والمشاركات والحاويات والمستخدمون ونقاط الاسترداد غير المرتبطة بصلاحياتها وتوقيتها السابقين.
حد التوقف صريح: إذا أزال Compose down الحالة المشتركة، أو استطاع مستخدم واحد قراءة قاعدة بيانات مستخدم آخر، أو أثرت عمليات الترحيل وارتفاعات الموارد في كليهما، فارجع إلى آخر تهيئة تم التحقق منها، واحتفظ بالأدلة، ولا تصعّد إلى اختبار أعمق للمنصة أو الأجهزة إلا عندما يكون الفرع قابلًا للتكرار.
بعد ثبات النتيجة المستهدفة، قارنها مع سياسات إعادة تشغيل الخدمة حتى لا ينقل الإصلاح المخاطر إلى خدمة مجاورة. يظل اختبار الهدف الناجح تغييرًا فاشلًا إذا نتج عنه عطل جديد في النسخ الاحتياطي أو الهوية أو المهلة أو التوافر.
الأسئلة الشائعة
بالنسبة إلى خدمة قاعدة البيانات المشتركة عبر مشاريع Compose، تتعلق عمليات البحث المتبقية عادةً بما إذا كان يمكن لـ depends_on إدارة قاعدة بيانات في مشروع آخر، وما إذا كان ينبغي للتطبيقين مشاركة مستخدم قاعدة بيانات واحد، ومن يتولى نسخ قواعد البيانات الاحتياطية وتحديثاتها. تُبقي الإجابات أدناه هذه الحالات الطرفية منفصلة عن القرار الأساسي.
لا يتغير حد القبول: يصل كل تطبيق إلى مخططه أو قاعدة بياناته فقط، ويمكن لمشروع واحد إعادة النشر دون إعادة إنشاء قاعدة البيانات المشتركة. إذا غيّر شرط لاحق نظام الملفات أو الهوية أو مسار الشبكة أو إصدار التطبيق، فأعد تنفيذ الاختبار الفاصل المتأثر بذلك التغيير فقط.
توقف عن توسيع التجربة عندما يزيل Compose down الحالة المشتركة، أو يستطيع مستخدم واحد قراءة قاعدة بيانات مستخدم آخر، أو تؤثر عمليات الترحيل وارتفاعات الموارد في كليهما. عندها افصل قواعد البيانات أو انشر مشروع Compose مخصصًا للبنية التحتية يتولى الخدمة المشتركة؛ واحتفظ بالأدلة قبل التصعيد إلى مالك المنصة أو التخزين أو الأجهزة.
هل يستطيع depends_on إدارة قاعدة بيانات في مشروع آخر؟
ليس مباشرةً عبر نماذج المشاريع المستقلة؛ استخدم فحوصات الصحة وإعادة المحاولة من التطبيق بدلًا من ذلك.
هل ينبغي للتطبيقين مشاركة مستخدم قاعدة بيانات واحد؟
لا. استخدم بيانات اعتماد منفصلة ومنحًا بأقل الصلاحيات لأغراض التدقيق والاحتواء.
من يتولى النسخ الاحتياطية والتحديثات لقاعدة البيانات؟
مالك أو مشروع بنية تحتية مخصص، وليس أي تطبيق يبدأ تشغيله أولًا.
بالنسبة إلى خدمة قاعدة البيانات المشتركة عبر مشاريع Compose، تظل الإجابة العملية مشروطة: يصل كل تطبيق إلى مخططه أو قاعدة بياناته فقط، ويمكن لمشروع واحد إعادة النشر دون إعادة إنشاء قاعدة البيانات المشتركة. عندما يزيل Compose down الحالة المشتركة، أو يستطيع مستخدم واحد قراءة قاعدة بيانات مستخدم آخر، أو تؤثر عمليات الترحيل وارتفاعات الموارد في كليهما، افصل قواعد البيانات أو انشر مشروع Compose مخصصًا للبنية التحتية يتولى الخدمة المشتركة؛ فالنجاح الجزئي الذي لا يصمد أمام حمل العمل الأصلي لا يُعد توافقًا.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
هل يمكنك استبدال مروحة حاسوب صغير صاخبة من دون تغيير التحكم الحراري؟
نعم - إذا كان البديل متوافقًا مع الواجهة الكهربائية وتدفق الهواء وإشارات التغذية الراجعة؛ فتوافق الموصل وحده لا يحافظ على التحكم الحراري.
هل يمكن للخادم المنزلي استئناف تشغيل الخدمات بترتيب التبعية بعد استعادة الطاقة عبر مزود الطاقة غير المنقطع؟
نعم - استخدم تبعيات تشغيل صريحة وفحوصات الجاهزية؛ إذ إن سياسات إعادة التشغيل وحدها لا تضمن أن تصبح الخدمات قابلة للاستخدام بالترتيب الصحيح.
هل يمكنك استخدام ميزة التنبيه عبر الشبكة المحلية (Wake-on-LAN) بعد انقطاع كامل للطاقة؟
أحيانًا - يحتاج WOL إلى طاقة الاستعداد وحالة البرنامج الثابت/بطاقة الشبكة لاستعادة التشغيل بعد عودة التيار المتردد؛ ولا يمكنه إيقاظ الجهاز أثناء انقطاع الطاقة.
