Imagem oficial do Docker com suporte da comunidade

Awesome! I’ve bookmarked this post, and if anybody asks how to run Discourse in Kubernetes or Swarm, I’ll be sure to point them at your images :+1:. Advantage of being not-an-employee: my word doesn’t have to carry the weight of being Official™.

They, on the other hand, benefit immensely from having One Official™️ Way of deploying Discourse. CDCK is not going to take on the load of maintaining a deployment system that they themselves don’t use and is massive overkill for most self-hosters. And if they don’t maintain it, they ain’t endorsing it. Brand protection demands it.

Thanks for creating this thread @pierreozoux!

I recently reached critical appreciation for discourse and got interested in hosting a deployment. I’m currently hosting JupyterHub, GitLab and Mattermost - everything through Helm charts and would very much like to do the same with Discourse.

Some background about Helm / Kubernetes:
A Helm chart is a set of configurable Kubernetes resources, and Kubernetes resources are for example a Deployment Kubernetes resource that makes a given docker image run at all time. Installing something can end up becoming a single line command + some configuration.

I would be happy to at least review code and make some PRs to fix various things in a Helm chart for discourse if it would be developed. I’m currently a maintainer of JupyterHub’s Helm chart and have various contributions to other charts.

I think it’s actually possible / feasible to break up Discourse into a set of kube pods, but have fun sizing the resource requirements for the web and sidekiq runners :slight_smile:

If insane levels of infrastructure failure tolerance is not a business requirement for you, just use the singleton fat container, it’s going to be order of magnitude cheaper & easier for the same level of steady state service.

Olá, pessoal!

Eu venho de uma comunidade italiana bastante grande que usa o Discourse como ferramenta para seu fórum.
Embora amemos o Discourse, também observamos algumas dificuldades ao implantá-lo no Kubernetes por meio de procedimentos “padrão”.

Sinto a dor dos mantenedores :slight_smile: Trabalhei na Open Networking Foundation por anos, e um dos maiores desafios foi migrar o CORD — uma de nossas principais plataformas — de instalações baseadas em scripts para Dockerfiles/docker-compose e imagens Docker hospedadas no DockerHub + helm-charts. Embora haja um medo razoável ao fazer isso, e se uma solução que se adapte a todos os casos nunca exista de verdade, posso dizer que vimos absolutamente os benefícios desde as primeiras implantações.

Geralmente, o maior passo a dar é entrar na mentalidade de deixar as ferramentas existentes fazerem o que fazem de melhor :slight_smile: O Docker tem procedimentos de instalação que são padrão, fáceis e já bem documentados. Scripts são algo personalizado, que frequentemente exige customizações e manutenção.
Além disso, realmente não há motivo pelo qual você não deveria poder usar as imagens Docker originais / helm-charts como dependências do Discourse (ou seja, unicorn, postgres, redis, …).

Sugiro abordar primeiro o básico (ou seja, ter um Dockerfile, docker-compose e uma build automatizada no DockerHub para cada componente). Uma vez que isso seja feito (com as modificações adequadas de software e documentação), o desenvolvimento dos helm-charts é a coisa mais fácil.

Ficarei muito feliz em ajudar, inclusive agendando uma chamada para discutirmos os prós e contras das soluções propostas acima.

