Bootstrap / neu aufbauen, ohne alles noch einmal zu klonen?

Unterstützung
1

Die Discourse-Instanz befindet sich hinter der GFW, daher verwenden wir einen SOCKS5-Proxy für Git. Wir haben einige Plugins installiert, sodass entweder das Neuerstellen oder das Bootstrapping der App diese Repositories immer wieder klont. Leider schlägt das Klonen regelmäßig mit einem Timeout fehl, sodass der gesamte Prozess von vorne beginnt, obwohl die aktuellste Codebasis bereits geklont wurde. Ich habe über 40 Versuche unternommen und etwa fünf Stunden verschwendet. Die letzte Hürde ist ein Yarn-Subprozess innerhalb des Containers, der dann normalerweise mit einem Timeout abbricht, was zu einem fehlgeschlagenen Upgrade führt.

Gibt es eine Möglichkeit, wie ich die app.yml strukturieren kann, damit zumindest der gesamte Klonprozess für Plugins nicht ausgelöst wird? Das Klonen in den Docker-Manager-Code und die Discourse-Codebasis hat eine Erfolgschance von 50/50, mit einer Erfolgsquote von etwa 1/3 für das anschließende Klonen. Ich weiß nicht, was den Fehler im Yarn-Subprozess verursacht, aber im Moment scheint es nicht möglich zu sein, Discourse mit den gegebenen Methoden wieder zum Laufen zu bringen.

Natürlich war ich dumm genug, launcher destroy app aufzurufen, da ich es manuell bootstrappen wollte, sodass ich nicht einmal launcher enter app ausführen kann, um zu versuchen, den Yarn-Befehl manuell auszuführen. Hat jemand Ideen? Vielen Dank für Ihre Beiträge.

2

Ich bin kein Experte auf diesem Gebiet, aber ich denke, die Lösung ist ein Caching-Proxy für die Dinge, die Sie herunterladen.

Es gibt eine web.china.template.yml, verwenden Sie diese?

3

Natürlich. Ich verwende die chinesische Ruby-Quelle in allen Rails-Anwendungen, das ist zumindest erfreulich. Was mich verwirrt: Alle Repos (auch die der Plugins) sind jetzt bereits geklont, nur dieser Yarn-Subprozess ruft Folgendes auf:

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

Aus irgendeinem Grund mag die GFW nicht zu viele Git-Klonprozesse nacheinander und unterbricht irgendwann die Verbindung. Wenn ich den Launcher nur mit einem Flag ausführen könnte, das sagt: „Okay, der Code ist da, kein Klonen nötig… nur Bootstrapping für jetzt“, :grinning:

Bearbeitet: Es ist unglaublich. Gerade als wir tippen, hat mein 78. Versuch nach 11 Stunden endlich geklappt. Ich habe auf sshuttle zurückgegriffen, was auch etwa 12 Versuche dauerte, aber aus irgendeinem Grund hatte die GFW Mitleid mit meiner armen Seele.

4

Das würde Ihr eigener Caching-Proxy tun (oder das denke ich zumindest). Schauen Sie sich squid an. Dann würden Sie sehen, dass der Launcher von Ihrem Spiegel und nicht von der eigentlichen Quelle gezogen wird.

launcher hat den Code nicht, weil er ihn in einen neuen Container klont, ohne den Code, weshalb er jedes Mal den gesamten Code herunterlädt. Jedes. Mal.

5

Ja, wir haben bis zu einem gewissen Grad Erfahrung mit Squid. Dies erfordert sowieso eine allgemeine Lösung, da ich nicht jedes Mal Stunden mit einem manuellen Discourse-Upgrade verbringen kann. Einige Monate lang funktionierte ein regulärer SOCKS5-Proxy, doch es ist ein ständiges Katz-und-Maus-Spiel mit der GFW und der Zugriff auf GitHub ist seit Anfang Oktober mühsam geworden. Kein Wunder, dass es auf dieser gitee.com-Seite Unmengen von Klonen gibt.

Danke für die Erklärung zum Launcher, ich bin ziemlich dumm, was Docker angeht, und hatte angenommen, dass es die Git-Repos lokal klont und sie dann in einen Container schreibt.

Ich werde mir auf jeden Fall die Squid-Optionen ansehen, da dies auch bei meiner zweiten Schmerzquelle helfen könnte: fonts.googleapis.com

1 „Gefällt mir“
6

Das sollte kein git clones sein, sondern eine Installation aus dem NPM-Paket-Repository. Sicherlich gibt es ein Äquivalent zu bundle config mirror.https://rubygems.org https://gems.ruby-china.com/ für NPM/Yarn.

1 „Gefällt mir“
7

Oh, direkt danach folgte ein Subprozess, der etwas geklont hat und fehlgeschlagen ist. Leider kann ich das Fehlerprotokoll jetzt nicht mehr reproduzieren. Es hat definitiv etwas von GitHub gezogen, da die Fehlermeldung die gleiche TLS-Handshake-Fehler/Timeout war. Es ist aber jetzt nicht mehr wichtig. Normalerweise hat npm aus irgendeinem Grund hier nie Timeouts. Die GFW ist lang und voller Geheimnisse!

2 „Gefällt mir“
8

Vielleicht war es

1 „Gefällt mir“
9

Du bist der Mann! Genau das hat mein Upgrade kaputt gemacht.

2 „Gefällt mir“
10

Das ist ziemlich verdammt stabil, gibt es eine Chance, dass wir es jetzt im NPM-Registry veröffentlichen können, @pmusaraj?

3 „Gefällt mir“
11

Ja, auf jeden Fall, machen wir das.

2 „Gefällt mir“
12

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