J’utilise Discourse dans un cluster Kubernetes depuis un certain temps en utilisant l’image Bitnami non prise en charge. Maintenant que Bitnami déprécie l’image et passe derrière un paywall, je cherche à migrer notre serveur vers une solution auto-hébergée sur AWS.
J’ai quelques questions pour lesquelles je serais reconnaissant si la communauté pouvait m’aider :
Nous utilisons déjà une base de données Postgres externe pour l’installation et elle restera en place. Cependant, nous avons mis à jour certains paramètres via l’interface utilisateur ainsi qu’en utilisant des variables d’environnement que les scripts d’installation Bitnami mappent à Discourse, par exemple DISCOURSE_S3_BACKUP_BUCKET est mappé à S3_BACKUP_BUCKET.
Est-il suffisant de définir les paramètres de Discourse dans les fichiers yaml requis ou devons-nous toujours utiliser des variables d’environnement ?
Si nous effectuons une sauvegarde à partir de l’interface utilisateur, que restaurera-t-elle réellement ? Met-elle à jour la base de données ?
Est-il préférable de créer une nouvelle base de données avec une nouvelle installation, puis d’effectuer une sauvegarde/restauration ?
Si la nouvelle installation est une version ultérieure de Discourse, cela posera-t-il un problème si une restauration est tentée ?
Le guide d’installation standard utilise Docker. Comment surveillez-vous les conteneurs dans un environnement de production, car il semble que l’installation standard soit une seule VM avec Docker.
Existe-t-il des documents détaillant une migration et des pièges à éviter ?
Je suis sûr que j’aurai d’autres questions au fur et à mesure de la migration, mais tout conseil/aide qui pourra être apporté sera vraiment apprécié.
Si ce n’était pas déjà votre plan, je passerais à une nouvelle base de données (sur le même serveur) pour la migration afin de ne pas casser votre site existant.
Si par “mieux” vous entendez “cela signifie-t-il que je ne casserai pas notre site existant et que je le laisserai dans un état où il ne fonctionnera plus jamais ?”, la réponse est oui.
C’est ce que vous voulez. L’endroit à partir duquel vous restaurez doit être égal ou plus récent que la version de la sauvegarde. Il migrera la base de données après sa restauration.
C’est peut-être tout ce que vous avez besoin de savoir et nous sommes heureux de vous aider ici gratuitement. Si vous souhaitez une attention pratique spécifique à votre configuration, vous pouvez me contacter ou demander de l’aide sur Marketplace.
Une autre option serait de construire des images et de les lancer dans k8s. Je l’ai fait plusieurs fois et j’ai utilisé github pour construire les images.
Mon expérience corrobore cela. J’ai vu tellement de petites défaillances étranges au fil des ans que je maintiens toujours des sauvegardes complètes afin de pouvoir repartir de zéro et restaurer le site. Compter sur la correction des problèmes in situ finira par vous faire défaut.
Comme vous, j’ai été laissé en plan lorsque Bitnami a cessé de proposer des images et des graphiques gratuits. J’ai dû adapter et migrer de nombreux déploiements. L’un d’eux était mon déploiement Discourse. Si cela vous est utile, voici un lien vers le graphique Helm de remplacement que j’ai créé en très peu de temps (ce qui signifie qu’il fonctionne mais est loin d’être une conception idéale). C’est une tentative d’utiliser la « méthode d’installation officielle » étant donné que je n’ai vu aucun graphique Helm « standard communautaire » émerger après toutes ces années. (Je suppose que le graphique de Bitnami était effectivement ce standard, car peu d’entre nous avaient prédit ce changement brutal.) Dans tous les cas, ce nouveau graphique que j’exécute pour l’une de mes communautés de recherche est essentiellement juste un pod avec deux conteneurs : le conteneur Docker-in-Docker officiel et un conteneur personnalisé basé sur python:3, installant Docker puis utilisant l’installation Discourse officielle. Comme tous les composants (serveur Discourse, Redis, PostgreSQL) s’exécutent dans la boîte noire de l’image construite localement par le script de lancement, il n’y a pas de scalabilité ni de support pour la haute disponibilité. J’ai réussi à réduire le temps d’arrêt dû à la régénération du pod sur un autre nœud (par exemple, lors de la vidange d’un nœud pour des mises à jour du système d’exploitation ou un crash de nœud) en utilisant docker save pour stocker l’image construite sur le volume persistant, puis en chargeant celle-ci si local_discourse/app:latest n’est pas trouvé.
Mais pour répondre à votre question, je ne sais pas comment surveiller quoi que ce soit dans ce nouveau déploiement. J’exécute en « production » mais ma communauté est suffisamment petite et l’utilisation suffisamment modérée pour que si le forum est hors ligne pendant un certain temps, ce n’est pas grave. Même ainsi, je suis très proche d’abandonner l’auto-hébergement et de migrer vers un service comme Communiteq ou Discourse.org.
