C’est un peu le but de la configuration ci-dessus ; il est très utile d’avoir le serveur de staging pointant vers le même bucket, car cela facilite grandement leur synchronisation.
Cependant, vous ne voulez pas qu’il contribue automatiquement à des sauvegardes (ou en supprime) - d’où le fait que ces options soient désactivées par ces paramètres :
Je suis d’accord que le CDN doit être désactivé pour votre site de staging. Je n’ai pas touché à cela moi-même, mais une fois que vous aurez compris comment faire, veuillez mettre à jour / ajouter au wiki dans le message d’origine.
Merci, Nathan. J’ai vu qu’il était mentionné que les sauvegardes S3 facilitaient les choses, mais une sauvegarde est différente des ressources du site, donc je n’étais pas sûr.
J’ai déjà désactivé les sauvegardes et les e-mails, donc tout va bien de ce côté-là. Je vais continuer à faire pointer le serveur de staging vers le bucket existant et m’assurer qu’il n’utilise pas le CDN.
Je prévois de créer un miroir de ma production Discourse en utilisant la méthode rsync.
J’ai quelques autres sites web qui s’intègrent à Discourse, donc avoir les versions dev/test de ces sites capables d’accéder et d’interagir avec une version dev/test/staging de Discourse serait idéal.
Par conséquent, je ne l’allumerais que lorsque nécessaire, et je restaurerais une sauvegarde de ma base de données PROD sur mon STAGING périodiquement - pas quotidiennement et peut-être aussi peu qu’une fois par mois.
Si je fais cela, comment puis-je empêcher certains paramètres de changer lors de la restauration de la base de données ?
Ceux-ci, par exemple, seraient inestimables :
Y a-t-il un moyen de restaurer une sauvegarde de base de données, puis d’appliquer manuellement certains paramètres avant de démarrer Discourse ? D’autres idées, suggestions, pièges ?
Si vous conservez des sauvegardes sur S3 et que vous les configurez via des variables d’environnement, vous pouvez facilement créer un nouveau site capable de restaurer cette sauvegarde. Il suffit de créer une nouvelle VM, de cloner Discourse, de copier le fichier yml, de reconstruire et de restaurer. Vous pouvez remplacer les paramètres dans la base de données par des variables d’environnement, comme dans la citation de votre publication.
Il me manque une étape ? Je suis à peu près sûr que cela fonctionnait il y a environ un an. Mais maintenant, bien que cela se peuple, cela n’ajoute aucun sujet ni aucun message au-delà de la section À propos de la catégorie… quelque chose a-t-il changé ?
Merci Jay ! Voici un écran montrant ce que j’ai essayé… Il semble que je doive être dans un « environnement de développement ». Comment puis-je y accéder ?
J’ai fini par restaurer une ancienne sauvegarde d’une de mes instances discourse où j’avais déjà utilisé cette méthode pour peupler. J’ai dû faire ceci, mais cela a fonctionné.
Il y a une chose à faire pour pouvoir supprimer la base de données. Si vous exécutez la tâche rake db:drop, elle vous indiquera ce que c’est. Je suppose donc qu’il faudrait arrêter unicorn avec sv stop unicorn, puis supprimer, créer et migrer la base de données avant d’exécuter la tâche. Ou c’est la prochaine chose que j’essaierais, mais vous avez une autre solution…
J’essaie d’insérer des données de test sur mon serveur de staging, mais j’obtiens une erreur :
rake aborted!
Database commands are only supported in development environment
Ceci concerne une configuration multisite, donc les commandes que j’exécute sont :
./launcher enter web_only
ALLOW_DEV_POPULATE=1 bundle install
RAILS_DB=instance-x ALLOW_DEV_POPULATE=1 rake dev:populate
Que j’utilisais sans problème jusqu’à présent, mais maintenant j’obtiens cette erreur. Puis-je définir une variable d’environnement pour autoriser les commandes de base de données en production ?
