Échec de la reconstruction de Discourse pendant le bootstrap : timeout HTTPS Git, recherche d'une solution de contournement propre basée sur SSH

Soutien
1

Bonjour,

Je exécute une installation standard de Discourse auto-hébergée sous Ubuntu en utilisant la configuration officielle discourse_docker.

Environnement

  • Ubuntu Server
  • Docker
  • discourse_docker officiel
  • Installation en conteneur unique (app.yml)
  • Reconstruction effectuée via :
cd /var/discourse
./launcher rebuild app

Problème

Le processus de reconstruction échoue lors de la phase de bootstrap lorsque Discourse tente de mettre à jour le code source de l’application depuis GitHub.

L’échec se produit à :

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

et génère :

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

suivi de :

FAILED
bootstrap failed with exit code 128

Constats importants

GitHub est accessible via HTTPS

Sur l’hôte :

curl -I https://github.com

termine correctement.

De même :

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

termine correctement.

Git sur HTTPS est peu fiable dans mon environnement

Dans l’environnement Discourse :

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

échoue avec :

SSL connection timeout

D’après mes investigations, cela semble être dû à des problèmes de connectivité de mon fournisseur d’accès Internet vers GitHub sur HTTPS. Pour l’instant, je ne cherche pas à résoudre ce problème réseau lui-même. Je cherche plutôt un moyen d’effectuer les reconstructions de Discourse en utilisant SSH, car la connectivité SSH vers GitHub fonctionne correctement dans mon environnement.

L’authentification SSH sur GitHub fonctionne

J’ai généré une nouvelle clé SSH, l’ai ajoutée à GitHub et vérifié l’authentification :

ssh -T git@github.com

renvoie :

Hi <username> ! Vous vous êtes authentifié avec succès, mais GitHub ne fournit pas d'accès au shell.

De plus :

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

fonctionne correctement depuis l’hôte.

URLs du dépôt

Sur l’hôte, j’ai modifié /var/discourse pour utiliser SSH :

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

et les opérations Git fonctionnent.

Cependant, à l’intérieur du conteneur de l’application Discourse :

cd /var/www/discourse
git remote -v

affiche :

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

Ainsi, lors du bootstrap, Discourse tente toujours d’utiliser HTTPS.

Ce que je souhaite accomplir

Mon objectif principal est de rendre les reconstructions de Discourse fiables dans un environnement où les connexions HTTPS vers GitHub sont instables ou échouent fréquemment par délai d’attente.

Je souhaiterais savoir :

  1. Existe-t-il une méthode officiellement supportée pour que le bootstrap et la reconstruction de Discourse utilisent GitHub via SSH au lieu de HTTPS ?
  2. Si non, quelle est l’approche recommandée pour les environnements où Git sur HTTPS est peu fiable mais où SSH fonctionne correctement ?
  3. Existe-t-il une méthode supportée pour injecter des identifiants SSH lors de la phase de bootstrap/construction ?
  4. Quelqu’un a-t-il réussi à configurer discourse_docker pour récupérer les mises à jour du code source de Discourse via SSH ?

Je privilégie une solution qui survive aux futures mises à niveau, mais je suis également intéressé à comprendre si la récupération via SSH pendant le bootstrap est techniquement supportée.

Toute orientation serait grandement appréciée.

Merci.

2

Le HTTPS sortant est-il bloqué d’une manière ou d’une autre ?

Il ne sera pas facile de réécrire tous les éléments qui s’attendent à pouvoir utiliser HTTPS. J’ai peur que la solution réside dans le fait d’avoir un réseau fiable.

3

Merci pour ces précisions, Jay.

Après des diagnostics supplémentaires, il semble que le HTTPS sortant ne soit pas bloqué sur l’hôte lui-même — les requêtes curl directes vers GitHub et raw.githubusercontent.com aboutissent de manière constante. Le problème ne se manifeste que dans le conteneur d’initialisation, où git ls-remote via HTTPS rencontre occasionnellement des délais d’attente SSL. L’accès à GitHub en SSH reste entièrement fiable, c’est pourquoi j’avais initialement envisagé la possibilité d’utiliser un chemin SSH propre lors de l’initialisation.

Ton argument concernant la difficulté de réécrire tous les composants qui supposent l’utilisation du HTTPS est tout à fait fondé. Étant donné que les échecs du HTTPS sont liés à une instabilité de la route de mon FAI vers GitHub, et non à un pare-feu local ou à un problème de réseau Docker, je vais me concentrer sur la stabilisation du chemin réseau amont plutôt que de tenter de modifier le processus d’initialisation.

Merci encore pour tes conseils et pour avoir clarifié les contraintes liées à l’utilisation du HTTPS dans la chaîne de construction.

4

Je pense qu’il est possible de configurer un proxy, donc peut-être que vous pourriez en utiliser un qui évite de passer par le réseau de votre FAI. Il semble plus facile de changer de FAI, mais la vie n’est souvent pas aussi simple qu’on le souhaite.