同意します、指示には調整が必要かもしれません。データ部分が動作しなくなるのは奇妙に思えます。
年に一度程度の長いダウンタイムはそれほど悪くありません…
いいえ、既存の app.yml 設定で web_only.yml を誤って編集したことによって生じた問題以外は、問題ありませんでした。![]()
同意します、指示には調整が必要かもしれません。データ部分が動作しなくなるのは奇妙に思えます。
年に一度程度の長いダウンタイムはそれほど悪くありません…
いいえ、既存の app.yml 設定で web_only.yml を誤って編集したことによって生じた問題以外は、問題ありませんでした。![]()
この2コンテナのセットアップでは、これが現在機能していることをご報告できて嬉しいです!
残る問題は、CLIから再構築する方法を教えるために使用されるサイトのテキスト(「app」)だけですが、これはごくわずかなことです。
cc: @pfaffman
ええ、それはハードコードされています。思い出せない場合は、テキストをカスタマイズする必要があります。![]()
5件の投稿が新しいトピックに分割されました: rubyのバージョン不一致によりビルドが失敗する
それは絶対に機能しません。先ほど見落として申し訳ありません。OPを更新しました。データを再構築する必要がある場合は、次のようにする必要があります。
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
いいえ。それがまさに期待されていることです。別のpostgresがファイルにアクセスしている間にpostgresを再構築することはできません。新しいデータコンテナが作成された場合、dockerが名前付きのコンテナへの参照ではなく、正確なコンテナにリンクする方法があるため、新しいweb_onlyコンテナを破棄して起動する必要があります。
正気ではないのか、それとも discourse-install スクリプトに –two-container 引数がなくなったのでしょうか?Hetzner の新しい Ubuntu 24.04 VPS で、推奨される場所 (https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse) から直接実行したところ、app.yml を使用した通常の単一コンテナセットアップがインストールされただけでした。そこから生成される discourse-setup を実行する必要があるのかと思いましたが、それも同じことを繰り返しただけでした。
手動インストール方法と ./discourse-setup --two-container を使用しました。前回使用したときは問題ありませんでした。
または、OPで参照されているように、便利なインストールスクリプトを使用してインストールしてから、2つのコンテナに変換します。
@Falco と @pmusaraj 、古い INSTALL-cloud.md の一部をどこかに保管しておき、現在の INSTALL-cloud.md で参照できるようにしておくと便利だと思いますか?
実際になくなっていたので、上記のWikiからその記述を削除しました。
情報ありがとうございます。なぜ削除されたのですか?それは非常に便利なメソッドでした。
Dockerにあまり詳しくない人々による2つのコンテナインストールが、あまりにも多くのサポート負担を生み出しました。これは高度なインストール設定であり、その方法を知っている人に限定されるべきです。
そのため、その機能を使っている私たちにとっては不便になっています。この変更について事前に誰かに尋ねましたか?OPの方法を誤って使用しても、自分自身にいくつかの問題を引き起こす可能性があることを考えると、そのままにしておくこともできたように思えますが。
誰にとっての負担ですか?このスレッドでのことですか?サポートはチームではなく、ボランティアやユーザーによって提供されてきました。
つまり、web_onlyとdataはサンプルに残し、2つのコンテナを使用したい人は手動でコピーして設定する必要があるということですか?以前に必要な追加サポートは、データコンテナを更新しなかった人々を助けることだけでした。
今や、たくさんの人にcpとnanoの使い方を教える必要が出てきます。議論の余地はありますが、cpとnanoを知らない人は2コンテナセットアップを実行すべきではないでしょう。Jeffは、cpとnanoを知らないならDiscourseをインストールすべきではないと主張していましたが、私がdiscourse-setupを書いたときに彼の考えを変えることができました。
しばらくの間、標準インストールをやめるためにdashboard.literatecomputing.comを書き直し(discourse-setupに回答をパイプできなくなったため)、そこで2コンテナインストールのオプションを提供し続けるつもりです。
私はあまり好きではありません。これは、全体として2コンテナのサポートを打ち切る一歩に近づいているように感じられ、それは非常に残念なことです。
そして、それがオープンソースの素晴らしいところです。人々は自分の冒険を選ぶ自由があるのです!
![]()
何十人もの人々が忘れ去られた古いコンテナを実行しているのは素晴らしいことではなく、PostgreSQL のメジャーアップデートが必要になるたびに多くの混乱を引き起こし、その結果、私たちの PostgreSQL の更新が少なくなり、製品全体が悪化しました。
同意します ![]()
2つ(またはN個)のコンテナインストールのサポートを完全に廃止することは実際には不可能ではありません。Discourse は、Configure Discourse to use a separate PostgreSQL server で文書化されているように、外部データベースにネイティブに接続します。
柔軟性は何も削除されていませんが、The Power of Defaults と同様に、作成するすべてのオプションは考慮する必要があるものになります。
数千行のスクリプトを削除し、より一般的なユースケースをカバーするようにインストーラーを合理化することは意図的な選択でしたが、Discourse は引き続きすべての同じユースケースをサポートしており、人々は望むなら自分の道を進む自由があります。
この生産方式が大幅なカスタマイズなしで引き続き機能するという安心感に感謝します ![]()
削除されたメソッドを使用している人々の利便性が犠牲になり、全員に特定のパスを強制することになりました。これは一人の決定だったのか、それとも他の人も関与したのでしょうか?
codinghorrorより
「デフォルトはおそらく、ソフトウェア開発者として行う最も重要な設計上の決定です。優れたデフォルトを選択すれば、ユーザーはソフトウェアの素晴らしさと使いやすさを賞賛するでしょう。貧弱なデフォルトを選択すれば、設定に関するユーザーの不満や、おそらく多数のテクニカルサポートへの問い合わせに直面することになります。」
私の考えでは、貧弱なデフォルトが選択されており、その選択/変更は、変更を嘆いているユーザー層との関与、議論、考慮なしに行われました。
再度尋ねますが、誰による意図的な選択だったのでしょうか?
このユーザーは、そのコメントを傲慢さと無礼として受け取ります。見下され、無視されていると感じるのと同じように感じられます。意図がそのような反応を引き起こすことではなかったと思いますが、現実はこうです。
全体として、この一件は、数週間前に@natとのプライベートメッセージで私が不満を述べていたことと一致しています。CDCK/Metaには2つの不平等な顧客層があります。ホスティングにお金を払っている人々ともう一つはセルフホストしている人々です。この一件でのアプローチは、この二層システムにおける最新かつ最も悪質な例かもしれません。
上記を踏まえて…
新しいインストーラーを称賛します。インストール時の問題と、初日から発生していたサポートの要求に対処するのに優れた仕事をしていると思います。
変更については、CDCKには自由に構築/変更する権利があります。それについては議論の余地はありません。私の希望は、人々を疎外することのない方法でそれを行ってくれることです。
最後に、codinghorrorの投稿を再読したことで、ジェフが投稿に関与したときの状況について考えさせられました。彼の投稿はしばしば、無視、無礼、そしてわずかな傲慢さを感じさせました。幸いなことに、私はその直接の対象になったことはありませんでしたが、そのような投稿の中には読むのが辛いものもありました。投稿の処理方法をめぐるスタッフとの最近のやり取りとこの一件は、非常によく似ていると感じます。もしかしたら私だけかもしれませんが。
それは少しきつい言い方だと思います。チームは、unsupported-install に該当する人たちも含め、このフォーラムでセルフホスターの方々を毎日助けていますよ ![]()