前書き

_reverse proxy_は、HTTP(S)要求を受け取り、それらを1つ以上のバックエンドサーバーに透過的に配布するプロキシサーバーの一種です。 多くの最新のWebアプリケーションは、ユーザーが直接アクセスすることを意図しておらず、多くの場合基本的なHTTP機能のみをサポートするバックエンドアプリケーションサーバーを使用して着信HTTPリクエストを処理するため、リバースプロキシが役立ちます。

リバースプロキシを使用して、これらの基になるアプリケーションサーバーが直接アクセスされるのを防ぐことができます。 また、これらを使用して、着信要求から複数の異なるアプリケーションサーバーに負荷を分散し、大規模なパフォーマンスを向上させ、フェイルセーフを実現することもできます。 キャッシング、圧縮、SSL暗号化など、アプリケーションサーバーが提供しない機能でギャップを埋めることができます。

このチュートリアルでは、 `+ mod_proxy +`拡張機能を使用してApacheを基本的なリバースプロキシとして設定し、同じネットワーク上で実行されている1つまたは複数のバックエンドサーバーに着信接続をリダイレクトします。 このチュートリアルでは、http://flask.pocoo.org/ [Flask web framework]で記述されたシンプルなバックエンドを使用しますが、任意のバックエンドサーバーを使用できます。

前提条件

このチュートリアルを実行するには、次のものが必要です。

ステップ1-必要なApacheモジュールの紹介

Apacheをリバースプロキシとして使用するために必要なモジュールには、 `+ mod_proxy +`自体とその機能を拡張してさまざまなネットワークプロトコルをサポートするいくつかのアドオンモジュールが含まれます。 具体的には、次のものを使用します。

  • + mod_proxy +、接続をリダイレクトするためのメインプロキシモジュールApacheモジュール。これにより、Apacheが基礎となるアプリケーションサーバーへのゲートウェイとして機能できます。

  • HTTP接続のプロキシのサポートを追加する「+ mod_proxy_http +」。

  • + mod_proxy_balancer +`および `+ mod_lbmethod_byrequests +。複数のバックエンドサーバーに負荷分散機能を追加します。

CentOS 7の新規インストールでは、4つのモジュールすべてがデフォルトで有効になっています。 これらが有効になっていることを確認するには、次を実行します。

httpd -M

コマンド出力には、有効なすべてのApacheモジュールがリストされます。 探している4行は、前述のモジュール名です。

Output. . .

. . .

. . .

. . .

. . .

モジュールが有効になっていない場合、 `+ nano `で ` / etc / httpd / conf.modules.d / 00-proxy.conf +`を開くことで有効にできます:

sudo nano /etc/httpd/conf.modules.d/00-proxy.conf

そして、行の先頭から「#」記号を削除して、ファイルが次のようになるように、必要なモジュールで行のコメントを外します。

/etc/httpd/conf.modules.d/00-proxy.conf

. . .

. . .

. . .

. . .

. . .

変更を有効にするには、ファイルを保存してApacheを再起動します。

sudo systemctl restart httpd

Apacheは、HTTPリクエストのリバースプロキシとして機能する準備ができました。 次のステップでは、2つの非常に基本的なバックエンドサーバーを作成します。 これらは、構成が適切に機能するかどうかを確認するのに役立ちますが、すでに独自のバックエンドアプリケーションがある場合は、手順3にスキップできます。

ステップ2-バックエンドテストサーバーの作成

いくつかの単純なバックエンドサーバーを実行すると、Apache構成が適切に機能しているかどうかを簡単にテストできます。 ここでは、HTTP要求に応答してテキスト行を印刷する2つのテストサーバーを作成します。 1つのサーバーは* Hello world!と言い、もう1つのサーバーは Howdy world!*と言います。

Flaskは、Webアプリケーションを構築するためのPythonマイクロフレームワークです。 基本的なアプリでは数行のコードしか必要ないため、Flaskを使用してテストサーバーを作成しています。 これらを設定するためにPythonを知る必要はありませんが、学びたい場合は、https://www.digitalocean.com/community/tags/python?type = tutorials [これらのPythonチュートリアル]を参照してください。 。

最初にIUSパッケージリポジトリファイルをインストールしましょう。 IUS(Inline with Upstream Stable)は、Python 3を含む最新バージョンの厳選されたソフトウェアをCentOSに導入するコミュニティプロジェクトです。

