Debian 8でmod_proxyを使用してApacheをリバースプロキシとして使用する方法

前書き

_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 +。複数のバックエンドサーバーに負荷分散機能を追加します。

これらの4つのモジュールを有効にするには、次のコマンドを連続して実行します。

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests

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

sudo systemctl restart apache2

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チュートリアル]を参照してください。 。

最初にパッケージリストを更新します。

sudo apt-get update

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

sudo apt-get -y install python3-pip

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

sudo pip3 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 +`またはお好みのテキストエディターを使用して、デフォルトのApache設定ファイルを開きます。

sudo nano /etc/apache2/sites-available/000-default.conf

そのファイルの中では、最初の行から始まる `+ <VirtualHost *:80> +`ブロックがあります。 以下の最初の例では、このブロックを単一のバックエンドサーバーのリバースプロキシに構成する方法を説明し、2番目の例では複数のバックエンドサーバーの負荷分散リバースプロキシを設定します。

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

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

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>




</VirtualHost>

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

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

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

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

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

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

sudo systemctl restart apache2

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

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

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

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

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>









</VirtualHost>

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

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

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

sudo systemctl restart apache2

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 +`ドキュメント]を参照してください。