Durante minha breve pesquisa, também notei que a Bitnami (super famosa no espaço Docker) lançou algumas imagens (https://github.com/bitnami/bitnami-docker-discourse#how-to-use-this-image). Fiquei me perguntando se isso foi um trabalho separado que eles realizaram sozinhos ou algo coordenado com vocês. Pode ser um ótimo ponto de partida. Se não houver parceria com eles, sugiro que seja uma possibilidade a ser considerada. Não tenho certeza se eles fariam isso gratuitamente, mas pode ser uma possibilidade.
FYI: abri um issue no repositório deles para saber mais sobre o trabalho realizado (https://github.com/bitnami/bitnami-docker-discourse/issues/132).

Por favor, me digam o que acham e se posso ajudar de alguma forma.

Olá @Luca_Prete, você verificou o trabalho de @pierreozoux acima e a resposta da equipe?

A maior parte do trabalho de empacotamento do Docker consistiria em seguir o que o pups faz em segundo plano para o launcher, incluindo algumas configurações personalizadas para Postgres, Sidekiq, etc. @unteem resolveu uma necessidade e seguiu o que o pups fez para versões anteriores do Discourse. Manter a imagem do Docker atualizada com a versão oficial é um desafio. Seria interessante detalhar todo o processo e percorrer esse caminho com uma abordagem padrão do Docker. Se houver um caminho viável para usar uma configuração padrão, acredito que muitas pessoas aqui ficariam super felizes.

@hellekin Obrigado.

Ainda não. Tenho certeza de que há muito conteúdo lá, mas geralmente costumo me afastar — pelo menos para trabalho — de funções de usuário único (em oposição às apoiadas pela comunidade), pelo simples fato de que pode se tornar difícil mantê-las posteriormente.

O caminho específico realmente depende de alguns detalhes da plataforma.

O que vejo como uma solução possível no seu caso seria começar a entender como as imagens padrão (Postgres, Redis, …) funcionariam com o Discourse sem customizações específicas.

A razão pela qual considero isso importante é que isso lhe dá a capacidade de confiar — em qualquer lugar onde você instale o Discourse — em serviços externos e padrão (que podem ser instalados em hardware físico, em uma VM, em alguns containers, no k8s na forma de dependências de chart, …).

Cada um desses serviços normalmente permite o uso de alguns scripts de inicialização para criar um banco de dados e assim por diante… não deveria ser tão difícil.

Em seguida, eu criaria um Dockerfile adequado (que também se torna automaticamente seu guia de início rápido para usuários que desejam instalar o Discourse sem Docker).

Depois vem o docker-compose.yaml (isso é praticamente o mesmo que o Bitnami expõe no seu GitHub).

Neste ponto, você deve ser capaz de levantar o Discourse no seu laptop na forma de "micro"serviços, usando imagens de dependência padrão, em poucos segundos, com um único comando, sem nenhum script personalizado.

Por último, mas não menos importante, vem a diversão do Kubernetes (alguns arquivos YAML, possivelmente empacotados na forma de helm-charts), para ser publicado no repositório oficial e estável ou, alternativamente — pelo menos no início do processo — no seu repositório auto-hospedado.

@unteem não está sozinho :slight_smile: Trabalhamos juntos.
Fazemos isso porque hospedamos várias instâncias do Discourse.
Começamos no Docker e agora rodamos no Kubernetes.

Migramos nosso trabalho para https://lab.libreho.st/, que é um esforço comunitário (@hellekin também faz parte). Queremos divulgar mais nosso trabalho nas próximas semanas/meses.

É uma verdadeira dor de cabeça manter isso… Eu literalmente passei horas, se não dias, com este commit que corrigiu minhas builds:

Enfim. Estamos trabalhando em operadores do Kubernetes. Começamos com o Nextcloud, depois o RocketChat, e o próximo provavelmente será o Discourse.

Enquanto isso, você pode encontrar o código das imagens Docker que usamos aqui:

As próprias imagens estão aqui:

Como podem ver, temos dedicado tempo a isso ultimamente. Então temos tags e pipelines. Precisamos adicionar automação para ter builds semanais.

Temos um chart Helm lá:
https://git.indie.host/indiehost/helm-discourse
Mas, como podem ver, ele não é realmente mantido.

O que posso dizer é que funciona para nós :slight_smile: Se quiserem compartilhar a jornada e se sentirem aventureiros, sintam-se à vontade para se juntar a nós :slight_smile: Nos divertimos :slight_smile:

Não oferecemos muito suporte, não temos muito tempo para isso, mas se fizerem um PR, será bem-vindo. Eu realmente gostaria que pudéssemos fazer esse trabalho sob a guarda oficial do Discourse, seria muito mais fácil.
Mas no final das contas, começo a entender a equipe do Discourse. Eles têm apenas uma ferramenta que apoiam para a comunidade, e ela funciona bem. Eles oferecem bom suporte para usuários menos técnicos, e isso é realmente ótimo. Se houver um problema, git pull && rebuild resolve 99% dos problemas :slight_smile: Entendo que apoiar outra ferramenta é um grande risco, e se não for suportado ou não for bem feito, pode prejudicar o projeto de alguma forma. Mais uma vez, muito obrigado à equipe do Discourse pelo trabalho árduo :slight_smile:
Meu único problema é que provavelmente somos muitos desenvolvendo nossa própria solução, e a única maneira de colaborar é colaborar aqui a montante.

Na verdade, uma maneira de fazer isso seria ter outra imagem no discourse_docker chamada super_base? sem runit/anacron/nginx/postgres, e a base seria baseada no super_base, e poderíamos reutilizá-la para nossa implantação no k8s? Acho que isso funcionaria :slight_smile:

O que vocês acham?

O Discourse está usando Kubernetes? Estou curioso :slight_smile:

@pierreozoux obrigado pela resposta!

Acho que vocês fizeram um ótimo trabalho e ficaria feliz em contribuir conforme minha disponibilidade :slight_smile:

Também tive mais tempo para analisar melhor o trabalho que os caras da Bitnami realizaram. A boa notícia é que eles já separaram os containers. Vocês tiveram a oportunidade de dar uma olhada nisso? O que acham?

Aqui estão os arquivos Docker usados tanto para os containers web quanto do sidekiq: bitnami/discourse Dockerfile

Não consigo colar o link do docker-compose, mas você pode encontrá-lo facilmente seguindo o link que adicionei em minha postagem anterior no tópico.

No mesmo repositório, há também um arquivo YAML do Kubernetes: https://github.com/bitnami/bitnami-docker-discourse/blob/master/test.yaml

Começando pela imagem Docker, vocês veem algum problema? O software está “atualizado” o suficiente?

O que parece faltar é o helm-chart, que deveria ser feito seguindo as melhores práticas adotadas para os charts estáveis.

O que vocês acham? Seria válido unir esforços e integrar seus arquivos ao trabalho deles?

Essa é exatamente a mesma alteração feita por DEV: Bump uglifyjs · discourse/discourse_docker@c87937d · GitHub. Se você estiver fazendo um fork da imagem, talvez queira considerar integrar as alterações desse repositório upstream de forma simultânea.

Isso é praticamente nossa motivação para manter o status quo.

Adicionar qualquer coisa que não usamos internamente significa apenas que isso vai quebrar e será descontinuado pouco depois, causando mais dor de cabeça para todos que dependiam disso. Tivemos vários exemplos disso no projeto.

Se isso é algo que a comunidade deseja trabalhar, tudo bem.

Não, não usamos k8s.

É apenas que há uma série de dependências para manter atualizadas.

As pessoas relatam com bastante frequência aqui que elas não estão funcionando de uma forma ou de outra.

O que tenho feito é usar o launcher para construir imagens e enviá-las para um repositório que depois implanto com Kubernetes, e tenho scripts para upgrades sem tempo de inatividade. É um exagero enorme para os clientes para os quais configurei isso. Estou hospedando 3 milhões de visualizações de página/mês em hardware comum com uma configuração (na maioria) padrão (apenas com o traefik fazendo reverse-proxy para vários sites).

Eu considerei publicar um conjunto de imagens com, digamos, vários conjuntos de plugins, mas o problema é que, se houver algum problema com elas, elas não podem receber suporte aqui.

Houve alguma mudança sobre o assunto? Existe ou haverá uma imagem oficial do Discourse que possa ser facilmente utilizada para implantações no Kubernetes?

Não haverá. A solução que utilizo é inicializar a nova imagem, enviá-la para um repositório, depois lançá-la e, por fim, executar as migrações pós-atualização assim que os novos pods forem iniciados.

Alguma atualização? Ainda não há um Helm Chart oficial para instalar o Discourse no Kubernetes?

Não, e isso também não está em nosso roteiro.

Veja Can Discourse ship frequent Docker images that do not need to be bootstrapped? para contexto.

Eu tenho considerado fazer uma oferta assim (e não seria “oficial”), mas precisaria ter certeza de que não geraria problemas extras de suporte aqui e que me pagasse pelo tempo que gastei mantendo e dando suporte a ela. Tenho pouca ideia de como resolver qualquer um desses problemas, mas se você tiver um orçamento, sinta-se à vontade para entrar em contato comigo.

Estamos hospedando o discourse com sucesso no helm com nossa própria imagem docker há alguns meses.
(antes também usávamos nossa própria imagem, com compose)

E é com suporte s3/minio.

https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse

(mas definitivamente falta documentação e “abertura” para abrir contas e contribuir.
Se houver demanda, aqui ou em pm, podemos abrir :slight_smile: )

@pfaffman se você encontrar pessoas felizes dispostas a apoiar seu tempo, ficaremos felizes em colaborar!

Estamos hospedando discourse para algumas pequenas comunidades, principalmente na França, parte do movimento comum.
(Como https://forum.chatons.org/ é o maior que hospedamos pro bono)