Discourse peut-il envoyer fréquemment des images Docker qui n'ont pas besoin d'être initialisées ?

C’était une note expliquant pourquoi l’exemple de composition que j’ai posté n’utilisait pas l’image PG générique.

Hmm… mais ne diriez-vous pas que cela rend les autres méthodes plus complexes ?

Compris ! :slight_smile:

En tant que gourou de Docker, tout cela devrait être très facile pour vous ?

3 « J'aime »

Comme j’essaie de l’expliquer depuis quelques jours, avec la solution actuelle fournie, tout est sauf facile :wink:

en bref ;
Une simple image Discourse (similaire à celle de bitnami) avec un tas de variables d’environnement pour configurer des éléments de base (comme l’accès à Redis, la base de données) serait plus que suffisant, mais pour une raison quelconque, c’est un non absolu… :man_shrugging:

Je partage ici des preuves de concept pour faire exactement cela.

Pour un plugin simple, oui, mais nous ne pouvons pas supposer qu’un plugin aura une certaine apparence - certains plugins nécessitent une configuration supplémentaire, l’installation de gems supplémentaires, ou des dépendances de gems supplémentaires ou des programmes externes nécessitant un apt-get install. Cela devrait être intégré dans une image personnalisée.

Ce serait formidable de voir cela fait, mais ce n’est pas trivial.


re: Mise à jour Web, les opérateurs Discourse ne sont pas non plus censés connaître la CLI ou docker.

1 « J'aime »

Il vous suffit de créer votre propre image avec le lanceur (ce que vous pouvez faire avec les actions GitHub), de la pousser vers un dépôt et de la démarrer avec les variables d’environnement. Vous devez toujours migrer la base de données, précompiler les assets et les pousser vers S3. Vous pouvez migrer la base de données et utiliser skip_post_deployment_migrations afin que l’ancien conteneur puisse continuer à fonctionner jusqu’à ce que le nouveau soit opérationnel, puis l’arrêter et exécuter le reste des migrations. Mais c’est beaucoup trop compliqué pour quelqu’un qui ne connaît pas beaucoup plus Discourse que ce que vous semblez vouloir savoir. Et il y a beaucoup, beaucoup de choses qui peuvent mal tourner, c’est pourquoi la solution actuelle, qui est horrible pour toutes les raisons que vous décrivez, est la meilleure solution pour des milliers de personnes qui ne savent pas ce qu’est bash.

Dans la plupart des cas, vous n’avez qu’à utiliser ./launcher rebuild app, sauf une fois tous les deux ans lorsque vous devez mettre à niveau la base de données, vous devez donc le faire deux fois. Vous ne pouvez tout simplement pas obtenir ce niveau de simplicité avec docker-compose. Il est possible que si docker-compose était utilisable lorsqu’ils ont commencé, ils auraient pu l’utiliser au lieu de devoir créer le leur, mais ce n’est pas ainsi que les choses se sont passées.

Si vous souhaitez utiliser l’image Bitnami, vous le pouvez, mais vous ne pourrez pas obtenir beaucoup d’aide ici. Je parie qu’elle fonctionne aussi pour beaucoup de monde.

1 « J'aime »

Hmm… pour un langage/environnement qui se veut universel et indépendant de la plateforme, s’appuyer sur le gestionnaire de paquets du système d’exploitation sous-jacent semble assez étrange… :open_mouth:

C’est ce à quoi il a été fait référence précédemment, à savoir que Discourse semble être fermement ancré dans l’“ancienne” méthode de gestion des logiciels/forums PHP :slight_smile:

Donc, pour résumer toute la discussion (et éventuellement la mettre dans le premier message pour éviter de la répéter à l’infini :slight_smile: ) :

  1. Discourse est adapté et axé sur les “gens ordinaires” et toute la configuration est conçue pour répondre à leurs besoins
  2. Étant donné à quel point Ruby (l’environnement) est un peu étrange et (1) il est pratiquement impossible de fournir des images docker officielles suffisamment génériques dans le dépôt officiel de Discourse

correct ? :slight_smile:

Je dirais un peu différemment

Étant donné qu’il n’y a pas d’offre d’image officielle (par défaut) autre que le lanceur pour configurer Discourse, ce qui fait du lanceur la méthode par défaut et essentiellement la seule (recommandée) pour configurer Discourse, on pourrait soutenir que la déclaration originale est toujours valide :wink:

Mais ce ne sont que des sémantiques.

Quoi qu’il en soit, le sujet est :

Discourse peut-il fournir des images Docker fréquentes qui n’ont pas besoin d’être amorcées ?

D’après toute la discussion, il semble que : « Non, Discourse ne peut pas/ne veut pas fournir des images Docker fréquentes qui n’ont pas besoin d’être amorcées », cqfd.

Par conséquent, la suggestion d’ajouter un commentaire tout en haut, indiquant qu’une telle image ne sera pas fournie, permettrait d’économiser BEAUCOUP de tracas :slight_smile:

C’est une hypothèse incorrecte

Nous n’avons pas encore priorisé la fourniture d’une image officielle avec un ensemble de plugins spécifiques
nous y réfléchissons, nous avons plein d’idées sur la façon de le faire, cela n’a tout simplement pas été une priorité pour l’entreprise

5 « J'aime »

c’est un travail que nous envisageons, nous avons plein d’idées sur la façon de le faire, cela n’a tout simplement pas été une priorité pour l’entreprise
[/quote]

traduction d’une personne travaillant sur un autre projet : “cela pourrait arriver dans le futur, mais ça pourrait ne pas arriver… étant donné que ce n’est pas une priorité / que ce n’est pas sur une feuille de route, les chances que cela se produise sont minces à néant” :wink:

Cependant, plus sérieusement - une configuration de base avec un ensemble de plugins judicieux serait super cool !

Merci pour votre contribution ! <3

Pour information, j’ai mis en place un moyen pour moi de construire une image Discourse sur une boîte de développement et de la déployer sur un serveur d’une manière qui élimine la nécessité d’utiliser le script lanceur.
Plus de discussions à ce sujet ici dans une demande d’extraction que j’ai créée.

J’ai configuré cela d’une manière qui le rend entièrement compatible avec la configuration Docker officielle de Discourse, vous n’avez donc pas à vous soucier que cette solution devienne obsolète ou qu’elle se casse.
Le TLDR sur le fonctionnement est que j’ai rendu l’image Docker responsable de l’exécution des commandes d’amorçage au démarrage (au lieu du script launcher).

1 « J'aime »

Approche intéressante.

Aussi : lanceur v2 intéressant (GitHub - discourse/launcher: Discourse Launcher CLI) !

2 « J'aime »