Como posso incluir o Discourse na minha stack de desenvolvimento local?

Minha organização executa um aplicativo web, um fórum e alguns outros aplicativos, como o Bitwarden. Containerizei tudo para garantir a paridade entre desenvolvimento e produção e uma configuração de desenvolvimento simples usando o Docker Compose. Utilizamos um arquivo compose muito similar para executar em produção, o que funciona muito bem para nosso caso de uso básico.

Gostaria de migrar nosso fórum para o Discourse, mas estou com dificuldades para entender como manter a paridade entre desenvolvimento e produção e uma configuração de desenvolvimento simples.

A documentação sugere que, embora o Discourse use Docker para instalar e executar, ele não se encaixa no paradigma de contêineres como os outros contêineres Docker: não é possível adicioná-lo a uma pilha (stack) do Compose, Swarm ou Kubernetes e executá-lo, conectando-o a contêineres de banco de dados e Redis como faríamos com outro contêiner de aplicação. Soluções alternativas ou sugestões são fortemente desencorajadas, no esforço de não fragmentar a comunidade, então não estou aqui para questionar essa abordagem.

Aceitei que, em vez de executar e gerenciar o Discourse da mesma forma que faço com o restante da minha pilha, precisarei executar uma máquina virtual (VM) dedicada em produção e gerenciá-la de forma diferente. Mas tenho curiosidade sobre como atender aos meus objetivos fundamentais: uma configuração de desenvolvimento simples que tenha uma paridade razoável com a produção.

Para contextualizar, minha configuração atual de desenvolvimento é: “instalar o Docker, clonar este repositório e executar docker-compose up”. Se entendi corretamente, o guia de instalação local indica que agora precisaremos de 9 dependências do sistema (Ruby, PostgreSQL, etc.) antes de clonar e configurar manualmente o próprio Discourse. Na minha opinião, uma das vantagens do Docker (e do Docker Compose) é que você não precisa ter coisas como PostgreSQL e Redis rodando no seu sistema (e os problemas associados à configuração disso quando os desenvolvedores estão no Windows); basta executar uma pilha e os processos ficam isolados em contêineres descartáveis. Existe alguma maneira de manter essa vantagem?

A outra desvantagem é que, como somos uma pequena equipe de voluntários, a maioria dos outros desenvolvedores está no Windows 10 Home, que, até onde sei, não suporta o WSL. Isso significa que eles não conseguirão seguir as instruções de instalação para Windows de qualquer maneira (o Docker funciona no Windows 10 Home).

Bem, a boa notícia é que na maioria das vezes você não precisará!

A menos que você esteja desenvolvendo integrações específicas para o fórum ou criando temas para o próprio fórum, o site do Discourse pode funcionar de forma independente do restante da sua infraestrutura.

Existem opções para instalar em ambiente de desenvolvimento baseado em Docker no Linux e no WSL; não recomendamos isso no macOS devido a questões de desempenho do sistema de arquivos.

1 curtida

Na verdade, isso é bastante crítico, pois quero usar o Discourse como sistema de autenticação para meus aplicativos. Sem ele, os usuários não poderão fazer login localmente.

Nesse caso, recomendo implementar o SSO com um ambiente de staging ativo.

Configure uma segunda cópia do Discourse no mesmo provedor de hospedagem (ou similar), conceda acesso de administrador a todos e crie os Segredos do Provedor de SSO para localhost:3000, localhost:4000, localhost:4001, *.cluster.local, etc., conforme necessário.

Todos os membros da sua equipe de desenvolvimento poderão gerar payloads de autenticação a partir desse site, por isso é fundamental documentar isso e utilizar seu site de produção real para a autenticação de verdade.

2 curtidas