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.