Je suis en train de migrer mon serveur d’un déploiement existant basé sur Bitnami (une version assez ancienne) vers l’installation officiellement prise en charge sur AWS en utilisant la dernière version de Discourse. Cette nouvelle installation dispose d’instances Elasticache et RDS externes et utilisera également S3 pour les sauvegardes et les téléchargements.
J’ai 2 questions :
L’ancien serveur Discourse est sur une version assez ancienne - en effectuant la sauvegarde/restauration sur le nouveau serveur Discourse, cela exécutera-t-il simplement toutes les commandes de mise à niveau pertinentes ?
Si je copie le fichier de sauvegarde dans le nouveau conteneur Docker Discourse sur le nouveau serveur et que j’initie la restauration en utilisant la ligne de commande, les nouvelles valeurs de bucket que j’ai définies dans ma configuration seront-elles écrasées dans le cadre de la restauration ou mes nouvelles valeurs seront-elles utilisées ? Je suppose que ma nouvelle base de données est renseignée à partir de la sauvegarde, puis lorsque je quitte le conteneur et exécute ./launcher rebuild app, mes nouvelles valeurs S3 seront utilisées.
Si mes hypothèses sont correctes, alors avant d’effectuer la restauration, je suppose que je devrais copier le contenu des anciens buckets S3 vers les nouveaux ?
Y a-t-il d’autres pièges à connaître pour ce type de migration avec une sauvegarde ?
Peut-être que je manque quelque chose, mais pourquoi établissez-vous de nouveaux buckets ? Un nouveau bucket de sauvegarde avec des règles de cycle de vie appropriées semble acceptable, mais si votre instance Discourse existante utilise un bucket de téléchargement S3, vous aurez des problèmes.
2 raisons pour lesquelles nous avons besoin de nouveaux buckets :
Je ne suis pas sûr à 100 % que la migration depuis Bitnami se déroulera sans encombre, nous ne voulons donc pas impacter les données existantes au cas où nous devrions abandonner la migration.
Nous avons changé notre nomenclature de buckets, il a donc semblé plus simple d’avoir 2 buckets flambant neufs pour cela.
Le point 1 est celui qui m’inquiète le plus, je suis donc juste très prudent.
Quels problèmes envisagez-vous avec le nouveau bucket de téléchargement ? L’ancien serveur Discourse sera mis en lecture seule. Le plan est qu’une fois que le nouveau serveur sera opérationnel et validé, nous arrêterons notre ancien serveur, changerons le DNS pour le nouveau serveur, puis viderons le cache dans le CDN (Cloudfront) et enfin l’ouvrirons au public.
J’avais manqué que vous alliez copier les données des anciens buckets. J’ai regardé sur AWS, cela semble simple. Si c’était moi, je ne m’embêterais pas à changer de bucket avant de migrer vers AWS ou un nouveau serveur ailleurs.
[quote=“stevejr, post:1, topic:395948”]vers l’installation officiellement supportée dans AWS en utilisant la dernière version de Discourse.
[/quote]
Officiellement supportée ?? J’en doute fort.
Je vous suggère fortement de mettre à jour Discourse avant de passer à un nouveau serveur.
Sur l’ancienne instance, je suggère de déplacer la configuration S3 vers le fichier app.yml si ce n’est pas déjà fait avant la migration.
Je suis très curieux de savoir comment réaliser ce type d’installation représente une proposition de valeur ajoutée.
D’après les nombreux messages concernant les installations non prises en charge, cela semble plus être une source de problèmes qu’un avantage, à moins que les gens ne le fassent pour apprendre/expérimenter.
Une telle configuration pourrait être une installation non prise en charge du point de vue de Discourse, mais du point de vue d’une organisation informatique d’entreprise, RDS et Elasticache pourraient être standard et l’installation standard de Discourse serait l’exception.
Comme mentionné par @RGJ, notre infrastructure d’entreprise utilise des services externes pour des éléments tels que le cache, la base de données, etc., d’où l’Elasticache et le RDS. Cela signifie que nous pouvons avoir une sauvegarde complète et une redondance pour ces services, et cela aide également avec les contrôles de sécurité. Il s’agit d’une installation officielle/supportée du point de vue de Discourse ; elle utilise simplement un ensemble de modèles différent — nous utilisons discourse_docker/samples/web_only.yml at main · discourse/discourse_docker · GitHub (utiliser le mot standard était peut-être un peu trompeur, nos excuses).
Donc, il semble que nous devrions d’abord mettre à jour nos noms de bucket pour l’installation existante, puis effectuer le transfert vers le nouveau serveur. La mise à jour de l’installation existante vers la dernière version est hors de question — nous avons rencontré des problèmes avec la mise à niveau Bitnami précédemment, d’où le passage à la méthode d’installation officielle.
Puis-je demander cependant, quels problèmes sont susceptibles de se produire si nous effectuons la restauration avec les buckets existants, puis mettons à jour le fichier app.yml pour référencer les nouveaux buckets ? Toutes les variables d’environnement DISCOURSE_ ne prennent-elles pas le pas sur toute configuration dans la base de données (le cas échéant) ? Ou y a-t-il autre chose qui pourrait causer un problème ?
Parce que si vous le faites avant la migration et que les choses tournent mal, vous aurez le problème sur l’ancienne instance Bitnami au lieu de votre nouvelle instance standard fraîchement installée. Et, en plus de l’ancienne version, même la mention du mot Bitnami vous fera obtenir beaucoup, beaucoup moins de support ici sur meta.
Une autre question si je peux me permettre : lorsque j’exécute la restauration depuis la ligne de commande à l’intérieur du conteneur Discourse, utilise-t-elle la configuration existante /var/www/discourse/config/discourse.conf pour les détails de la connexion à la base de données, la connexion Redis, etc., ou écrase-t-elle cette configuration avec ce qui se trouve dans le fichier de sauvegarde ?
discourse.conf est généré à partir de app.yml, il n’est pas inclus dans le fichier de sauvegarde.
Généralement, ce qui se trouve dans discourse.conf surcharge les paramètres du site.
Donc, si vous avez setting_foo dans votre base de données, vous pouvez le remplacer en définissant DISCOURSE_SETTING_FOO dans votre app.yml, ce qui générera ensuite setting_foo dans discourse.conf.
[quote=“philh, post:6, topic:395948”]installations non prises en charge
[/quote]
Poiner un conteneur Discourse vers un serveur postgresql et redis externe en utilisant notre image de conteneur avec nos outils est une installation prise en charge.
RDS[1] est Postgresql, et Elasticache est Redis, c’est bien.
[quote=“stevejr, post:1, topic:395948”]L’ancien serveur Discourse est sur une version assez ancienne - en faisant la sauvegarde/restauration sur le nouveau serveur Discourse, cela exécutera-t-il simplement toutes les commandes de mise à niveau pertinentes ?
[/quote]
Cela devrait aller, nous faisons cela pour les personnes qui passent à notre hébergement.
Ma préférence est de garder le processus aussi simple que possible, donc si vous pouvez effectuer une sauvegarde complète (y compris les téléchargements) sur l’ancien serveur et la restaurer sur le nouveau, cela vous permettra de tester entièrement la nouvelle configuration sans aucun impact sur l’ancienne.
Je vais faire la sauvegarde/restauration sans changer les noms de bucket comme l’a également suggéré @RGJ. Comme je l’ai dit, mon inquiétude était de ne pas impacter les données du serveur existantes de quelque manière que ce soit, mais si je sauvegarde les buckets existants d’abord et que je m’assure que le serveur existant est en mode lecture seule pendant la migration, je pense que l’intégrité des données téléchargées dans les buckets est plutôt bien protégée.
Je voulais juste dire que nous avons effectué notre migration hier et que tout s’est déroulé presque aussi bien que du beurre, ce qui était très, très satisfaisant.
