Image Docker officielle prise en charge par la communauté

Dev
21

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.

22

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.

23

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.

24

Bonjour à tous !

Je proviens d’une communauté italienne assez importante qui utilise Discourse comme outil pour son forum.
Bien que nous aimions Discourse, nous avons également constaté certaines difficultés à le déployer sur Kubernetes via des procédures quelque peu « standard ».

Je comprends la douleur des mainteneurs :slight_smile: J’ai travaillé pendant des années à la Open Networking Foundation, et l’un des plus grands défis a été de faire passer CORD — l’une de nos plus grandes plateformes — des installations basées sur des scripts vers des Dockerfiles, du docker-compose et des images Docker hébergées sur DockerHub, ainsi que des charts Helm. Bien qu’il existe une crainte raisonnable de le faire, et qu’une solution qui convienne à tous les cas n’existe jamais vraiment, je peux vous dire que nous avons absolument vu les avantages dès les premiers déploiements.

Généralement, la plus grande étape consiste à adopter l’état d’esprit qui consiste à laisser les outils existants faire ce qu’ils font le mieux :slight_smile: Docker dispose de procédures d’installation standard, faciles et déjà bien documentées. Les scripts sont quelque chose de personnalisé, qui nécessite souvent des adaptations et de la maintenance.
De plus, il n’y a vraiment aucune raison pour que vous ne puissiez pas utiliser les images Docker originales ou les charts Helm comme dépendances de Discourse (c’est-à-dire unicorn, postgres, redis, …).

Je suggère de commencer par les bases (c’est-à-dire avoir un Dockerfile, du docker-compose et une construction automatisée DockerHub pour chaque composant). Une fois cela fait (avec les modifications appropriées du logiciel et de la documentation), le développement des charts Helm est la chose la plus facile.

Je serais très heureux d’aider, même en organisant un appel ensemble pour discuter des avantages et des inconvénients des solutions proposées ci-dessus.

