كيفية فصل ترحيلات قاعدة البيانات عن بدء تشغيل التطبيق أثناء عمليات نشر الحاويات

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

يسهل منع عمليات ترحيل قاعدة البيانات المكررة عندما تُنفَّذ تغييرات المخطط كخطوة نشر صريحة واحدة بدلًا من تنفيذها عند بدء تشغيل كل حاوية تطبيق.

يتمثل التصميم الوقائي في منح عمليات الترحيل مسؤولًا واحدًا، ومجموعة بيانات اعتماد واحدة، وإشارة اكتمال واحدة قبل أن تبدأ النسخ المتماثلة الجديدة في استقبال حركة المرور. أبقِ حاويات الويب والعمال حرة في إعادة التشغيل دون الحصول على صلاحيات تغيير المخطط، واجعل عملية النشر تنتظر نجاح مهمة الترحيل، وصمّم تغييرات المخطط بحيث يمكن للإصدارين القديم والجديد من التطبيق التعايش لفترة وجيزة. وبذلك تُزال حالة السباق بدلًا من الاكتفاء بالأمل في أن تلاحظ كل نسخة متماثلة سجل الترحيل نفسه أولًا.

أزل أوامر الترحيل من بدء تشغيل التطبيق المعتاد

افحص نقطة دخول الصورة، وأمر Compose، وأمر العامل، وغلاف فحص الصحة، وبرنامج النشر النصي بحثًا عن استدعاءات الترحيل التلقائية. ينبغي أن يتمكن التطبيق من إعادة التشغيل دون تعديل المخطط، ما لم تكن إعادة التشغيل تلك هي خطوة الترحيل المختارة عمدًا.

توضح مقالة نشر من Octopus أن عمليات الترحيل تحتاج إلى دورة حياة منفصلة بدلًا من ربطها ببدء تشغيل كل عملية من عمليات الخدمات المصغرة.

أبقِ ملف الترحيل التنفيذي متاحًا حيث يلزم، لكن لا تستدعِه من نقطة دخول الويب ومن مهمة ثانية في الوقت نفسه. فوجود مسؤول واحد أسهل في التدقيق من عدة مسارات لبدء التشغيل تعتمد جميعها على أقفال الإطار البرمجي.

شغّل مهمة ترحيل واحدة قبل النشر

أنشئ مهمة تُنفَّذ مرة واحدة، وتستخدم ملفات الترحيل نفسها المضمنة في الإصدار، ولا تنتهي بنجاح إلا بعد وصول قاعدة البيانات المستهدفة إلى حالة المخطط المتوقعة. واجعل نشر التطبيق يعتمد على هذه النتيجة.

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

لا توسّع نطاق مهمة الترحيل كما تفعل مع خدمة التطبيق. ينبغي أن يكون للمهمة مسؤول تنفيذ واحد لكل قاعدة بيانات مستهدفة، ومهلة زمنية محددة، وسجلات، وحالة فشل واضحة تمنع الإصدار الجديد من التطبيق.

اربط بدء تشغيل التطبيق بنجاح الترحيل

أبقِ حاويات الويب والعمال الجديدة في وضع انتظار حتى تُبلغ مرحلة الترحيل عن نجاحها، لكن لا تجعل كل حاوية منتظرة تعيد تنفيذ الترحيل بنفسها. فالاعتماد يكون على النتيجة، لا على تنفيذ تغيير المخطط مرة أخرى.

يستخدم نمط النشر الذي يقدمه Andrew Lock انتظار حاويات التطبيق للترحيل مع إبقاء منطق الترحيل مركزيًا.

بالنسبة إلى حزمة صغيرة على خادم منزلي، يمكن تطبيق المبدأ نفسه باستخدام خدمة Compose مخصصة وبرنامج نشر نصي مُدار. أبقِ الآلية بسيطة بما يكفي لإيقاف النشر بوضوح عند فشل الترحيل.

استخدم تغييرات مخطط متوافقة مع الإصدارات السابقة أثناء فترة التعايش

قد تشغّل عمليات النشر التدريجية مؤقتًا إصدارات قديمة وجديدة من التطبيق على قاعدة بيانات واحدة. تجنب ترحيلًا يزيل حقلًا أو يعيد تسميته قبل أن يتوقف الإصدار القديم عن استخدامه.

يوصي دليل حديث للترحيل دون توقف بالتوسيع قبل التقليص، بحيث تُطبَّق تغييرات المخطط الإضافية قبل التنظيف التدميري.

قسّم التغييرات الكبيرة إلى مراحل التوسيع، والملء الخلفي، والتبديل، والتقليص عند الحاجة. يجب ألا تنشئ مهمة الترحيل مخططًا لا يفهمه إلا الإصدار الجديد من الحاوية بينما لا تزال النسخ القديمة تستقبل الطلبات.

أبقِ بيانات اعتماد الترحيل خارج نسخ التطبيق المتماثلة

استخدم، متى أمكن، حساب قاعدة بيانات يمتلك صلاحيات تغيير المخطط لمرحلة الترحيل التي تُنفَّذ مرة واحدة فقط. وينبغي أن تلتزم حاويات التطبيق العادية بصلاحيات القراءة والكتابة المحدودة اللازمة لبيانات التطبيق.

تصف مقالة نشر من Liquibase أن تغييرات قاعدة البيانات تنتمي إلى الأتمتة مع تطبيق تغييرات مضبوط وقابل للتكرار.

يقلل هذا الفصل احتمال تنفيذ الترحيل عن طريق الخطأ حتى عند إعادة تشغيل عملية التطبيق أو تكرارها. خزّن بيانات الاعتماد ذات الصلاحيات المرتفعة في مسار أسرار النشر بدلًا من بيئة الخدمة العادية طويلة التشغيل.

تحقق من أن النشر لا يستطيع تطبيق الدفعة مرتين

اختبر عملية النشر على قاعدة بيانات مؤقتة أو لقطة مستعادة، وذلك ببدء عدة نسخ متماثلة من التطبيق، وإعادة تشغيلها، وإعادة تنفيذ أمر النشر. ينبغي أن تُبلغ مرحلة الترحيل عن حالة المخطط الحالية دون تغييرها مرة ثانية.

تلخص JetBrains القاعدة التشغيلية بعبارة تشغيل الترحيلات كخطوة نشر قبل بدء تشغيل التطبيق المعتاد.

تكتمل سياسة الوقاية عندما لا تتمكن إعادة تشغيل التطبيق من تعديل المخطط، ويمنع ترحيل واحد فاشل الإصدار، ويترك تكرار تنفيذ النشر قاعدة البيانات دون تغيير. وتُعد مقالة ZimaSpace ذات الصلة حول تشخيص الترحيل المكرر مسار التعافي إذا كان التنفيذ المكرر قد حدث بالفعل.

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.