لقد أنشأنا مستودعًا يسمى RPS Discourse Image Builder يُستخدم لإنشاء صورة Discourse OCI. أعتقد أن هذا قد يكون مفيدًا لبعض الأشخاص الذين يبحثون عن هذا. لقد فعلنا هذا بشكل أساسي حتى لا نضطر إلى انتظار نشر Discourse الذي يستغرق وقتًا طويلاً ولتكون قادرًا على تثبيت إصدارات Discourse بشكل موثوق.
لقد كتبنا نصًا برمجيًا يستخدم مستودع discourse_docker لبناء الصورة بالإصدار المستقر بأكثر طريقة عامة ممكنة.
يوجد أيضًا ملف docker-compose يقوم بتشغيل قواعد البيانات المطلوبة للبناء وصورة Discourse للاختبار وتشغيلها للتطوير المحلي. يمكن تشغيل هذا على GitLab runner باستخدام المنفذ shell، ولكنك تحتاج إلى نظام به إصدار docker-compose يدعم الملفات الشخصية.
النهج
يجب تشغيل نص البناء البرمجي ضمن خطوط أنابيب CI/CD الخاصة بنا حتى نتمكن من تحديث الإصدار بسهولة، بحيث يتم إجراء تعديلات إضافية في مستودعات مختلفة باستخدام Dockerfiles التي تستند إلى الصورة التي تم إنشاؤها بواسطة هذا المستودع.
الخلفية
Discourse هو برنامج رائع جدًا، ولكنه ليس سهل النشر وتثبيت الإصدار. يُستخدم هذا المستودع لإنشاء صورة Docker يمكن استخدامها لنشر Discourse.
المشكلة هي أن Discourse لديها طريقة فريدة جدًا لبناء صور Docker الخاصة بها. يتوقع مطورو Discourse منك بناء الصورة على الجهاز المستهدف باستخدام مستودع discourse_docker الخاص بهم.
كانت هناك مناقشات مطولة حول هذا الأمر في المنتدى، الخلاصة: يرفض مطورو Discourse الرئيسيون دعم صورة Docker عامة يمكن استخدامها لنشر Discourse. يريدون الاحتفاظ بمستودع discourse_docker باعتباره الطريقة الرسمية الوحيدة لنشر Discourse.
العيوب الرئيسية لهذا النهج هي:
من تجربتنا، لا يمكن تثبيت إصدارات Discourse بشكل موثوق.
يستغرق بناء الصورة وقتًا طويلاً، وعندما يتم بناء الصورة، لا تكون الخدمة متاحة. كما أن Discourse لديها أطول دورة تكرار DevOps من بين جميع الخدمات التي ندعمها.
تتم إدارة قواعد البيانات بطريقة مختلفة عن المشاريع المعتادة المستندة إلى Docker.
قصة النشر الرسمية لـ Discourse غير متوافقة مع سير عمل التطوير والنشر المستند إلى OCI، مثل Kubernetes أو حتى Docker-Compose.
يقوم مشغل discourse_docker بإجراء الكثير من الافتراضات حول البيئة التي يعمل فيها. على سبيل المثال، يرفض التشغيل على Podman بدون صلاحيات الجذر (rootless) مع خطأ حول وحدات التخزين المفقودة دون أن يكون قادرًا على تجاوز ذلك باستخدام وسيط أو متغير بيئة.
صحيح، نحاول جعله سهل الاستخدام لمديري المواقع من خلال “سحب وإفلات محتويات ملف zip هذا باستخدام FileZilla عبر FTP”، مع ضمان أن الجميع يشغلون إصدارات حديثة ومدعومة ومُرقّعة من جميع البرامج في المكدس، حتى قواعد بياناتهم.
نعم، تدفق المشغل (launcher) غير متوافق بشكل مباشر مع تنسيق الحاويات. ومع ذلك، يمكن جعله متوافقًا عن طريق تشغيل ./launcher bootstrap app ودفع الصورة الناتجة إلى سجل حاويات ثم تشغيل هذه الصورة عبر التنسيق.
نرحب بطلب سحب (pull request) لجعل هذا ممكنًا، حيث يبدو مفيدًا بشكل عام. pr-welcome
هذا لأن Discourse 2.8 لم يعد مدعومًا، مما يعني أننا لم نقم بنقل أحدث إصدار Ruby إليه، وهو يعمل على إصدار Ruby الذي انتهى دعمه بالفعل. لا ينبغي لأحد تشغيله في بيئة الإنتاج.
ولكن إذا حاولت تثبيت إصدار قديم جدًا، فقد لا يعمل مع الإصدارات المحدثة من صورة Discourse الأساسية. لا أتذكر أمثلة محددة، ولكن أشياء مثل إصدار قديم من Discourse لن يعمل مع Ruby 3.2، لذلك تحتاج أحيانًا إلى تثبيت discourse_docker أيضًا إذا قمت بتثبيت إصدار قديم من Discourse.
الحل الأكثر أمانًا، وفي معظم الحالات، الأقل إهدارًا هو بناء صورة ودفعها إلى مستودع بدلاً من بناء صورة جديدة في كل عملية نشر. وإذا كان لديك إضافات، فمن المحتمل أن تحتاج إلى تثبيت كل منها أيضًا.
لقد فعلت هذا لعدة عملاء لـ ECS وكذلك لـ k8s على GCP و AWS.
أنا متأكد من أنه يمكنك ذلك إذا قمت أيضًا بتثبيت discourse_docker إلى الإصدار القديم. كما ذكرت أعلاه، الأمر أكثر تعقيدًا مع الإضافات، حيث من المحتمل أن تحتاج إلى تثبيتها إلى الإصدارات القديمة أيضًا. إذا كنت تريد حقًا الاحتفاظ بالإصدارات القديمة، فإن بنائها مرة واحدة بالضبط ودفعها إلى مستودع هو الطريق الصحيح. أنا أفعل هذا مع عميل لاختبار مسارات الترقية من الإنتاج الحالي إلى الأحدث وهو يعمل بسلاسة.