sudo yum -y install https://centos7.iuscommunity.org/ius-release.rpm

次に、Python 3と、推奨されるPythonパッケージマネージャーであるPipをインストールします。

sudo yum -y install python35u python35u-pip

Pipを使用してFlaskをインストールします。

sudo pip3.5 install flask

必要なすべてのコンポーネントがインストールされたので、現在のユーザーのホームディレクトリに最初のバックエンドサーバーのコードを含む新しいファイルを作成することから始めます。

nano ~/backend1.py

次のコードをファイルにコピーし、保存して閉じます。

〜/ backend1.py

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
   return 'Hello world!'

最初の2行は、Flaskフレームワークを初期化します。 1行のテキストを返す関数 + home()+`があります( `+ Hello world!+)。 `+ home()`関数の定義の上の `@app.route( ‘/’)`行は、Flaskに向けられたHTTPリクエストに対する応答として ` home()`の戻り値を使用するように指示します。アプリケーションの ` / +`ルートURL。

2番目のバックエンドサーバーは、異なるテキスト行に戻ることを除いて、最初のバックエンドサーバーとまったく同じなので、最初のファイルを複製することから始めます。

cp ~/backend1.py ~/backend2.py

新しくコピーしたファイルを開きます。

nano ~/backend2.py

返されるメッセージを* Hello world!から Howdy world!*に変更し、ファイルを保存して閉じます。

〜/ backend2.py

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
   return ''

次のコマンドを使用して、ポート `+ 8080 `で最初のバックグラウンドサーバーを起動します。 また、Flaskの出力は ` / dev / null +`にリダイレクトされます。これは、コンソール出力をさらに曇らせるためです。

FLASK_APP=~/backend1.py flask run --port=8080 >/dev/null 2>&1 &

ここでは、同じ行に環境変数 `+ FLASK_APP `を設定することで、 ` flask +`コマンドに先行しています。 環境変数は、シェルから生成されるプロセスに情報を渡す便利な方法です。 環境変数の詳細については、https://www.digitalocean.com/community/tutorials/how-to-read-and-set-environmental-and-shell-variables-on-a-linux-vps [How To Linux VPSでの環境変数とシェル変数の読み取りと設定]。

この場合、環境変数を使用すると、設定が実行中のコマンドにのみ適用され、その後は使用できなくなります。これは、2番目のサーバーを起動するように「+ flask +」コマンドに同じ方法で別のファイル名を渡すためです

同様に、このコマンドを使用して、ポート `+ 8081 `で2番目のサーバーを起動します。 ` FLASK_APP +`環境変数の異なる値に注意してください。

FLASK_APP=~/backend2.py flask run --port=8081 >/dev/null 2>&1 &

`+ curl`を使用して、2つのサーバーが実行されていることをテストできます。 最初のサーバーをテストします。

curl http://127.0.0.1:8080/

これにより、* Hello world!*がターミナルに出力されます。 2番目のサーバーをテストします。

curl http://127.0.0.1:8081/

代わりに* Howdy world!*が出力されます。

次のステップでは、Apacheの構成ファイルを変更して、リバースプロキシとして使用できるようにします。

手順3-デフォルト構成を変更してリバースプロキシを有効にする

このセクションでは、デフォルトのApache仮想ホストを設定して、単一のバックエンドサーバーまたは負荷分散されたバックエンドサーバーのアレイのリバースプロキシとして機能します。

`+ nano `または好みのテキストエディタを使用して、 ` / etc / httpd / conf.d +`ディレクトリに新しい空のApache設定ファイルを作成して、新しいデフォルトの仮想ホストを作成します。

sudo nano /etc/httpd/conf.d/default-site.conf

以下の最初の例では、単一のバックエンドサーバーのリバースプロキシにデフォルトの仮想ホストを構成する方法について説明し、2番目の例では、複数のバックエンドサーバーの負荷分散リバースプロキシを設定します。

例1-単一のバックエンドサーバーのリバースプロキシ

次の内容を `+ default-site.conf +`ファイルに貼り付けて、設定ファイルが次のようになるようにします。

/etc/httpd/conf.d/default-site.conf

手順2でサンプルサーバーを使用した場合は、上記のブロックに記述されているように「127.0.0.1:8080」を使用します。 独自のアプリケーションサーバーがある場合は、代わりにそのアドレスを使用します。

