Primeiro, tentei executar o Discourse com configurações semi-padrão e funcionou muito bem, pude fazer upload de arquivos e outras coisas.
Então percebi que o caminho em app.yml era /var/discourse e o atualizei para /var/www/discourse, parei e destruí o contêiner, removi completamente a pasta anterior. E o coloquei para funcionar novamente… mas notei que agora não consigo mais fazer upload de arquivos.
Que tipo de permissões a pasta uploads precisa? Posso fazer algumas alterações manualmente, mas gostaria de saber exatamente o quê e se está tudo bem em geral (o lançador não deveria cuidar de definir as permissões corretas, especialmente quando iniciado do zero?)
O caminho /var/www/discourse é o caminho para o discourse dentro do contêiner. /var/discourse é o caminho normal para o Discourse_docker fora do contêiner.
Como você acabou de começar, eu recomendaria que você apenas recomeçasse e não renomeasse nada desta vez.
Minha suposição é que você não atualizou o caminho em seu app.yml e, portanto, ele está tentando acessar algo que não existe.
Tenho muitos outros projetos neste servidor e todos eles estão bem localizados na minha pasta /var/www, então prefiro mantê-lo assim E não me importo como é dentro do contêiner.
Mas eu atualizei? Em mounts, ou onde mais deveria ir?
Ok, nada funcionou, então acabei mudando as permissões para a pasta uploads para 755 e agora está tudo bem. Após a reconstrução, parece que os uploads em si estavam ok (do lado do engine), no entanto, o nginx não conseguiu lê-los.
Eu não entendo totalmente por que você está fazendo tudo isso. É sua escolha colocar o contêiner em um caminho que será visível mundialmente se você cometer um pequeno erro, mas essa é sua escolha. Mas todo o resto… por quê?
Ter um proxy reverso na frente do Discourse é realmente trivial e, de outra forma, sua configuração seria uma instalação padrão sem toda essa confusão. Claro, se você quer brincar e esse é o seu hobby, mas em breve alguém aparecerá e dirá que você só pode obter suporte para a instalação padrão e o maior problema é que ninguém realmente sabe o que você fez. Ou por quê.
Você está corrigindo um problema que surgiu ao tentar fazer outra coisa, algo que um padrão exigiria. Mesmo com um proxy reverso.
É por isso que você está bem longe do padrão Porque existem duas opções:
você tem um bug em mãos que ninguém mais tem
você fez algo engraçado
Talvez seja um bug. E você confirmou isso fazendo uma instalação padrão usando um caminho seguro (de muitas maneiras) e, ao mesmo tempo, conectando seu proxy reverso da maneira correta. Porque se ainda estiver quebrado, aposto que o problema está no host virtual e/ou nas portas. Mas se funcionar… então voltamos à opção “engraçada” — onde ninguém sabe o que você fez.
Você vê o problema aqui?
De qualquer forma — usar um proxy reverso leva a nenhum suporte… essa é a política aqui. Mas outros usuários podem e, com bastante frequência, ajudar.
E não me importo como é dentro do contêiner.
A situação é a mesma com o contêiner docker.
