Essa foi uma observação sobre o motivo pelo qual a amostra de composição que postei não estava usando a imagem PG genérica.
Hmm… mas você não diria que isso torna outras maneiras mais complexas?
entendi! 
Como um guru do Docker, tudo isso deveria ser muito fácil para você?
3 curtidas
Como estou tentando explicar nos últimos dias, com a solução atual fornecida, isso torna tudo, menos fácil 
Resumindo;
Uma imagem simples do Discourse (semelhante à da Bitnami) com um monte de variáveis de ambiente para configurar coisas básicas (como acesso ao Redis, banco de dados) seria mais do que suficiente, mas por algum motivo isso é totalmente inviável… 
Estou compartilhando provas de conceito aqui para fazer exatamente isso.
Para um plugin simples, com certeza, mas não podemos presumir que um plugin terá uma determinada aparência - alguns plugins precisam de configuração adicional, gemas extras para instalar, ou dependências de gemas extras ou programas externos que exigem um apt-get install. Isso deve ser incorporado a uma imagem personalizada.
Seria ótimo ver isso feito, mas não é trivial.
re: Atualização da Web, os operadores do Discourse também não devem saber nada sobre CLI ou docker.
1 curtida
Você só precisa construir sua própria imagem com o launcher (o que você pode fazer com GitHub Actions), enviá-la para um repositório e iniciá-la com as variáveis de ambiente. Você ainda precisa migrar o banco de dados, pré-compilar os assets e enviá-los para o S3. Você pode migrar o banco de dados e usar skip_post_deployment_migrations para que o contêiner antigo possa continuar funcionando até que o novo esteja pronto, e então desligá-lo e executar o restante das migrações. Mas isso é muito complicado para alguém que não sabe muito mais sobre o Discourse do que acho que você quer saber. E há muitas, muitas coisas que podem dar errado, é por isso que a solução atual, que é horrível por todos os motivos que você descreve, é a melhor solução para milhares de pessoas que não sabem o que é bash.
Na maioria das vezes, você só precisa executar ./launcher rebuild app, exceto uma vez a cada dois anos, quando precisa atualizar o banco de dados, então você tem que fazer isso duas vezes. Você simplesmente não consegue esse nível de simplicidade com o docker-compose. Há uma chance de que, se o docker-compose fosse utilizável quando eles começaram, eles poderiam tê-lo em vez de ter que criar o seu próprio, mas não foi assim que as coisas aconteceram.
Se você quiser usar a imagem do Bitnami, pode, mas não pode obter muita ajuda aqui. Aposto que funciona para muitas pessoas também.
1 curtida
hmm… para uma linguagem/ambiente que deveria ser universal e independente de plataforma, depender do gerenciador de pacotes do sistema operacional subjacente parece bastante estranho… 
É a isso que me referi anteriormente, que o Discourse parece estar firmemente fixado na maneira “antiga” de gerenciar software/fóruns PHP
Então, para resumir toda a discussão (e possivelmente colocar isso na primeira mensagem para evitar repeti-la ad nauseum ):
- O Discourse é adaptado e focado em “pessoas comuns” e toda a configuração é voltada para atender às suas necessidades
- Dado o quão estranho é o Ruby (ambiente) e (1) é virtualmente impossível fornecer imagens docker oficiais genéricas o suficiente no repositório oficial do Discourse
correto?
Eu diria de forma um pouco diferente
Dado que não há uma oferta oficial de imagem (por padrão) além do launcher, o que torna o launcher a maneira padrão e basicamente única (recomendada) de configurar o Discourse, pode-se argumentar que a declaração original ainda é válida
Mas isso são apenas semânticas.
De qualquer forma - o tópico é:
O Discourse pode fornecer imagens Docker frequentes que não precisam ser inicializadas
Pela discussão inteira, parece que: “Não, o Discourse não pode/não quer fornecer imagens Docker frequentes que não precisam ser inicializadas”, q.e.d.
Portanto, a sugestão de adicionar um comentário logo no topo, de que tal imagem não será fornecida, economizaria MUITO trabalho
Esta é uma suposição incorreta
Ainda não priorizamos o envio de uma imagem oficial com um pacote de plugins específicos
É um trabalho que estamos considerando, temos muitas ideias de como fazer isso, simplesmente não tem sido uma prioridade da empresa
5 curtidas
é um trabalho que estamos considerando, temos muitas ideias de como fazer isso, simplesmente não tem sido uma prioridade da empresa
[/quote]
tradução de uma pessoa trabalhando em outro projeto: “pode acontecer no futuro, mas pode não acontecer… dado que não é uma prioridade / não está em um roteiro, as chances de isso acontecer são mínimas ou nulas”
Embora, em um tom mais sério - uma configuração básica com um conjunto sensato de plugins agrupados seria muito legal!
Obrigado pela contribuição! <3
Para sua informação - configurei uma maneira para mim mesmo construir uma imagem do Discourse em um devbox e implantá-la em um servidor de uma forma que elimina a necessidade de usar o script launcher.
Mais discussões sobre isso aqui em um pull request que criei.
Configurei isso de forma a torná-lo totalmente compatível com a configuração oficial de docker do Discourse, para que você não precise se preocupar com esta solução ficando sem suporte ou quebrando.
O TLDR sobre como isso funciona é que fiz a imagem Docker responsável por executar comandos de bootstrap na inicialização (em vez do script launcher).
1 curtida
Abordagem legal.
Também: interessante launcher v2 (GitHub - discourse/launcher: Discourse Launcher CLI)!
2 curtidas