Discourse公式「cloud native」Dockerイメージ

特徴
1

こんにちは。

チームは最近、インターフェース経由でのロングポーリングの無効化のサポートを終了しました。これにより、Passengerを使用しており動作しないBitnami Dockerイメージに必要な機能が壊れてしまいました。詳細は https://github.com/bitnami/bitnami-docker-discourse/issues/177 を参照してください。Bitnamiイメージは環境パラメータを直接渡さないため、誰かがBitnamiイメージを拡張するまでこれは壊れたままです。詳細は DEV: Drop `enable_long_polling` and `long_polling_interval` settings by tgxworld · Pull Request #16323 · discourse/discourse · GitHub を参照してください。

もちろん、DiscourseはすでにDockerコンテナでのみ配布されているので、私には質問があります。チームは「クラウドネイティブ」Dockerイメージを維持する可能性はありますか？

Bitnamiイメージとあなたのイメージの大きな違いは、動作モードです。最新のインフラストラクチャは、インストールの自動化を期待しています。通常、KubernetesではHelmで行われますが、VMを使用した比較的伝統的な環境でのAnsibleデプロイメントでも同様の結果が得られます。したがって、比較的無視されているBitnamiイメージと同等にするために実際に行うことは、自動インストーラーのルーチンを追加し、おそらくHelmテンプレートを適応させることでしょう。

せっかくなので、Discourse自体とその「クラウド対応」についてフィードバックを残させてください。

一般的に、再現可能なセットアップを現在の顧客プロジェクトに結び付けようとした際に、Discourseは最新のインフラストラクチャの観点から作られていないことがすぐにわかりました。一例として、共有NFSストレージの必要性が挙げられます。これは信頼性もスケーラビリティもありません。幸いなことに、そのほとんどはすでにS3にリダイレクトできますが、プラグインが残っています。

プラグインの問題を解決するには3つの方法があります。

  • データベースに保存された評価済みコード（推奨されません）
  • 事前パッケージ化されたサイドカーコンテナ（Kubernetesの用語ではinitContainerとして使用され、空のディレクトリに書き込みます）を、Discourseコンテナ起動前に揮発性ストレージ（つまりtmpfs）に書き込みます（推奨されますが、あまり快適ではありません）。
  • インストーラーのルーチン。起動時にDBから現在のプラグイン情報とそのインストールコマンドを取得し、実行時にもプラグインをインストールするためのウォッチャー/リスナーのルーチン（推奨されません。非常に遅く、エラーが発生しやすいため）。
「いいね！」 3
2

ここでかなり広範囲に議論されていると思います。

「いいね！」 3
3

正直なところ、bitnamiが簡単に解決してくれたので、それについてそれほど議論する理由はあまりありません。Discourseを簡単にデプロイできるようにすることは、ロケット科学ではないでしょう。

4

多くのDiscourseサイトをクラウド環境で実行していますが、NFSストレージは使用していません。アセットとアップロードはオブジェクトストレージ（S3）で処理され、ソースコード（コアとプラグイン）はブートストラップされたコンテナイメージに永続化されます。

「いいね！」 4
5

それはすでに回答されています。幸いなことに、これラのほとんどはすでにS3にリダイレクトできますが、プラグインとして残っている部分があります。事前に構築されたコンテナを使用するのは悪い習慣です。なぜなら、Helmチャートの使用中に適切にアップグレードされないリスクが高まるからです。

6

プラグインが共有NFSストレージを必要とする理由がわかりません。詳しく説明していただけますか？

7

申し訳ありませんが、このエピックなトピックについてはすでに議論があります。

これを分割したくありません。アイデアがあれば、以下で議論してください。

「いいね！」 3