web-dev-qa-db-ja.com

Apache + TomcatVSスタンドアロンTomcatまたはGlassFish

Java Webアプリケーションを提供するためにDebianサーバーをセットアップしています。ここ数週間、かなりの調査を行っています。TomcatのWebサイトでは、速度を上げるにはスタンドアロンのTomcatを使用する方がよいと述べています。クラスタリングではありませんが、Apache + Tomcatを使用すると、セキュリティと攻撃に対する保護が向上することを多くの人が示唆しています。

プロセスが非特権ユーザーとしてポート80で実行されると想定してください。サーバーの前でファイアウォールを実行している場合は、Tomcatで問題ないと思います。ただし、Linuxファイアウォールを使用して公開されたWebサーバーを実行したいだけの場合、最良のオプションは何ですか?

あるいは、誰かが別のオープンソースWebサーバーを推奨できるかもしれません。これらのWebアプリはコンテナーで実行されるため、ソリューションを可能な限り軽量に保つようにしています。

すべての意見を歓迎し、評価します。

6
TonyZ

私自身の経験から、Tomcatの前に何かを置いて、外の世界から少し保護するのが賢明です。 Tomcatネイティブの拡張機能を使用してTomcatを実行する場合、IOは非常に高速であり、Tomcatは非常に適切に動作します。

また、Tomcatは、ディストリビューションに付属していない場合、ビルドと使用が非常に簡単なjsvcを使用することにより、ルートで実行せずにポート80で実行できます。

ただし、万が一に備えて単純なWebフロントエンドを維持することも役立ちます。このフロントエンドは、Tomcatでは得られない小さな柔軟性を提供できるためです(gzipオンザフライ、ルールの書き換え、同じIPで複数のTomcatの処理:単純な仮想ホストとプロキシマッピングを使用したポート...)

Apache2は、mod_proxy + AJPを使用してこのフロントエンドにすることができます。 AJPはTomcatへのヘッダーとソースIP転送を処理しますが、Apacheは非常に簡単な方法で提供するため、ドメインにRewriteRulesを追加する必要がある場合はそれほど幸せではありません。

ただし、AJPはWebアプリのステータス変更を選択するのに非常に時間がかかり、Webアプリが再起動してインターネットで再び利用できるようになるまで30秒待たなければならないのは非常に苛立たしいことです。最新のAJPとTomcatの組み合わせには、空のページと壊れたコンテンツタイプにつながる、それほど良くない問題もいくつかあります(ただし、Tomcatネイティブの拡張機能を放棄することで修正できます...)。

単純なHTTP Mod_proxyも使用できますが、実際のプロキシではないため(Apacheはホストを変更します:ヘッダー、送信元IPはプロキシアドレスになります...)、私はあまり好きではありません。

他の素晴らしい選択肢は次のとおりです。

  • HAProxy:非常にスマートでシンプルなプロキシ、負荷の処理に非常に優れ、構成が非常に簡単で、堅固で実際のHTTPプロキシは、通常のX-Forwarded-Forヘッダーを介してソースIPを転送できます。私はこれを本番環境で使用していますが、とても満足しています。バックエンドへのアクティブな接続の数を制限しながら、数千のライブ接続にスケールアップでき、多くの優れた機能が組み込まれています。ただし、HTTPルーティングよりもはるかに巧妙なもの(たとえばRewriteRulesなど)を作成することはおそらく適切ではありません。

  • Nginx:このサーバーは実際にAJPをサポートしていると聞きました。 Apacheよりも軽量で、HAProxyよりもフル機能であるため、機会があれば、今日これを試してみます。

結論

  • テストする時間があれば、Nginxを試してください。
  • シンプルで堅実なフロントエンドが必要な場合は、HAProxyを使用してください。
  • 「従来の」ルートを好む場合は、Apache2 + AJPを選択してください。
  • Tomcatが十分に強力で、必要なすべての機能を提供すると思われる場合は、jsvcを使用して、Tomcatをポート80に配置します。
4
Oct

UNIX上のTomcatとGlassfishの両方で遭遇した問題は、(Javaアプリケーションだと思います))ポート80にバインドできず、root権限を削除できないことです。これらのタイプを実行するルートとしてのことはベストプラクティスではないため、2つのオプションがあります。

(1)アプリケーションサーバーを高ポート(たとえば8080)にバインドされた通常のユーザーとして実行し、iptablesルールのようなものを使用してポート80トラフィックをポート8080にリダイレクトします。これはLinux上のいくつかのGlassfishサーバーで実行しました。結構。

(2)アプリケーションサーバーをApacheの背後にある通常のユーザーとして実行します。 Apacheはポート80にバインドし、特権を削除してから、高いポートでアプリケーションサーバーにリクエストをプロキシできます。

私は後者の方が好きですが、主な理由は、Apacheを長い間使用していて、構成と管理が便利だと思ったからです。したがって、Apacheがそれをうまく使用していることを知っている場合は、その場でいくつかのURLを書き直したり、有効期限ヘッダーを調整したりする必要があるときに、満足できます。一方、Apacheの経験がない場合(またはこの場合はできるだけ軽量にする必要があるため)、Tomcatだけに固執してiptablesを使用する方が簡単な場合があります。

1
Deutsch

@deutschの回答に続いて、TomcatはUNIXでrootとして実行する必要はありません。パッケージからインストールする場合、例: Fedora/CentOS/RedHat用のTomcat6RPMは、制限された特権セットを持つユーザーTomcatとして実行されます。

そうは言っても、私は@Deutschの最後の段落に同意します。デプロイの期限が非常に限られている場合を除いて、TomcatのフロントエンドとしてApacheを使用してください。まだ慣れていない場合でも、Tomcatの前でmod_proxyを使用して基本的なデプロイメントを行うのは簡単であり、将来的には柔軟性とセキュリティが向上することでほぼ確実にメリットが得られます。

1
gareth_bowles