Rails デプロイメント ソリューションの 1 つは、Apache をリバース プロキシとして使用して、リクエストをアプリケーション サーバー (Phusionpassenger など) に転送することです。リバース プロキシ サーバーとして、Apache はその背後にあるアプリケーション サーバーとどのように対話しますか?
たとえば、私の Apache はポート 1080 をリッスンし、プロセス情報をチェックしました:
リクエストが來ると、まず Apache に送られます。Apache はこれらのプロセスからプロセスを割り當ててリクエストを処理します (たとえば、プロセス 8391 が割り當てられます)。では、プロセス 8391 は何をするのでしょうか?彼はこのリクエストを後続のアプリケーション サーバー (Phusion 乗客) に転送しますか?もしそうなら、アプリケーションサーバーにも獨自の獨立したプロセスがありますか?それとも、プロセス 8391 をアプリケーション サーバー プロセスとみなして、このリクエストを単獨で処理できるのでしょうか?
Apache はその背後にあるアプリケーション サーバーとどのように対話するのでしょうか?
この質(zhì)問を長い間見ていましたが、その時は答えていませんでした。
Rails には獨自の Web サーバーが付屬しており、サービスを提供するために特定のポートをリッスンする役割を果たします。
Ruby 言語には http 関連の API があり、簡単な靜的ファイル サーバーを自分で書くこともできます。そして、同様のサービスを提供する強力な寶石がたくさんあります。
Apache は、原則として、最も基本的な靜的ファイルにのみ応答できるプロフェッショナルな http サーバーです。
Apache で PHP 言語を?qū)g行する最も一般的な方法は、プラグインとして実行することです。つまり、Apache は php ファイル要求に応答するように変更されます。
Apache と Phusionpassenger を使用して Rails アプリケーションをデプロイするのは、主に、より洗練されたエラー プロンプトと自動化されたエラー処理 (主に再起動)、さらに完全なログ システムとロード バランシングなどの高度な機能が目的です。
Rails や Thin などの Web サーバーを使用してサービスを開始することもできますが、ブラウザーと開発者の両方にとって使いやすいものではありません。
自動エラー処理が必要ない場合は、nginx リバース プロキシ レールまたはシン ポートを使用することが最良の選択です。
リバース プロキシを構(gòu)成すると、Apache は HTTP クライアントとして機能し、同じリクエストをアプリケーション サーバーに送信し、その結(jié)果を?qū)g際のクライアントに送信します。
Apache を起動すると、10 ~ 20 を超えるプロセスが存在します (構(gòu)成によって異なります)
そして、Apache がリクエストを受信した後、プロセスがそれを処理し、リバース プロキシの條件を満たす場合、リクエストはアプリケーション サーバーに送信されます
。
実際、アプリケーションサーバーには直接アクセスできる必要があります(ファイアウォールなどが存在しない限り)
とにかく、アプリケーションサーバーはリクエストを受信し、Apacheにレスポンスを送り返します
その後、Apache はブラウザーに応答を送り返します
ただし、このプロセス中に、応答の HTML の URL の書き換えを構(gòu)成する必要がある場合もあります