Discourse + Webサーバー:可能か、それとも避けたほうがよい?

【簡単な免責事項】VPS環境をゼロから構築するのは比較的初心者ですが、Webホスティング(特に共有ホスティングと管理型Dedicatedサーバー)に関する経験はあり、何をすべきか理解し、チュートリアルを読み解くことはできます。

その上で、現在は実験用にDigitalOceanの最も安価なドロプレットを使用しています。私は趣味でやっており、大量のトラフィックは想定していません。ゲームデザイン用とコンテンツクリエーターコミュニティ用の2つのインスタンスを作成しようとしています。それぞれに何らかのフロントページ(おそらくWordPress)とそれに伴うDiscourseフォーラムを提供する予定です。

DiscourseとApacheは、Discourseがポート80を使用する決定をしたため、互換性が良くないことは理解しています。また、回避策が存在することも知っていますが、その形態は様々で結果が確認されておらず、Discourse側から「これで問題ない」という公式な保証もありません。

なぜこれほど素晴らしいプラットフォームが、Webサーバーの管理を阻害するように設計されているのか少し混乱していますが、これまでのソフトウェアとの関わりから、何とか動作させる方法を見つけたいという興味は湧いています。WordPressとの統合機能が存在し、機能ページでも注目されているようですが、Discourseはあくまでスタンドアロンとして設計されているように見えます。

同じような状況に直面した方からのアドバイスやご意見をお聞かせください。よろしくお願いします!

これが探しているものだと思います:

@neounix は Discourse を Apache2 と一緒に実行する経験がありますので、何かアドバイスができるかもしれません。

「いいね!」 4

これは Nginx への切り替えを推奨しているのでしょうか?私は Nginx に全く経験がなく、これまで使ったことのある Web サーバー(事前設定済みのも含め)はすべて Apache を採用していました。

Apache に関する情報はこちらもあります:Set up Discourse on a server with existing Apache sites

しかし、正しく動作させる際に多くの問題が発生しているようです。特に SSL 関連の問題が目立ちます。

ウェブサイト用と Discourse 専用として 2 つのドロプレットを運用する方が簡単でしょうか?サブドメインの DNS レコードを Discourse 用のドロプレットを指すように変更すれば、問題は解決すると思われます。ただ、フォーラムのためにサーバーを 2 台運用するのは少し奇妙に感じられます。

@OrbitStorm さん、こんにちは

ようこそ!

Discourse は全く邪魔になりません。

リバースプロキシ Web サーバーの背後で Docker 化された Discourse を運用する技術を習得することは、Apache2 または nginx を使用する場合でも、非常にやりがいのある経験です。

すでに Apache の背後でアプリを運用している場合、Apache の背後に 1 つ、あるいは 100 の Docker 化された Discourse インスタンスを設定することも簡単です!

「いいね!」 5

ご返信いただきありがとうございます。

最大限の敬意を込めて申し上げますが、Discourse は標準状態で、事実上専用のサーバーを必要とします。リバースプロキシを用いて、同じ VPS 上で Discourse と並行して Web サーバーを動作させるのは、コメントや他の苦情からも明らかなように、運次第であり、SSL が機能するかどうかすら不確かです。また、同じサーバー上で Discourse のインスタンスを 2 つ動かすことは事実上不可能です。これらすべてが私にとっては障壁に感じられます。XenForo や Invision といった高機能なプラットフォームを含め、これほど多くの不確実性を伴いながら、これほど多くの手間を強いるフォーラムソフトウェアは他にありません。それらは高価なパッケージなので、Discourse では「支払っていない分の価値」を得ているのかもしれません。新しいユーザーとしてこれらの障壁を目の当たりにすると、Discourse は他の何も(つまり、ウェブサイトなど)を考慮せずに設計されたように思えてなりません。

参考までに、私の元の投稿でも述べた通り、Discourse はワンクリックデプロイメントで導入しました。そのため、Apache(もしチュートリアルが見つからなければ Nginx)を同じサーバー上で動作させるには、すべてを逆の手順で行う必要があります。Discourse をメインのフォーラムプラットフォームとして使用するつもりであれば、1 つのコミュニティのために 2 つのサーバーを動かすことには興味がありません。それは単に愚かです。

正直に言って、それは可能だと思います。私は専門家ではなく、あちこちに存在する非常に優れたガイドやチュートリアルを「ただ」フォローしているだけです。Discourse を Nginx の背後に設定する際、ほとんど問題はありませんでした。少し運が良かっただけかもしれませんが、不可能ではないと思います。:slightly_smiling_face:

