La reconstrucción de Discourse falla durante el bootstrap: tiempo de espera de Git HTTPS, buscando un método alternativo limpio basado en SSH

Soporte
1

Hola,

Estoy ejecutando una instalación estándar de Discourse autoalojada en Ubuntu utilizando la configuración oficial discourse_docker.

Entorno

  • Ubuntu Server
  • Docker
  • discourse_docker oficial
  • Instalación de un solo contenedor (app.yml)
  • Reconstrucción realizada mediante:
cd /var/discourse
./launcher rebuild app

Problema

El proceso de reconstrucción falla durante la fase de arranque (bootstrap) cuando Discourse intenta actualizar el código fuente de la aplicación desde GitHub.

El error ocurre en:

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

y produce:

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

seguido de:

FAILED
bootstrap failed with exit code 128

Hallazgos importantes

GitHub es accesible vía HTTPS

En el host:

curl -I https://github.com

funciona correctamente.

También:

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

funciona correctamente.

Git sobre HTTPS es poco fiable en mi entorno

Dentro del entorno de Discourse:

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

falla con:

SSL connection timeout

Según mi investigación, esto parece ser causado por problemas de conectividad de mi proveedor de Internet hacia GitHub a través de HTTPS. En este momento, no estoy intentando resolver ese problema de red en sí mismo. En su lugar, busco una forma de realizar las reconstrucciones de Discourse usando SSH, ya que la conectividad SSH con GitHub funciona correctamente en mi entorno.

La autenticación SSH de GitHub funciona

Generé una nueva clave SSH, la agregué a GitHub y verifiqué la autenticación:

ssh -T git@github.com

devuelve:

Hola <usuario>! Te has autenticado correctamente, pero GitHub no proporciona acceso a la shell.

También:

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

funciona correctamente desde el host.

URLs del repositorio

En el host, cambié /var/discourse para usar SSH:

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

y las operaciones de Git funcionan.

Sin embargo, dentro del contenedor de la aplicación de Discourse:

cd /var/www/discourse
git remote -v

muestra:

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

Por lo tanto, durante el arranque (bootstrap), Discourse aún intenta usar HTTPS.

Lo que me gustaría lograr

Mi objetivo principal es hacer que las reconstrucciones de Discourse sean fiables en un entorno donde las conexiones HTTPS de GitHub son inestables o suelen tener tiempos de espera.

Me gustaría saber:

  1. ¿Existe una forma oficialmente soportada de hacer que el arranque y la reconstrucción de Discourse utilicen GitHub sobre SSH en lugar de HTTPS?
  2. Si no es así, ¿cuál es el enfoque recomendado para entornos donde Git HTTPS es poco fiable pero SSH funciona correctamente?
  3. ¿Existe un método soportado para inyectar credenciales SSH en la fase de arranque/construcción?
  4. ¿Alguien ha configurado con éxito discourse_docker para obtener actualizaciones del código fuente de Discourse a través de SSH?

Preferiría una solución que sobreviva a futuras actualizaciones, pero también me interesa entender si la obtención basada en SSH durante el arranque está técnicamente soportada.

Agradecería mucho cualquier orientación.

Gracias.

2

¿Está bloqueada la salida HTTPS de alguna manera?

No será fácil reescribir todo lo que espera poder usar HTTPS. Me temo que lo que necesitas resolver es tener una red confiable.

3

Gracias por la aclaración, Jay.

Tras realizar diagnósticos adicionales, parece que el tráfico HTTPS saliente no está bloqueado en el propio host: las solicitudes directas con curl a GitHub y a raw.githubusercontent.com tienen éxito de manera consistente. El problema solo se manifiesta dentro del contenedor de inicio, donde git ls-remote a través de HTTPS intermitentemente presenta tiempos de espera de SSL. El acceso basado en SSH a GitHub sigue siendo totalmente fiable, por lo que inicialmente exploré si era viable un camino limpio mediante SSH durante el inicio.

Tu observación sobre la dificultad de reescribir todos los componentes que asumen HTTPS es muy acertada. Dado que los fallos de HTTPS están relacionados con la inestabilidad en la ruta de mi proveedor de Internet hacia GitHub y no con un firewall local o un problema de red de Docker, me centraré en estabilizar la ruta de red superior en lugar de intentar modificar el proceso de inicio.

Gracias de nuevo por la orientación y por aclarar las restricciones en torno al uso de HTTPS en la tubería de compilación.

4

Creo que hay una forma de especificar un proxy, así que tal vez podrías apuntar a uno que evite usar la red de tu proveedor de Internet. Parece más fácil cambiar de proveedor, pero la vida a menudo no es tan sencilla como nos gustaría.