Alguém poderia me aconselhar sobre como construir uma imagem Docker do Discourse que já tenha vários plugins incorporados, em vez de instalá-los através da interface do usuário?
Contexto - queremos utilizar a versão mais recente do Discourse, ou seja, discourse:stable, e pelo que li no guia de instalação e outra documentação, podemos usar esta como imagem base em nosso próprio Dockerfile e, em seguida, fazer algo como:
RUN cd /var/www/discourse/plugins && \
git clone https://github.com/discourse/discourse-chat-integration.git
Isso adicionaria o plugin discourse-chat-integration à compilação. Em seguida, em tempo de execução, podemos passar todas as variáveis de ambiente necessárias, ou seja, DISCOURSE_HOSTNAME, DISCOURSE_SMTP_DOMAIN, DISCOURSE_DB_HOST, etc., em vez de tê-las codificadas no arquivo app.yml.
Se alguém puder aconselhar sobre o acima, ficaria muito grato.
Você não pode instalar plugins pela interface do usuário. Você os instala a partir do arquivo YML. Se você estiver usando algum contêiner ainda não suportado que você não construiu com o launcher, então você faria algo como você sugere.
Mas esse plugin está no core (mas talvez ainda não na versão stable)?
Eles não são realmente codificados no arquivo YML. O arquivo yml é usado para construir e iniciar o contêiner. Você pode construí-lo e depois iniciá-lo como quiser. Você pode usar ./launcher start-cmd nome-do-container (ou algo parecido com isso, você pode verificar no launcher para ver se errei).
Então, o que eu acho que você quer fazer é continuar usando o launcher, adicionar o plugin, executar ./launcher bootstrap app no contêiner e, em seguida, iniciá-lo como quiser. Você pode até enviá-lo para um repositório onde pode iniciá-lo a partir de outra máquina.
Portanto, o que estamos tentando fazer é rodar o Discourse no nosso cluster Kubernetes e gostaríamos de ser capazes de construir a imagem no nosso fluxo de trabalho de CI/CD, daí o Dockerfile personalizado. Todas as variáveis de ambiente são então fornecidas ao pod em execução em um ConfigMap e/ou Secret. Eu sei que esta não é uma instalação suportada, mas estou tentando pelo menos usar a maneira suportada de construir uma imagem do Discourse para uma versão específica do Discourse para que possamos controlar quando atualizamos.
Analisando o script launcher existente e o samples/web_only.yml, acredito que posso comentar as seções volumes e links, pois isso seria feito no Kubernetes com um Volume Persistente e montagem. Em seguida, adicionaríamos os valores de ambiente fixos no web_only.yml, construiríamos o contêiner com o comando de inicialização e, em seguida, copiaríamos a imagem gerada para o nosso próprio repositório.
Quanto à versão do Discourse, podemos monitorar quando uma nova versão está disponível no Docker Hub e, em seguida, alterar o valor de base_image no arquivo web.template.yml.
Talvez, mas o contêiner precisa se comunicar com algum banco de dados para construir o contêiner, geralmente. Não precisa ser o banco de dados real (mas então você precisa migrar o banco de dados e pré-compilar os ativos no seu pipeline).
Você pode estar confundindo a questão das atualizações do Discourse com as atualizações dos recursos no contêiner base.
Eu consegui fazer o contêiner compilar sem o hook db:migrate - não sei se vai funcionar, pois ainda não testei - está na lista de tarefas
Para o valor de base_image - presumo que isso mude quando uma nova imagem docker for lançada, então acho que vou apenas pegar o que estiver no branch principal, pois é o que é chamado no script do launcher.
Isso é um bom começo! Você ainda precisará migrar seu banco de dados ao iniciar um novo Discourse.
Não há motivo para obter uma nova imagem base se você não estiver atualizando o Discourse. Então, você realmente não se importa se houver novas imagens base.
Obrigado, Jay. Finalmente consegui fazer meu build funcionar, bem, o pod iniciou Eu mudei meu processo de build de CI/CD para incluir o db:migrate usando um banco de dados temporário.
Um db:migrate precisa sempre ser executado na inicialização, já que a construção da minha imagem seria contra um banco de dados/redis fictício? Minha abordagem atual é que o db:migrate e a pré-compilação seriam realizados em um initContainer no meu pod.
A imagem discourse/discourse seria ideal de usar se estiver pronta para produção em breve.
Se você estiver interessado em atualizações com tempo de inatividade zero, você deve usar SKIP_POST_DEPLOYMENT_MIGRATIONS e, depois que os pods antigos forem encerrados, executar a migração novamente com algo como rake db:ensure_post_migrations db:migrate
Atualmente, estou definindo várias variáveis de ambiente em nossa implantação, como DISCOURSE_BACKUP_LOCATION=s3, e meu entendimento é que o Discourse usará esse valor em vez do que foi definido pela interface do usuário e, portanto, armazenado na tabela site_settings - isso está correto? Se sim, existem ferramentas/scripts disponíveis que me permitiriam verificar quais variáveis de ambiente estão definidas e determinar seu equivalente na configuração do site?
Por quê - Estou procurando migrar uma instância do Discourse em execução e, para ajudar a minimizar o risco, queria não definir as variáveis de ambiente por enquanto, caso eu tenha esquecido alguma na nova instância e isso tivesse um impacto prejudicial na nova instância. Meu pensamento era verificar o que está definido na instância atual, criar as configurações relevantes na tabela, fazer backup/restaurar para a nova instância e, em seguida, remover as variáveis de ambiente uma de cada vez.
Lógico - talvez não, mas pensei que essa seria a abordagem mais sensata, caso uma variável de ambiente na instância em execução seja diferente/não suportada na nova instância (em execução = versão antiga do Discourse, nova = versão mais recente do Discourse).
Mais ou menos. Elas substituem o que está no banco de dados. Elas são gravadas em /var/www/discourse/config/discourse.conf ou algo muito parecido com isso.
