新しいDBとバックアップ・アップロード用の新しいS3バケットを持つ新しいサーバーへの移行

インストール
,
1

こんにちは。

現在、既存のBitnamiベースのデプロイメント（かなり古いバージョン）から、最新のDiscourseリリースを使用したAWSの公式サポートされているインストールにサーバーを移行中です。この新しいインストールでは、外部のElasticacheとRDSインスタンスが使用され、バックアップとアップロードにはS3も使用されます。

2つの質問があります。

  1. 古いDiscourseサーバーはかなり古いバージョンですが、新しいDiscourseサーバーでバックアップ/リストアを実行すると、関連するすべてのアップグレードコマンドが実行されるだけでしょうか？
  2. バックアップファイルを新しいサーバー上の新しいDiscourse Dockerコンテナにコピーし、コマンドラインでリストアを開始した場合、設定で設定した新しいバケット値はリストアの一部として上書きされますか、それとも新しい値が使用されますか？新しいDBはバックアップから設定され、コンテナを終了して./launcher rebuild appを実行すると、新しいS3の値が使用されると想定しています。

私の想定が正しい場合、リストアを実行する前に、古いS3バケットの内容を新しいバケットにコピーする必要があると思われます。

このようなバックアップを使用した移行を行う際に、他に注意すべき点はありますか？

よろしくお願いします。

2

何か見落としているかもしれませんが、なぜ新しいバケットを確立しているのですか？適切なライフサイクルルールを持つ新しいバックアップバケットを作成するのは問題ないように思えますが、既存のDiscourseインスタンスがS3アップロードバケットを使用している場合、いくつかの問題が発生します。

「いいね！」 1
3

新しいバケットが必要な2つの理由：

  1. Bitnamiからの移行が問題なく機能するかどうか100%確信がないため、移行を中止する必要がある場合に備えて、既存のデータに影響を与えたくありません。
  2. バケットの命名規則を変更したため、このために2つの全く新しいバケットを用意する方が簡単だと考えました。

特に1点目が懸念されるため、念には念を入れています。

新しいアップロードバケットに関して、どのような問題が想定されますか？古いDiscourseサーバーは読み取り専用モードに設定されます。計画としては、新しいサーバーが起動して検証されたら、古いサーバーを停止し、DNSを新しいサーバーに変更してから、CDN（Cloudfront）のキャッシュをパージし、一般公開するという流れです。

4

古いバケットからデータをコピーする予定だったことを見逃していました。AWSを確認したところ、簡単そうです。私なら、AWSや他のサーバーに移行する前に、バケットを変更するような面倒なことはしません。

公式サポート？本当かどうかはわかりません。

新しいサーバーへの移行前にDiscourseを更新することを強くお勧めします。
古いインスタンスでは、まだ設定されていない場合は、S3の設定をapp.ymlに移動することを推奨します。

5

これは、本番環境に影響を与えることなく簡単にテストできることです。

個人的には、これら2つのことを同時に行うことは可能な限り避けたいと思います。

  1. バケットの移動をすべて回避できるか確認する
  2. 回避できない場合は、Bitnamiからの移行後に実行する
「いいね！」 1
6

このような種類のインストールを行うことが、どのように付加価値のある提案になるのか、非常に興味があります。
サポートされていないインストールに関する数多くの投稿から見ると、学習や実験目的でない限り、メリットよりも手間の方が大きいように思われます。

7

そのような設定は、Discourseの観点からはサポートされていないインストールかもしれませんが、エンタープライズIT組織の観点からは、RDSとElasticacheは標準的であり、Discourseの標準インストールの方が異質なものとなる可能性があります。