Devi assicurarti che entrambi i container siano sulla stessa rete Docker. Se NPM non funziona, allora non hai (ancora) un problema di configurazione di Discourse.
Ho dimenticato per errore la rete Docker di MariaDB; ma dopo aver aggiunto
network_mode: bridge
ottengo ancora un errore npm nel connettermi al database di discourse;
environment:
DB_MYSQL_HOST: "172.17.0.2" # container dati - ma ricevo errore ( error connect ECONNREFUSED 172.17.0.2:3306 ) quando abilitato.
# DB_MYSQL_HOST: "db" database npm predefinito (esterno a discourse).
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "h4xb0xr1z__0k"
DB_MYSQL_NAME: "npm"
quando npm e maria sono attivi e in esecuzione; i log di maria sono buoni… ma npm
error connect ECONNREFUSED 172.17.0.2:3306
manca qualcosa?
il mio file docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
network_mode: bridge
restart: unless-stopped
ports:
- '80:80' # Public HTTP Port
- '443:443' # Public HTTPS Port
- '81:81' # Admin Web Port
environment:
DB_MYSQL_HOST: "172.17.0.2" #data container - but i receive error ( connect ECONNREFUSED 172.17.0.2:3306 ) when enabled.
# DB_MYSQL_HOST: "db" default npm databse (outside 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
ho discourse in esecuzione con data + web-only; la mappa per gli IP dopo npm e maria è la seguente:
IP del container dati: 172.17.0.2
IP del container web_only: 172.17.0.3
IP del container npm: 172.17.0.5
IP dei dati di Maria (npm): 172.17.0.4
Ciao @tophee
Puoi darci la tua raccomandazione sull’uso di SQLite con NPM, dato che è più facile e affidabile da usare rispetto ai problemi di mariadb;
Ho configurato NPM con SQLite e tutto funziona bene, virtual host nginx, ssl, ecc… ma voglio assicurarmi come collegare il database di discourse con NPM? dato che sto ricevendo un errore 502 per la configurazione di NPM con il sito discourse.
il mio docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: always
network_mode: bridge
ports:
# Public HTTP Port:
- '80:80'
# Public HTTPS Port:
- '443:443'
# Admin Web Port:
- '81:81'
environment:
DB_SQLITE_FILE: "/data/database.sqlite"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
No, la mia raccomandazione è di usare la configurazione standard di NPM a meno che tu non sappia cosa stai facendo. Questo è il motivo per cui sto usando la configurazione standard.
Non hai bisogno del passaggio 3 se connetti il container di discourse tramite websocket.
Questo è perché
Sei sicuro che 172.17.0.2 sia il tuo container db? In ogni caso: puoi evitare questo problema lasciando NPM sulla propria rete e connettendo discourse tramite web socket.
Grazie @tophee per il chiarimento, ho fatto e corretto tutto, ma sembra che non abbia usato websocket e mi fossi concentrato sulla porta con la configurazione npm e i container di discourse;
il mio problema con NPM era con il tunnel Argo di CloudFlared, dopo aver terminato la configurazione di NPM, SSL, tutto.. sono riuscito a eseguire il tunnel Argo di CloudFlared ma il problema era che CloudFlared non può essere eseguito come proxy secondario, dove dobbiamo disabilitare NPM per essere davanti al web di origine; l’errore che ricevo da CloudFlare è questo:
Errore 1000: DNS punta a IP proibito
dopo aver cercato questo errore con cloudflare; mi dà questo
C'è un reverse-proxy alla tua origine che rimanda la richiesta attraverso il proxy Cloudflare. Invece di usare un reverse-proxy, contatta il tuo provider di hosting o l'amministratore del sito per configurare un reindirizzamento HTTP alla tua origine.
Come possiamo disabilitare NPM come reverse-proxy?
Il mio obiettivo è far funzionare l’IP di origine senza NPM “mentre” npm è installato e funzionante; in modo da poter far comunicare cloudflared con il nostro server?
Disinstalla NPM. L’intero scopo di NPM è agire come reverse proxy. Se non vuoi un reverse proxy, spegnilo.
Non capisco bene il punto e sicuramente non ho alcuna conoscenza in merito. Dovresti probabilmente controllare il forum di NPM o qualcosa del genere. Questo non ha nulla a che fare con discourse.
Ho già aperto lì; e discuto anche qui, e sì, l’ho disabilitato dopo 2 giorni di tentativi; ma aggiungerei come aggiungere il supporto per porte personalizzate con Discourse e NPM qui, poiché questo argomento supporta solo socket nginx con npm;
Grazie.
No. Non supporta solo i socket a meno che tu non segua le istruzioni per i socket. Dice che non devi usare i socket:
L’ultima volta che ho testato, ha funzionato bene usando una porta come suggerito.
Queste istruzioni mi hanno aiutato a configurare Discourse con Nginx Proxy Manager.
Tuttavia, il browser restituisce errori di “contenuto misto” quando tenta di caricare font e immagini da http.
Puoi “forzare https” nei link con l’opzione qui:
Wow, è un argomento piuttosto complicato con molti se e ma.
Oggi ho provato anch’io la configurazione e purtroppo ho fallito miseramente. Le istruzioni hanno buone intenzioni, ma secondo me non sono così facili da capire/comprendere.
Quando lavoro con Docker, di solito voglio che i container funzionino separatamente/isolati l’uno dall’altro. Non troppe dipendenze, prerequisiti e “single points of failure”. Ma questi sono esattamente i problemi causati dall’approccio: NPM è un ottimo strumento. Non capisco perché devo apportare modifiche speciali alla sua configurazione Docker dal Proxy Manager per rendere felice Discourse e fornirgli certificati. A casa, uso anche il NPM per il mio dominio DynDNS in modo da poter assegnare in modo flessibile servizi e host in qualsiasi momento. E per averne alcuni pubblici (Home Assistant, Grafana, …).
Oggi volevo unire le mie due istanze di Discourse. Ho affittato appositamente un server cloud da Hetzner/Germania. Ecco perché Discourse non era preinstallato, come presumono le istruzioni.
Vorrei che Discourse offrisse ufficialmente l’installazione con NPM per impostazione predefinita. O almeno non creasse così tanti problemi con lo script ./discourse-setup.
Una piccola guida per installare istanze multiple 
In questo caso, inizieremo con un’installazione pulita del server e potremmo voler ripristinare una vecchia istanza in seguito.
Passaggio 0: Backup!!!
Scarica il backup. Ti servirà più tardi.
Passaggio 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 / riservato!
- '81:81' # porta web-admin
- '443:443' # https / riservato!
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
e infine: docker-compose up -d
(Per persone ancora più pigre, come me a volte, usa semplicemente casaOS (su qualsiasi porta diversa da ≠ 80/81/443). Assicurati solo di utilizzare credenziali di accesso sicure e un host proxy aggiuntivo con il tuo certificato SSL per un ulteriore livello di sicurezza. Puoi anche impostare alcune regole firewall se sai cosa stai facendo.)
Passaggio 2: Installazione di Docker su server 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
Passaggio 3: Preparazione dell’installazione di 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
Apporta le modifiche necessarie ai tuoi file app.yml. Ciò include diverse porte esposte per ciascuna istanza (sì, puoi usarle anche per la manutenzione), impostazioni di posta elettronica e così via.
es. app1 ottiene la porta 8080/1443 e app2 ottiene la porta 8081/2443 per http/https.
/var/discourse/launcher rebuild app1
/var/discourse/launcher rebuild app2
Passaggio 4: Infine, configura NGINX Proxy Manager
Guarda questo per una comprensione di base dell’utilizzo di NGINX Proxy Manager.
Tutto ciò che devi fare è puntare le tue voci di host proxy a ciascuna istanza (porta http, ad esempio 8080 e 8081 con il tuo IP locale o pubblico, la decisione spetta a te) e sarai in grado di ottenere certificati gratuiti Let’s Encrypt per ogni istanza e dominio. Assicurati solo di abilitare Force SSL e così via.
Passaggio 5: Fatto. Bevi una tazza di caffè.
Nel mio caso funziona perfettamente.
Potrebbero esserci alcuni piccoli problemi con le dipendenze software preinstallate, ma sono sicuro che troverai una soluzione. Non arrabbiarti con me per il mio consiglio su casaOS. Ma per le persone a cui piace giocare con i propri server, utilizzare tutte le risorse disponibili in modo semplice, sicuro e protetto, sono sicuro che troverai interessante questa gestione di Docker.
Passaggio 6: Infine, ripristina i tuoi backup precedenti.
Posso combinarlo usando il tunnel clouflare per il dominio?
Certo, perché no?
Assicurati solo di esporre la porta corretta e di configurare questa porta per il tuo dominio in Cloudflare tunnels.
Personalmente, non preferisco questa soluzione perché mi rende dipendente da Cloudflare e ogni tunnel agent apre un buco
nel mio firewall, facendomi sentire come se stessi installando un cavallo di Troia.
La gestione del firewall è essenziale per gli amministratori di server. Avrai dei compiti da svolgere prima di esporre i siti alla DMZ.
