Alguém configurou com sucesso o Discourse rodando em um vhost do Apache, em vez do padrão Nginx?
Parece que a maioria das discussões sobre o Apache nesses fóruns trata de executar o Discourse em um host que já possui o Apache instalado. Em todos os casos que vi, as pessoas apenas fazem o proxy do Apache de volta para o Nginx. Para ficar claro: eu quero que o container de backend do Docker que executa o Discourse utilize o virtual host no Apache, e não no Nginx.
Especificamente, espero rodar o backend do Discourse no Apache em vez do Nginx para habilitar o mod_security. Configurar o Nginx com o mod_security exige compilar o Nginx a partir do código-fonte — uma complexidade que gostaria de evitar.
Meu servidor de produção atual já está executando vários sites (WordPress, MediaWiki, etc). Usamos o Nginx para terminar o HTTPS e fazer uma limitação básica de taxa contra DOS → cache Varnish → backend Apache com mod_security. Se possível, gostaria de manter essa arquitetura para o Discourse — com o container Docker de backend do Discourse rodando o Apache com mod_security, e não o Nginx.
Alguém configurou com sucesso o Discourse para rodar no Apache?
Desculpe, sou novo no Docker. Estou tendo muita dificuldade para entender como o arquivo ‘/etc/nginx/conf.d/discourse.conf’ é colocado no container Docker. Alguém poderia esclarecer os passos de como esse arquivo é gerado e inserido no container pelo script ‘./launcher’?
EDIT: espere, o Nginx já está sendo compilado a partir do código-fonte pelo Discourse?
Não, ninguém conseguiu. O Discourse está bastante integrado ao nginx. Será difícil, se não impossível, substituí-lo pelo Apache. E como você será a única pessoa fazendo isso, ninguém se importará quando algo der errado.
Basta usar o contêiner Docker que todo mundo no planeta usa e coloque o Apache na frente dele se achar que isso ajudará na segurança de alguma forma.
Parece que o arquivo /etc/nginx/conf.d/discourse.conf é gerado dentro do container a partir do arquivo de modelo /var/docker/templates/web.template.yml — que o copia para o local correto a partir de $home/config/nginx.sample.conf e, em seguida, aplica alterações por meio dos blocos YAML replace (que são posteriormente atualizados em modelos subsequentes, como templates/web.socketed.template.yml).
Eu assumia que o arquivo nginx.sample.conf fosse simplesmente instalado no local pelo nginx ao compilar a partir do código-fonte em image/base/install-nginx, mas o único arquivo nginx.sample.conf que encontrei no container (/var/www/discourse/config/nginx.sample.conf) já continha diretivas específicas do Discourse.
Para ficar claro: você acha que seria mais seguro para mim atualizar o script ‘image/base/install-nginx’ para compilar o nginx dentro do container Docker do Discourse com suporte ao mod_security, em vez de atualizar o container para executar o vhost do Discourse atrás do Apache (em vez do Nginx)? Se sim, quais são os riscos de eu modificar o script install-nginx? Como isso poderia quebrar minha instalação do Discourse no futuro?
PSA: Tudo o que você está propondo fazer, embora tecnicamente viável, é completamente sem suporte. Não podemos dar suporte razoável a todas as combinações possíveis que as pessoas inventam para hospedar o Discourse na web. Portanto, o suporte aqui neste fórum está restrito às instalações que seguem o guia discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub.
Eventualmente, isso quebrará de muitas formas. Você ficará responsável por mesclar continuamente com as alterações a partir da versão principal e manter seu fork para sempre.
@ledimeo Foi isso que @pfaffman sugeriu, e é o que acho que seria melhor neste caso, para não quebrar as coisas de forma grave no futuro quando novas versões forem lançadas. Mas parece que ele já usa outro nginx na frente como proxy reverso e não quer:
Dito isso, acho que fazer o proxy do apache para o nginx (mesmo que isso acabe resultando nessas 4 camadas) seria pelo menos mais sustentável do que tentar mudar a maneira como o Discourse funciona na instalação oficial.
Então, adicionar o Apache como proxy ao nginx do Discourse é definitivamente uma opção.
Concordo que um profissional tornaria futuras atualizações mais fáceis, e esse é um ponto importante.
Mas adicionar mais um salto à arquitetura não apenas tornaria a depuração de problemas no futuro mais complexa — também tenho preocupações sobre o desempenho do Apache como proxy para uma aplicação web que usa long polling, conforme apontado por @sam neste post de 2016.
Geralmente prefiro o nginx ao Apache, exceto quando se trata do mod_security. Seria fantástico se os repositórios do SO incluíssem pacotes para habilitar o mod_security no nginx, como fazem para o Apache, mas atualmente habilitar o mod_security no nginx requer compilar o nginx a partir do código-fonte tanto no RHEL/Cent quanto no Debian. E eu evito depender de pacotes compilados a partir do código-fonte em produção como se fosse uma praga.
Relacionado: Estive mexendo no script install-nginx e encontrei um pequeno erro de lógica: a linha de limpeza que deveria deletar o source do nginx de /tmp/ na verdade não faz nada.
Não há um diretório /tmp/nginx/: é /tmp/nginx-$VERSION/ (no momento é /tmp/nginx-1.17.4/ e há também o tarball /tmp/nginx-1.17.4.tar.gz).
Infelizmente, meu script atualizado /var/discourse/image/base/install-nginx não parece ser executado quando eu executo /var/discourse/launcher destroy app && /var/discourse/launcher rebuild app.
Há algum motivo para que o comando rebuild não reexecute o script install-nginx atualizado?
Se você não está familiarizado com o Docker, esse será um caminho difícil…
discourse_docker contém o código-fonte da nossa imagem base do Docker, que fica no registro público do Docker, nunca será executada localmente, e a razão para isso é ter uma imagem reutilizável.
Ok. Bem, menti sobre o vim para simplificar. Na verdade, estou executando esses comandos para atualizar o script de forma idempotente e robusta
cd /var/discourse/image/base
cp install-nginx install-nginx.`date "+%Y%m%d_%H%M%S"`.orig
# adiciona um bloco para fazer o checkout do módulo nginx do modsecurity logo antes de baixar o código-fonte do nginx
grep 'ModSecurity' install-nginx || sed -i 's%\(curl.*nginx\.org/download.*\)%# mod_security --maltfield\napt-get install -y libmodsecurity-dev modsecurity-crs\ncd /tmp\ngit clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git\n\n\1%' install-nginx
# atualiza a linha de configuração para incluir o módulo ModSecurity verificado acima
sed -i '/ModSecurity/! s%^[^#]*./configure \(.*nginx.*\)%#./configure \1\n./configure \1 --add-module=/tmp/ModSecurity-nginx%' install-nginx
# adiciona uma linha à seção de limpeza
grep 'rm -fr /tmp/ModSecurity-nginx' install-nginx || sed -i 's%\(rm -fr.*/tmp/nginx.*\)%rm -fr /tmp/ModSecurity-nginx\n\1%' install-nginx
Onde devo colocar esses comandos para que o script realinstall-nginx usado pelo contêiner durante a inicialização seja modificado?