私はこれらが気に入っています:
https://linuxize.com/post/how-to-install-nginx-on-ubuntu-18-04/
https://linuxize.com/post/secure-nginx-with-let-s-encrypt-on-ubuntu-18-04/

ただし、マルチサイト/マルチコンテナと S3 クローンを組み合わせるのは簡単な道のりではないかもしれません。:sweat_smile:

Postfix と Dovecot の組み合わせについては:
https://linuxize.com/post/install-and-configure-postfix-and-dovecot/

「いいね!」 1

@Benjamin_D 私の抱える問題は、ここで利用可能なすべてのチュートリアルが、現在の環境の何らかの側面を欠いていることです。Apache に関するチュートリアルはありますが、CentOS を前提としたものです。私は Ubuntu を使用しています。また、Kane York による別のチュートリアルは Nginx を使用していますが、前述の通り、私は Apache を使用しています。

私が行っていることは特に複雑なものではありません。DigitalOcean、Linux + Ubuntu 18.04 を使用し、すべてをドロレット上でホストしています(サードパーティのストレージは使用していません)。メールソリューションとして Mailgun を使用していますが、現時点では受信トレイ機能がないことは問題ありません。

できるだけシンプルにすることを心がけています。

「いいね!」 1

@OrbitStorm

実際、Discourse は現時点で地球上で最高のフォーラムおよびコミュニティ構築用オープンソースソフトウェアです(個人的な見解ですが)。その理由は多岐にわたりますが、いくつか挙げてみましょう。

  1. Discourse はオープンソースであり、強力なコミュニティと非常に有能で能力の高いコア開発チームを擁しています。

  2. Discourse は本番環境で Docker コンテナ上で動作するように設計されており、これには多くの利点があります。

  • Discourse は、外部の Web サーバーやデータベースを必要とせずに、standalone mode(単独モード)で簡単にデプロイできます。

  • Discourse は、より高い信頼性とシームレスなアップグレードを実現する multi-container mode(マルチコンテナモード)でも簡単にデプロイできます。

  • Discourse は、Docker Swarm や Kubernetes を使用して非常に高い可用性を持つ構成でもデプロイ可能で、必要に応じてスケールアップ・スケールダウンできます。

  • Discourse のバックアップとリストアは簡単です。標準の Discourse バックアップを OOTB(Out of the Box)で取得し、世界中のどこでも、新鮮な空の Docker コンテナにリストアできます。

  1. Discourse は、Apache2 と nginx の両方のリバース Web プロキシサーバーの背後で簡単に動作します。これにも多くの利点があります。
  • Discourse は、既存の Web サーバー(nginx または Apache2)上で、Docker 公開 TCP/IP ポートまたは UNIX ドメインソケットのいずれかに関わらず、わずかな努力で動作させることができます。

  • リバースプロキシの背後で Web ベースのアプリケーションを動作させる方法は確立されています。この設定は Discourse に固有のものではありませんが、Discourse はサポートを提供します。

  • リバースプロキシの背後での SSL 設定は非常に簡単で、サポートされている無料の LETSENCRYPT を使用して certbot -d my.great-discourse.site とするだけで済むこともあります。

  1. Discourse は GitHub 上でコミット単位で完全にドキュメント化されており、誰でもコードの変更を追跡できます。

  2. Discourse には段階的なビジネスモデルがあり、以下のような重要な利点があります。

  • Discourse のコアソフトウェアや多くの優れたプラグイン、テーマ、コンポーネントは無料です。
  • Discourse は、標準的な設定サポートを含む無料のサポートを meta で提供しています。
  • Discourse は、セルフホストしたくない、またはより「手抜き」を好む人向けに商用ホスティングを提供しています。
  • Discourse はコミュニティ内で商用コンサルティングやプラグイン開発を促進し、持続可能なビジネスエコシステムを創出しています。
  1. これ以外にもありますが、これで締めくくりたいと思います!

コアの Discourse チームが行ったすべての決定に私(私たち)が同意し、彼らが私たちの(または私の)すべてのアイデアや提案に同意しているでしょうか?
いいえ、もちろんそうではありません。また、彼らも私たちも、あるいは私自身も、そうであるべきではありません。私たちは自由に提案し、コードの提案や PR を提出することができ、コアの Discourse チームはこれらの提案をオープンな心で受け止めます。

