Imagem docker oficial "cloud native" do discourse

Olá,

A equipe recentemente removeu o suporte para desabilitar o long polling pela interface. Isso quebrou a funcionalidade necessária para a imagem docker bitnami, que usa passenger e não funciona, veja https://github.com/bitnami/bitnami-docker-discourse/issues/177. A imagem bitnami não passa parâmetros de ambiente diretamente, então isso está quebrado até que alguém estenda a imagem bitnami, veja DEV: Drop `enable_long_polling` and `long_polling_interval` settings by tgxworld · Pull Request #16323 · discourse/discourse · GitHub.

Claro que a questão surgiu para mim, já que o discourse já é distribuído apenas com um container docker: Há alguma chance de a equipe manter uma imagem docker “cloud native”?

A grande diferença entre a imagem bitnami e a sua é o modo de operação. A infraestrutura moderna espera que você possa automatizar a instalação. Geralmente em k8s feito com helm, mas também implantações ansible em ambientes mais tradicionais com VMs resultariam no mesmo resultado. Então, o que realmente tornaria o discourse comparável à imagem bitnami, que é bastante negligenciada, seria adicionar uma rotina de auto-instalador e talvez até adaptar o template helm.

Já que estou aqui, gostaria de deixar alguns comentários sobre o discourse em si e sua “prontidão para nuvem”:

Em geral, quando tentamos integrar o discourse a uma configuração reproduzível para um projeto atual de cliente, ficou bastante claro que o discourse nunca foi feito sob os aspectos da infraestrutura moderna. Um exemplo é a necessidade de um armazenamento NFS compartilhado. Isso não é confiável nem escalável. Felizmente, a maior parte disso já pode ser redirecionada para um S3, mas restam partes que são os plugins.

Existem três maneiras de resolver o problema dos plugins:

  • Código avaliado armazenado no banco de dados (não recomendado)
  • Contêineres sidecar pré-empacotados (em termos de kubernetes, seriam usados como initContainers escrevendo em um emptyDir) escrevendo em um armazenamento volátil (ou seja, tmpfs) antes do início do contêiner discourse (recomendado, embora não seja super confortável)
  • Uma rotina de instalador, obtendo informações atuais de plugins e seus comandos de instalação do banco de dados na inicialização e uma rotina de observador/ouvinte para instalar plugins em tempo de execução também (não recomendado, pois é super lento e propenso a erros)
3 curtidas

Eu acho que isso já foi discutido extensivamente aqui:

3 curtidas

Sinceramente, como a Bitnami resolveu isso facilmente, não há muito motivo para discutir tanto sobre isso. Não seria ciência de foguetes tornar o Discourse facilmente implantável.

Só queria apontar que executamos muitos sites Discourse em ambientes de nuvem e não usamos armazenamento NFS. Ativos e uploads são tratados via armazenamento de objetos (S3) enquanto o código-fonte (core e plugins) são persistidos na imagem do contêiner inicializada.

4 curtidas

Bem, isso já foi respondido: Felizmente, a maior parte disso já pode ser redirecionada para um S3, mas restam partes que são os plugins. Construir um contêiner antecipadamente para uso é uma má prática, pois aumenta o risco de não atualizar corretamente os gráficos do Helm utilizados.

Você pode, por favor, elaborar sobre isso? Não vejo como os plugins exigem armazenamento NFS compartilhado.

Peço desculpas, mas já temos este tópico épico para discutir isso.

Não quero desmembrar isso. Se houver alguma ideia, ela deve ser discutida em:

3 curtidas