Au cours de mes recherches brèves, j’ai également remarqué que Bitnami (très célèbre dans l’univers Docker) a proposé des images (https://github.com/bitnami/bitnami-docker-discourse#how-to-use-this-image). Je me demandais s’il s’agissait d’un travail séparé qu’ils ont réalisé seuls, ou d’une action coordonnée avec vous. Cela pourrait être un excellent point de départ. S’il n’y avait pas de partenariat avec eux, je le suggérerais comme une voie possible à suivre. Je ne sais pas s’ils le feraient gratuitement, mais c’est une possibilité.
Pour information, j’ai ouvert un problème sur leur dépôt pour en savoir plus sur le travail effectué (https://github.com/bitnami/bitnami-docker-discourse/issues/132).

Veuillez me faire part de vos réflexions et me dire si je peux aider d’une manière ou d’une autre.

26

Salut @Luca_Prete, as-tu consulté le travail de @pierreozoux ci-dessus ainsi que la réponse de l’équipe ?

La plupart des efforts liés au packaging Docker consisteraient à reproduire ce que fait pups en arrière-plan pour launcher, y compris certaines configurations personnalisées pour Postgres, Sidekiq, etc. @unteem a répondu à un besoin en suivant la démarche de pups pour les versions antérieures de Discourse. Maintenir l’image Docker à jour par rapport à la version officielle est un défi. Il serait intéressant de détailler l’ensemble du processus et de suivre cette voie avec une approche Docker standard. S’il existe une voie viable vers une configuration standard, je suppose que beaucoup de personnes ici seraient ravies.

27

@hellekin Merci.

Je ne l’ai pas encore fait. Je suis sûr qu’il y a beaucoup de choses là-bas, mais j’ai tendance à éviter - du moins pour le travail - les projets à utilisateur unique (par opposition à ceux soutenus par la communauté), simplement parce qu’ils peuvent devenir difficiles à maintenir plus tard.

La voie spécifique dépend vraiment de certains détails de la plateforme.

Ce que je vois comme une solution possible dans votre cas serait de commencer par comprendre comment les images standard (Postgres, Redis, …) fonctionnent avec Discourse sans personnalisations spécifiques.

La raison pour laquelle je considère cela important est que cela vous permet de vous appuyer - où que vous installiez Discourse - sur des services externes et standard (qui pourraient être installés sur du matériel physique, sur une machine virtuelle, dans des conteneurs, sur Kubernetes sous forme de dépendances de chart, etc.).

Chacun de ces services permet généralement l’utilisation de scripts de démarrage pour créer une base de données, etc. Cela ne devrait pas être trop difficile.

Ensuite, je créerais un Dockerfile approprié (qui devient automatiquement votre guide de démarrage rapide pour les utilisateurs souhaitant installer Discourse sans Docker).

Vient ensuite le fichier docker-compose.yaml (c’est à peu près la même chose que ce que Bitnami expose sur leur GitHub).

À ce stade, vous devriez pouvoir lancer Discourse sur votre ordinateur portable sous forme de « micro »services, en utilisant des images de dépendances standard, en quelques secondes, avec une seule commande, sans aucun script personnalisé.

Enfin, vient l’aspect amusant de Kubernetes (quelques fichiers YAML, éventuellement emballés sous forme de Helm Charts), à publier sur le dépôt officiel et stable, ou alternativement - du moins au début du processus - sur votre dépôt auto-hébergé.

28

@unteem n’est pas seul :slight_smile: Nous travaillons ensemble.
Nous faisons cela parce que nous hébergeons plusieurs instances Discourse.
Nous avons commencé avec Docker, et maintenant nous utilisons Kubernetes.

Nous avons déplacé notre travail sous https://lab.libreho.st/ qui est un effort communautaire (@hellekin y participe également). Nous souhaitons davantage faire connaître notre travail au cours des semaines et mois à venir.

C’est un vrai casse-tête à maintenir… J’ai littéralement passé des heures, voire des jours, pour ce commit qui a corrigé mes builds :

Bref, nous travaillons actuellement sur des opérateurs Kubernetes. Nous commençons par Nextcloud, puis RocketChat, et le prochain sera probablement Discourse.

En attendant, vous pouvez trouver le code des images Docker que nous utilisons ici :

Les images elles-mêmes sont disponibles ici :

Comme vous pouvez le voir, nous y avons consacré du temps récemment. Nous avons donc des tags et des pipelines. Nous devons ajouter de l’automatisation pour avoir des builds hebdomadaires.

Nous avons un chart Helm ici :
https://git.indie.host/indiehost/helm-discourse
Mais comme vous pouvez le voir, il n’est pas vraiment maintenu.

Ce que je peux dire, c’est que cela fonctionne pour nous :slight_smile: Si vous voulez partager l’aventure et que vous vous sentez aventureux, n’hésitez pas à nous rejoindre :slight_smile: Nous nous amusons :slight_smile:

Nous ne fournissons pas vraiment de support, nous n’avons pas beaucoup de temps pour cela, mais si vous faites une PR, elle sera la bienvenue. J’aimerais vraiment que nous puissions effectuer ce travail sous l’égide officielle de Discourse, ce serait tellement plus facile.
Mais au final, je commence à comprendre l’équipe de Discourse. Ils n’ont qu’un seul outil qu’ils supportent pour la communauté, et cela fonctionne bien. Ils offrent un bon support pour les utilisateurs moins techniques, et c’est vraiment bien. S’il y a un problème, git pull && rebuild, cela résout 99 % des problèmes :slight_smile: Je comprends que supporter un autre outil représente un gros risque, et si ce n’est pas supporté ou mal fait, cela pourrait nuire au projet d’une certaine manière. Encore une fois, un grand merci à l’équipe de Discourse pour le travail acharné :slight_smile:
Mon seul problème est que nous sommes probablement nombreux à développer notre propre solution, et la seule façon de collaborer est de le faire ici en amont.

En fait, une façon de faire serait d’avoir une autre image dans discourse_docker appelée super_base ? sans runit/anacron/nginx/postgres, et la base serait basée sur super_base, et nous pourrions la réutiliser pour notre déploiement k8s ? Je pense que cela fonctionnerait :slight_smile:

Qu’en pensez-vous ?

Discourse utilise-t-il Kubernetes ? Je suis curieux :slight_smile:

29

@pierreozoux Merci pour ta réponse !

Je pense que vous avez fait du bon travail et je serais ravi de contribuer selon mes possibilités :slight_smile:

J’ai également eu plus de temps pour examiner de plus près le travail réalisé par l’équipe de Bitnami. Bonne nouvelle : ils ont déjà séparé les conteneurs. Avez-vous eu l’occasion de jeter un œil ? Qu’en pensez-vous ?

Voici les fichiers Docker utilisés pour les conteneurs web et sidekiq : bitnami/discourse Dockerfile

Je ne peux pas coller le lien vers le docker-compose, mais vous pouvez facilement le trouver en suivant le lien que j’ai ajouté dans mon précédent message dans le fil de discussion.

Dans le même dépôt, il y a aussi un fichier YAML pour Kubernetes : https://github.com/bitnami/bitnami-docker-discourse/blob/master/test.yaml

En commençant par l’image Docker, voyez-vous un problème ? Le logiciel est-il suffisamment « à jour » ?

Ce qui semble manquer, c’est le helm-chart, qui devrait être réalisé en suivant les meilleures pratiques adoptées pour les charts stables.

Qu’en pensez-vous ? Ne vaudrait-il pas la peine de unir nos efforts et d’intégrer vos fichiers dans leur travail ?

30

C’est exactement le même changement que celui effectué par DEV: Bump uglifyjs · discourse/discourse_docker@c87937d · GitHub. Si vous faites un fork de l’image, vous pourriez envisager de remonter les modifications depuis ce dépôt en parallèle.

C’est à peu près notre motivation pour le statu quo.

Ajouter tout ce que nous n’utilisons pas en interne signifie simplement que cela cassera et sera rapidement déprécié, causant plus de problèmes à tous ceux qui en dépendaient. Nous avons eu plusieurs exemples de cela dans le projet.

Si c’est quelque chose que la communauté souhaite prendre en charge, cela ne nous dérange pas.

Non, nous n’utilisons pas k8s.

31

C’est simplement qu’il y a un certain nombre de dépendances à suivre.

Les gens signalent assez régulièrement ici qu’elles ne fonctionnent pas d’une manière ou d’une autre.

Ce que je fais, c’est utiliser launcher pour construire des images et les pousser vers un dépôt que je déploie ensuite avec Kubernetes. J’ai également scripté des mises à jour sans temps d’arrêt. C’est un surdimensionnement considérable pour les clients pour lesquels je l’ai configuré. J’héberge 3 millions de vues par mois sur du matériel standard avec une configuration (pour la plupart) classique (il utilise simplement traefik pour faire du reverse-proxying de plusieurs sites).

J’ai envisagé de publier un ensemble d’images avec, par exemple, différents ensembles de plugins, mais le problème est que s’il y a des problèmes avec elles, elles ne peuvent pas bénéficier d’un support ici.

32

Des changements sur le sujet ? Existe-t-il, ou y aura-t-il, une image Discourse officielle pouvant être facilement utilisée pour les déploiements Kubernetes ?

33

Ce ne sera pas le cas. La solution que j’utilise consiste à amorcer la nouvelle image, la pousser vers un dépôt, puis la lancer, et enfin exécuter les migrations post-mise à niveau une fois que les nouveaux pods sont opérationnels.

34

Des mises à jour ? Toujours pas de Helm Chart officiel pour installer Discourse sur Kubernetes ?

35

Non, et ce n’est pas non plus dans notre feuille de route.

Voir Can Discourse ship frequent Docker images that do not need to be bootstrapped? pour le contexte.

36

J’ai envisagé de faire une telle offre (et elle ne serait pas « officielle »), mais je devrais m’assurer qu’elle ne crée pas de problèmes de support supplémentaires ici et qu’elle me paie pour le temps que j’ai passé à la maintenir et à la supporter. Je n’ai aucune idée de la façon de résoudre l’un ou l’autre de ces problèmes, mais si vous avez un budget, n’hésitez pas à me contacter.

37

Nous hébergeons avec succès discourse sur helm avec notre propre image docker depuis quelques mois maintenant.
(avant nous utilisions aussi notre propre image, avec compose)

Et c’est avec le support de s3/minio.

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

(mais cela manque vraiment de documentation, et d’“ouverture” pour ouvrir des comptes et contribuer.
S’il y a de la demande, ici ou en mp, nous pouvons ouvrir :slight_smile: )

@pfaffman si vous trouvez des personnes heureuses et désireuses de soutenir votre temps, nous serions heureux de collaborer !

Nous hébergeons discourse pour quelques petites communautés, principalement en France, faisant partie du mouvement des communs.
(Comme https://forum.chatons.org/ est la plus grande que nous hébergeons pro bono)