Discourse installé dans la VM Ubuntu Server UNRAID derrière le proxy inverse NPM ne résolvant pas le nom d'hôte

Salut tout le monde ! J’ai lu divers posts ici sans succès, alors j’ai pensé expliquer ma configuration actuelle en détail dans l’espoir que quelqu’un puisse me donner des conseils pour résoudre le problème.

J’utilise actuellement un serveur Unraid. Unraid héberge des conteneurs Docker ainsi que des machines virtuelles. J’ai un Nginix Reverse Proxy Manager (NPM) qui fonctionne dans un conteneur Docker et gère les proxys inverses pour tous mes autres conteneurs Docker. Mon pare-feu est configuré pour envoyer tout le trafic WAN sur les ports 80/443 vers NPM et je redirige le trafic au sein de NPM vers mes conteneurs.

J’ai suivi le guide suivant : discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

Il indique qu’il est destiné à l’installation sur un serveur cloud, bien que le mien soit une machine bare-metal auto-hébergée.

Informations système au dimanche 28 janvier 07:35:54 UTC 2024

  Charge système :              0.5126953125
  Utilisation de / :               45.9% de 13.16 Go
  Utilisation de la mémoire :             6%
  Utilisation du swap :             0%
  Processus :                125
  Utilisateurs connectés :          0
  Adresse IPv4 pour docker0 : 172.17.0.1
  Adresse IPv4 pour enp1s0 :  10.30.20.150

J’ai démarré une VM dans Unraid, installé Ubuntu Server, défini une adresse IP statique, installé Docker et téléchargé Discourse. Lors de l’exécution de la configuration, j’obtiens l’erreur suivante.

Nom d'hôte pour votre Discourse ? [discourse.example.com] : forum.mydomain.net

Vérification de votre nom de domaine . . .
AVERTISSEMENT : Le port 443 de l'ordinateur ne semble pas accessible en utilisant le nom d'hôte :
AVERTISSEMENT : La connexion à (port 80) échoue également.

Cela suggère que forum.mydomain.net résout une adresse IP qui n'atteint pas cette machine où vous installez Discourse.

La première chose à faire est de confirmer que forum.mydomain.net résout l'adresse IP de ce serveur.
Vous faites généralement cela à l'endroit où vous avez acheté le domaine.

Si vous êtes sûr que l'adresse IP se résout correctement, il pourrait s'agir d'un problème de pare-feu.
Une recherche sur le Web pour « ouvrir les ports VOTRE SERVICE CLOUD » pourrait aider.

Cet outil est conçu uniquement pour les installations les plus standard. Si vous ne parvenez pas à résoudre le problème ci-dessus, vous devrez modifier vous-même le fichier containers/app.yml, puis taper

./launcher rebuild app

Je suis capable de pinger ma VM Ubuntu à l’adresse IP statique qui lui est attribuée, 10.30.20.150, depuis mon conteneur NPM. J’ai configuré ma configuration NPM pour cibler le port 443 HTTPS et le port 80 HTTP sur 10.30.20.150, sans succès. Lorsque la configuration échoue, il semble fermer le conteneur Discourse dans la VM ?

Y a-t-il une solution de contournement ?
Peut-être, modifier les ports de mon pare-feu pour contourner le proxy inverse et cibler directement la VM afin qu’elle puisse obtenir un certificat et exécuter le conteneur, puis une fois en cours d’exécution, pouvoir modifier manuellement le fichier config.yml pour utiliser mon proxy inverse ?
Puis-je modifier l’installation d’une manière ou d’une autre pour ne pas demander de certificat SSL, et fonctionner sur le port 80, puis gérer l’obtention d’un certificat SSL via NPM ?

Enfin, j’ai vu dans quelques posts qu’il existe une version ‘production’ et une version ‘développement’ de Discourse… il semble que la version de développement puisse être exécutée en HTML sur un port local ? Si c’est le cas, j’imagine que je pourrais facilement mettre tout derrière mon proxy inverse plus facilement… D’après ce que j’ai lu, le package de production est plus facile à maintenir à jour et peut avoir des améliorations de performance.

J’apprécierais grandement de l’aide, des commentaires ou des suggestions à ce sujet.

C’est la seule installation de production prise en charge ici.

Mais je ne suis pas convaincu que ce soit adapté à votre situation car vous avez déjà un proxy inverse.

Vous pourriez envisager d’utiliser l’image de base Discourse et de faire de l’ingénierie inverse de votre propre composition personnalisée :

https://hub.docker.com/r/discourse/base/

1 « J'aime »

Pouvez-vous supprimer dans app.yml la référence aux ports 80 et 443 avec un # ?

ce fichier se trouve-t-il dans /var/discourse/containers ? Je ne peux pas me déplacer dans ce répertoire, il est indiqué ‘permission denied’

donc le concept de base serait de modifier le Dockerfile de base de Discourse et de supprimer les lignes qui installent/configurent le reverse-proxy fourni avec le package ?

Non, je regarderais la création d’un docker compose entièrement personnalisé (ou tout autre outil d’orchestration que vous utilisez) et j’utiliserais un dockerfile personnalisé pour discourse.

Je n’ai jamais fait cela auparavant et cela semble un peu intimidant. Je n’ai aucune idée par où commencer. Je me demande si quelqu’un est déjà passé par là où je vais et a déjà fait et publié une solution.

Je me demande si faire quelque chose de similaire à ce que ce gars a fait ici pourrait isoler les conteneurs construits dans le proxy inverse afin que je puisse terminer une installation, ou résoudre correctement mon proxy inverse externe fonctionnant dans son propre conteneur Docker ?

2 « J'aime »

C’est un travail d’administrateur système avancé, mais Docker Compose, c’est un peu comme jouer avec des Legos très cool - ce n’est pas aussi difficile que ça en a l’air et il y a beaucoup d’aide sur le web.

Ce serait une excellente expérience d’apprentissage pour développer une compétence très transférable, lancez-vous !

Votre lien semble également être un autre bon endroit pour essayer.

2 « J'aime »

Oui, c’est bien ça.

Ce n’est pas si facile, cependant. Quand j’ai fait ça, j’ai quand même utilisé launcher pour construire une image, la pousser vers un dépôt, puis la lancer. Ensuite, vous devez également avoir les moyens de précompiler les assets, de migrer la base de données et peut-être d’autres choses.

Suivre la méthode « exécuter d’autres sites web » est probablement la meilleure chose à faire.

3 « J'aime »

Oui, ce n’est pas trivial, mais j’ai travaillé avec une très bonne solution Docker Compose chez un client - aucun launcher en vue !

J’ai aussi une installation de développement en cloud privé utilisant DC…

2 « J'aime »