Olá,
Acabei de instalar o Discourse e o Cloudflared no meu R-Pi 4, e segui as instruções na postagem original, mas não tenho certeza do que colocar como host para o Discourse, devo apenas colocar localhost, já que o túnel cloudflared irá encaminhá-lo?
Talvez o @Falco possa ajudar?
Aliás, desculpe por ressuscitar o tópico.
Você ainda precisa possuir um domínio para este guia, portanto, o valor do host será o ápice do domínio ou o subdomínio que você configurou para o Discourse e para o túnel.
Então o valor do host deve ser o subdomínio que eu quero que o Discourse esteja?
Sim, deve ser o URL onde você quer que o Discourse fique.
Tem certeza?
Se eu fizer isso, recebo este erro:
Defini o nome do host do Discourse para o subdomínio exato onde quero que o Discourse fique.
Instalei o Cloudflared no R-Pi4 a partir da CLI (conforme escrito aqui: Set up your first tunnel · Cloudflare One docs) e estou executando-o como um serviço.
E instalei o Discourse conforme mencionado em sua postagem original, tenho quase certeza.
Você pode compartilhar o domínio?
Posso te enviar por DM? Não quero que pessoas aleatórias vejam.
Está funcionando agora que você colocou o domínio correto?
Sim! Acabei de inicializar! Obrigado pela sua ajuda! Só tenho um problema com o MailJet (o provedor de e-mail que uso para STMP), que está se divertindo pré-bloqueando meus e-mails de verificação…
Uma postagem foi dividida em um novo tópico: Alguma alternativa ao MailJet?
Uma postagem foi mesclada em um tópico existente: Alternativas ao MailJet?
Olá, consegui fazer uma instalação funcionar! Tenho apenas uma pequena pergunta: quanta atividade/membros você acha que um R-Pi 4 Model B com 4 GB de RAM pode lidar?
Essa é uma ótima pergunta. Como é difícil fazer uma correlação direta entre o número de usuários e a carga do servidor em um sistema complexo como o Discourse, é justo reconhecer que o principal gargalo em um sistema Raspberry Pi é o IOPS de armazenamento.
Portanto, desde que a maioria dos seus recursos necessários esteja na RAM, entre os processos RSS e o cache do Linux, você terá uma experiência tranquila. O fato de o Cloudflare atuar como um CDN de cache também ajudará bastante, e você pode até estender a longevidade da configuração do Pi usando Usando Armazenamento de Objetos para Uploads (S3 e Clones) depois de um tempo.
Recebi este erro em partes do docker
FAILED
--------------------
Pups::ExecError: /usr/local/bin/ruby -e 'if ENV["DISCOURSE_HOSTNAME"] == "discourse.example.com"; puts "Aborting! Domain is not configured!"; exit 1; end' falhou com retorno #<Process::Status: pid 115 exit 1>
Localização da falha: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec falhou com os parâmetros "/usr/local/bin/ruby -e 'if ENV[\"DISCOURSE_HOSTNAME\"] == \"discourse.example.com\"; puts \"Aborting! Domain is not configured!\"; exit 1; end'"
bootstrap falhou com código de saída 1
** FALHA AO INICIALIZAR ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.
9ba0db264ae559f3f748cc1e42a8683ea0b4e355b0d45da0f472afea7ff7c472
Isso significa que você não configurou seu domínio corretamente. Você precisa de um domínio válido para que isso funcione. Execute ./discourse-setup novamente ou edite o arquivo app.yml para corrigir.
obrigado pela resposta
consegui implantá-lo no RockPi4 
Olá @Falco,
Tenho certeza de que configurei exatamente como seu guia, mas estou notando algo estranho.
Na configuração do contêiner, não estou carregando os modelos SSL e tenho a variável de ambiente DISCOURSE_FORCE_HTTPS definida como true. Não tenho certeza do que isso faz, mas imagino que defina SiteSetting.force_https como true e, em seguida, a oculte no painel de administração para evitar que seja desativada.
Minha configuração do túnel CF é assim:
ingress:
- hostname: dc.example.com
service: http://dc:80 # dc é o nome do meu contêiner de aplicativo independente do discourse
O problema é que posso acessar http://dc.example.com e ele não é redirecionado para https. Esse é o comportamento esperado?
Você consegue reproduzir isso? Imagino que seja um bug.
Minhas configurações relevantes do CF são:
Eu sei que posso fazer o CF redirecionar (seja com Usar Sempre HTTPS ou uma regra de redirecionamento em massa), mas eu teria assumido que o discourse lidaria com isso e redirecionaria todos os URIs internos se force_https estivesse ativado. O que você acha?
Ignorando o problema de redirecionamento, navegar em https://dc.example.com funciona bem, independentemente do valor de DISCOURSE_FORCE_HTTPS ou SiteSetting.force_https.
edite: apesar de não entender o que force_https está realmente fazendo para nós (talvez não faça nada se os modelos SSL não estiverem incluídos?), ocorreu-me que a configuração do túnel provavelmente não funcionaria como está se o discourse realmente redirecionasse tudo para https. Se fizesse isso, o argotunnel não conseguiria acessar o discourse com http (como service: http://dc:80), então talvez eu devesse:
service: https://dc:443)De qualquer forma, talvez seu guia de argotunnel pudesse ser atualizado para levar isso em consideração?
Você está certo. Eu não tinha notado que meu TLD de teste .dev é apenas HTTPS:
Atualizei o guia dizendo às pessoas para usarem uma regra de página para isso, obrigado pelo relatório!
mas tenho uma pergunta..
vejo alta visualização anônima em Consolidated Pageviews, acho que por causa de ddos porque o servidor de cpu chegou a 60% e o crawler é apenas um pouco.. mas como proteger de ddos.. obrigado antes pela resposta
se você usar o cloudflare como um proxy reverso (algo separado do cloudflared/argotunnel), você já terá alguma proteção contra ddos. habilite-o com a ‘nuvem laranja’ em seus registros de dns.