Depois de passar uma semana procurando uma solução para instalar o Discourse junto com o Apache, estou relutantemente pedindo conselhos sobre os próximos passos, pois parece que ativar um SSL para o Discourse atrás do Apache é praticamente impossível, dada a tendência do Discourse em priorizar o Nginx.
Estrutura atual do meu ambiente de hospedagem:
Droplet Digital Ocean de $10
Ubuntu 18.04
Apache com SSL Let’s Encrypt para a página inicial HTML
PHP, MySQL e phpMyAdmin
Webmin (sem SSL)
Discourse
Gostaria de manter a flexibilidade de instalar o WordPress, então não estou convencido de que o Nginx seja o caminho a seguir, pois li que o Apache mantém melhor compatibilidade com o WordPress.
Meu objetivo: ativar um SSL em todo o meu domínio, incluindo o Discourse, sem precisar migrar o Discourse para um droplet separado. Se isso exigir um uso limitado do Nginx, tudo bem. Só preciso de uma ideia de quais tutoriais procurar para resolver essa bagunça.
Estou procurando algo semelhante, mas vocês estão à frente no processo. Tenho algumas dúvidas sobre a configuração de vocês, se não se importarem em responder:
Vocês têm um proxy reverso?
O proxy reverso está fazendo SSL?
Os outros servidores não estão fazendo SSL e dependem do proxy reverso para isso, ou vocês estão aplicando defesa em profundidade, com cada servidor fazendo SSL?
A comunicação entre o proxy reverso e os servidores é feita exclusivamente por sockets e não por portas?
Para informação, realizei testes extensivos com Apache2 e nginx como proxies reversos na frente do Discourse em produção (usando sockets Unix) e o nginx não é “muito mais rápido”.
Nessa configuração, o nginx é “ligeiramente mais rápido”, mas a diferença de velocidade não é perceptível para o usuário.
Além disso, os testes do Google PageSpeed nas ferramentas para webmasters (Lightspeed), calculados em média ao longo do tempo, não mostram diferenças significativas entre os dois proxies reversos.
Esse comentário, para informação, não se baseia em teoria ou na repetição do que outros escreveram; baseia-se em testes reais em produção.
Executamos todas as nossas instâncias do Discourse atrás de proxies reversos Apache2 (originalmente eram proxies reversos nginx) porque gostamos de hospedar muitos sites (hospedagem virtual) em nossos servidores, onde já temos aplicativos LAMP hospedados.
Qualquer pessoa que deseje usar o Apache2 como proxy reverso em vez do nginx ficará bem! Esse fato torna o Discourse facilmente acessível a uma ampla base de usuários e hospedeiros (Apache2 e nginx).
@fzngagan Não estou começando do zero, e aquele tutorial é para CentOS, quando deixei claro em minha postagem que estou usando Ubuntu.
@EricGT Confira a solução que compartilhei em meu próprio tópico, porque encontrar suporte se você usar algo diferente de Nginx ou CentOS é praticamente impossível — como evidenciado por este tópico, onde não recebi respostas para minha pergunta, mas sim um debate fora do tema sobre Apache versus Nginx.
Isso pode até ser verdade, mas o Apache tem suporte mais amplo. O Discourse é o único software de fórum que essencialmente força o uso do Nginx aos seus usuários. É por isso que prefiro me manter no Apache, pois é mais comum, mais fácil para novos usuários e o suporte será muito mais fácil de encontrar. “Ajustes finos” não é algo que me interesse.
No entanto, a comunidade do Discourse desencoraja ativamente essa prática e se recusa a oferecer suporte a quem deseja fazê-lo, com exceção de links para tutoriais não suportados. Criei vários tópicos e fiz ainda mais perguntas, mas você foi o único que chegou remotamente perto de oferecer suporte (em outro tópico) ao compartilhar sua configuração; como iniciante, esperavam que eu decifrasse e aplicasse isso ao meu próprio caso. Tudo o mais foi “veja este tutorial desatualizado” ou conversas fora do tema.
Bem, como afirmamos claramente várias vezes, há um limite para o que podemos oferecer gratuitamente aqui, devido a restrições de tempo e saúde mental. É por isso que temos uma instalação padronizada que funciona bem para 95% das pessoas que a testam, e damos suporte total a ela.
Se você gostaria de explorar opções de suporte pago para instalações personalizadas, recomendo o Marketplace.
Este fórum é amplamente peer-to-peer, então sua declaração não faz o menor sentido. Além disso, ainda não fiz nenhuma pergunta complexa, apenas solicitei esclarecimentos ou atualizações para tutoriais existentes que continuam sendo vinculados, mesmo estando desatualizados ou incorretos. Tive que obter assistência da DigitalOcean, um provedor de hospedagem, para configurar um proxy reverso adequado. Isso é de deixar qualquer um de queixo caído, mesmo para software de código aberto.
Sua resposta me dá a impressão de que o “suporte” aqui é apenas uma farsa para vender mais.
Primeiramente, utilizamos o Discourse em produção atrás de um proxy reverso Apache2 (em mais de uma instância) e não tivemos nenhum problema na configuração; além do normal “buscar no Google quando precisar de ajuda”, que todos fazem sem hesitação.
Segundo, nunca pedi à equipe do Discourse ou a qualquer pessoa no meta que oferecesse suporte ao Apache2 como nosso proxy reverso, pois essa configuração não é oficialmente suportada. O Discourse não (que eu saiba) “oficialmente” suporta configurações multi-container, proxies reversos (Apache2), Kubernetes, Docker Swarm e um número quase infinito de outras configurações. É compreensível e correto que a equipe do Discourse, que disponibiliza esse excelente software gratuitamente e torna todo o código, cada commit no Github, de código aberto, limite suas “configurações oficialmente suportadas.” Achei que Jeff resumiu isso de forma muito adequada e correta:
Bem, como deixamos claro várias vezes, há um limite para o que podemos oferecer gratuitamente aqui devido a restrições de tempo e sanidade. - Jeff A.
Terceiro, o Discourse oferece vários tutoriais para configurações “não suportadas”, como o uso do Apache2 como proxy reverso; no entanto, configurar um proxy reverso não é uma “tarefa do Discourse” propriamente dita. Configurar um proxy reverso é uma “tarefa genérica de administração de sistemas”, que é basicamente a mesma para qualquer aplicativo back-end, incluindo o Discourse.
Executamos o Apache como proxy reverso na frente de vários aplicativos web, incluindo Discourse, Docker Registry e outros contêineres e aplicativos Docker. O uso do Apache2 (ou nginx) como proxy reverso não é específico do Discourse. É uma tarefa genérica de administração de sistemas.
Quarto. Há uma infinidade de informações na internet sobre como configurar o Apache2 como proxy reverso para um aplicativo. É totalmente desnecessário e inútil para a sua causa intimidar a equipe do Discourse sobre esse assunto. Intimidar pessoas e usar termos como “farsa” é impreciso e não ajuda a sua causa (ou a ninguém aqui).
Portanto, para resumir para você, @OrbitStorm (este é meu último post no seu tópico, então leia com atenção), o que já foi dito antes, incluindo as palavras gentis e pacientes de J. A., você tem muitas opções:
Você pode facilmente ir à internet e aprender como configurar o Apache2 como proxy reverso (é o que fizemos), e é divertido e gratuito para você aprender a realizar essa tarefa genérica de administração de sistemas.
Você pode contratar alguém para fazer isso para você se não estiver disposto a aprender, ou não conseguir “descobrir sozinho”, ou não tiver tempo.
Você pode postar aqui e reclamar, chamando o meta e este fórum de “farsa” e lançando insultos a todos na tentativa de intimidá-los para que o apoiem pessoalmente em uma configuração não suportada.
Recomendo fortemente, como usuário do Discourse e administrador de sistemas há várias décadas, que você não escolha a opção #3 (intimidação e bullying não funcionarão com a equipe do meta, posso assegurar isso); e considere a opção #1 se não quiser gastar dinheiro com ajuda.
Configurar o Apache2 como proxy reverso para o Discourse é realmente bastante fácil. Existem alguns posts no meta do Discourse sobre isso (alguns atuais, outros desatualizados) e inúmeros tutoriais na internet sobre como configurar o Apache2 como proxy reverso para um aplicativo web. A técnica é a mesma. Recomendo expor um socket Unix ao executar no modo proxy reverso.
Sinceramente, é divertido configurar o Apache2 como um host virtual proxy reverso para o Discourse. Por que tornar isso estressante e postar insultos contra as pessoas que criaram esse excelente software e o disponibilizam gratuitamente? O Discourse é um presente gratuito! Se você quiser configurar o Discourse de forma diferente das configurações oficialmente suportadas, ninguém vai impedi-lo!
Para encerrar, @OrbitStorm, aconselho fortemente (falando como usuário do Discourse, não como membro da equipe) que você mude sua abordagem de intimidar o meta para obter suporte. Como disse, executo o Discourse em configurações “não oficialmente suportadas” e já publiquei atualizações e código aqui para ajudar outros (retribuindo a essa grande comunidade). Já publiquei código funcional, fácil de seguir, para configurar o Apache2 como proxy reverso, assim como outros antes de mim.
Por favor, escolha entre a opção #1 (faça você mesmo) ou #2 (contrate alguém para fazer); e abandone sua abordagem atual da opção #3 (intimidação, bullying e insultos à equipe do meta). Se quiser escolher a opção #3, vá postar em nossos fóruns de Unix e Linux e pode me intimidar lá se quiser, à vontade
Você montou esse muro de texto em resposta sem nunca realmente abordar o tópico original, em uma tentativa vã de defender algo que nem está sendo atacado. Você me rotulou de “bully” (rs?) porque respondi a um nonsense fora do tópico vindo de um cara que me bombardeou com ataques ad hominem sobre inteligência e transformou este tópico em seu pedestal para falar de Nginx (comentários que foram convenientemente apagados para esconder evidências da natureza tóxica que este fórum cria em relação a novos usuários). Seu primeiro post não foi muito diferente, pois respondeu à minha pergunta sem realmente respondê-la. Você faz parte do problema.
Você continua falando de obrigação, mas aqui está, respondendo persistentemente aos meus tópicos apenas para ser argumentativo (como Stephen fez). Não sabia que existia uma regra proibindo-me de pedir suporte para uma configuração de hospedagem popular (o W3Techs foi citado anteriormente e mostra 67% de participação para o Apache). Você poderia simplesmente ter deixado meus tópicos sem resposta se não aprovasse, mas escolheu ser beligerante e desviar a conversa.
Você está distorcendo intencionalmente minhas palavras porque não estou me conformando ao status quo de aceitar um tutorial desatualizado e nunca mais retornar — um fator pelo qual virtualmente todos os tópicos sobre essa configuração ficam sem solução (ou seja, assédio de caras como você). Você realmente acha que não fiz minha due diligence antes de postar? Eu aceitei o que sabia que viria, mas esperava que outros que pudessem estar na minha posição (como EricGT) pudessem oferecer algo de valor antes que tudo fosse esmagado com respostas pomposas.
Estou na desenvolvimento de jogos há 16 anos e nunca experimentei um nível tão insano de falta de profissionalismo e mesquinhez como aqui, em apenas cinco dias curtos. Isso é uma cornice no nível do Reddit; uma piada absoluta.
Não consigo entender por que a configuração SSL teria algo a ver com os aplicativos atrás do proxy , desde que o template SSL esteja desabilitado no app.yml? nginx, apache, haproxy ou traefik, todos têm o mesmo conceito de snippet/bloco de servidor/virtualhost, onde basicamente você especifica ssl on, depois onde estão localizados seus certificados no seu host e alguns parâmetros SSL, aqui há dragões talvez?
Acho que a solução que você está procurando não é relacionada ao Discourse, mas ao Apache, e acredito que qualquer configuração SSL pronta para uso do Apache com virtual host funcione bem com o Discourse, assim como funcionou com outros proxies reversos, mas posso estar um pouco otimista .
Embora eu me lembre de ter tido um problema com os cifras talvez, você deve ter certeza de copiar/colar com cuidado (a linha é muito longa) aqueles em uso dentro do contêiner Docker.
Sobre essa encosta escorregadia, acho que é meio como esqui fora de pista, é ótimo, mas é muito malvisto pelo resgate de montanha, e admito que é razoavelmente diferente quando você cai em um barranco enquanto ainda está aprendendo se é um esquiador experiente.
Por favor, profissional ou não, seja gentil com o
, desde que o template SSL esteja desabilitado no app.yml? nginx, apache, haproxy ou traefik, todos têm o mesmo conceito de snippet/bloco de servidor/virtualhost, onde basicamente você especifica ssl on, depois onde estão localizados seus certificados no seu host e alguns parâmetros SSL, aqui há dragões talvez?
.