Patreonログイン、HTTPS強制、S3 CDNに関する問題（3つの問題）

インストール
1

投稿を3つに分ける必要があるかもしれませんが、関連しているので、まず1つから始めます。

数日前、私はこのチュートリアル（https://www.digitalocean.com/community/tutorials/how-to-scale-your-discourse-deployment-with-a-load-balancer-and-managed-database-cluster）をほぼそのまま使用して、Digital OceanのスタンドアロンDiscourse Dropletをロードバランサー内の2つのDropletに移行しました。ここまでは順調でした。

次に、このチュートリアル（Configure an S3 compatible object storage provider for uploads

この時点で、ロードバランサー内でHTTPSで動作するようにサーバーを完全に壊してしまいましたが、それは不可能でした。このチュートリアル（Configure an S3 compatible object storage provider for uploads Ocean Space/CDNをS3/CDNと連携させることができませんでした。細部まで確認し、何度も各側面を検査しましたが、機能しませんでした。Discourseを再構築できる唯一の方法は、app.ymlからDISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.comパラメータを削除することでしたが、それでも構築はできましたが、サーバーが応答しませんでした。ロードバランサーとDO Space/CDNの設定に応じて、503サーバー応答なしエラー、または通常のブラウザサーバー応答なしまたはサーバー切断エラーが発生しました。試した設定のすべての可能な組み合わせを試しましたが、ページを提供できるようにするものはありませんでした。

DISCOURSE_S3_ENDPOINTパラメータを残したままにすると、Discourseの再構築中に次のエラーが発生しましたが、S3_ENDPOINTパラメータをコメントアウトすると消えました。
Aws::S3::Errors::InvalidAccessKeyId: Aws::S3::Errors::InvalidAccessKeyId

すべてのファイルはS3に同期されていたので、アクセスキーは問題なかったと仮定しても安全だと思います。問題は、S3_ENDPOINTパラメータが何らかの形で原因でした。

今日、前回の試みを機能させることを諦め、HTTPのみでロードバランシングしていたDropletのバックアップを復元しました。そして、このチュートリアル（https://meta.discourse.org/t/setting-up-file-and-image-uploads-to-s3/7229）を実行して、ようやく再び機能させることができました。ただし、今回は推奨チュートリアルに記載されている設定で`app.yml`を編集するのではなく、Discourse管理パネルからS3設定を編集しました。最終的に機能しましたが、重要な違いは、S3 CDN設定を意図的に省略したことです。投稿にアップロードされた画像がS3に保存されていること、およびDiscourseを直接S3にバックアップできることを確認しました。これが私が本当に望んでいることですが、現在、3つの問題に悩まされています。1つはクリティカルで、2つは無視できるものですが、可能であればここで確認したいです。

クリティカルな問題は、ユーザーがDiscourseログインページにあるPatreonログインボタンを使用してログインできなくなったことです。次のメッセージが表示されます。
申し訳ありませんが、アカウントの認証中にエラーが発生しました。もう一度お試しください。

URLはこちらです。
https://mbp.community/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fmbp.community%2Flogin&strategy=patreon

これを機能させるために試せることは何か、アドバイスをいただけると大変助かります。しかし、再び、サーバー内部でHTTPSで実行されていないことが原因ではないかと疑問に思っています。URLからわかるように、外部ではHTTPSですが、内部ではそうではありません。そのため、確実なことはわかりにくいです。誰かがDiscourseでのDigital Oceanロードバランシングなどの経験を持っていることを期待しています。

他の2つの問題は、現在管理コンソールで次のように指摘されています。

