Automatisation des thèmes

Dev
1

Salut à tous, je suis nouveau ici :slight_smile:

J’exécute une version Dockerisée de bitnami Discourse (la dernière) sur un cluster Kubernetes, cela semble être un excellent projet. Cependant, je rencontre un problème en essayant d’automatiser l’installation d’un thème. Essentiellement, j’ai besoin de construire, déployer, exécuter et configurer cette image Docker à partir d’un CICD, de sorte qu’à la toute première connexion, tout soit prêt. Concernant les configurations, il y a l’installation du thème personnalisé. D’après ce que j’ai pu comprendre de plusieurs forums et documentations, il n’y a pas de moyen natif de l’installer par programme, j’ai seulement trouvé un guide étape par étape (corrigez-moi si je me trompe svp).

Ma première idée était d’ajouter les fichiers du thème « manuellement » dans le système de fichiers de Discourse via k8s, mais d’après ce que je vois, Discourse gère ses fichiers d’une manière étrange, en les renommant selon sa propre logique interne, ce qui rend impossible de les prédire.

En regardant de plus près, j’ai trouvé cet excellent outil en ligne de commande appelé discourse_theme, le problème ici est que j’aurais toujours besoin de générer une clé API de Discourse au préalable, sinon cela ne peut pas fonctionner (encore… corrigez-moi si je me trompe).

Donc, au final, j’ai quelques questions :
Premièrement, existe-t-il une manière différente/native d’installer programmatiquement un thème dans Discourse que j’aurais manquée ?
Et d’autre part, existe-t-il un moyen d’obtenir une clé API de Discourse à partir d’un script ?
Et enfin, quelqu’un connaît-il des astuces Kubernetes pour contourner ce type de problème ?

Merci d’avance

Cordialement

2

C’est pris en charge lorsque vous utilisez notre méthode d’installation officielle : Install a Theme programatically

1 « J'aime »
3

Je pense que la seule solution est de construire une image qui inclut les plugins souhaités, de la pousser vers un dépôt Docker, de la lancer avec les variables d’environnement appropriées, et à un moment donné de constater que la base de données est migrée et les assets précompilés et poussés vers S3 lors de la première exécution de l’image (au minimum). Vous pourriez vouloir migrer une fois avec SKIP_POST_DEPLOYMENT_MIGRATIONS défini pendant que l’ancienne image est en cours d’exécution, puis à nouveau après que la nouvelle image a été lancée et que les anciennes ont été arrêtées avec SKIP_POST_DEPLOYMENT_MIGRATIONS désactivé ou exécuter la tâche rake db:ensure_post_migrations.

Vous pouvez exécuter une tâche rake dans l’une de vos images en cours d’exécution, quelque chose comme

rake api_key:create_master[‘description de la clé’]

Ce qui précède pourrait suffire à vous faire avancer un peu. J’ai géré des instances kubernetes pour des clients sur GCP et AWS par le passé. Je n’ai jamais été entièrement satisfait de la façon dont cela fonctionnait (cela fonctionnait parfaitement du point de vue du client, ce n’était tout simplement pas très élégant de mon point de vue, mais ce n’était pas si peu élégant que j’aie pris la peine de le corriger, non plus !). Je n’ai pas grand-chose de plus à offrir ici, mais n’hésitez pas à me contacter directement si vous avez besoin d’aide supplémentaire.

1 « J'aime »