Você precisa ver que ambos os contêineres estão na mesma rede docker. Se o NPM não estiver funcionando, você ainda não tem um problema de configuração do Discourse.
1 curtida
Cometi o erro de esquecer a rede docker do MariaDB; mas depois de adicionar
network_mode: bridge
ainda recebo erro npm ao conectar ao banco de dados do discourse;
environment:
DB_MYSQL_HOST: "172.17.0.2" # container de dados - mas recebo erro ( error connect ECONNREFUSED 172.17.0.2:3306 ) quando habilitado.
# DB_MYSQL_HOST: "db" banco de dados npm padrão (fora do discourse).
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "h4xb0xr1z__0k"
DB_MYSQL_NAME: "npm"
quando npm e maria estão ativos e rodando; os logs do maria estão bons… mas o npm
error connect ECONNREFUSED 172.17.0.2:3306
faltou algo?
1 curtida
meu arquivo docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
network_mode: bridge
restart: unless-stopped
ports:
- '80:80' # Porta HTTP pública
- '443:443' # Porta HTTPS pública
- '81:81' # Porta Web de Administração
environment:
DB_MYSQL_HOST: "172.17.0.2" # container de dados - mas recebo erro ( connect ECONNREFUSED 172.17.0.2:3306 ) quando habilitado.
# DB_MYSQL_HOST: "db" banco de dados npm padrão (fora do 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
tenho o discourse rodando com data + web-only; o mapa de IPs após npm e maria é assim:
IP do container de dados: 172.17.0.2
IP do container web_only: 172.17.0.3
IP do container npm: 172.17.0.5
IP dos dados do maria (npm): 172.17.0.4
1 curtida
Olá @tophee
Você pode nos dar sua recomendação sobre o uso do SQLite com o NPM, já que é mais fácil e confiável de trabalhar do que os problemas do mariadb;
Eu configurei o NPM com SQLite e tudo está funcionando bem, host virtual nginx, ssl, etc… mas quero ter certeza de como conectar o banco de dados do discourse com o NPM? já que estou recebendo um erro 502 para a configuração do npm com o site do discourse.
meu docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: always
network_mode: bridge # esta rede foi adicionada para permitir que o NPM esteja na mesma rede do discourse, e agora eles se veem.
ports:
# Porta HTTP pública:
- '80:80'
# Porta HTTPS pública:
- '443:443'
# Porta Web de Administração:
- '81:81'
environment:
DB_SQLITE_FILE: "/data/database.sqlite"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
Não, minha recomendação é usar a configuração padrão do NPM, a menos que você saiba o que está fazendo. Esse é o motivo pelo qual estou usando a configuração padrão.
Você não precisa da etapa 3 se conectar o contêiner do Discourse via websocket.
Isso ocorre porque
Você tem certeza de que 172.17.0.2 é o seu contêiner de banco de dados? Em qualquer caso, você pode evitar esse problema deixando o NPM em sua própria rede e conectando o Discourse via websocket.
2 curtidas
Obrigado @tophee pelo esclarecimento, eu fiz e corrigi tudo, mas parece que não usei websocket e estava focado na porta com a configuração do npm e nos contêineres do discourse;
meu problema que enfrentei com o NPM foi com o túnel Argo do CloudFlared, depois que terminei a configuração do NPM, SSL, tudo.. consegui rodar o túnel Argo do CloudFlared, mas o problema foi que o CloudFlared não pode ser executado como um proxy secundário, onde precisamos desabilitar o NPM para ficar na frente da web de origem; o erro que recebo do CloudFlare é este:
Erro 1000: DNS aponta para IP proibido
depois de pesquisar este erro com o cloudflare; ele me dá isto
Há um proxy reverso em sua origem que envia a solicitação de volta através do proxy do Cloudflare. Em vez de usar um proxy reverso, entre em contato com seu provedor de hospedagem ou administrador do site para configurar um redirecionamento HTTP em sua origem.
Como podemos desabilitar o NPM como um proxy reverso?
Meu objetivo é fazer com que o IP de origem funcione sem o NPM “enquanto” o npm está instalado e funcionando; para que possamos fazer o cloudflared se comunicar com nosso servidor?
1 curtida
Desinstale o NPM. O objetivo do NPM é atuar como um proxy reverso. Se você não quer um proxy reverso, desative-o.
Eu não entendi bem o ponto e certamente não tenho conhecimento sobre isso. Você provavelmente deveria verificar o fórum do NPM ou algo assim. Isso não tem nada a ver com o discourse.
2 curtidas
Eu já abri lá; e discuto aqui também, e sim, eu desativei depois de 2 dias mexendo; mas eu adicionaria como adicionar suporte a porta personalizada com Discourse e NPM aqui, já que este tópico suporta apenas socket nginx com npm;
Obrigado.
1 curtida
Não. Ele não suporta apenas sockets, a menos que você siga as instruções do socket. Ele diz que você não precisa usar sockets:
Quando testei isso pela última vez, funcionou bem usando uma porta como sugerido.
1 curtida
Estas instruções me ajudaram a configurar o Discourse com o Nginx Proxy Manager.
No entanto, o navegador apresenta erros de "conteúdo misto" ao tentar carregar fontes e imagens de http.
Você pode "forçar https" nos links com a opção aqui:
1 curtida
Uau, esse é um tópico bastante complicado com muitos “ses” e “mas”.
Hoje também tentei a configuração e infelizmente falhei miseravelmente. As instruções têm boas intenções, mas na minha opinião não são tão fáceis de entender/compreender.
Quando trabalho com Docker, geralmente quero que os contêineres rodem separadamente/isolados uns dos outros. Não muitas dependências, pré-requisitos e “pontos únicos de falha”. Mas esses são exatamente os problemas que são causados pela abordagem: NPM é uma ótima ferramenta. Não entendo por que tenho que fazer ajustes especiais em sua configuração Docker do Proxy Manager para deixar o Discourse feliz e fornecer certificados. Em casa, também uso o NPM para meu domínio DynDNS para que eu possa atribuir flexivelmente serviços e hosts a qualquer momento. E para ter alguns deles públicos (Home Assistant, Grafana, …).
Eu queria fundir minhas duas instâncias do Discourse hoje. Aluguei especialmente um servidor em nuvem da Hetzner/Alemanha. É por isso que o Discourse não veio pré-instalado, como as instruções assumem.
Gostaria que o Discourse oferecesse oficialmente a instalação com NPM por padrão. Ou, pelo menos, não criasse tantos problemas com o script ./discourse-setup.
1 curtida
Apenas um pequeno guia para instalar várias instâncias 
Neste caso, começaremos com uma instalação limpa do servidor e poderemos restaurar uma instância antiga depois.
Passo 0: Backup!!!
Baixe o backup. Você precisará dele mais tarde.
Passo 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' # porta web-admin
- '443:443' # https / reservado!
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
e finalmente: docker-compose up -d
(Para pessoas ainda mais preguiçosas, como eu às vezes, basta usar o casaOS (em qualquer porta diferente de ≠ 80/81/443). Apenas certifique-se de estar usando credenciais de login seguras e um host proxy adicional com seu certificado SSL para uma camada extra de segurança. Você pode até configurar algumas regras de firewall se souber o que está fazendo.)
Passo 2: Instalação do Docker no 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
Passo 3: Preparação da instalação do 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
Faça quaisquer alterações necessárias em seus arquivos app.yml. Isso inclui diferentes portas expostas para cada instância (sim, você pode até usá-las para manutenção), configurações de e-mail e assim por diante.
por exemplo: app1 recebe a porta 8080/1443 e app2 recebe a porta 8081/2443 para http/https.
/var/discourse/launcher rebuild app1
/var/discourse/launcher rebuild app2
Passo 4: Por último, mas não menos importante, configurando o NGINX Proxy Manager
Assista a este vídeo para uma compreensão básica de como usar o NGINX Proxy Manager.
Tudo o que você precisa fazer é apontar suas entradas de host proxy para cada instância (porta http, por exemplo, 8080 e 8081 com seu IP local ou público, a decisão é sua) e você poderá obter certificados gratuitos do Let’s Encrypt para cada instância e domínio. Apenas certifique-se de habilitar o Force SSL e assim por diante.
Passo 5: Feito. Beba uma xícara de café.
No meu caso, funciona perfeitamente.
Pode haver alguns problemas menores com as dependências de software pré-instaladas, mas tenho certeza de que você encontrará uma solução. Não fique bravo comigo pela minha dica do casaOS. Mas para pessoas que gostam de brincar com seus servidores, usar todos os recursos disponíveis de uma maneira fácil de usar, segura e protegida, tenho certeza de que você achará este gerenciamento do Docker interessante.
Passo 6: Finalmente, restaure seus backups anteriores.
1 curtida
Posso combinar isso usando o Cloudflare Tunnel para o domínio?
1 curtida
Claro, por que não?
Apenas certifique-se de expor a porta correta e configurá-la para o seu domínio nos túneis do Cloudflare.
Pessoalmente, não prefiro essa solução porque me torna dependente do Cloudflare e cada agente de túnel abre um buraco 
no meu firewall, o que me faz sentir como se estivesse instalando um cavalo de Troia.
O gerenciamento de firewall é essencial para administradores de servidores. Você terá algumas tarefas de casa para fazer antes de expor sites à DMZ.