Vous devez vous assurer que les deux conteneurs sont sur le même réseau Docker. Si NPM ne fonctionne pas, vous n’avez pas (encore) de problème de configuration Discourse.
1 « J'aime »
j’ai oublié par erreur le réseau docker maria db ; mais après avoir ajouté
network_mode: bridge
j’obtiens toujours une erreur npm pour me connecter à la base de données discourse ;
environment:
DB_MYSQL_HOST: "172.17.0.2" # conteneur de données - mais je reçois une erreur ( error connect ECONNREFUSED 172.17.0.2:3306 ) lorsqu'il est activé.
# DB_MYSQL_HOST: "db" base de données npm par défaut (en dehors de discourse).
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "h4xb0xr1z__0k"
DB_MYSQL_NAME: "npm"
quand npm et maria sont opérationnels ; les logs de maria sont bons… mais npm
error connect ECONNREFUSED 172.17.0.2:3306
quelque chose manque ?
1 « J'aime »
mon fichier docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
network_mode: bridge
restart: unless-stopped
ports:
- '80:80' # Port HTTP public
- '443:443' # Port HTTPS public
- '81:81' # Port Web d'administration
environment:
DB_MYSQL_HOST: "172.17.0.2" # conteneur de données - mais je reçois une erreur ( connect ECONNREFUSED 172.17.0.2:3306 ) lorsqu'il est activé.
# DB_MYSQL_HOST: "db" base de données npm par défaut (en dehors de discourse).
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "mypassword"
DB_MYSQL_NAME: "npm"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
# depends_on:
# - db
db:
image: 'mariadb:latest'
restart: unless-stopped
network_mode: bridge
environment:
MYSQL_ROOT_PASSWORD: 'mypassword'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'mypassword'
volumes:
- ./data/mysql:/var/lib/mysql
j’ai discourse en cours d’exécution avec data + web-only ; la carte des adresses IP après npm et maria est la suivante :
IP du conteneur de données : 172.17.0.2
IP du conteneur web_only : 172.17.0.3
IP du conteneur npm : 172.17.0.5
IP des données Maria (npm) : 172.17.0.4
1 « J'aime »
Salut @tophee
Pouvez-vous nous donner votre recommandation sur l’utilisation de SQLite avec NPM, car il est plus facile et plus fiable de travailler avec que les problèmes de mariadb ;
J’ai configuré NPM avec SQLite et tout fonctionne bien, l’hôte virtuel nginx, le ssl, etc… mais je veux m’assurer comment connecter la base de données de discourse avec NPM ? puisque j’obtiens une erreur 502 pour la configuration NPM avec le site discourse.
mon docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: always
network_mode: bridge #-- ce réseau a été ajouté pour permettre à NPM d'être dans le même réseau discourse, et ils se voient maintenant.
ports:
# Port HTTP public :
- '80:80'
# Port HTTPS public :
- '443:443'
# Port Web d'administration :
- '81:81'
environment:
DB_SQLITE_FILE: "/data/database.sqlite"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
Non, ma recommandation est d’utiliser la configuration standard de NPM à moins que vous ne sachiez ce que vous faites. C’est la raison pour laquelle j’utilise la configuration standard.
Vous n’avez pas besoin de l’étape 3 si vous connectez le conteneur discourse via websocket.
C’est parce que
Êtes-vous sûr que 172.17.0.2 est votre conteneur db ? - Dans tous les cas : vous pouvez éviter ce problème en laissant NPM sur son propre réseau et en connectant discourse via web socket.
2 « J'aime »
Merci @tophee pour la clarification, j’ai tout fait et corrigé, mais il semble que je n’ai pas utilisé websocket et que je me concentrais sur le port avec la configuration npm et les conteneurs de Discourse ;
Mon problème avec NPM concernait CloudFlared Argo tunnel. Après avoir terminé la configuration de NPM, SSL, tout… j’ai réussi à faire fonctionner CloudFlared argo tunnel, mais le problème était que CloudFlared ne peut pas être exécuté comme proxy secondaire, où nous devons désactiver NPM pour qu’il soit devant le web d’origine ; l’erreur que j’obtiens de CloudFlare est la suivante :
Erreur 1000 : DNS pointe vers une IP interdite
Après avoir recherché cette erreur avec Cloudflare, elle me donne ceci :
Il y a un proxy inverse à votre origine qui renvoie la requête via le proxy Cloudflare. Au lieu d'utiliser un proxy inverse, contactez votre fournisseur d'hébergement ou votre administrateur de site pour configurer une redirection HTTP à votre origine.
Comment pouvons-nous désactiver NPM en tant que proxy inverse ?
Mon objectif est de faire fonctionner l’IP d’origine sans NPM “pendant que” NPM est installé et fonctionne ; afin que nous puissions faire communiquer CloudFlared avec notre serveur ?
1 « J'aime »
Désinstallez NPM. Le but de NPM est d’agir comme un proxy inverse. Si vous ne voulez pas de proxy inverse, désactivez-le.
Je ne saisis pas bien le but et ce n’est certainement rien que je connaisse. Vous devriez probablement consulter le forum NPM ou quelque chose comme ça. Cela n’a rien à voir avec discourse.
2 « J'aime »
J’ai déjà ouvert un ticket là-bas ; et j’en discute ici aussi, et oui, je l’ai désactivé après 2 jours de tâtonnements ; mais j’ajouterais comment ajouter la prise en charge des ports personnalisés avec Discourse et NPM ici, puisque ce sujet ne prend en charge que les sockets nginx avec npm ;
Merci.
1 « J'aime »
Non. Il ne prend pas uniquement en charge les sockets, sauf si vous suivez les instructions relatives aux sockets. Il est indiqué que vous n’avez pas à utiliser de sockets :
Lors de mon dernier test, cela a parfaitement fonctionné en utilisant un port comme suggéré.
1 « J'aime »
Ces instructions m’ont aidé à configurer Discourse avec Nginx Proxy Manager.
Cependant, le navigateur affiche des erreurs de « contenu mixte » lors de la tentative de chargement de polices et d’images depuis http.
Vous pouvez « forcer https » dans les liens avec l’option ici :
1 « J'aime »
Wow, c’est un sujet assez compliqué avec beaucoup de conditions.
Aujourd’hui, j’ai aussi essayé la configuration et j’ai malheureusement échoué lamentablement. Les instructions ont de bonnes intentions, mais à mon avis, elles ne sont pas si faciles à comprendre.
Quand je travaille avec Docker, je veux généralement que les conteneurs fonctionnent séparément/isolément les uns des autres. Pas trop de dépendances, de prérequis et de « points de défaillance uniques ». Mais ce sont précisément les problèmes causés par l’approche : NPM est un excellent outil. Je ne comprends pas pourquoi je dois faire des ajustements spéciaux à sa configuration Docker à partir du Proxy Manager pour satisfaire Discourse et lui fournir des certificats. À la maison, j’utilise également le NPM pour mon domaine DynDNS afin de pouvoir attribuer des services et des hôtes de manière flexible à tout moment. Et pour en avoir certains en public (Home Assistant, Grafana, …).
Je voulais fusionner mes deux instances Discourse aujourd’hui. J’ai spécialement loué un serveur cloud chez Hetzner/Allemagne. C’est pourquoi Discourse n’était pas préinstallé, comme le supposent les instructions.
J’aimerais que Discourse propose officiellement l’installation avec NPM par défaut. Ou du moins, qu’il ne pose pas autant de problèmes avec le script ./discourse-setup.
1 « J'aime »
Petit tutoriel pour installer plusieurs instances 
Dans ce cas, nous allons commencer par une installation propre du serveur et nous pourrons ensuite restaurer une ancienne instance.
Étape 0 : Sauvegarde !!!
Téléchargez la sauvegarde. Vous en aurez besoin plus tard.
Étape 1 : NGINX Proxy Manager
mkdir -p /opt/nginx-proxy-manager
cd /opt/nginx-proxy-manager
nano docker-compose.yml
version: '3'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: always
ports:
- '80:80' # http / réservé !
- '81:81' # port d'administration web
- '443:443' # https / réservé !
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
et enfin : docker-compose up -d
(Pour les personnes encore plus paresseuses, comme moi parfois, utilisez simplement casaOS (sur n’importe quel port autre que ≠ 80/81/443). Assurez-vous simplement d’utiliser des identifiants de connexion sécurisés et un hôte proxy supplémentaire avec votre certificat SSL pour une couche de sécurité supplémentaire. Vous pouvez même configurer des règles de pare-feu si vous savez ce que vous faites.)
Étape 2 : Installation de Docker sur un serveur Ubuntu
sudo apt update && apt upgrade -y
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update
sudo apt-get install docker-ce docker-ce-cli containerd.io
Étape 3 : Préparation de l’installation de Discourse
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cp /var/discourse/samples/standalone.yml /var/discourse/containers/app1.yml
nano /var/discourse/containers/app1.yml
cp /var/discourse/samples/standalone.yml /var/discourse/containers/app2.yml
nano /var/discourse/containers/app2.yml
Apportez les modifications nécessaires à vos fichiers app.yml. Cela inclut différents ports exposés pour chaque instance (oui, vous pouvez même les utiliser pour la maintenance), les paramètres de messagerie, etc.
par exemple, app1 obtient le port 8080/1443 et app2 obtient le port 8081/2443 pour http/https.
/var/discourse/launcher rebuild app1
/var/discourse/launcher rebuild app2
Étape 4 : Enfin, la configuration du NGINX Proxy Manager
Regardez ceci pour une compréhension de base de l’utilisation du NGINX Proxy Manager.
Tout ce que vous avez à faire est de pointer vos entrées d’hôte proxy vers chaque instance (port http, par exemple 8080 et 8081 avec votre IP locale ou publique, c’est votre décision) et vous pourrez obtenir des certificats Let’s Encrypt gratuits pour chaque instance et domaine. Assurez-vous simplement d’activer Force SSL, etc.
Étape 5 : Terminé. Buvez une tasse de café.
Dans mon cas, cela fonctionne parfaitement.
Il peut y avoir quelques problèmes mineurs avec les dépendances logicielles préinstallées, mais je suis sûr que vous trouverez une solution. Ne me blâmez pas pour mon conseil sur casaOS. Mais pour les personnes qui aiment jouer avec leurs serveurs, utiliser toutes les ressources disponibles de manière simple, sûre et sécurisée, je suis sûr que vous trouverez cette gestion Docker intéressante.
Étape 6 : Enfin, restaurez vos sauvegardes précédentes.
1 « J'aime »
Puis-je combiner cela à l’aide d’un tunnel Cloudflare pour le domaine ?
1 « J'aime »
Bien sûr, pourquoi pas ?
Assurez-vous simplement d’exposer le bon port et de configurer ce port pour votre domaine dans les tunnels Cloudflare.
Personnellement, je ne préfère pas cette solution car elle me rend dépendant de Cloudflare et chaque agent de tunnel crée un trou 
dans mon pare-feu, ce qui me donne l’impression d’installer un cheval de Troie.
La gestion du pare-feu est essentielle pour les administrateurs de serveurs. Vous aurez des devoirs à faire avant d’exposer des sites à la DMZ.