Kuby-core: دعم الإصدارات الأخيرة من kubedb

حسنًا ، بعض السياق الإضافي هنا. اتضح أن الجزء الصعب لا يجلب ترخيصًا برمجيًا (وهو أمر ممكن ، علينا فقط مطالبة الأشخاص برمز خادم ترخيص وعنوان بريد إلكتروني وما إلى ذلك). الجزء الصعب هو _upgrading_ مشغل kubedb وقواعد البيانات الفردية. يعد إلغاء تثبيت الإصدار v0.12 أمرًا صعبًا في حد ذاته لأنك من الواضح أنك لا تريد إزالة أي مثيلات قاعدة بيانات موجودة ، لكنني في النهاية نجحت في تشغيلها. لحسن الحظ ، يعد تثبيت الإصدار v0.18 (أحدث إصدار في وقت كتابة هذا التقرير) أمرًا سهلاً للغاية مع Helm ... ولكن من الصعب للغاية ترقية مثيل Postgres أو MySQL موجود بالفعل قيد التشغيل (بدون أي توقف). فيما يلي الخطوات التي عملت بها (تقريبًا) في Postgres:

1. تأكد من إعداد db الحالي للنسخ المنطقي ، الأمر الذي يتطلب تغييرًا في مستوى WAL (سجل الكتابة المسبقة). يتطلب تعيين مستوى WAL إعادة تشغيل pg ، وبالتالي فإن أسهل طريقة للقيام بذلك هي تعيين عدد النسخ المتماثلة إلى> 1 مع إخبار kubedb في نفس الوقت باستخدام تكوين إضافي ، مما سيؤدي إلى إعادة التشغيل. تريد نسخًا متماثلة متعددة على أي حال ، لذا لا تؤدي عمليات إعادة التشغيل إلى تعطل.
2. قم بإلغاء تثبيت الإصدار القديم من مشغل kubedb وقم بتثبيت الإصدار الجديد ، مع الحرص بشكل خاص على عدم إسقاط مثيل (طبعات) قاعدة البيانات الحالية. قد يكون هذا صعبًا بعض الشيء نظرًا لأن k8s مترددة إلى حد ما في حذف Postgres CRD إذا كان لا يزال هناك مثيلات Postgres قيد التشغيل. من المنطقي. لحسن الحظ ، هناك طرق لخداع k8s لفعل ما تريد.
3. قم بإنشاء مثيل postgres جديد باستخدام WAL = منطقي وأنشئ الناشر / الفرعي الضروري بين القديم والجديد بحيث يتم نسخ أي سجلات في db القديم إلى db الجديد. كن حذرًا لإعطاء المستخدم postgres كلمة مرور في db الجديد إذا كان المستخدم الذي تستخدمه للوصول إلى db من Rails _isn't_ postgres (يستخدم Kuby root افتراضيًا) . هذا ضروري بسبب ما أعتقد أنه خطأ في نصوص kubedb الأولية. من الواضح أن هذا db الجديد له اسم مختلف عن الاسم القديم ، وهذه مشكلة. يحدد اسم db اتصال قضبان اسم DNS ، والذي لا يمكننا تغييره حقًا. همم...
4. انشر تطبيق ريلز وقم بتوجيهه بطريقة ما إلى خدمة قاعدة البيانات الجديدة.
5. احذف قاعدة البيانات القديمة
6. ربح

أنا عالق حاليًا في محاولة اكتشاف كيفية توجيه تطبيق القضبان بسهولة إلى خدمة قاعدة البيانات الجديدة. عنوان URL للخدمة مرمز بشكل أساسي ولا يمكن تغييره ديناميكيًا. علاوة على ذلك ، لا يمكن أن تحمل خدمة قاعدة البيانات الجديدة نفس الاسم الموجود حاليًا ، لذلك يتعين علينا تخزين الخدمة "الصحيحة" في مكان ما (ربما تعليق توضيحي على النشر؟) والتشاور معها في كل ... هذا عندما نعيد كتابة database.yml؟ قرف.

قد يكون الحل الآخر هو استخدام نوع من الوكيل الذي يمكنه توجيه حركة المرور ديناميكيًا إلى خدمة أو أخرى ، مثل موازن التحميل ولكن فوق الخدمات.

في حين أن kuby يمكن أن يفعل بعض الأشياء الصعبة للحصول على ترخيص تلقائيًا ، فإن هذا لا يشعر بالأخلاق بشكل خاص (أو ربما حتى قانوني؟)

Tamal رقيق جيد ولا أعتقد أنه سيهتم على الإطلاق ، طالما أنك تكشف تفاصيل ما يحدث للمستخدمين حتى لا يتفاجأوا عندما ينتهي الترخيص المؤقت في نهاية الشهر. (؟ ماذا يحدث عند انتهاء صلاحية الترخيص ، أتساءل الآن؟ إذا كان ذلك يعني إيقاف النسخ الاحتياطية ، فقد يكون ذلك سيئًا ؛ إذا كان ذلك يعني أن هناك أشياء أخرى تبدأ في الفشل ، فقد يكون ذلك سيئًا أيضًا ... إذا كان هذا يعني أنه لا يمكنك إنشاء قواعد بيانات جديدة لـ الآن ، حتى يتم تجديد الترخيص ، قد لا يكون هذا سيئًا للغاية.)

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

شكرًا لك على الإرشادات التفصيلية حول ما هو مطلوب للترقية! لدي ترخيص KubeDB الخاص بي ، والذي تم منحه بسخاء إلى Team Hephy لمجموعة الإنتاج لدينا ، ولدي قواعد بيانات قديمة بحاجة إلى ترقيات ، لم يتم بدء تشغيلها أو استضافتها من KubeDB ؛ حصلت على ترخيص لتعلم استخدام النسخ الاحتياطية لقاعدة البيانات ، ولدي كل من PostgresQL و MariaDBs ، tl ؛ لقد قمت بقطع عملي في هذا المجال أيضًا.

أنا أتعلم الآن كيفية تشغيل برنامج تخزين CSI مناسب مع مجموعة المختبر المنزلي ، وأتوقع أن يحدث هذا فرقًا كبيرًا في كيفية التعامل مع قواعد البيانات وتحسين خصائص التعافي من الكوارث لمجموعة "الإنتاج" الخاصة بي. 🎉

يمكن أن يتحول Kuby أيضًا ، على المدى الطويل ، إلى ناقل مبيعات كبير لـ KubeDB. لا أعرف كيف ستشعر حيال ذلك!