Comment puis-je inclure Discourse dans ma pile de développement locale ?

Mon organisation gère une application web et un forum, ainsi que quelques autres applications comme Bitwarden. J’ai tout conteneurisé pour assurer une parité entre les environnements de développement et de production, tout en simplifiant la configuration de développement grâce à Docker Compose. Nous utilisons un fichier Compose très similaire en production, ce qui fonctionne très bien pour notre cas d’usage de base.

Je souhaite migrer notre forum vers Discourse, mais je peine à trouver comment maintenir cette parité dev/prod tout en conservant une configuration de développement simple.

La documentation indique que, bien que Discourse utilise Docker pour l’installation et l’exécution, il ne s’intègre pas vraiment dans le paradigme des conteneurs comme les autres images Docker : on ne peut pas l’ajouter à une stack Compose, Swarm ou Kubernetes pour l’exécuter en le reliant à des conteneurs de base de données et de Redis comme on le ferait avec une autre application. Les solutions alternatives ou suggestions sont fortement découragées afin d’éviter de diviser la communauté, aussi ne suis-je pas ici pour remettre en question cette approche.

J’ai accepté que, contrairement au reste de ma stack que je gère de manière standard, je devrai déployer une machine virtuelle dédiée en production et l’administrer différemment. Mais je me demande comment répondre à mes objectifs fondamentaux : disposer d’une configuration de développement simple offrant une bonne parité avec la production.

Pour contextualiser, ma configuration de développement actuelle consiste à « installer Docker, cloner ce dépôt, puis exécuter docker-compose up ». Si j’ai bien compris d’après le guide d’installation locale, nous aurons désormais besoin de 9 dépendances système (Ruby, PostgreSQL, etc.) avant de cloner et configurer manuellement Discourse lui-même. À mon sens, l’un des avantages de Docker (et de Docker Compose) est précisément de ne pas avoir besoin d’avoir PostgreSQL ou Redis installés localement (et des problèmes associés liés à leur configuration lorsque les développeurs sont sous Windows) ; on peut simplement lancer une stack et les processus sont isolés dans des conteneurs éphémères. Existe-t-il un moyen de conserver cet avantage ?

L’autre inconvénient est que, comme nous sommes une petite équipe de bénévoles, la plupart des autres développeurs utilisent Windows 10 Home, qui, à ma connaissance, ne prend pas en charge WSL. Ils ne pourront donc pas suivre les instructions d’installation pour Windows (Docker fonctionne cependant sous Windows 10 Home).

Eh bien, la bonne nouvelle est que la plupart du temps, vous n’aurez pas à le faire !

Sauf si vous développez des intégrations spécifiques pour le forum ou créez des thèmes pour le forum lui-même, le site Discourse peut fonctionner de manière autonome en dehors de votre infrastructure.

Il existe des options pour une installation de développement basée sur Docker sous Linux et WSL ; nous ne recommandons pas cette méthode sous macOS en raison de problèmes de performances du système de fichiers.

1 « J'aime »

En fait, c’est vraiment critique car je souhaite utiliser Discourse comme système d’authentification pour mes applications. Sans cela, cela signifiera que les utilisateurs ne pourront pas se connecter localement.

Dans ce cas, je recommande de mettre en place un SSO avec un site de préproduction en direct.

Configurez une seconde copie de Discourse sur un hébergement similaire, accordez les droits d’administrateur à tout le monde, et créez des secrets de fournisseur SSO pour localhost:3000, localhost:4000, localhost:4001, *.cluster.local, etc., selon les besoins.

Chaque membre de votre équipe de développement pourra générer des charges utiles d’authentification depuis ce site, il est donc important de le documenter et d’utiliser votre véritable site de production pour l’authentification réelle.

2 « J'aime »