Imagem do Docker discourse/discourse é considerada segura e pronta para produção?

Olá!
Me cadastrei apenas para agradecer a todos pela ajuda, especialmente ao @featheredtoast.
Quase consegui fazer funcionar, mas o envio de e-mail não estava funcionando.
Acho que foi porque estou usando o Caddy como proxy reverso.

Agora, voltei a usar o Discourse separadamente dos outros serviços na minha configuração do Docker Compose.

Você sabe como fazer isso funcionar com o Caddy? Acredito que precise usar um exemplo com socket, mas não sei como modificar o app.yml dentro da configuração do Discourse no Docker Compose.

Um grande abraço a todos - Y

A menos que você esteja de alguma forma fazendo o Caddy fazer proxy do seu e-mail de saída, não acho que seja relacionado.

Você não precisa fazê-lo com socket; pode simplesmente referenciar o nome do Docker e/ou o IP. Discourse working with jwilder /nginx proxy & acme-companion - #7 by Steve_Emerson fala sobre o uso do modelo com socket e um monte de outras coisas.

Então, a resposta curta é não, não diretamente via docker-compose — é algo que eu gostaria de ver, mas o plano aqui é permitir que qualquer pessoa crie uma imagem base personalizada que possa ser compartilhada publicamente para impulsionar o progresso. Criar um plugin envolve clonar o repositório do plugin, executar bundle install, npm e recompilar o Ember… Isso não deve ser feito durante a inicialização.

Portanto, parte da ideia aqui é permitir que as imagens sejam construídas exatamente como a discourse/discourse — com o mesmo app.yml das versões suportadas do Discourse.

Como exemplo, estou construindo minha imagem pessoal com o resenha atualizando o app.yml principal para incluir o plugin aqui e, em seguida, enviando-a para um registro Docker externo (público!).

Se você estiver usando um serviço de e-mail externo, não acho que seu proxy reverso Caddy seja o problema. Diferentemente das builds atuais do launcher, a imagem discourse/discourse não vai te cobrar sobre a configuração das variáveis de ambiente de e-mail (mas ainda é necessário fazê-lo) — eu verificaria essas variáveis primeiro.

Consegui alterar o limite de tamanho de upload:

cat fix-upload-size.sh (que precisa ter permissão de execução com chmod +x):

#!/bin/sh
sed -i 's/client_max_body_size .*;/client_max_body_size 500m;/' /etc/nginx/conf.d/discourse.conf

no docker-compose.yml:

    volumes:
     - ./fix-upload-size.sh:/etc/runit/1.d/fix-upload-size

Consegui construir uma imagem, mas ‘apenas’ usando a versão ESR. Quando utilizo algo mais recente que isso, o processo de build exige um banco de dados e uma instância do Redis. Isso é intencional?

Existe alguma maneira de atualizar o Discourse para a versão mais recente ao usar esta imagem?

Estou usando-a para o fórum do grupo de pesquisa da minha faculdade e gostaria de atualizar para a versão mais recente do Discourse, mas a imagem não foi atualizada desde março. Qual seria a maneira recomendada de fazer a atualização?

Esse foi um efeito colateral não intencional de adicionar uma chamada para limpar atualizações da web travadas; estou trabalhando para resolver isso em breve por meio de FIX: run clear_stuck_web_upgrades during precompile stage · Pull Request #1055 · discourse/discourse_docker

Ótimo, obrigado!

Mas tenho outra pergunta: estou usando o Azure para estudantes e o Container Apps. Se eu de alguma forma atualizar dentro do aplicativo, tenho medo de que, se a instância onde o Discourse está rodando falhar por algum motivo, nosso fórum possa ficar desorganizado, pois ao reiniciar, provavelmente estará em uma versão anterior.

Mais uma vez, muito obrigado!

Isso é um risco — infelizmente, não há uma boa maneira de contornar isso, a não ser garantir que a imagem esteja atualizada se você estiver atualizando tanto no aplicativo quanto puxando imagens do repositório do Docker. Eu realmente não recomendaria fazer isso.

Enquanto isso, ainda estou organizando o repositório do Docker (há outro problema a ser resolvido aqui).