「デプロイメント」という言葉には、状況に応じて2つの意味があります。また、Apache / Nginxの役割を他のコンポーネントの役割と混同しています。
歴史的メモ：この記事は、Rubyアプリサーバーのエコシステムが制限されていた2010年11月6日に最初に書かれました。2013年3月15日にこの記事を更新し、エコシステムの最新の更新をすべて加えました。
免責事項：私は、アプリケーションサーバーの1つであるPhusion Passengerの作成者の1人です。
Apache対Nginx
どちらもWebサーバーです。静的ファイルを提供できますが、適切なモジュールを使用すると、PHPで記述された動的なWebアプリなども提供できます。Apacheはより人気があり、より多くの機能を備えています。Nginxはより小型で高速であり、機能が少ないです。
ApacheもNginxも、すぐにRuby Webアプリを提供することはできません。そのためには、後で説明するように、Apache / Nginxをある種のアドオンと組み合わせて使用する必要があります。
ApacheとNginxはリバースプロキシとしても機能することができます。つまり、着信HTTPリクエストを受け取り、それを別のサーバー（HTTPを話す）に転送できます。そのサーバーがHTTP応答で応答すると、Apache / Nginxは応答をクライアントに転送します。これが関連する理由については後で説明します。
Mongrelおよびその他の本番アプリサーバーとWEBrick
MongrelはRubyの「アプリケーションサーバー」です。具体的には、Mongrelは次のようなアプリケーションです。
- Rubyアプリを独自のプロセス空間にロードします。
- TCPソケットを設定し、外部（インターネットなど）と通信できるようにします。MongrelはこのソケットでHTTPリクエストをリッスンし、リクエストデータをRuby Webアプリに渡します。
- 次に、Ruby WebアプリはHTTP応答がどのように見えるかを記述したオブジェクトを返し、Mongrelがそれを実際のHTTP応答（実際のバイト）に変換してソケット経由で送り返します。
しかし、雑種はかなり古く、今日ではもはや維持されていません。新しい代替アプリケーションサーバーは次のとおりです。
- Phusion Passenger
- ユニコーン
- 薄い
- プーマ
- トリニダード（JRubyのみ）
- TorqueBox（JRubyのみ）
それらについては後で説明し、それらが互いに、また雑種とどのように異なるかを説明します。
WEBrickはMongrelと同じことを行いますが、違いは次のとおりです。
- WEBrickは、前に述べた他のすべてとは異なり、本番環境には適していません。WEBrickは完全にRubyで書かれています。Mongrel（および他のほとんどのRubyアプリサーバー）は、一部はRubyで一部はC（ほとんどがRuby）ですが、そのHTTPパーサーはパフォーマンスのためにCで記述されています。
- WEBrickは低速で堅牢性が劣ります。既知のメモリリークと既知のHTTP解析問題がいくつかあります。
- WEBrickはデフォルトでRubyに含まれているため、通常、WEBrickは開発中のデフォルトサーバーとしてのみ使用されます。Mongrelと他のアプリサーバーは個別にインストールする必要があります。本番環境でWEBrickを使用することはお勧めしませんが、何らかの理由でHerokuはデフォルトサーバーとしてWEBrickを選択しました。以前はThinを使用していたので、なぜWEBrickに切り替えたのかわかりません。
アプリサーバーと世界
現在のすべてのRubyアプリサーバーはHTTPに対応していますが、一部のアプリサーバーはポート80でインターネットに直接公開されている場合とそうでない場合があります。
- インターネットに直接公開できるアプリサーバー：Phusion Passenger、Rainbows
- インターネットに直接公開されていない可能性があるアプリサーバー：Mongrel、Unicorn、Thin、Puma。これらのアプリサーバーは、ApacheやNginxなどのリバースプロキシウェブサーバーの背後に配置する必要があります。
- トリニダードとトルクボックスのことはよくわからないので省略しました。
一部のアプリサーバーをリバースプロキシの背後に配置する必要があるのはなぜですか？
- 一部のアプリサーバーは、プロセスごとに同時に1つのリクエストしか処理できません。2つのリクエストを同時に処理する場合は、それぞれが同じRubyアプリを提供する複数のアプリサーバーインスタンスを実行する必要があります。このアプリサーバープロセスのセットは、アプリサーバークラスターと呼ばれます（そのため、Mongrel Cluster、Thin Clusterなどの名前）。次に、ApacheまたはNginxをセットアップして、このクラスターへのリバースプロキシを設定する必要があります。Apache / Nginxは、クラスター内のインスタンス間でリクエストを分散します（これについては、「I / O同時実行モデル」のセクションで詳しく説明します）。
- ウェブサーバーはリクエストとレスポンスをバッファリングして、アプリサーバーを「遅いクライアント」（データの送受信が非常に遅いHTTPクライアント）から保護します。クライアントが完全な要求を送信するか、完全な応答を受信するのを待っている間、アプリケーションサーバーが何もしないようにする必要があります。ApacheとNginxは、マルチスレッド化またはイベント化されているため、同時に多くのことを行うのに優れています。
- ほとんどのアプリサーバーは静的ファイルを提供できますが、特に優れているわけではありません。ApacheとNginxはそれをより速く行うことができます。
- 人々は通常、Apache / Nginxを設定して静的ファイルを直接提供しますが、静的ファイルに対応しないリクエストをアプリサーバーに転送することは、セキュリティの良い習慣です。ApacheとNginxは非常に成熟しており、（おそらく悪意のある）破損したリクエストからアプリサーバーを保護できます。
一部のアプリサーバーを直接インターネットに公開できるのはなぜですか？
- Phusion Passengerは、他のすべてのアプリサーバーとは非常に異なる獣です。そのユニークな機能の1つは、Webサーバーに統合されることです。
- Rainbowsの作者は、インターネットに直接公開しても安全であると公式に述べています。作成者は、HTTPパーサー（および同様の）に脆弱性がないことをかなり確信しています。それでも、作者は保証を提供せず、使用は自己責任であると述べています。
アプリケーションサーバーの比較
このセクションでは、前述のほとんどのアプリケーションサーバーを比較しますが、Phusion Passengerは比較しません。Phusion Passengerは他の動物とはかなり異なる獣で、専用のセクションを用意しました。TrinidadとTorqueBoxも十分に理解していないので省略しましたが、いずれにしても、JRubyを使用する場合にのみ関係があります。
- 雑種はかなり裸の骨でした。前述のように、Mongrelは純粋にシングルスレッドのマルチプロセスであるため、クラスターでのみ役立ちます。プロセスの監視はありません。クラスター内のプロセスがクラッシュした場合（アプリのバグが原因など）、手動で再起動する必要があります。人々は、MonitやGodなどの外部プロセス監視ツールを使用する傾向があります。
- ユニコーンは雑種のフォークです。限定的なプロセス監視をサポートしています。プロセスがクラッシュした場合、マスタープロセスによって自動的に再起動されます。すべてのプロセスが、プロセスごとに個別のソケットを使用するのではなく、単一の共有ソケットをリッスンするようにできます。これにより、リバースプロキシの構成が簡略化されます。Mongrelと同様に、純粋にシングルスレッドのマルチプロセスです。
- Thinは、EventMachineライブラリを使用して、イベントI / Oモデルを使用します。Mongrel HTTPパーサーを使用する以外は、Mongrelに基づいているわけではありません。そのクラスターモードにはプロセスの監視がないため、クラッシュなどを監視する必要があります。Unicornのような共有ソケットはないため、各プロセスは独自のソケットでリッスンします。理論的には、ThinのI / Oモデルは高い同時実行性を可能にしますが、Thinが使用されるほとんどの実際的な状況では、1つのThinプロセスは1つの同時要求しか処理できないため、クラスターが必要です。セクション「I / O同時実行モデル」のこの特異なプロパティの詳細。
- PumaもMongrelから分岐されましたが、Unicornとは異なり、Pumaは純粋にマルチスレッド化されるように設計されています。したがって、現時点では組み込みのクラスターサポートはありません。複数のコアを確実に利用できるように、特別な注意を払う必要があります（これについては、「I / O同時実行モデル」セクションで詳しく説明します）。
- Rainbowsは、さまざまなライブラリを使用して複数の同時実行モデルをサポートしています。
Phusion Passenger
Phusion Passenger は他のすべてのものとは非常に異なって動作します。Phusion Passengerは直接ApacheまたはNginxに統合されるため、Apacheのmod_phpと比較できます。mod_phpがApacheにほとんど魔法のようにPHPアプリを提供できるように、Phusion PassengerはApache（およびNginx！）にほとんど魔法のようにRubyアプリを提供できるようにします。Phusion Passengerの目標は、できるだけ手間をかけずにすべてをJust Work（tm）にすることです。
アプリのプロセスまたはクラスターを開始し、Phasion Passengerを使用して静的ファイルやリバースプロキシリクエストをプロセス/クラスターに提供するようにApache / Nginxを構成する代わりに、次のことだけが必要です。
- ウェブサーバーの設定ファイルを編集して、Rubyアプリの「public」ディレクトリの場所を指定します。
- 手順2はありません。
すべての構成は、Webサーバー構成ファイル内で行われます。Phusion Passengerはほとんどすべてを自動化します。クラスタを起動してプロセスを管理する必要はありません。プロセスの開始/停止、クラッシュしたときの再起動など-すべて自動化されています。他のアプリサーバーと比較して、Phusion Passengerは可動部品がはるかに少ないです。この使いやすさが、Phusion Passengerを使用する主な理由の1つです。
また、他のアプリサーバーとは異なり、Phusion Passengerは主にC ++で記述されているため、非常に高速です。
また、自動ローリングリスタート、マルチスレッドサポート、デプロイメントエラー耐性などの機能を備えたPhusion PassengerのEnterpriseバリアントもあります。
上記の理由により、Phusion Passengerは現在最も人気のあるRubyアプリサーバーであり、New York Times、Pixar、Airbnbなどの大規模なものを含む150,000を超えるWebサイトを強化しています。
Phusion Passengerと他のアプリサーバーの比較
Phusion Passengerは、より多くの機能を提供し、次のような他のアプリサーバーに比べて多くの利点を提供します。
- トラフィックに基づいてプロセス数を動的に調整します。リソースに制約のあるサーバー上で公開されていない大量のRailsアプリを実行しており、組織内のユーザーは1日に数回しか使用していません。Gitlab、Redmineなど。PhusionPassengerは、使用されていないときにこれらのプロセスをスピンダウンし、使用されているときにそれらをスピンアップして、より重要なアプリが利用できるリソースを増やすことができます。他のアプリサーバーでは、すべてのプロセスが常にオンになっています。
- 一部のアプリサーバーは、設計上、特定のワークロードには適していません。たとえば、Unicornは高速で実行されるリクエストのみを目的として設計されています。UnicornWebサイトのセクション「Just Worse in Cases」を参照してください。
Unicornが得意としないワークロードは次のとおりです。
- ストリーミングワークロード（例：Rails 4ライブストリーミングまたはRails 4テンプレートストリーミング）。
- アプリがHTTP API呼び出しを実行するワークロード。
Phusion Passenger Enterprise 4以降のハイブリッドI / Oモデルは、この種のワークロードに最適です。
- 他のアプリサーバーでは、ユーザーはアプリケーションごとに少なくとも1つのインスタンスを実行する必要があります。対照的に、Phusion Passengerは単一のインスタンスで複数のアプリケーションをサポートします。これにより、管理オーバーヘッドが大幅に削減されます。
- 自動ユーザー切り替え、便利なセキュリティ機能。
- Phusion Passengerは、多くのMRI Ruby、JRuby、Rubiniusをサポートしています。Mongrel、Unicorn、ThinはMRIのみをサポートしています。Pumaはすべて3もサポートします。
- Phusion Passengerは実際にはRubyだけではありません！また、Python WSGIもサポートしているため、たとえばDjangoアプリやFlaskアプリを実行することもできます。実際、Phusion Passengerはポリグロットサーバーになる方向に向かっています。TODOリストでのNode.jsのサポート。
- アウトオブバンドガベージコレクション。Phusion Passengerは、Rubyガベージコレクターを通常のリクエスト/レスポンスサイクルの外で実行できるため、リクエスト時間が数百ミリ秒も短縮される可能性があります。Unicornにも同様の機能がありますが、Phusion Passengerのバージョンは1）GCに限定されず、任意の作業に使用できるため、より柔軟です。2）Phusion Passengerのバージョンはマルチスレッドアプリで適切に機能しますが、Unicornのバージョンでは機能しません。
- 自動ローリング再起動。Unicornや他のサーバーでのローリングリスタートには、スクリプト作業が必要です。Phusion Passenger Enterpriseはこの方法を完全に自動化します。
より多くの機能と利点がありますが、リストは本当に長いです。詳細については、総合的なPhusion Passengerのマニュアル（Apacheバージョン、Nginxバージョン）またはPhusion PassengerのWebサイトを参照してください。
I / O同時実行モデル
- シングルスレッドマルチプロセス。これは、Rubyエコシステムでのマルチスレッディングサポートが非常に悪かったこともあって、Rubyアプリサーバーで最も人気のあるI / Oモデルです。各プロセスは、一度に1つのリクエストしか処理できません。Webサーバーはプロセス間で負荷を分散します。このモデルは非常に堅牢で、プログラマーが並行性のバグを引き起こす可能性はほとんどありません。ただし、I / Oの同時実行性は非常に制限されています（プロセスの数によって制限されます）。このモデルは、高速で短時間のワークロードに非常に適しています。HTTP APIの呼び出しを含むワークロードなど、低速で長時間実行されるブロッキングI / Oワークロードには非常に適していません。
- 純粋にマルチスレッド。現在、Rubyエコシステムは優れたマルチスレッドサポートを備えているため、このI / Oモデルは非常に実用的なものになっています。マルチスレッドは高いI / O同時実行性を可能にし、短期および長期の両方のブロッキングI / Oワークロードに適しています。プログラマーは並行性のバグを導入する可能性が高くなりますが、幸いなことに、ほとんどのWebフレームワークは、これがまだほとんど起こらないように設計されています。ただし、グローバルインタープリターロック（GIL）を使用しているため、複数のスレッドがある場合でも、MRI Rubyインタープリターは複数のCPUコアを利用できないことに注意してください。各プロセスはCPUコアを利用できるため、複数のマルチスレッドプロセスを使用してこれを回避できます。JRubyとRubiniusにはGILがないため、1つのプロセスで複数のコアを完全に活用できます。
- ハイブリッドマルチスレッドマルチプロセス。主にPhusion Passenger Enterprise 4以降で実装されています。シングルスレッドのマルチプロセス、純粋なマルチスレッド、またはおそらく複数のスレッドを持つ複数のプロセスを簡単に切り替えることができます。このモデルは、両方の長所を備えています。
- イベント発生。このモデルは、前述のモデルとは完全に異なります。非常に高いI / O同時実行性を可能にするため、長時間実行されるブロッキングI / Oワークロードに最適です。それを利用するには、アプリケーションとフレームワークからの明示的なサポートが必要です。ただし、RailsやSinatraなどのすべての主要なフレームワークは、イベントコードをサポートしていません。このため、実際には、シンプロセスは一度に複数のリクエストを処理できず、シングルスレッドのマルチプロセスモデルと実質的に同じように動作します。Crampなど、イベントI / Oを利用できる特殊なフレームワークがあります。
最近、Phusionブログに、ワークロードに応じてプロセスとスレッドの数を最適に調整することに関する記事が投稿されました。Tuning Phusion Passengerの同時実行設定を参照してください。
カピストラーノ
カピストラーノは、まったく違うものです。これまでのすべてのセクションで、「デプロイ」とは、アプリケーションサーバーでRubyアプリを起動して訪問者がアクセスできるようにすることを指しますが、その前に、通常、次のような準備作業を行う必要があります。
- Rubyアプリのコードとファイルをサーバーマシンにアップロードする。
- アプリが依存するライブラリをインストールする。
- データベースのセットアップまたは移行。
- アプリが依存する可能性のあるデーモン（Sidekiq / Resqueワーカーなど）の起動と停止。
- アプリケーションを設定するときに行う必要があるその他のこと。
カピストラーノの文脈では、「展開」とはこの準備作業をすべて行うことを指します。Capistranoはアプリケーションサーバーではありません。代わりに、すべての準備作業を自動化するためのツールです。Capistranoにサーバーの場所と、アプリの新しいバージョンをデプロイするたびに実行する必要のあるコマンドを指示すると、CapistranoがRailsアプリをサーバーにアップロードし、指定したコマンドを実行します。
Capistranoは常にアプリケーションサーバーと組み合わせて使用されます。アプリケーションサーバーの代わりにはなりません。逆に、アプリケーションサーバーはCapistranoに代わるものではなく、Capistranoと組み合わせて使用できます。
もちろん、あなたはしていない持っているカピストラーノを使用します。RubyアプリをFTPでアップロードし、毎回同じ手順のコマンドを手動で実行したい場合は、それを実行できます。他の人々はそれに飽きてきたので、彼らはカピストラーノでそれらのステップを自動化しました。