Debes asegurarte de que ambos contenedores estén en la misma red de Docker. Si NPM no funciona, entonces (todavía) no tienes un problema de configuración de Discourse.
1 me gusta
olvidé por error la red de Docker de MariaDB; pero después de agregar
network_mode: bridge
todavía obtengo un error de npm al conectarme a la base de datos de Discourse;
environment:
DB_MYSQL_HOST: "172.17.0.2" # contenedor de datos - pero recibo un error (error connect ECONNREFUSED 172.17.0.2:3306) cuando está habilitado.
# DB_MYSQL_HOST: "db" base de datos npm predeterminada (fuera de Discourse).
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "h4xb0xr1z__0k"
DB_MYSQL_NAME: "npm"
cuando npm y maria se inician y están en funcionamiento; los registros de maria están bien… pero npm
error connect ECONNREFUSED 172.17.0.2:3306
¿falta algo?
1 me gusta
mi archivo docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
network_mode: bridge
restart: unless-stopped
ports:
- '80:80' # Puerto HTTP público
- '443:443' # Puerto HTTPS público
- '81:81' # Puerto Web de administración
environment:
DB_MYSQL_HOST: "172.17.0.2" # Contenedor de datos - pero recibo un error (connect ECONNREFUSED 172.17.0.2:3306) cuando está habilitado.
# DB_MYSQL_HOST: "db" base de datos npm predeterminada (fuera 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
tengo discourse ejecutándose con data + web-only; el mapa de IPs después de npm y maria es así:
IP del contenedor de datos: 172.17.0.2
IP del contenedor web_only: 172.17.0.3
IP del contenedor npm: 172.17.0.5
IP de datos de maria (npm): 172.17.0.4
1 me gusta
Hola @tophee
¿Puedes darnos tu recomendación sobre el uso de SQLite con NPM, ya que es más fácil y confiable trabajar con él que con los problemas de mariadb?
He configurado NPM con SQLite y todo funciona bien, host virtual de nginx, ssl, etc… pero quiero asegurarme de cómo conectar la base de datos de discourse con NPM, ya que estoy recibiendo un error 502 para la configuración de NPM con el sitio de discourse.
mi docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: always
network_mode: bridge #-- esta red se ha añadido para que NPM esté en la misma red de discourse, y ahora se ven mutuamente.
ports:
# Puerto HTTP público:
- '80:80'
# Puerto HTTPS público:
- '443:443'
# Puerto web de administración:
- '81:81'
environment:
DB_SQLITE_FILE: "/data/database.sqlite"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
No, mi recomendación es usar la configuración estándar de NPM a menos que sepas lo que estás haciendo. Esa es la razón por la que estoy usando la configuración estándar.
No necesitas el paso 3 si conectas el contenedor de discourse a través de websocket.
Esto se debe a que
¿Estás seguro de que 172.17.0.2 es tu contenedor de base de datos? - En cualquier caso: puedes evitar este problema dejando NPM en su propia red y conectando discourse a través de web socket.
2 Me gusta
Gracias @tophee por la aclaración, lo he hecho y corregido todo, pero parece que no usé websocket y me centré en el puerto con la configuración de npm y los contenedores de discourse;
mi problema que enfrento con NPM fue con el túnel Argo de CloudFlared, después de terminar la configuración de NPM, ssl, todo.. logré ejecutar el túnel argo de CloudFlared pero el problema fue que CloudFlared no puede ejecutarse como un proxy secundario, donde necesitamos deshabilitar NPM para que esté delante de la web de origen; el error que obtengo de CloudFlare es este:
Error 1000: DNS apunta a una IP prohibida
después de buscar este error con cloudflare; me da esto
Hay un proxy inverso en tu origen que envía la solicitud de regreso a través del proxy de Cloudflare. En lugar de usar un proxy inverso, contacta a tu proveedor de hosting o administrador del sitio para configurar una redirección HTTP en tu origen.
¿Cómo podemos deshabilitar NPM como proxy inverso?
Mi objetivo es hacer que la IP de origen funcione sin NPM “mientras” npm está instalado y funcionando; para que podamos hacer que cloudflared se comunique con nuestro servidor?
1 me gusta
Desinstala NPM. El propósito de NPM es actuar como un proxy inverso. Si no quieres un proxy inverso, apágalo.
No entiendo muy bien el punto y ciertamente no tengo ningún conocimiento sobre eso. Probablemente deberías consultar el foro de NPM o algo así. Esto no tiene nada que ver con discourse.
2 Me gusta
Ya lo abrí; y discuto aquí también, y sí, lo deshabilité después de 2 días de experimentar; pero añadiría cómo agrego soporte de puerto personalizado con Discourse y NPM aquí, ya que este tema solo admite nginx de socket con npm;
Gracias.
1 me gusta
No. No solo soporta sockets a menos que sigas las instrucciones de sockets. Dice que no tienes que usar sockets:
Cuando probé esto por última vez, funcionó bien usando un puerto como se sugiere.
1 me gusta
Estas instrucciones me ayudaron a configurar Discourse con Nginx Proxy Manager.
Sin embargo, el navegador muestra errores de “contenido mixto” al intentar cargar fuentes e imágenes desde http.
Puedes “forzar https” en los enlaces con la opción aquí:
1 me gusta
Vaya, ese es un tema bastante complicado con muchos “si” y “peros”.
Hoy también intenté la configuración y, lamentablemente, fracasé estrepitosamente. Las instrucciones tienen buenas intenciones, pero en mi opinión no son tan fáciles de entender/comprender.
Cuando trabajo con Docker, normalmente quiero que los contenedores se ejecuten por separado/aislados unos de otros. No demasiadas dependencias, requisitos previos y “puntos únicos de fallo”. Pero estos son exactamente los problemas que causa el enfoque: NPM es una gran herramienta. No entiendo por qué tengo que hacer ajustes especiales en su configuración de Docker desde el Proxy Manager para que Discourse funcione y le proporcione certificados. En casa, también uso el NPM para mi dominio DynDNS para poder asignar servicios y hosts de forma flexible en cualquier momento. Y para tener algunos de ellos públicos (Home Assistant, Grafana, …).
Quería fusionar mis dos instancias de Discourse hoy. He alquilado especialmente un servidor en la nube de Hetzner/Alemania. Por eso DIscourse no venía preinstalado, como suponen las instrucciones.
Ojalá Discoruse ofreciera oficialmente la instalación con NPM por defecto. O al menos no causara tantos problemas con el script ./discourse-setup.
1 me gusta
Una pequeña guía para instalar múltiples instancias 
En este caso, comenzaremos con una instalación limpia del servidor y es posible que queramos restaurar una instancia antigua después.
Paso 0: ¡Copia de seguridad!
Descarga la copia de seguridad. La necesitarás más tarde.
Paso 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 / ¡reservado!
- '81:81' # puerto de administración web
- '443:443' # https / ¡reservado!
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
y finalmente: docker-compose up -d
(Para las personas aún más perezosas, como yo a veces, simplemente usa casaOS (en cualquier puerto que no sea ≠ 80/81/443). Solo asegúrate de usar credenciales de inicio de sesión seguras y un host proxy adicional con tu certificado SSL para una capa adicional de seguridad. Incluso puedes configurar algunas reglas de firewall si sabes lo que estás haciendo.)
Paso 2: Instalación de Docker en el servidor 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
Paso 3: Preparación de la instalación 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
Realiza los cambios necesarios en tus archivos app.yml. Esto incluye diferentes puertos expuestos para cada instancia (sí, incluso puedes usarlos para mantenimiento), configuración de correo, etc.
por ejemplo, app1 obtiene el puerto 8080/1443 y app2 obtiene el puerto 8081/2443 para http/https.
/var/discourse/launcher rebuild app1
/var/discourse/launcher rebuild app2
Paso 4: Por último, pero no menos importante, configurar el NGINX Proxy Manager
Mira esto para una comprensión básica de cómo usar NGINX Proxy Manager.
Todo lo que necesitas hacer es apuntar tus entradas de host proxy a cada instancia (puerto http, por ejemplo, 8080 y 8081 con tu IP local o pública, es tu decisión) y podrás obtener certificados gratuitos de Let’s Encrypt para cada instancia y dominio. Solo asegúrate de habilitar Force SSL y otras opciones.
Paso 5: Hecho. Bebe una taza de café.
En mi caso funciona perfectamente.
Puede haber algunos problemas menores con las dependencias de software preinstaladas, pero estoy seguro de que encontrarás una solución. No te enfades conmigo por mi consejo sobre casaOS. Pero para las personas a las que les gusta jugar con sus servidores, usar todos los recursos disponibles de una manera fácil de usar, segura y protegida, estoy seguro de que encontrarás interesante esta gestión de Docker.
Paso 6: Finalmente, restaura tus copias de seguridad anteriores.
1 me gusta
¿Puedo combinar esto usando un túnel de Cloudflare para el dominio?
1 me gusta
Claro, ¿por qué no?
Solo asegúrate de exponer el puerto correcto y configurar este puerto para tu dominio en los túneles de Cloudflare.
Personalmente, no prefiero esta solución porque me hace dependiente de Cloudflare y cada agente de túnel abre un agujero 
en mi firewall, lo que me hace sentir que estoy instalando un caballo de Troya.
La gestión del firewall es esencial para los administradores de servidores. Tendrás que hacer algunos deberes antes de exponer sitios a la DMZ.