فشل إعادة بناء Discourse أثناء التمهيد: انتهاء مهلة Git HTTPS، نبحث عن حل بديل نظيف يعتمد على SSH

الدعم
1

مرحباً،

أقوم بتشغيل تثبيت قياسي لـ Discourse مستضاف ذاتياً على نظام Ubuntu باستخدام إعداد discourse_docker الرسمي.

البيئة

  • خادم Ubuntu
  • Docker
  • discourse_docker الرسمي
  • تثبيت بحاوية واحدة (app.yml)
  • تم إعادة البناء باستخدام:
cd /var/discourse
./launcher rebuild app

المشكلة

يفشل عملية إعادة البناء خلال مرحلة التمهيد (bootstrap) عندما يحاول Discourse تحديث مصدر التطبيق من GitHub.

يحدث الفشل عند:

git fetch --tags --prune-tags --prune --force origin

ويظهر الخطأ التالي:

fatal: unable to access 'https://github.com/discourse/discourse.git/': SSL connection timeout

يلي ذلك:

FAILED
bootstrap failed with exit code 128

ملاحظات هامة

يمكن الوصول إلى GitHub عبر HTTPS

على المضيف (Host):

curl -I https://github.com

تعمل بشكل صحيح.

كذلك:

curl -I https://raw.githubusercontent.com

تعمل بشكل صحيح.

Git عبر HTTPS غير موثوق في بيئتي

داخل بيئة Discourse:

git ls-remote https://github.com/discourse/discourse.git

تفشل مع:

SSL connection timeout

من خلال تحقيقي، يبدو أن هذا ناتج عن مشاكل في اتصال مزود الإنترنت الخاص بي مع GitHub عبر HTTPS. في الوقت الحالي، لا أحاول حل مشكلة الشبكة نفسها. بدلاً من ذلك، أبحث عن طريقة لإجراء عمليات إعادة بناء Discourse باستخدام SSH، حيث أن اتصال SSH بـ GitHub يعمل بشكل صحيح في بيئتي.

مصادقة SSH على GitHub تعمل

لقد ولدت مفتاح SSH جديدًا، وأضفته إلى GitHub، وراجعت المصادقة:

ssh -T git@github.com

تُرجع:

مرحباً <اسم_المستخدم>! لقد قمت بالمصادقة بنجاح، لكن GitHub لا يوفر وصولاً إلى shell.

كذلك:

git ls-remote git@github.com:discourse/discourse.git

تعمل بنجاح من المضيف.

عناوين المستودعات

على المضيف، قمت بتغيير /var/discourse لاستخدام SSH:

origin git@github.com:discourse/discourse_docker.git

وتعمل عمليات Git.

ومع ذلك، داخل حاوية تطبيق Discourse:

cd /var/www/discourse
git remote -v

تُظهر:

origin https://github.com/discourse/discourse.git

لذلك، أثناء التمهيد، يحاول Discourse استخدام HTTPS.

ما أود تحقيقه

هدفي الأساسي هو جعل إعادة بناء Discourse موثوقة في بيئة تكون فيها اتصالات GitHub عبر HTTPS غير مستقرة أو تتعطل بشكل متكرر.

أود معرفة ما يلي:

  1. هل توجد طريقة مدعومة رسميًا لجعل عملية تمهيد وإعادة بناء Discourse تستخدم GitHub عبر SSH بدلاً من HTTPS؟
  2. إذا لم تكن موجودة، ما هو النهج الموصى به للبيئات التي يكون فيها Git عبر HTTPS غير موثوق بينما يعمل SSH بشكل صحيح؟
  3. هل توجد طريقة مدعومة لحقن بيانات اعتماد SSH في مرحلة التمهيد/البناء؟
  4. هل نجح أي شخص في تكوين discourse_docker لجلب تحديثات مصدر Discourse عبر SSH؟

أفضل حل يظل ساريًا حتى بعد الترقية المستقبلية، لكنني مهتم أيضًا بفهم ما إذا كان جلب البيانات عبر SSH أثناء التمهيد مدعومًا تقنيًا.

سأقدر جدًا أي توجيه.

شكرًا لك.

2

هل تم حظر https الصادر بطريقة ما؟

لن يكون من السهل إعادة كتابة كل الأشياء التي تتوقع القدرة على استخدام https. أخشى أن ما تحتاج إلى حله هو وجود شبكة موثوقة.

3

شكرًا على التوضيح، جاي.

بعد إجراء تشخيصات إضافية، يبدو أن حركة HTTPS الصادرة من المضيف نفسه غير محظورة — إذ تنجح طلبات curl المباشرة إلى GitHub وraw.githubusercontent.com باستمرار. تظهر المشكلة فقط داخل حاوية التمهيد (bootstrap container)، حيث يواجه الأمر git ls-remote عبر HTTPS انقطاعات مؤقتة في بروتوكول SSL بشكل متقطع. يبقى الوصول إلى GitHub عبر SSH موثوقًا تمامًا، وهو السبب في أنني استكشفت في البداية إمكانية اعتماد مسار SSH نظيف أثناء عملية التمهيد.

نقطة مطروحة بشأن صعوبة إعادة كتابة جميع المكونات التي تفترض استخدام HTTPS هي نقطة صائبة. ونظرًا لأن فشل HTTPS مرتبط بعدم استقرار في مسار مزود خدمة الإنترنت (ISP) الخاص بي نحو GitHub وليس بسبب جدار حماية محلي أو مشكلة في شبكة Docker، سأركز على تثبيت مسار الشبكة العلوي (upstream) بدلاً من محاولة تعديل عملية التمهيد.

شكرًا مجددًا على التوجيه وعلى توضيح القيود المتعلقة باستخدام HTTPS في خط البناء (build pipeline).

4

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