現在のサイト設定に基づいたアドバイス

  • ウェブサイトはSSLを使用しています。しかし、[force_https](https://mbp.community/admin/site_settings/category/all_results?filter=force_https)はサイト設定でまだ有効になっていません。
  • サーバーはファイルをS3にアップロードするように構成されていますが、S3 CDNは構成されていません。これにより、高額なS3コストとサイトパフォーマンスの低下につながる可能性があります。「オブジェクトストレージを使用したアップロード」を参照して詳細を確認してください（https://meta.discourse.org/t/-/148916）。

そのため、force_httpsをオンにすることは構いませんが、ロードバランシングされたサーバーが内部でHTTPSで実行されていないため、サーバーからロックアウトされるのではないかと心配しています。昨日の問題のため、12時間かけて頭を壁に打ち付け、無数の15分ごとのDiscourse再構築を見ても何も得られないのは避けたいです。再び、私の構成でforce_httpsをオンにしても安全であることを知っている人がいれば、教えてください。

そして2番目の問題は、app.ymlファイルに追加されたパラメータではうまくいかなかったので、これも再度試すのは気が進みません。これは、app.ymlファイルに追加されたパラメータと基本的に同じことを行うと確認できますか？もしそうなら、この2番目のメッセージは無視します。逆に、何らかの理由で試しても安全な場合は、教えてください。バックアップを取って試してみます。

長い投稿ですみません。何についてアドバイスを求めているのか理解していただければ幸いです。

「いいね！」 1
2

それなら、ここでサポートされているのは標準的なインストールだけなので、そこで助けを得る必要があります。

1日のページビューが20万件を超えることを期待していますか？そうでないなら、CDNを備えた単一の8GB Dropletの方が管理がはるかに簡単で、おそらく安価でしょう。そして、私が把握している限り、それらの指示は誰にとっても機能しない可能性が少なくともいくつかあります。

まず、ステップ5で説明されているように外部Redisを設定しましたか？もしそうでないなら、少なくともいくつかの問題が発生すると予想されます。彼らはスティッキーを使用することで「修正」されると示唆していますが、実際にはそうではありません。そのため、診断が困難な偽のエラーが発生する可能性があります。また、すべてのインスタンスがDiscourseのまったく同じバージョンを実行していることを確認する方法を指定していないため、それも問題を発生させる可能性があります。

実際、それを最初に実行する必要がありました。そうしないと、その設定は機能しません。なぜなら、一部のアップロードは一方のサーバーに、他方は別のサーバーに配置されることになり、それらの指示には「アップロード」という言葉がまったく言及されていないからです。したがって、テスト以外でこれを使用している場合、かなりの混乱が生じている可能性があり、複数のDroplet間でアップロードを同期する必要があるでしょう。

Digital OceanのCDNはDiscourseでは機能しないと具体的に記載されています。

推奨されているように、別のCDNを使用しましたか？Bunny.netは設定が非常に簡単でシンプルです。

「いいね！」 2
3

ああ、あのガイドを書いたのが誰なのか分かりませんが、Discourseを大規模に運用することに慣れている人ではなかったことは確かです。

最後のステップでは、Dropletのスナップショット機能を使用してロードバランサーにバックエンドを追加できるとありますが、ガイドではアップロードにオブジェクトストレージを使用することに言及していないため、それを行うとユーザーのアップロードが完全に壊れます。また、そのガイドに従うと、アップデートは簡単ではなくなります。

@Martin_Baileyへのアドバイスは、そこにあるものを何もフォローしないことです。壊れたインストールになるだけです。あなたが発見したように。

Discourseを迅速かつ健全にインストールしたい場合は、公式のインストールガイドに従ってください。その道から外れると、すぐにフルタイムの仕事になる可能性があります。

「いいね！」 3
4

面白い。そこにラファエルの投稿へのリンクといくつかの問題点を概説したコメントを残しましたが、削除されました。

「いいね！」 3
5

すごい！OK、うまくいったと思ったのですが、いくつか間違いに気づいた点がありました。しかし、ロードバランシングされたインストールができました。もちろん、最初に見つけたのは画像アップロードが壊れていたことでした。だから、画像を保存するためにS3を使ったのです。

現状では、単一サーバーに戻すにはさらに多くの作業が必要なので、Patreonログインの問題について何かできることはありますか？他の2つの問題は無視します。

いずれにしても、ご協力ありがとうございます。皆さんはここで素晴らしい仕事をしています。

6

ジェイさん、こんにちは。ご協力ありがとうございます。ご質問にお答えします…

Patreonコミュニティはクローズドなので、ユーザー数はそれほど多くありません。主な目的は、サイトをダウンさせることなく1つのサーバーを更新できるようにすることでした。これは可能であることを確認したので、セットアップには満足しています。はい、ステップ5を実行したので、状態は外部Redisドロップレットに保存されています。

しばらくの間、私の進歩を妨げていたもう1つのことは、DISCOURSE_DBパラメータに実際のポートが含まれているにもかかわらず、Postgresにデフォルトポートで接続しようとしていたため、再構築が失敗し続けていたことです。そのため、app.ymlに以下のパラメータを追加する必要がありました。

DISCOURSE_DB_BACKUP_PORT: 25060

最初のチュートリアルに基づいてすべてを機能させるまで、アップロードについては考えていませんでした。S3をセットアップしようとしたときに、すべてが壊れましたが、それは、皆さんが提供しているDO Space CDN設定が機能しなかったためです。

Digital Ocean CDNはDiscourseでは機能しないと明記されています。

知っていますが、チュートリアルではこれを追加するように指示されています。
DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com

これはDO Spaceから取得したものですよね？これらのチュートリアルで読んだすべてに基づいて、異なるCDNをどのように使用するかはまったくわかりませんが、後でカバーするので、現時点では心配していません。

いいえ、別のCDNは使用しませんでした。CDNを使用しないことにはまったく問題ありません。CDN設定は空のままにしておきます。さらに更新情報として、皆さんが親切に提供してくれたアドバイスに基づいて、先週のバックアップにロールバックしようとしていたのですが、まずforce_httpsオプションを有効にすることを試みました。それを有効にすると、思ったとおり、Patreonログインの問題が解決しました。サーバーに変更は加えられていないため、Patreonログインの問題は、おそらくDiscourseの内部ロジックによって引き起こされたものですが、これも、推奨もサポートもされていないことを（今になって）理解しています。

したがって、現時点では、セットアップは最初のチュートリアルで推奨されているものとほぼ同じですが、画像とバックアップはすべてCDNなしでS3に送信されています。非常にうまく機能しています。スタンドアロンインストールを使用するように推奨していただいていることは理解していますが、アップデートが来るたびにサイトを15分間ダウンさせるのは非常に苦痛です。昨日、マルチサーバーセットアップのためのdata.ymlとweb_only.ymlへの参照を見つけましたが、何をすればよいかわからなかったので、あきらめました。

今のところ、このまま進めます。皆さんの助けと、皆さんがしてくださっているすべてのことに感謝します。

7

わかりました、皆さん、あなたの勝ちです。:slight_smile:

画像が http 経由で共有され、https 経由で共有されない場合があるため、画像が再び読み込まれないという問題がさらに発生し始めました。あなたの言う通り、これはひどい状況です。

Postgres データベースはそのままにして、サーバーの Droplet を 1 つに戻し、ロードバランサーなしで、画像/Redis をローカルに保存するように、ほとんど元に戻しました。ただし、サイトのバックアップのために S3 はそのまま残しています。それがどれほどスムーズに機能するかは気に入っています。

アップグレードごとに 15 分間のダウンタイムに戻ると思いますが、これまでに合計 5 日間費やしました。これ以上時間を費やすことはできないので、最初にフォローしたチュートリアルについて皆さんが正してくれたことに感謝しています。まるで、人々にもっと Droplet を購入してほしいかのようです。:slight_smile:

ご協力ありがとうございました。

8

実は、お伺いしたいのですが、Discourse のセットアップ方法に関するチュートリアルはありますか？これにより、アップデートごとに発生する 15 分間のダウンタイムを回避できます。data.yml と web_only.yml に関するメモを見ましたが、それを実現するために何をする必要があるのか全く分かりません。

9

data と web_only の YAML を別々に持つことは、2 つのコンテナのセットアップによるものです。

「いいね！」 1
10

これは機能し、いくつかの問題を解決します。もし（他の）理由でロックアウトされたとしても、いつでも launcher enter app で戻ってきて、Rails コンソールからサイト設定を元に戻すことができます。

他の人がすでに言っているように、別のガイドに従う方が良いでしょう。

「いいね！」 1
11

皆さん、こんにちは。

DigitalOceanの記事を書いたのですが、いくつか間違いがあったようです。申し訳ありません！

修正のため、記事を更新したいと思います。

そこで、修正版で間違いがないように、いくつか質問させてください。

記事の中で、マネージドRedisインスタンスをオプションで使用できると書きました。当時、スティッキーセッションを使用すれば、Discourseイメージに組み込まれているRedisを使用できると考えていました。これは正しいでしょうか？それとも、これだけでは不十分で、外部Redisインスタンスが必須要件となるべきでしょうか。

オブジェクトストレージに関する@Falcoさんのコメントに同意します。これは私の見落としでした。画像アップロードを処理するためにDigitalOcean Spacesを使用する手順を含めるように記事を更新できます。

Dropletsからすべてのステートを削除することが、インストールの問題を解決する答えだと推測しています。スティッキーセッションのおかげで外部Redisがオプションで済むことを期待していましたが、間違っているかもしれません。

Discourseのアップグレードがより複雑になることにも同意します。しかし、Dropletsからすべてのステートを削除すれば、1つのDropletをアップグレードし、それをスナップショット化し、スナップショットから作成した新しいDropletsで他のDropletsを置き換えるだけで済むはずだと思います（Kubernetes Deploymentsのようなものですが、再デプロイは手動で行います）。

Discourseをスケーリングするためのより良い方法があることにも同意しますが、それでも記事を修正したいと思っています。そうすれば、人々が望むならそれに従うことができます。

よろしくお願いします。
Francis

12

私はハッピーなDigital Oceanの顧客で、クライアントがAPIキーとホスト名を入力すると、自動的にドロップレットを作成し、Mailgunを設定し、DNSレコードの設定を待ち、Discourseをインストールするダッシュボードがあります。

あなたの提案通りには全く機能しません。フォーラム（他に方法が見つからなかったので）でDigital Oceanに連絡して知らせたのですが、メッセージは削除されました。それから9ヶ月後にここで返信があります。

正しく行うのはかなり複雑な偉業であり、役立つケースはかなり考えにくいです。私は1日10万PVのサイトを8GBのドロップレットで運用しています。このガイドのターゲットオーディエンスは誰だと思いますか？

はい、外部Redis、Postgres、およびCDN付きS3バケットが必要です。Digital OceanのCDNは機能しないため、ガイドでは他の会社のCDNを設定する方法を説明する必要があります。それはしたくないでしょう。そして、それはセットアップのためだけです。その後、アップグレードしたい場合、それは誰も地球上で助ける方法を知らないであろう全く別の手順になります。

あなたが最善を尽くせることは、そのガイドを完全に削除することです。あなたが本当のヒーローになりたいなら、メールなどの設定に使用する独自のプロプライエタリスクリプトを使用しないように1クリックインストールを修正できます。そうすれば、実際には標準的なインストールになります。Discourseに到達するためにcontrol-cを使用しなければならないのはかなり混乱します。そして、1クリックを使用した人々は標準のDiscourseツールを使用しなかったため、コマンドラインでのアップグレードの時期が来てもそれらを使用する方法を知りません。それをしていただけると、本当に本当に素晴らしいです。

ここで、それを使用した人々が問題を抱えていたのを見ることができます：Search results for 'digital ocean one-click' - Discourse Meta

「いいね！」 1
13

いいえ、Redisは単純なキャッシュではなく、多くのカウント、レート制限、バックグラウンドジョブ、Pub/Subなどを処理するため、複数のRedisインスタンスがあると、カウントの破損や動作の不具合が発生します。

それは解決策になりますが、マネージドRedis、マネージドPostgreSQL、マネージドロードバランサー、オブジェクトストレージ、コンテナレジストリを追加すると、標準ホスティングの料金を支払うよりもはるかに高価になり、メンテナンスも非常に複雑になります。

そうなると、月数百ドルを支払っても構わないが、SPOF（単一障害点）によってサービスが停止しても気にしないという人々との共通点は非常に小さくなり、フォーラム管理者が推奨するものというよりは、ホビイスト向けのセットアップになります。

「いいね！」 1