Bootstrap / إعادة بناء دون استنساخ كل شيء مرة أخرى؟

الدعم
1

يقع مثيل Discourse خلف جدار الحماية العظيم (GFW)، لذا نستخدم وكيل SOCKS5 لـ Git. لدينا عدد قليل من الإضافات مثبتة، لذا فإن إعادة بناء التطبيق أو تهيئته تستنسخ جميع هذه المستودعات مرارًا وتكرارًا. للأسف، يؤدي الاستنساخ إلى انتهاء المهلة بانتظام، لذلك تبدأ العملية برمتها من البداية، على الرغم من أنه تم بالفعل استنساخ أحدث قاعدة تعليمات برمجية. لقد قضيت 40+ محاولة وأهدرت حوالي خمس ساعات. الحاجز الأخير هو عملية فرعية لـ yarn داخل الحاوية، والتي عادةً ما تنتهي مهلتها، مما يؤدي إلى فشل الترقية.

هل هناك أي طريقة يمكنني من خلالها هيكلة app.yml، بحيث لا أقوم على الأقل باستدعاء عملية استنساخ الإضافات بأكملها؟ يأتي الاستنساخ في كود docker-manager وقاعدة كود discourse بنسبة نجاح 50/50، مع الاستنساخ اللاحق بنسبة نجاح حوالي 1/3. لا أعرف ما الذي يتسبب في فشل العملية الفرعية لـ yarn، ولكن في الوقت الحالي يبدو أنه من غير الممكن إعادة Discourse إلى الحياة بالطرق المتاحة.

بالطبع، كنت غبيًا بما يكفي لاستدعاء launcher destroy app لأنني أردت تهيئته يدويًا، لذلك لا يمكنني حتى إجراء launcher enter app لمحاولة تشغيل أمر yarn يدويًا. هل لدى أي شخص أي أفكار؟ شكرًا لمساهماتكم.

2

لست خبيرًا في هذه الأمور، لكن أعتقد أن الحل هو وكيل تخزين مؤقت للأشياء التي تقوم بتنزيلها.

يوجد ملف web.china.template.yml، هل تستخدمه؟

3

بالتأكيد. أستخدم مصدر Ruby الصيني في جميع تطبيقات Rails، ويسعدني الحصول على ذلك على الأقل. ما يحيرني: تم استنساخ جميع المستودعات (بما في ذلك مستودعات الإضافات) بالفعل، وهذه العملية الفرعية لـ yarn تستدعي ما يلي فقط:

INFO -- : > cd /var/www/discourse && [ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache clean'

لأي سبب كان، فإن جدار الحماية العظيم (GFW) لا يحب الكثير من عمليات استنساخ git واحدة تلو الأخرى، وفي مرحلة ما ينهي الاتصال. لو كان بإمكاني فقط تشغيل المشغل بعلامة تقول شيئًا مثل “حسنًا يا صديقي، الكود موجود هنا، لا حاجة للاستنساخ… فقط قم بالتمهيد الآن”، :grinning:

تعديل: لا يصدق. بينما نكتب، نجحت محاولتي الثامنة والسبعين أخيرًا بعد 11 ساعة. لجأت إلى sshuttle، والتي استغرقت أيضًا حوالي 12 محاولة ولكن لأي سبب كان، فإن جدار الحماية العظيم قد رحمة بروحي المسكينة.

4

هذا ما سيفعله وكيل التخزين المؤقت الخاص بك (أو هكذا أعتقد). سألقي نظرة على squid. بعد ذلك، سترى أن المشغل تم سحبه من النسخة المتطابقة الخاصة بك بدلاً من المصدر الفعلي.

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

5

نعم، لدينا بعض الخبرة مع Squid إلى حد معين. هذا يحتاج إلى حل عام على أي حال، حيث لا يمكنني قضاء ساعات في ترقية يدوية لـ Discourse في كل مرة. لبضعة أشهر، كان استخدام وكيل socks5 عادي يعمل، ومع ذلك فهي لعبة مستمرة من ضرب الخلد مع GFW وأصبح الوصول إلى GitHub عبئًا منذ بداية أكتوبر. لا عجب أن هناك أطنانًا من النسخ المستنسخة على هذا الموقع gitee.com.

شكرًا على الشرح بخصوص المشغل، أنا غبي جدًا عندما يتعلق الأمر بـ Docker وافترضت أنه يستنسخ مستودعات git محليًا، ثم يكتبها فوق بعض الحاويات.

سألقي بالتأكيد نظرة على خيارات Squid، حيث قد يساعد هذا أيضًا في مصدر ألمي الثاني: fonts.googleapis.com

إعجاب واحد (1)
6

لا ينبغي أن تكون استنساخ git بل تثبيت من سجل حزم NPM. بالتأكيد قد يكون هناك ما يعادل bundle config mirror.https://rubygems.org https://gems.ruby-china.com/ لـ NPM/Yarn.

إعجاب واحد (1)
7

حسنًا، تبع ذلك مباشرة بعض العمليات الفرعية التي استنسخت شيئًا ما وفشلت. للأسف لا يمكنني إعادة إنتاج سجل الخطأ الآن. لقد سحبت شيئًا ما من GitHub بالتأكيد، حيث كانت رسالة الخطأ هي نفس خطأ مصافحة TLS / المهلة. لكنه ليس مهمًا الآن. عادةً ما لا تواجه npm أبدًا مهلات هنا لأي سبب كان. جدار الحماية العظيم طويل ومليء بالأسرار!

إعجابَين (2)
8

ربما كان

إعجاب واحد (1)
9

أنت الرجل! هذا بالضبط ما أفسد ترقيتي.

إعجابَين (2)
10

هذا مستقر جدًا، هل هناك فرصة لدفع ذلك إلى سجل NPM الآن @pmusaraj؟

3 إعجابات
11

نعم بالتأكيد، لنفعل ذلك.

إعجابَين (2)
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.