しかし、最終的には、コアチームは Discourse コミュニティを一貫した方向へ導く必要があります。これは、異なる文化背景を持つ数百人の人々が異なる設定を望み、異なる優先順位、ビジネスモデル、アイデアを持っている場合には容易なことではありません。

つまり、Discourse から「避けるべき」もの(あなたのトピックのタイトルにある言葉)は何もありません。特に、リバースプロキシの設定や Docker の習得についてはそうです。多くの人(私を含めて)は、Discourse のためだけでなく、他の Web アプリケーションのためにも Kubernetes へ移行しています。

Discourse は「妨害的」(これもあなたの言葉です、私の言葉ではありません)とは「最も遠い」存在です。また、設計上コンテナベースであるため、経験豊富なシステム管理者が Discourse を非常にスケーラブルな本番環境にデプロイする方法には「天に限り」があります。同時に、初心者が standalone mode で簡単にデプロイできるほどシンプルでもあります。

これ以上言う必要はあるでしょうか?

REM の曲『Losing My Religion』の歌詞にあるように:

Oh no, I’ve said too much, I set it up

このトピックを終了します… @OrbitStorm 様、幸運をお祈りします。

「いいね!」 2

私の理解が正しければ、あなたが求めているのは、一方では nginx がリッスンしてあるサブドメインを Apache にリダイレクトし、他方では別のサブドメインを Discourse が動作しているコンテナにリダイレクトすることです(app.yml で適切なポートを公開するか、web.socketed テンプレートを使用することで設定可能)。あるいは、Apache をプロキシとして使用しているのでしょうか?

CentOS のチュートリアルでは HAProxy ではなく nginx が使用されていると記憶していますが、どうでしょうか。

近いですが、まだ違います。繰り返しになりますが、私は Linux + Ubuntu 18.04 を使用しています。Apache で標準的な HTML ウェブサイト(将来的には WordPress)を提供しており、サブドメイン下に Discourse をインストールしています。必要なことは、これらのチュートリアルに従ってリバースプロキシを設定し、Apache がすでにポート 80 と 443 を使用しているため、これらのポートからのトラフィックを新しいポートにリダイレクトする方法を見つけることです。Nginx は使用したことがないため、Apache と併用して設定をさらに複雑にしたくありません。私は上級開発者ではありません。フロントエンドには精通しており、パネルの基礎を理解していますが、SSH の理解は限られており、それ以外のことはほぼ何も理解していません(そのためチュートリアルを利用しています)。最終的な目標は、それぞれにフロントページを持つ 2 つのドメインと、各ウェブサイトに対応する複数の Discourse インスタンスを構築することです。シンプルなものですね。

「いいね!」 1

Apache をサーバー兼プロキシとして使う方が、nginx や HAproxy をバンドルするより複雑かどうかはわかりません :sweat_smile:
チュートリアルについては、CentOS と Ubuntu で大きな違いはありません。yum の代わりに apt を使います。
https://support.cloudflare.com/hc/en-us/articles/360029696071-Restoring-original-visitor-IPs-Option-2-Installing-mod-remoteip-with-Apache

Apache をリバースプロキシとして使う場合は、こちらをお勧めします。

「いいね!」 1

人生を楽にしたいなら、Discourse を単一の Droplet で実行してください。Discourse と Apache を 1GB の Droplet 上で同時に実行することは実際にはできません。そのため、1GB の Droplet を 2 台使うとしても、コストはさほど増えません。

「いいね!」 2

@pfaffman 最初から最小のドロップレットを使い続けるつもりはありませんでした。設定を完了させるまでの間、一時的に利用しているだけです。実験中は高い時間単価を支払う意味がありません。

2 つのドロップレットを動かしたくない唯一の理由は、3〜4 つの異なるドメインを DigitalOcean に移行する可能性があるからです。6〜8 つのドロップレットに料金を支払うのは、あまりにも不合理です。

Discourse サイトを 3 つ以上必要とする場合は、マルチサイト構成を検討する必要があります。私は Traefik との構成を行っていますが、他のリバースプロキシも調査中です。

Apache を使用しており、複数の個別のサイトを構築したい場合は、「VirtualHost」が関連する検索用語です。

「いいね!」 4

小さな Droplet の場合は、バッファを減らすことを検討してください。私の Droplet は 4GB のメモリと 4 つの共有コアを備えています。

「いいね!」 2

DigitalOcean の Bobbyiliev 氏のおかげで、解決策を見つけることができました。

その解決策はこちらからご覧いただけます:Discourse not loading with Apache and proxy redirect - #8 by OrbitStorm

「いいね!」 3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.