DiscourseのDiscourseイメージの構築 - プラグインのインストール方法

インストール
, ,
1

こんにちは。

UI経由でインストールするのではなく、いくつかのプラグインを組み込んだDiscourse Dockerイメージを構築する方法について、どなたかアドバイスをいただけますでしょうか。

背景として、最新のDiscourseビルド、つまりdiscourse:stableを利用したいと考えており、インストールガイドやその他のドキュメントを読んだところ、これを独自のDockerfileでベースイメージとして使用し、以下のようなことを行えるようです。

RUN cd /var/www/discourse/plugins && \
      git clone https://github.com/discourse/discourse-chat-integration.git

これにより、discourse-chat-integrationプラグインがビルドに追加されます。その後、実行時に、app.ymlファイルにハードコードする代わりに、必要なすべての環境変数、すなわちDISCOURSE_HOSTNAME、DISCOURSE_SMTP_DOMAIN、DISCOURSE_DB_HOSTなどを渡すことができます。

上記について何かアドバイスをいただけると大変助かります。

ありがとうございます。

2

UIからプラグインをインストールすることはできません。YMLファイルからインストールします。もし、ご自身でLauncherを使ってビルドしなかった、まだサポートされていないコンテナを使用している場合は、あなたが提案するように何かを行うでしょう。

しかし、そのプラグインはコアに含まれています（ただし、まだstableではないかもしれませんが？）。

それらはYMLファイルにハードコードされているわけではありません。YMLファイルはコンテナをビルドして起動するために使用されます。ビルドしてから、好きなように起動できます。./launcher start-cmd container-name（またはそれに類するもの。私が間違っているかどうかはLauncherで確認できます）を使用できます。

ですから、あなたがやりたいことは、Launcherを使い続け、プラグインを追加し、コンテナを./launcher bootstrap appでブートストラップし、その後好きなように起動することだと思います。他のマシンから起動できるように、リポジトリにプッシュすることもできます。

ええ、stableではなくなっているかもしれませんが、少なくとももうすぐそうなるでしょう。RFC: A new versioning strategy for Discourse を参照してください。

3

上記の情報、誠にありがとうございます。

私たちがやりたいことは、KubernetesクラスターでDiscourseを実行し、CI/CDワークフローでイメージをビルドできるようにしたいので、カスタムのDockerfileが必要です。その後、すべての環境変数はConfigMapまたはSecretとして実行中のPodに供給されます。これがサポートされているインストール方法ではないことは承知していますが、少なくとも特定のバージョンのDiscourse用のサポートされている方法でDiscourseイメージをビルドし、更新のタイミングを制御できるようにしたいと考えています。

既存のlauncherスクリプトとsamples/web_only.ymlを見ると、volumesセクションとlinksセクションは、Kubernetesで永続ボリュームとマウントを使用して実行するため、コメントアウトできると考えています。その後、web_only.ymlに固定の環境値を追加し、ブートストラップコマンドでコンテナをビルドしてから、生成されたイメージを独自のレポジトリにコピーします。

Discourseのバージョンについては、Docker Hubで新しいリリースが利用可能になったときに監視し、web.template.ymlファイルのbase_image値を修正することで対応できます。

これでよろしいでしょうか？

4

そうかもしれませんが、コンテナをビルドするためには、通常、コンテナはそのデータベースと通信する必要があります。実際のデータベースである必要はありません（ただし、その場合はデータベースを移行し、パイプラインでアセットを事前コンパイルする必要があります）。

Discourse のアップグレードの問題と、ベースコンテナ内のリソースの更新の問題とを混同している可能性があります。

最先端のもの（bleeding edge）で問題ない場合は、こちらがあります: Is Docker image discourse/discourse considered safe and production-ready? - #14 by JackNZ

5

コンテナは db:migrate フックなしでビルドすることには成功しましたが、まだテストしていないので動作するかどうかはわかりません。それはやることリストに入っています :slight_smile:

base_image の値については、新しい Docker イメージがリリースされたときに変更されると想定しているので、ランチャースクリプトで呼び出されるメインブランチにあるものをそのまま使用するつもりです。

他のスレッドも確認します :+1:

「いいね！」 1
6

それは良いスタートですね！新しい Discourse を起動するときには、データベースのマイグレーションが必要になります。

Discourse をアップグレードしていないのであれば、新しいベースイメージを取得する必要はありません。したがって、新しいベースイメージがあるかどうかは実際には気にしなくてもよいのです。

7

ジェイさん、ありがとうございます。ついにビルドが動作しました。ポッドが起動しましたよ :slight_smile: 一時的なデータベースを使用して、CI/CDビルドプロセスで db:migrate を含めるように変更しました。

イメージビルドがダミーのデータベース/Redisに対して行われる場合、db:migrate は起動時に常に実行される必要がありますか？私の現在の方法は、db:migrate とプリコンパイルをポッド内の initContainer で実行することです。

discourse/discourse イメージは、まもなく本番環境に対応可能になれば使用するのが理想的です。

8

それはうまくいくはずです。

ゼロダウンタイムアップグレードに興味がある場合は、SKIP_POST_DEPLOYMENT_MIGRATIONSを使用し、古いPodが停止した後、rake db:ensure_post_migrations db:migrateのようなもので再度マイグレーションを実行する必要があります。

9

これまでのご協力に大変感謝いたします、Jayさん。

もう一つ質問があります :slight_smile:

現在、デプロイ時にいくつかの環境変数（例：DISCOURSE_BACKUP_LOCATION=s3）を設定していますが、DiscourseはUI経由で設定され、site_settingsテーブルに保存された値ではなく、その環境変数の値を使用するという理解で正しいでしょうか？もしそうであれば、設定されている環境変数をチェックし、それに対応するサイト設定を特定できるようなツールやスクリプトはありますか？

理由ですが、稼働中のDiscourseインスタンスを移行しようとしており、リスクを最小限に抑えるために、新しいインスタンスで設定し忘れた環境変数があり、それが新しいインスタンスに悪影響を及ぼす場合に備えて、現時点では環境変数を設定しないでおきたいと考えています。私の考えでは、現在のインスタンスで設定されているものを確認し、関連する設定をテーブルに作成し、新しいインスタンスにバックアップ/リストアした後、環境変数を一つずつ解除していくという方法です。

論理的かどうかは分かりませんが、稼働中のインスタンスの環境変数が新しいインスタンス（稼働中＝古いDiscourseバージョン、新しい＝最新のDiscourse）で異なっていたり、サポートされていなかったりする場合に備えて、最も常識的なアプローチだと考えました。

10

まあ、そんなところです。それらはデータベース内の値を上書きします。それらは /var/www/discourse/config/discourse.conf またはそれに非常によく似たファイルに書き込まれます。

11

素晴らしい。ジェイ、助けてくれてありがとう。失敗するところだったデプロイを機能させる上で、本当に大きな違いになりました :+1:

「いいね！」 1