提供されたスクリプトなしでDiscourseをインストールする方法はありますか？

サポート インストール
1

みなさん、こんにちは。

また変なことをお伺いしようと思い、来ました :sparkles:

社内コミュニティ向けに Discourse をインストールする方法について、まだ調査中です。以前は、「外部 Redis と外部 Postgres を使用して Discourse をインストールする方法」や「Kubernetes クラスター内ですべてを管理する方法」について質問しました。詳細はこちらをご覧ください。

さて、新たに疑問が生じました。ヘルム (Helm) を使用してデプロイする際、独自のコンテナイメージを作成する必要があると聞きました。そのため、クラウドインストールガイドで提供されているスクリプトを使用して、公式ドキュメント通りにインストールすることができなくなってしまうのではないかという懸念です :cold_sweat:

ブートストラップコマンドを使って独自イメージを構築しようと試みましたが、Ruby テンプレートを探してエラーを返すため、自分で Docker イメージを起動することができません。

提供されているスクリプトを使わずにコンテナイメージを起動することは可能でしょうか？少しお手伝いが必要だと感じています。Bash スクリプトを見てみましたが、自分には少し難しすぎるようです。もしかすると、私と同じ状況にあった方がいて、アドバイスしてくださるかもしれません。

いつもありがとうございます :revolving_hearts:

2

より多くのコンテキストと詳細を提供します：

カスタマイズしたイメージを作成するために、bootstrap コマンドを使用してラッパースクリプトを実行しました。
その後、ドキュメントによると、イメージからコンテナを作成するには、run コマンドでラッパーを実行する必要があります。
スクリプトのコードを検証したところ、Docker の指示は以下の通りであることがわかりました：

$docker_path run --shm-size=512m $links $attach_on_run $restart_policy "${env[@]}" "${labels[@]}" -h "$hostname" \
        -e DOCKER_HOST_IP="$docker_ip" --name $config -t "${ports[@]}" $volumes $mac_address $user_args \
        $run_image $boot_command

しかし、これらの変数をすべて変換して、スクリプトなしで単独で実行できるコマンドを作成することができません。もしかすると、最初からこのアプローチ自体が間違っているのかもしれません。しかし、誰にも迷惑をかけずに自分で解決できるか試したかったため、この方法で試してみました。

自分で Docker イメージを実行しようとすると、コンテナが終了してしまい、ログを確認すると以下のエラーが表示されます：

Already up to date.
INFO -- : Loading --stdin
/pups/lib/pups/config.rb:23:in `initialize': undefined method `[]' for nil:NilClass (NoMethodError)
        from /pups/lib/pups/cli.rb:27:in `new'
        from /pups/lib/pups/cli.rb:27:in `run'
        from /pups/bin/pups:8:in `<main>'
3

./launcher start-cmd appを実行してみてください。

4

ありがとうございます、とても助かりました :sparkling_heart:

このコマンドはドキュメントに記載されていましたか？もしそうなら、質問してすみません。見落としていました。

いつも助けてくれて本当にありがとう :sparkles:

5

Discourse は、共有ボリューム上で動作する PostgreSQL に依存しています。また、画像、アップロードされたファイル、バックアップ、ログなど、多くの重要なファイルもその共有ボリューム内にあります。

Discourse の構成標準に従って /shared ボリュームのファイルシステムの整合性を維持していれば、Discourse の Docker イメージとコンテナアプリケーションを簡単に起動・停止できます。しかし、Discourse スクリプトなしでアプリケーションをビルドすることは（私の知る限り）できません（スクリプトを完全にリバースエンジニアリングし、完璧に機能しサポートされているスクリプトに基づいて独自のスクリプトを作成しない限り）。なぜなら、これらのスクリプトは、Ruby on Rails（サーバーサイド技術）の上に高度な EmberJS SPA（クライアントサイド技術）を構築する責任を負っており、コアアプリケーションとすべてのプラグインの構成管理も行っているからです。正直なところ、これは非常に複雑なアプリケーションです。

はい、すでにデータベース、画像とアップロード、バックアップ、ログファイルなどの永続的ストレージ要件を含む Discourse の構成標準に準拠した完璧な Discourse Docker イメージをビルドしている場合（その場合のみ）、スクリプトを使用せずに Discourse コンテナを起動したり、Discourse イメージから Discourse コンテナを作成したりすることができます。共有ボリュームには Discourse に必要な多くの重要なファイルが含まれており、上記のすべての必須前提条件（上記で言及されたものだけではありません！）が揃っていない状態で、単に「素の Discourse Docker イメージ」を取得して起動・実行することはできません。

これが役立つことを願っています。

6

返信ありがとうございます、とても参考になりました :slight_smile: 昨日、なぜこのスクリプトが必要なのかについて、このトピック や他のいくつかの記事で読んでいました。

より詳しいご説明を改めてありがとうございます。これらの情報はすべて、必要な基準に沿った独自のワークフローを作成する方法を理解する助けになりました :slight_smile:

7

どういたしまして。

(1) Ruby on Rails の開発者ではなく、(2) EmberJS の開発者でもない方にとっては、非常に混乱を招くこともあります。

基本的には、世界クラスの EmberJS SPA アプリケーション（メインのユーザーアプリ）の基盤となる、Docker 化された本番環境向けの Ruby on Rails アプリケーション（サーバーサイド技術）を構築しています。さらにその上には、長年この環境でコーディングを行ってきた、非常に才能があり経験豊富な Web に精通したチームによって維持管理されている、完全なオープンソースの構成管理システムが備わっています。その上、Discourse のビジネスエコシステム内で、プロフェッショナルなホスティングやカスタム開発も利用可能です。

なんて素敵でしょう？ :slight_smile:

8

これを見つけて驚きました。つまり、アプリとデータベースを物理的に異なるホストで実行し、共有するものを一切持たせることはできない、ということでしょうか？

私のケースでは完全にブロック要因になってしまいます…。

9

いいえ、そうではありません。Discourse を専用外部データベースと共に実行することは、サポートされ、文書化されたユースケースです。