J’ai eu quelques idées aléatoires qui me sont venues à l’esprit, et l’une d’elles était un plugin pour installer des plugins. Cela nécessite une reconstruction du forum. Existe-t-il un moyen de reconstruire en utilisant Ruby ? Je ne veux vraiment pas essayer :
Dans une installation standard, Discourse (et par conséquent, les plugins) s’exécute à l’intérieur d’un conteneur Docker. Ce conteneur n’a pas un accès complet au système de fichiers hôte, il ne peut donc pas accéder au répertoire /var/discourse de l’hôte pour modifier app.yml ou exécuter launcher.
Et même s’il le pouvait… il y a une petite dépendance circulaire ici. L’exécution de ./launcher rebuild tuerait le conteneur Docker… ce qui tuerait le launcher rebuild que vous avez démarré à partir du plugin
Il existe des solutions potentielles ici. Par exemple, ajouter des montages de volumes Docker supplémentaires, afin que la configuration/le lanceur puisse être accédé depuis l’intérieur du conteneur. Mais ce n’est pas trivial.
Si ma mémoire est bonne, quelqu’un a créé un plugin de « gestionnaire de plugins »… qui nécessitait quelques ajustements à app.yml pour ajouter des éléments tels que le montage de volume. Mais je ne trouve plus de sujets à ce sujet, donc je suppose qu’il n’est plus maintenu. Peut-être que quelqu’un d’autre peut partager un lien s’il le trouve ? (ou peut-être que ce n’était qu’un rêve )
Du côté de CDCK, nous privilégions définitivement l’utilisation de thèmes lorsque nous voulons que les clients puissent installer/mettre à jour/désinstaller à volonté. Permettre aux gens d’installer arbitrairement des plugins n’est pas une option, car cela affecterait les autres clients exécutant sur le même serveur.
Dashboard.literatecomputing.com installera et supprimera des plugins en modifiant app.yml (ou web_only.yml) et en effectuant la reconstruction (en fait, bootstrap, destroy, rebuild). Sur une installation à deux conteneurs, le temps d’arrêt est minimal.
Il fait également des choses comme mettre à jour Docker et PostgreSQL, nettoyer Docker, etc. Comme il gère une installation standard, vous n’êtes pas lié à lui, et il ne peut rien casser à moins qu’il ne fasse réellement quelque chose (comme installer un mauvais plugin).
C’est un plugin Discourse (privé) qui pilote un playbook Ansible. Vous pouvez rejoindre le groupe d’essai gratuit et l’utiliser gratuitement (avec un support limité).
Mais les problèmes de conservation des plugins dans le conteneur et dans app.yml pour la prochaine reconstruction sont là.
J’ai été brûlé un certain nombre de fois en faisant un ./launcher destroy app ;./launcher start app pour appliquer de nouvelles variables d’environnement à partir de app.yml pour découvrir que le conteneur “nouveau” est derrière la version de la base de données. C’est encore pire si quelqu’un a mis à jour uniquement certains plugins dans le conteneur qui fonctionnaient avec la version de Discourse qui se trouvait dans l’ancien conteneur, mais pas avec celle que vous obtenez lors de la reconstruction. . .
C’est donc pourquoi le plugin ProCouese n’a fait que cloner les dépôts, et ne peut être supprimé que via cette page de plugin pour rm -rf le dossier de plugin cloné.
Il a en fait très bien fonctionné comme preuve de concept. Il pourrait bénéficier de quelques ajustements car il a été dit qu’il pourrait rendre le dépannage plus difficile. Il faudrait donc peut-être des informations en ligne de commande sur la façon d’accéder à l’installateur procouree. Peut-être un meilleur fichier journal.
Le plus, cependant, est que vous pouvez désactiver tous les plugins simplement en supprimant/commentant l’installateur pro course. Bien qu’il soit maintenant cassé.
Joe a des idées très avant-gardistes. Si je me souviens bien, il a créé le plugin initial Post Voting ?