ここには3つのディレクティブがあります。

  • `+ ProxyPreserveHost `は、Apacheに元の ` Host +`ヘッダーをバックエンドサーバーに渡します。 これは、アプリケーションへのアクセスに使用されるアドレスをバックエンドサーバーに認識させるため、便利です。

  • + ProxyPass +`はメインのプロキシ設定ディレクティブです。 この場合、ルートURL( `+ / +)の下にあるすべてのものが、指定されたアドレスのバックエンドサーバーにマッピングされることを指定します。 たとえば、Apacheが `+ / example `のリクエストを受け取ると、 ` http:/// example +`に接続し、元のクライアントに応答を返します。

  • `+ ProxyPassReverse `には ` ProxyPass +`と同じ設定が必要です。 Apacheにバックエンドサーバーからの応答ヘッダーを変更するよう指示します。 これにより、バックエンドサーバーがロケーションリダイレクトヘッダーを返す場合、クライアントのブラウザーはバックエンドサーバーアドレスではなくプロキシアドレスにリダイレクトされます。これは意図したとおりに機能しません。

これらの変更を有効にするには、Apacheを再起動します。

sudo systemctl restart httpd

これで、Webブラウザーで「+ http:// +」にアクセスすると、標準のApacheウェルカムページではなく、バックエンドサーバーの応答が表示されます。 ステップ2を実行した場合、* Hello world!*が表示されます。

例2-複数のバックエンドサーバーにわたる負荷分散

複数のバックエンドサーバーがある場合、プロキシ時にトラフィックをそれらに分散させる良い方法は、 `+ mod_proxy +`の負荷分散機能を使用することです。

`+ VirtualHost +`ブロック内のすべてのコンテンツを次のものに置き換えます。設定ファイルは次のようになります。

/etc/httpd/conf.d/default-site.conf

設定は前の設定と似ていますが、単一のバックエンドサーバーを直接指定する代わりに、追加の `+ Proxy `ブロックを使用して複数のサーバーを定義しました。 ブロックには「 balancer:// 」という名前が付けられ(名前は自由に変更できます)、1つ以上の「 BalancerMember 」で構成され、バックエンドサーバーのアドレスを指定します。 ` ProxyPass `および ` ProxyPassReverse `ディレクティブは、特定のサーバーの代わりに ` mycluster +`という名前のロードバランサープールを使用します。

手順2でサンプルサーバーを使用した場合は、上記のブロックに記載されているように、 `+ BalancerMember +`ディレクティブに `+127.0.0.1:8080 +`および `+127.0.0.1:8081 +`を使用します。 独自のアプリケーションサーバーがある場合は、代わりにそのアドレスを使用します。

これらの変更を有効にするには、Apacheを再起動します。

sudo systemctl restart httpd

Webブラウザで `+ http:// +`にアクセスすると、標準のApacheページの代わりにバックエンドサーバーの応答が表示されます。 ステップ2を実行した場合、ページを複数回更新すると、* Hello world!および Howdy world!*が表示されます。これは、リバースプロキシが機能し、両方のサーバー間で負荷分散が行われていることを意味します。

結論

これで、Apacheを1つ以上の基礎となるアプリケーションサーバーへのリバースプロキシとして設定する方法がわかりました。 `+ mod_proxy +`は、PythonとDjangoまたはRubyとRuby on Railsなどの膨大な言語と技術で書かれたアプリケーションサーバーへのリバースプロキシを効果的に構成するために使用できます。 また、トラフィックの多いサイトの複数のバックエンドサーバー間のトラフィックのバランスをとったり、複数のサーバーで高可用性を提供したり、SSLをネイティブにサポートしていないバックエンドサーバーに安全なSSLサポートを提供したりするためにも使用できます。

`+ mod_proxy_http `付きの ` mod_proxy +`はおそらく最も一般的に使用されるモジュールの組み合わせですが、異なるネットワークプロトコルをサポートする他のいくつかがあります。 ここでは使用しませんでしたが、他の一般的なモジュールには次のものがあります。

  • FTPの場合は「+ mod_proxy_ftp +」。

  • SSLトンネリング用の + mod_proxy_connect +

  • TomcatベースのバックエンドのようなAJP(Apache JServ Protocol)の場合は「+ mod_proxy_ajp +」。

  • Webソケットの場合は + mod_proxy_wstunnel +

`+ mod_proxy `の詳細については、http://httpd.apache.org/docs/current/mod/mod_proxy.html [Apacheの公式の ` mod_proxy +`ドキュメント]を参照してください。