おいマイク。基本的には、./launcher bootstrap を使ってイメージをビルドし、リポジトリにプッシュしてから、./launcher start-cmd を実行して Docker に渡す必要がある ENV 変数を確認するんだ。
こんなガイドが存在しない理由は、基礎的な構成要素の仕組みを全く理解していない人がこれを見つけても意味がわからず、自分が考えているシステムだけが正解だと信じて、イングレスがどう機能するかについてのチュートリアルを期待してしまうからだ。
変だと思われるかもしれませんが、もしかしたらあなたが「われわれがそのように行ったのには理由がある」ということを証明しているのかもしれませんね 
ジェイ、ありがとう。そこまではわかったよ。やっと動かせたんだ。
- 自分が次に同じことをする時に時間を無駄にしないよう、自分がやったことをそのまままとめた動画とガイドを作成するつもりだ。
問題の一部は、他の Docker イメージの常識とは逆の動きをする点にあるようだ。完全に「プラグ＆プレイ」ではない。どちらかといえば「いじって、プラグして、そしてプレイ」だ。
繰り返すけど、このランチャーは、その目的においては美しく、信頼性の高いものだ。
非常にポジティブな点として、Web 版のビルドは抜群にうまくいく。私の Swarm 上では超高速で、ビルドサーバーを持っているのでアップデートも容易だ。
時間ができたら、Swarm 上で Docker イメージを Web ベースでビルドできるビルドサーバーを探してみたい。
試したが、あまり満足できなかっただけの試行錯誤…
- bitnami の Docker イメージ：足のない犬のように動きが悪かった。
- indiehosts の Dockerfile：ビルドにすらたどり着けなかった。何かをすべて構築しようとする意図が感じられた。Linux をコンパイルしていたのではないかと思う。やはり、もっと簡単な方法があるはずだ！
さて、ありがとう。
マイク。
私たちは「ファーストムーバーの不利」を享受しています 
ランチャー・スクリプトは、Docker Compose、Docker Swarm、Kubernetes などが登場する前に作成されましたが、今でも機能しています。他のシステムに乗り換える決定的な理由は特にありません。これらのシステムの「利点」は、Discourse のセルフホスティングにおける最大のユーザーである、クラウド VPS 上の予算重視のインストールにとっては利点にはなりません。
なるほど！いつも不思議に思っていました。最後に確認したときは、Ubuntu で docker-compose をインストールするには追加の手順が必要でした。まるで、Windows（または Mac？）を使わない限り、人々がそれを使いたくないかのように見えます。
開発チームからの公式な回答としてこれを知ることは少し悲しいですね。つまり、「本番環境でDiscourseを運用するためのこの未文書化されたプロセスを理解できないなら、本番環境でDiscourseを運用すべきではない」と言っているのと同じです。
残念ながら、私たち全員が広範なDevOps経験を持っているわけではありません。
@Mike_Sutton 私もあなたと同じ考えです。この問題の解決策を探るために、ここ数週間フォーラムを読み続けています。問題を解決する方法について動画を作成されましたか？
それで動作するでしょうか？DB マイグレーションはどうなりますか？
このシナリオでは、新しいコンテナイメージを構築する際に、ブートストラップがマイグレーションを実行します。
@lucasbasquerotto さん、こんにちは
はい、Discourse の Docker イメージをリポジトリにプッシュし、以下の議論のように /var/discourse の残りをアーカイブすることは可能です。ただし、これは効率的な方法ではなく、公式にはサポートされていません。最近、これを完全にテストしました：
しかし、この場合、bootstrap ステップは本番環境のサーバーで実行されなければなりません。これは、コンテナレジストリにベースイメージをプッシュするという目的をむしろ損なうことになります（私の認識が正しければ）。なぜなら、本番環境でイメージを bootstrap する必要性をなくすことが意図されているからです（データベースのマイグレーション実行など、ごく一部の処理を除いて）。
私がホストしている Discourse 以外のサイトでは、通常、Flyway を使ってデータベースのマイグレーションを実行し、Redis キャッシュのクリアなどの他の処理も行います。ただし、外部サービスに依存する重い処理は避けます。例えば、HTTPS 証明書の更新（初回のみ例外として cronjob で実施）や、コードベースの変更（イメージ内で静的にパッケージ、ライブラリなどを固定）などです。Discourse が Rake を使用しているのは問題ありませんが、Gem のインストール、アセットの生成、MaxMind DB の更新、あるいは他のサービスへの依存など、他の処理も含まれています。これらは、例えばサービスがダウンしている場合や API が変更された場合（稀ですがあり得ます）、ビルドステップを失敗させる可能性があります。
もちろん、Discourse がそのような方法を採用すべきだと言っているわけではありません。CI 環境でイメージを生成し、ステージング/本番サーバーでデータベースのマイグレーションステップを実行し、環境変数を設定するというアプローチは、WordPress、MediaWiki、Rocket.Chat などの他のソフトウェアでは容易に実現可能です。Discourse はフォーラムソフトウェアとして最高だと思いますし、彼らが現在の方法を採用しているのには良い理由があるかもしれません。しかし、現時点では、手間を避けるために標準インストール（またはマルチコンテナインストール）のみを使用し、ビルド時に何か問題が起きないことを祈るしかありません。
どうやら、bootstrap は依然として本番環境で行う必要があり、CI 環境でステージングと本番の両方で使用するベースイメージを生成するべきではないようです。さらに、標準インストールではないことは大きな警告信号であり、ソフトウェアが更新されるにつれて将来的に大きな頭痛の種になる可能性があります。
マイク様
結局、プロセスを文書化しましたか？ビデオも拝見できると嬉しいです。
よろしくお願いいたします。