Bonjour, je viens de mettre en place une nouvelle installation de Discourse - merci pour tout le travail accompli pour la rendre si simple !
Idéalement, j’aimerais rendre mon serveur Discourse remplaçable, de sorte que si, par exemple, quelqu’un le tue accidentellement dans la console EC2, je ne perde aucune donnée.
La fonctionnalité intégrée de sauvegarde/restauration est excellente, et j’ai déjà fait quelques tests avec. Je stocke app.yml, les uploads et les sauvegardes dans S3.
La prochaine étape serait de déplacer la base de données vers Amazon RDS, pour laquelle il existe un excellent guide ici.
Ma question est la suivante : si je fais cela, devrais-je en théorie être en mesure de terminer l’instance, puis sur un nouveau serveur simplement cloner Discourse, récupérer mon app.yml et exécuter ./launcher rebuild app ? OU y a-t-il d’autres états au-delà de postgres/uploads/app.yml ? Peut-être dans Redis ?
Je pense que c’est en grande partie vrai. Vous devrez vous assurer de ne pas en avoir deux en cours d’exécution simultanément. Lorsque vous construirez le nouveau conteneur, vous migrez la base de données, la rendant potentiellement inutilisable pour l’autre conteneur (vous pouvez l’éviter avec skip_post_deployment_migrations). Les éléments dans Redis sont considérés comme éphémères et ne sont pas sauvegardés. Je ne suis pas tout à fait sûr comment ou si certains des éléments là-bas sont restaurés, mais vous ne vous en souciez probablement pas.
@phil22 - J’ai travaillé sur une configuration similaire à ce que vous proposez et c’est plus subtil que vous ne le pensez :
L’équipe Discourse publie plusieurs versions par mois et vous devez donc rester sur votre version d’origine lorsque vous clonez sur votre nouvel ec2. Normalement, il est acceptable de mettre à niveau l’application aveuglément, mais certaines versions incluent des mises à niveau majeures de la base de données (PG 12 → PG 13) et si vous ne suivez pas cela et négligez de mettre à niveau votre RDS externe, vous pourriez vous retrouver bloqué.
Nous avons obtenu du succès en faisant en sorte que l’ec2 utilise un volume EBS qui est également configuré pour être monté à l’intérieur de votre conteneur d’application. En utilisant cela, nous stockons tout le contenu du dossier /shared. De cette façon, lorsque vos instances ec2 vont et viennent, vous avez tout ce contenu du dossier partagé persisté sur EBS. De plus, parfois vous changez d’avis sur le stockage de fichiers dans s3. Avoir un endroit alternatif pour stocker les fichiers téléchargés (comme le dossier /shared) est une bonne chose dans ce cas.
Suite à vos conseils, je pense que je vais opter pour RDS, mais en épinglant à un commit spécifique du dépôt discourse_docker. Bien que cela semble rendre les mises à niveau plus complexes, j’espère que cela signifie que si nous avons un problème avec le serveur, nous aurons tout en sécurité sur RDS et pourrons assez rapidement retrouver le même état de fonctionnement sans restauration manuelle.
(Je pense que nous pourrions obtenir la même chose avec EBS, mais avec le chiffrement de volume et la magie Unix pour monter/démonter le volume entre les instances, je suis un peu effrayé par le processus d’automatisation de cela)