Oh man that’s tragic. So sorry to hear 
7 curtidas
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam e este tópico deixam claro, isso nunca será resolvido embora o bitnami tenha acabado de fazer isso…
Pelo menos obtivemos uma resposta à nossa pergunta, que é não.
E quanto a evitar o uso do root em primeiro lugar? Usar fakeroot mostra que o principal obstáculo são os caminhos codificados (como /var). Caso contrário, exceto pelos vários bugs e problemas que a configuração atual tem, poderia funcionar.
É uma pena ver um software tão bom ter um procedimento de configuração obrigatório tão mal projetado, baseado em um mal-entendido comum de conteinerização. Está claro para mim que foi feito com as melhores intenções; ainda assim, o resultado é algo que não pode ser implantado em nenhum lugar fora de um ambiente de hobby.
1 curtida
Nossa imagem é executada como usuário do discourse, e acho que a oficial também.\n\nMas, de qualquer forma, é ótimo que o mundo "corporativo" esteja interessado, pois tem muito mais tempo/dinheiro do que o do hobby 
Tenho certeza que a comunidade apreciará sua contribuição para melhorar o ecossistema!
1 curtida
Isso certamente não está correto, implantamos nossa imagem usando nomad em frotas de máquinas, existem mais de 10.000 contêineres discourse em execução na aws e metal neste exato momento
3 curtidas
As ferramentas exigem acesso root para serem executadas e precisam ter acesso ao /var do host.
Frequentemente colaboro com comunidades e empresas de código aberto para melhorar suas configurações de contêineres. Terei prazer em ajudar e/ou considerar financiamento para ter uma configuração conteinerizada mais razoável.
Não é obrigatório. É apenas que, se você precisar de ajuda para configurá-lo, essa é a maneira de fazer isso. Ajudei clientes usando gke, eks, ecs, por exemplo. Sinta-se à vontade para entrar em contato comigo se precisar de ajuda com seus requisitos específicos.
/var não está codificado; trabalhei com alguém recentemente que o tinha em /var/www/discourse (o que parecia uma péssima ideia, pois corre o risco de servir dados secretos para a web, mas era uma “política”).
Não é mal projetado, é mal projetado se você fosse projetá-lo hoje em vez de uma década atrás. Foi um bom design na época, e ainda funciona para executar sua infraestrutura e até mesmo para muitas pessoas que não sabem nada sobre administração de sistemas.
2 curtidas
Eu acho que você não está contando com as ferramentas oficiais como discourse-setup, que requer root para ser executado, e provavelmente é destinado a uma configuração local.
Dê uma olhada no código-fonte do discourse-setup. Se você está familiarizado com a configuração e o ajuste de desempenho do Discourse, então não é obrigatório.
O Launcher faz todo o trabalho pesado para construir a imagem a partir do yml resultante.
2 curtidas
Tudo pode ser feito, mas me parece um esforço desnecessário.
- Use
fakerootantes de cada comando /varpode ser alterado editando o arquivo yaml:sed -i \"s;host: /var/discourse;host: $PWD/discourse;g\" containers/*.yml--skip-connection-test(encontrado olhando o código, pois o script não consegue verificar a conexão se houver um proxy reverso)- Vejo algo relacionado ao certbot que sei que precisarei descobrir como desabilitar, já que o SSL offloading geralmente é feito externamente
- As portas em
containers/app.ymlpodem ser alteradas para que portas>= 1024sejam usadas, mas isso não parece ser suficiente:Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
Não quero ser indelicado, mas ter múltiplos serviços rodando em um único contêiner sempre foi um mau design, pois significa ter pouca ou nenhuma maneira de saber o que está acontecendo com os serviços individuais, ter que configurar um mecanismo personalizado de análise de logs fora do Docker, healthchecks inúteis, não poder depender facilmente de um banco de dados externo, etc. Pode ser feito se esse for o único serviço que você executa em seu negócio, mas se todos os outros serviços começarem a fazer isso, a maioria dos benefícios de usar contêineres simplesmente desaparece.
Ficarei feliz em enviar alguns PRs e documentação para fazer o Discourse funcionar em um ambiente compatível com Docker sem acesso root, mas desacoplar os serviços e ter uma configuração padrão seria uma tarefa árdua sem garantia de que seria incorporada.
Se você discorda de aspectos fundamentais de como o Discourse é construído, você considerou usar um produto diferente?
3 curtidas
Ok, entendi melhor.
O Discourse tem uma opinião forte sobre as ferramentas para auto-hospedagem. Isso permite que eles forneçam suporte eficiente à maioria dos administradores menos experientes que desejam implantar o Discourse. Você pode concordar ou não, eu também fiquei um pouco triste no passado, mas agora entendo melhor 
Se você tem uma necessidade diferente de uma configuração rápida e funcional como a maioria das pessoas, então você está por conta própria. Uma vez que você sabe disso, tudo bem
Temos a mesma necessidade de uma imagem Docker autônoma do Discourse. Nós a executamos no Kubernetes com Minio, foi um pouco complicado para colocá-la em funcionamento, e ainda é muito esforço. Recebemos uma ajuda valiosa do Discourse também para fazer isso.
Nosso trabalho está disponível aqui:
https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
(não é documentado o suficiente, nem testado, nem mantido ou atualizado a tempo, nem automatizado, e provavelmente um pouco personalizado, é o que é)
Se as pessoas estiverem interessadas em melhorá-lo, não hesite em fazer um PR, ou conversar aqui: https://matrix.to/#/#libresh:liiib.re
Mas sim, a equipe do Discourse tem uma opinião forte sobre a versão comunitária do Discourse. Você pode concordar ou não, mas eles fornecem a maior parte do suporte às pessoas, e pelo pouco que vi, é um suporte incrível, então acho que foi uma boa decisão
6 curtidas
Estes são aspectos fundamentais de como o Discourse é empacotado, mais do que o próprio Discourse, que é um ótimo software, mas você está certo, devo considerar diferentes soluções.
2 curtidas
Sinta-se à vontade para remover os modelos para postgres e redis (bem como ssl e let’s encrypt) e usar os seus próprios.
2 curtidas
Obrigado por compartilhar. Eu também encontrei GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar e imagens da bitnami. O principal problema é que essas soluções não são oficialmente suportadas. Eu me pergunto se poderia ser uma ideia ter uma configuração Docker alternativa suportada pela comunidade, em vez de ter vários repositórios personalizados, pois não seria eficiente espalhar o esforço por vários lugares.
1 curtida
Você está certo, as configurações podem ser alteradas mesmo. Se eu conseguir fazer funcionar sem grande esforço, tentarei enviar alguns PRs para melhorar as ferramentas ou a documentação existentes, como executá-lo sem root. Isso deve ser compatível com as opiniões da equipe de desenvolvimento, ao mesmo tempo que traz algum alívio para alguns administradores de sistema mais exigentes.
9 anos depois, parece que o docker idiomático é coberto pelo discurso da bitnami?
Mas em outros lugares neste fórum há alegações de que ele consome muita memória e não é suportado. Fiquei surpreso ao ver quanta dificuldade ainda existe na configuração canônica ao tentar colocá-lo em funcionamento na nuvem.
Muitos serviços hoje em dia, como redis, postgres e armazenamento compatível com s3, são fáceis de configurar e mover entre diferentes hosts como digitalocean, supabase, aws, etc., então o backend é portátil. A VM que executa o discourse parece que também deveria ser fácil de escalar/trocar com compilações determinísticas. É uma pena que esteja tão perto desse ideal, mas impedido.
Como outro usuário disse, isso é surpreendente:
A lógica aludida anteriormente no tópico de que tornar isso mais fácil pode prejudicar oportunidades comerciais é estranha. Interesses comerciais terão pessoal para lidar com as compilações complexas, então isso afeta mais os desenvolvedores solo do que qualquer outra pessoa. Meu caso de uso pessoal é que gerencio uma comunidade muito grande (sem fins lucrativos). Portanto, ela não se enquadra em hobbyista por escala ou comercial por receita.
1 curtida
Eh… Estou pensando em configurar um fórum/quadro de comunidade e obviamente pensei em usar o Discourse (porque gosto da experiência do usuário final), mas novamente me deparei com o obstáculo da instalação/gerenciamento completamente hostil…
Ao longo dos anos, fiquei super apegado a ter tudo rodando com um simples arquivo docker-compose, adicionando alguns elementos extras (banco de dados, minio para armazenamento compatível com s3 e o que mais for), mas não… o Discourse ainda é super hostil neste caso.
Desculpe, mas ter algum “launcher” bobo para iniciar as coisas?
E então o processo de atualização afirmando:
Crie uma nova imagem base manualmente executando:
./launcher rebuild my_image
desculpe - reconstruir a imagem manualmente? Tipo WTF… é como ter/usar docker, mas na verdade não usá-lo…
./launcher rebuild app funciona? Esse é o comando usual.
Além disso, você seguiu o guia de instalação padrão?
Não tenho nada construtivo a comentar, então peço que tentem atualizar o servidor Mastodon, Pixelfed, Moodle… O Discourse é incrivelmente fácil.
Um comando manual é um obstáculo 
2 curtidas