مرحبًا بالجميع.
أنا أدير مثيلًا صغيرًا جدًا من Discourse (منذ سنوات بالفعل، مع شبه انعدام المشاكل): https://discuss.cubeisland.de/.
لقد كنت أستخدم عملية النشر القياسية المعتمدة على launcher على آلة افتراضية مخصصة (على أجهزتي الخاصة في مركز بيانات). الشيء الوحيد الذي غيّرتُه على مر السنين هو الانتقال إلى قاعدة بيانات PostgreSQL مشتركة تعمل خارجيًا.
في الآونة الأخيرة، بدأت في نقل التطبيقات من الآلات الافتراضية المخصصة إلى مجموعة Docker (Docker Swarm) كخطوة تمهيدية للانتقال في النهاية إلى مجموعة Kubernetes، وذلك في المقام الأول لتوفير الموارد وجعل أجزاء من البنية التحتية أكثر “مرونة”.
اليوم هو اليوم الذي نظرت فيه إلى مثيل Discourse الصغير هذا كأحد الآلات الافتراضية القليلة المتبقية التي تعمل كتطبيقات مخصصة. “إنه يعمل بالفعل على Docker، فكم يمكن أن يكون من الصعب نشره على مجموعة Swarm؟” هكذا فكرت. ومن خلال ما قرأته، يبدو أن ذلك ممكن بالفعل. يمكنني ببساطة أخذ الصورة من المثيل الحالي قيد التشغيل، ودفعها إلى السجل الداخلي الخاص بنا، وتشغيلها في مجموعة Swarm، وستعمل كل شيء على ما يرام، وهو أمر رائع.
نظرت في ملفات launcher، وخاصة القوالب والنماذج، واستنتجت أنه قد يكون فكرة جيدة فصل Redis في مثل هذا النشر، وربما يمكنني إعداد مهمة CI لبناء صور جديدة عند إضافة إضافات أو عندما أرغب في التحديث. لذا قمت باستنساخ discourse_docker محليًا، ونسخت تعريف حاوية app.yml الخاص بي إلى النسخة المستنسخة، وحاولت تشغيل ./launcher bootstrap app لبناء صورة يمكنني بعد ذلك دفعها إلى سجلي، دون نشرها فورًا.
إلى فاجأت، حاولت السكربت الاتصال بخادم PostgreSQL “الإنتاجي” لمحاولة ترحيل قاعدة البيانات، ولحسن الحظ لم يكن لديه وصول من محطة العمل المحلية الخاصة بي.
تفحصت هنا، ويبدو أن هذا هو كيفية عمل الأمر، مما يجعلني أتساءل:
- كيف يمكنني بناء حاوية لمثيل جديد، حيث لا أملك قاعدة بيانات بعد؟ هل سأحتاج إلى إعداد قاعدة بيانات الإنتاج قبل أن أتمكن من بناء الصورة؟
- أفترض أن هذا هو الوقت الوحيد الذي يتم فيه تشغيل db:migrate، لذا إذا كان لدي عدة مثيلات متشابهة (مثل الإنتاج والاختبار)، فستحتاج إلى ترقية أحد المثيلات لبناء الصورة الجديدة، ثم لا يمكنني استخدام نفس الصورة للمثيل الثاني، حتى لو كانت الصورة متطابقة.
- كيف يمكنني بناء صور للمثيلات التي لا يكون خادم قاعدة البيانات فيها متاحًا من النظام الذي يبني الصورة (وهو أمر ليس نادرًا كما قد يبدو)؟
بعد قراءة عدة منشورات (بالتأكيد بما في ذلك هذا المنشور)، أنا أدرك تمامًا أسباب عملية البناء كما هي حاليًا، وأرى قيمتها بالنسبة لـ 99% من الأشخاص الذين ينشرون Discourse بشكل عادي على آلاتهم الافتراضية الكاملة القياسية. وأنا معتاد جدًا على نماذج الحاويات “الكل في واحد”، ولا أعترض على ذلك. في النهاية، تكمن القيمة الرئيسية لـ Docker في حقيقة أن مورد البرمجيات يمكنه إعداد تكوينات مُحسَّنة مسبقًا وتجميعها في بيئة تشغيل قابلة للتكرار، مما يلغي الحاجة إلى الكثير من المعرفة المحددة بالتطبيق من جانب العمليات. لذا أنا متحمس تمامًا لاستخدام أدواتكم المقدمة، فلماذا أتوقع من شخص آخر بناء حاويات أفضل من مورد البرمجيات نفسه؟ ولماذا أريد فصل nginx عن تطبيق Ruby عندما لا توجد فائدة تُذكر، فقط لجعل النشر أكثر “نقاءً” (مهما كان ذلك يعني…)؟
ومع ذلك، من الغريب رؤية حاوية تقوم بتعديل حالة التشغيل أثناء عدم تشغيلها تقريبًا. لقد قمت بتشغيل العديد من التطبيقات في حاويات، وقمت بتغليف العديد منها بنفسي، وبعضها لم يكن مخصصًا للعمل في حاويات من الأساس.
أول مثال يخطر ببالي، لتطبيق يتعامل مع متطلبات/مشاكل مشابهة لتلك الخاصة بـ Discourse بطريقة مماثلة، هو GitLab. بينما يقدمون الآن مخطط Helm أنيقًا لنشر Kubernetes “المفكك بالكامل” كما ينبغي، فإنني أظن (دون النظر إلى أي أرقام) أن نسبة مماثلة تبلغ 99% من منشوراتها الصغيرة والمتوسطة الحجم تستخدم صورة Docker Omnibus الخاصة بـ GitLab (أو حزمة نظام التشغيل، وهي في الأساس نفس الشيء). لديهم عملية تهيئة مماثلة، ولكنها تعتمد على Chef داخل الحاوية، ويتم تنفيذها جميعًا عند كل بدء تشغيل، وتقوم بالأشياء المعتادة مثل ترحيل قاعدة البيانات وتجميع الأصول.
نعم، قد يستغرق بدء تشغيل GitLab عدة دقائق بسبب ذلك، لكن لم يكن ذلك أبدًا مشكلة في المنشورات التي رأيتها (بعضها في شركات كبرى). خاصة مع أنظمة التنسيق الحديثة مثل Docker Swarm وKubernetes وأي شيء آخر، والتي يمكنها تشغيل ترقيات متدحرجة لك، حيث يتم إيقاف المثيل القديم فقط إذا كان المثيل الجديد يعمل وقد نجح في فحص الصحة والاستعداد. لذا قد لا تكون عملية النشر الطويلة مشكلة في الواقع. ولكن حتى بدون ترقيات متدحرجة متطورة، والتي قد تعمل أو لا تعمل، يمكنك أيضًا تجاوز الكثير من وقت التوقف في العديد من المواقف.
إذن: هل من الممكن تكوين launcher لتجاوز العمليات المعتمدة على قاعدة البيانات أثناء بناء الصورة، وبدلاً من ذلك القيام بهذه العمليات أثناء بدء تشغيل الحاوية؟
أنا بالتأكيد مستعد لاستثمار بعض الوقت في هذا بنفسي، لكن وقتي في المساء محدود، لذا فإن أي تلميحات ستكون موضع ترحيب كبير.
أنا أيضًا منفتح على عمليات مختلفة تمامًا إذا كنت تعتقد أن هذا غير منطقي أو حتى غير ممكن أو ما إلى ذلك.
شكرًا لأي تغذية راجعة!