Do link acima, posso ver que imagens e anexos são armazenados em uma pasta compartilhada mais profunda na instalação do Discourse, não dentro do docker. Dado que eu gostaria de usar uma pasta de imagens vinculada simbolicamente do meu segundo armazenamento, que eu monto via NFS para outros servidores. E, em um servidor secundário, eu gostaria de executar o container docker do Discourse, como um meio de balanceamento de carga / failover…, e gostaria de usar a mesma pasta de imagens do NFS-mount. Eu já tenho o DB de outro servidor de rede, apenas por precaução.
Eu acabei de testar a configuração, mas o resultado não foi bom. Copiei todos os arquivos de imagem de /var/discourse/shared/standalone/uploads para /var/www/image/uploads
Então,
Criei links simbólicos para a pasta de imagens montada em NFS
chmod & chown com www-data:www-data e 755 para as pastas /uploads
Eu consigo ver as imagens no servidor primário onde a pasta de imagens está montada nativamente, mas não é o caso no servidor secundário montado em NFS. As imagens estão faltando com o tamanho do container.
Além disso, mesmo no servidor primário, eu consigo ver, mas não consigo baixar a imagem mais.
Eu acho que é devido à permissão de arquivo. Gostaria de saber qual é a configuração ideal.
Não tenho certeza se é vanilla ou devido a dezenas de reconstruções, mas as imagens na pasta padrão são 755/644 (pasta/arquivo) e main_id:www-data no meu servidor. Eu também copiei a mesma estratégia, mas não funcionou. Pode ser um problema específico de symlink ou NFS, mas não consigo mais rastrear.
Essa foi minha tentativa inicial. Dentro do Docker, descobri que o sistema de arquivos estava meio bagunçado, como eu havia percebido antes. Estava aninhado como /uploads/uploads/uploads antes de /default/ ser visto. Não tenho certeza do que realmente aconteceu, mas copiei todos os arquivos de dentro para o meu mount de imagem e adicionei a pasta de mount como um volume.
Aqui, a situação não foi muito diferente de um symlink. As permissões de arquivo realmente criaram o mesmo problema. Depois de entender que os arquivos são armazenados fora do contêiner Docker, pensei que um symlink poderia ser uma solução muito mais fácil.
Para ambos, tenho quase certeza de que é uma questão de permissão de arquivo, mas um CDN personalizado apenas com um bloco de servidor Nginx parece uma solução muito mais simples do que um volume Docker, desde que o symlink não funcione.
Tenho quase certeza de que nada de bom pode vir do uso de symlinks. Um problema é que é difícil ter o symlink igual dentro e fora do contêiner, e eu acho que seu problema de uploads aninhados está relacionado a isso. Já vi ser recomendado não usar symlinks e acho que é por isso.
O Discourse suporta CDN personalizada baseada em CNAME? Lembro-me de ter visto a configuração do S3 no admin e posts no meta sobre o Fastly, mas não consigo me lembrar da configuração de CDN personalizada.
Encontrei a postagem. Acho que preciso configurar uma versão auto-hospedada de CDN compatível com S3. Um simples servidor de imagem Nginx não é suficiente.