Bootstrap / reconstruire sans cloner tout à nouveau ?

L’instance Discourse est située derrière le GFW, nous utilisons donc un proxy SOCKS5 pour Git. Nous avons quelques plugins installés, donc reconstruire ou amorcer l’application clone tous ces dépôts encore et encore. Malheureusement, le clonage se termine régulièrement par un timeout, de sorte que l’ensemble du processus recommence depuis le début, même si la base de code la plus récente est déjà clonée. J’ai passé plus de 40 tentatives et perdu environ cinq heures. La dernière barrière est un sous-processus yarn à l’intérieur du conteneur, qui expire ensuite généralement, entraînant une mise à niveau échouée.

Existe-t-il un moyen de structurer app.yml afin de ne pas déclencher l’ensemble du processus de clonage des plugins ? Le clonage dans le code docker-manager et la base de code discourse ont une chance sur deux, avec un taux de succès d’environ 1/3 pour le clonage ultérieur. Je ne sais pas ce qui fait échouer le sous-processus yarn, mais pour le moment, il semble impossible de redonner vie à Discourse avec les méthodes données.

Bien sûr, j’ai été assez stupide pour invoquer launcher destroy app car je voulais l’amorcer manuellement, donc je ne peux même pas faire un launcher enter app pour essayer d’exécuter la commande yarn manuellement. Quelqu’un a-t-il des idées ? Merci pour votre contribution.

Je ne suis pas un expert en la matière, mais je pense que la solution est un proxy de mise en cache pour les éléments que vous téléchargez.

Il y a un web.china.template.yml, l’utilisez-vous ?

Bien sûr. J’utilise la source Ruby chinoise dans toutes les applications Rails, je suis content d’avoir au moins cela. Ce qui me déconcerte : tous les dépôts (y compris ceux des plugins) sont maintenant déjà clonés, seul ce sous-processus yarn invoque ce qui suit :

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

Pour une raison quelconque, le GFW n’aime pas trop de processus git clone les uns après les autres, et à un moment donné, il met fin à la connexion. Si seulement je pouvais exécuter le lanceur avec un drapeau qui dirait quelque chose comme « OK mec, le code est là, pas besoin de cloner… juste du bootstrap pour l’instant »,

Edit : C’est incroyable. Juste au moment où nous tapons, ma 78ème tentative a finalement fonctionné après 11 heures. J’ai eu recours à sshuttle, qui a également pris environ 12 tentatives, mais pour une raison quelconque, le GFW a eu pitié de ma pauvre âme.

C’est ce que ferait votre propre proxy de cache (ou du moins, je le penserais). Je regarderais squid. Ensuite, vous verriez que le lanceur est tiré de votre miroir plutôt que de la source réelle.

launcher n’a pas le code car il le clone dans un nouveau conteneur sans aucun code, c’est pourquoi il télécharge tout le code. Chaque. Fois.

Oui, nous avons une certaine expérience avec Squid dans une certaine mesure. Cela nécessite de toute façon une solution générale, car je ne peux pas passer des heures à mettre à jour manuellement Discourse à chaque fois. Pendant quelques mois, l’utilisation d’un proxy socks5 régulier avait fonctionné, mais c’est un jeu constant du “whac-a-mole” avec le GFW et l’accès à GitHub est devenu une corvée depuis début octobre. Pas étonnant qu’il y ait des tonnes de clones sur ce site gitee.com.

Merci pour l’explication concernant le lanceur, je suis plutôt stupide en ce qui concerne Docker et j’avais supposé qu’il clonait les dépôts git localement, puis les écrivait dans un conteneur.

Je vais certainement examiner les options de Squid, car cela pourrait également m’aider avec ma deuxième source de douleur : fonts.googleapis.com.

Cela ne devrait pas être des git clones mais une installation à partir du registre de paquets NPM. Il existe certainement un équivalent de bundle config mirror.https://rubygems.org https://gems.ruby-china.com/ pour NPM/Yarn.

Oh, juste après cela a suivi un sous-processus qui a cloné quelque chose et a échoué. Malheureusement, je ne peux pas reproduire le journal d’erreurs maintenant. Il avait certainement récupéré quelque chose de GitHub, car le message d’erreur était le même : erreur de négociation TLS / délai d’attente. Ce n’est pas important maintenant cependant. Habituellement, npm, pour quelque raison que ce soit, n’a jamais de délais d’attente ici. Le GFW est long et plein de mystères !

Peut-être que c’était

Tu es le meilleur ! C’est exactement ça qui a cassé ma mise à niveau.

C’est assez stable, y a-t-il une chance que nous puissions le pousser dans le registre NPM maintenant @pmusaraj ?

Ah oui, absolument, faisons cela.

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