新しい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の標準インストールの方が異質なものとなる可能性があります。

「いいね！」 1
8

ありがとうございます。つまり、なじみと既存のインフラストラクチャということですね。

「いいね！」 1
9

この質問へのご意見ありがとうございます。

@RGJ が述べたように、当社のエンタープライズインフラストラクチャは、キャッシュやデータベースなどのために外部サービスを使用しているため、Elasticache と RDS を使用しています。これにより、これらのサービスに対する完全なバックアップと冗長性を確保でき、セキュリティ管理にも役立ちます。これは、Discourse の観点からは公式/サポートされているインストールです。単に異なる一連のテンプレートを使用しているだけです（「標準」という言葉を使うのは少し誤解を招いたかもしれません、申し訳ありません）。

したがって、既存のインストール用にバケット名を更新してから、新しいサーバーへの移行を実行する必要があるようです。以前に Bitnami のアップグレードで問題が発生したため、公式のインストール方法への移行となるため、既存のインストールを最新バージョンに更新することは不可能です。

しかし、お尋ねしてもよろしいでしょうか。既存のバケットを使用してリストアを実行し、その後 app.yml を更新して新しいバケットを参照するようにした場合、どのような問題が発生する可能性が高いですか？すべての DISCOURSE_ 環境変数がデータベース内の設定（該当する場合）よりも優先されるのではないでしょうか？それとも、他に問題を引き起こす可能性のあるものはありますか？

10

私はそれはお勧めしません

移行前に実行して問題が発生した場合、新しくインストールした標準インスタンスではなく、古いBitnamiインスタンスで問題が発生することになります。また、古いバージョンであることに加え、「Bitnami」という言葉に言及するだけで、このメタ（フォーラム）でのサポートははるかに得られにくくなります。

はい、その通りです。

11

ああ、リチャードさん、すみません、S3の名前変更に関する箇条書きを読み間違えました :+1:

ですので、既存のバケットをバックアップし、移行を行い、バケット名の変更を行うのがより良い計画です。

これまでのご協力に感謝します。

そして、そうですね、「B」の単語は人々を黙らせるので、そこから離れるのは良いことです :slight_smile:

「いいね！」 1
12

はい、そして一度に多くのことを行わないように、バケット名の変更を行う前に数日待つべきです。

「いいね！」 1
13

承知いたしました。

もう一つ質問させてください。Discourseコンテナ内でコマンドラインからリストアを実行する場合、データベース接続やRedis接続などの詳細について、既存の/var/www/discourse/config/discourse.confの設定を使用するのでしょうか、それともバックアップファイル内の情報でその設定を上書きするのでしょうか？

重ねてお礼申し上げます！

14

discourse.conf は app.yml から生成され、バックアップファイルには含まれません。

一般的に、discourse.conf に含まれる設定はサイト設定を上書きします。

したがって、データベースに setting_foo がある場合、app.yml で DISCOURSE_SETTING_FOO を定義することにより、それを上書きでき、その結果 discourse.conf に setting_foo が生成されます。

「いいね！」 2
15

素晴らしい。@RGJ さん、大変お世話になりました。移行が完了したら、結果をご報告します。

「いいね！」 1
16

Discourseコンテナを、当社のツールキットを使用した外部のpostgresqlおよびredisサーバーに向けることは、サポートされているインストールです。

RDS[1]はPostgresqlであり、ElasticacheはRedisであるため、これは問題ありません。

これは問題ないはずです。私たちはこれをホスティングへの移行を行う人々のために行っています。

私の好みはプロセスを可能な限りシンプルに保つことです。そのため、古いサーバーで完全なバックアップ（アップロードを含む）を実行し、それを新しいサーバーにリストアできれば、古いサーバーに影響を与えることなく新しいセットアップを完全にテストできます。

  1. ok, Postgresql RDS ↩︎

17

@supermathie さん、どうもありがとうございます。

@RGJ さんからも提案があったように、バケット名を変更せずにバックアップ/リストアを実行します。申し上げたように、私の懸念は既存のサーバーデータに一切影響を与えないことでしたが、既存のバケットを先にバックアップし、移行中に既存のサーバーを読み取り専用モードにすれば、バケット内のアップロードデータの整合性は十分に保護されると考えています。

「いいね！」 1
18

情報ありがとうございます！自分の無知を大胆にさらけ出すのは嫌いです。

19

明確化: メジャーバージョンが私たちが提供するものと一致する場合

20

皆さん、こんにちは。

昨日、移行作業を実施しましたが、バターのようにスムーズに進み、非常に満足しています。

皆様のご協力に感謝いたします。

「いいね！」 2