Configurei o Discourse duas vezes, uma em um contêiner e a atual em uma VM. Em ambas as instalações, o Discourse não está acessível. Não tenho muita certeza do que pode estar errado.
Como faço para que ele use o IP da máquina HOST?
Não preciso de outra rede dentro de uma rede. Fico feliz em deixar o Docker usar o IP HOST, pois este é o único serviço nesta VM.
Qualquer ajuda seria muito apreciada!
Existe um método oficial para instalar sem Docker?
Não, esta máquina tem um IP local atribuído e o tráfego é roteado para o IP local através do meu firewall. Este não é o problema.
O IP público tem um registro A para o servidor e é roteado corretamente. forum.somedomain.com aponta –> para o servidor correto.
Sim, passei pela instalação. Concluí 100% (3 vezes) até o ponto em que o contêiner está em execução.
Ele passa por todas as verificações de domínio/dns. Afirma que é válido.
Não, isso não pode ser limitado em taxa, pois o certificado SSL é emitido através do meu proxy reverso. Eu tenho o certificado.
Esta instalação está 100% completa. O problema é que o Docker está criando uma nova rede 172.17.0.1 que não é necessária, pois eu gostaria de usar o IP local do HOST 192.xx.xx.xx.
O contêiner está em execução, mas em uma rede diferente. Não consigo colocá-lo no IP do HOST.
O host do docker deve ser o IP do servidor host (192.xxx.xxx.xxx) e não uma nova rede. Provavelmente está funcionando, mas nessa rede.
Como eu digo à instalação para usar meu IP local e não 172.17.0.1?
Você não pode usar discourse-setup com um proxy reverso. Você terá que editar o arquivo yml manualmente. Existem alguns tópicos sobre a execução do Discourse com outros sites na mesma máquina.
Você precisará remover os templates ssl e lets-encrypt se estiver usando um proxy reverso que cuida do SSL.
Isso é bem trivial. Você permite a porta http em app.yml onde o Ngix está enviando tráfego. E o SSL está desativado. Essas duas coisas são as únicas que você tem que consertar. Claro que você tem que dizer o IP real, mas isso tem que ser feito toda vez que o backend for Discourse, Moodle, WordPress ou qualquer outra coisa. O UFW tenta limitar o acesso apenas entre o frontend e o backend porque não há necessidade de permitir acesso direto ao backend.
Se bem me lembro, aqui está a documentação sobre como configurar o Apache2. O Nginx faz a mesma coisa, mas do seu próprio jeito, é claro.
A instalação é concluída com sucesso e então os problemas começam.
Não consigo acessar o contêiner docker do host por causa da rede docker0. Posso pingar 172.17.0.2 e ele está ativo e funcionando, mas da máquina host 192.168.1.10:80/443 não passa tráfego para o contêiner.
Tudo o que quero é que o contêiner docker use a rede do host, pois o contêiner tem as portas 80 e 443 expostas.
O primeiro proxy reverso nginx gerencia o tráfego de fora e o passa para a VM corretamente. Se não o fizesse, o ./discourse-setup não teria captado o nome de domínio corretamente e não conseguiria recuperar certificados ssl para o contêiner.
No final. Eu sei que o contêiner está funcionando 100%, eu apenas não consigo acessá-lo devido à rede docker.
Se precisar de alguma informação, por favor me avise.
Outra forma de abordar isso é usar a imagem base do discourse https://hub.docker.com/r/discourse/base
E construir sua própria orquestração com, por exemplo, docker compose (lembrando que você precisa de outros serviços como redis e postgres)
Eu posso fazer isso com Nginx ou Nginx+Varnish para Discourse no mesmo VPS ou VPS em um IP diferente. Você não diz o que realmente faz com seu Nginx agindo como proxy reverso. Seus exemplos são um pouco difíceis porque não há como saber se são exemplos ou se você está realmente tentando usar uma rede privada.
Mas:
Claro que não, porque isso cuida do tráfego de entrada. Você deve usar outra porta para o backend.
Algo como isto (que é realmente usado com Varnish, mas o princípio é totalmente o mesmo, e muito material de nível 101):
Não tenho certeza de qual, porque esta rede docker é confusa.
Absolutamente, é por isso que estou ficando frustrado com o docker, lol.
Abaixo está exatamente como a rede WAN passa e roteia o tráfego do meu proxy reverso nginx para o host correto.
map $scheme $hsts_header {
https "max-age=63072000;includeSubDomains; preload";
}
server {
set $forward_scheme https;
set $server "10.10.1.38";
set $port 443;
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name forum.domainname.com;
# Let's Encrypt SSL
include conf.d/include/letsencrypt-acme-challenge.conf;
include conf.d/include/ssl-ciphers.conf;
ssl_certificate /srv/ssl/domainname.pem;
ssl_certificate_key /srv/ssl/domainname-ke.pem;
# Asset Caching
include conf.d/include/assets.conf;
# Block Exploits
include conf.d/include/block-exploits.conf;
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
# Force SSL
include conf.d/include/force-ssl.conf;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
access_log /var/logs/domainname-access.log proxy;
error_log /var/logs/domainame_error.log warn;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $http_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
location / {
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
# Proxy!
include conf.d/include/proxy.conf;
}
}
O que é estranho, eu configurei um contêiner docker uma vez para um cliente que queria o gerenciador de proxy reverso nginx e foi extremamente simples.
docker-compose up -d
Isso foi tudo. O IP privado 192.168.1.3 poderia alcançar os 80/443 expostos dos contêineres e o tráfego de saída foi roteado corretamente para 192.168.1.3.
É confuso porque é um sistema de empacotamento que atua em sua própria sandbox. Basicamente, é isso.
Mas entender docker é uma coisa diferente de usá-lo (e agora um monte de desenvolvedores começou a chorar ) Seu proxy reverso está enviando tráfego para o IP através do firewall e você tem que dizer qual IP e porta de escuta. E você tem Discourse, também conhecido como docker, nesse IP, e a porta que você diz em app.yml. O Nginx interno que funciona com o próprio Discourse cuida do resto.
O Discourse não deve escutar 443 porque você já encerrou o SSL.
E você basicamente não pode usar cache no proxy reverso. O backend, Discourse, não é uma página da web. É um aplicativo web enviando javascript e json.
Com isso eu posso concordar. Eu não diria chorar, é apenas inútil para administradores de sistema e desenvolvedores que realmente conhecem o Linux. Criar um LxC ou VM que é isolado para então deixar o docker criar outro ambiente isolado é redundante e sem sentido.
Esta é a parte que é confusa. app.yml está expondo 80:80 e 443:443 em 172.17.0.2 que está na rede docker 172.17.0.1/16 com o IP da VM em 10.10.1.38.
Como faço para o discourse/docker permitir todo o tráfego que chega a 10.10.1.38 ser passado para 172.17.0.2 e todo o tráfego de saída ser passado para 10.10.1.38. É só isso que é necessário para resolver este problema. Literalmente.
) Seu proxy reverso está enviando tráfego para o IP através do firewall e você tem que dizer qual IP e porta de escuta. E você tem Discourse, também conhecido como docker, nesse IP, e a porta que você diz em 
