Quelqu’un pourrait-il me conseiller sur la construction d’une image Docker Discourse qui intègre un certain nombre de plugins plutôt que de les installer via l’interface utilisateur ?
Contexte : nous souhaitons utiliser la dernière construction de Discourse, c’est-à-dire discourse:stable, et d’après ce que j’ai lu dans le guide d’installation et d’autres documentations, nous pouvons prendre cette image de base dans notre propre Dockerfile et ensuite faire quelque chose comme :
RUN cd /var/www/discourse/plugins && \
git clone https://github.com/discourse/discourse-chat-integration.git
Ceci ajouterait le plugin discourse-chat-integration à la construction. Ensuite, à l’exécution, nous pourrons transmettre toutes les variables d’environnement requises, c’est-à-dire DISCOURSE_HOSTNAME, DISCOURSE_SMTP_DOMAIN, DISCOURSE_DB_HOST, etc., au lieu de les coder en dur dans le fichier app.yml.
Si quelqu’un pouvait me conseiller à ce sujet, ce serait grandement apprécié.
Vous ne pouvez pas installer de plugins depuis l’interface utilisateur. Vous les installez à partir du fichier YML. Si vous utilisez un conteneur non encore pris en charge que vous n’avez pas construit vous-même avec le lanceur (launcher), alors vous feriez quelque chose comme ce que vous suggérez.
Mais ce plugin est dans le cœur (core) (mais peut-être pas encore dans la version stable ?).
Ils ne sont pas vraiment codés en dur dans le fichier YML. Le fichier yml est utilisé pour construire et lancer le conteneur. Vous pouvez le construire et ensuite le lancer vous-même, comme vous le souhaitez. Vous pouvez utiliser ./launcher start-cmd nom-du-conteneur (ou quelque chose comme ça, vous pouvez regarder dans le lanceur pour voir si je me suis trompé).
Donc, ce que je pense que vous voulez faire est de continuer à utiliser le lanceur, d’ajouter le plugin, d’exécuter ./launcher bootstrap app pour le conteneur, puis de le lancer comme vous le souhaitez. Vous pouvez même le pousser vers un dépôt où vous pourrez le lancer à partir d’une autre machine.
Nous cherchons donc à exécuter Discourse dans notre cluster Kubernetes et souhaiterions pouvoir construire l’image dans notre flux de travail CI/CD, d’où le Dockerfile personnalisé. Toutes les variables d’environnement sont ensuite fournies au pod en cours d’exécution dans une ConfigMap et/ou un Secret. Je sais que ce n’est pas une installation supportée, mais j’essaie au moins d’utiliser la manière supportée de construire une image Discourse pour une version spécifique de Discourse afin de contrôler quand nous mettons à jour.
En examinant le script launcher existant et le fichier samples/web_only.yml, je pense pouvoir commenter les sections volumes et links, car cela serait géré dans Kubernetes avec un Volume Persistant et un montage. Nous ajouterions ensuite les valeurs d’environnement fixes dans web_only.yml, construirions le conteneur avec la commande de démarrage, puis copierions l’image générée dans notre propre référentiel.
Concernant la version de Discourse, nous pouvons surveiller la disponibilité d’une nouvelle version dans Docker Hub, puis modifier la valeur base_image dans le fichier web.template.yml.
Peut-être, mais le conteneur doit parler à une base de données pour construire le conteneur, habituellement. Il n’a pas besoin d’être la base de données réelle (mais alors vous devez migrer la base de données et précompiler les actifs dans votre pipeline).
Vous pourriez confondre le problème des mises à niveau de Discourse avec les mises à jour des ressources dans le conteneur de base.
J’ai réussi à faire compiler le conteneur sans le hook db:migrate - je ne sais pas si cela va fonctionner car je ne l’ai pas encore testé - c’est sur la liste des choses à faire
Pour la valeur base_image - je suppose que cela change lorsqu’une nouvelle image docker est publiée, donc je pense que je vais simplement prendre ce qui se trouve sur la branche principale car c’est ce qui est appelé dans le script de lancement.
C’est un bon début ! Vous devrez quand même migrer votre base de données lorsque vous lancerez une nouvelle instance de Discourse.
Il n’y a aucune raison de prendre une nouvelle image de base si vous ne mettez pas à jour Discourse. Donc, cela ne vous importe pas vraiment s’il y a de nouvelles images de base.
Merci Jay. J’ai finalement réussi à faire fonctionner ma construction, enfin le pod a démarré J’ai modifié mon processus de construction CI/CD pour inclure db:migrate en utilisant une base de données temporaire.
Est-ce que db:migrate doit toujours être exécuté au démarrage, car la construction de mon image se ferait contre une base de données/redis factice ? Mon approche actuelle est que db:migrate et la précompilation seraient effectuées dans un initContainer dans mon pod.
L’image discourse/discourse serait idéale à utiliser si elle était prête pour la production prochainement.
Si vous êtes intéressé par les mises à niveau sans temps d’arrêt, vous devriez utiliser SKIP_POST_DEPLOYMENT_MIGRATIONS et après que les anciens pods soient morts, effectuer à nouveau la migration avec quelque chose comme rake db:ensure_post_migrations db:migrate
Merci beaucoup pour toute l’aide jusqu’à présent, Jay.
J’ai une autre question
Actuellement, je définis plusieurs variables d’environnement dans notre déploiement, par exemple DISCOURSE_BACKUP_LOCATION=s3, et je crois comprendre que Discourse utilisera cette valeur plutôt que celle définie via l’interface utilisateur et donc stockée dans la table site_settings - est-ce correct ? Si oui, existe-t-il des outils/scripts qui me permettraient de vérifier quelles variables d’environnement sont définies et de déterminer leur équivalent dans les paramètres du site ?
Pourquoi - Je cherche à migrer une instance Discourse en cours d’exécution et pour aider à minimiser le risque, je voulais ne pas définir les variables d’environnement pour l’instant au cas où j’en oublierais dans la nouvelle instance et que cela ait un impact préjudiciable sur la nouvelle instance. Ma pensée était de vérifier ce qui est défini dans l’instance actuelle, de créer les paramètres pertinents dans la table, de sauvegarder/restaurer sur la nouvelle instance, puis de retirer progressivement les variables d’environnement une par une.
Logique - peut-être pas, mais je pensais que ce serait l’approche la plus sensée juste au cas où une variable d’environnement dans l’instance en cours d’exécution serait différente/non prise en charge dans la nouvelle instance (en cours d’exécution = ancienne version de Discourse, nouvelle = dernière version de Discourse).
En quelque sorte. Elles remplacent ce qui se trouve dans la base de données. Elles sont écrites dans /var/www/discourse/config/discourse.conf ou quelque chose de très similaire.
