NGiNXの機能にリバースプロキシサーバーというものがあります。
リバースプロキシについては、Cannonさんのサイバーセキュリティ情報局というホームページに詳しくありましたのでそちらを参照してみて下さい。
リバースプロキシとプロキシの違いとは？それぞれのサーバーの仕組みは？
NGiNXで単にリバースプロキシを立てても「あぁそうか」で終わりなので、ここでは1つひねった使い方をやってみようと思います。
例としてこんな話。
社内にバラバラに存在するシステム、それぞれで WebAPIを作って活用している。
全社システムを作ることになったが、それらの WebAPIを利用することで機能実現できることが分かった。
しかし色々なサーバーに分散してしまっているため、場所が分かりづらい。
こんなことは現実にはそう無いと思いますが、これらの WebAPIがまるで1つのサーバーで提供されているように見える、そんな環境を NGiNXのリバースプロキシで実現します。
環境は Ubuntu Desktop 22.04 と NGiNX 1.18.0 でやっています。
WebAPIを提供しているサーバーが2つあると仮定して、以下を作りました。
１．Node.js + EXPRESS
http://localhost:3000/api/hello
→ {"hello":"Node.js Express"} というJSONデータを返す。
２．Deno + FRESH
http://localhost:8000/api/hello
→ {"hello":"Deno Fresh"} というJSONデータを返す。
これら2つのWebAPIを提供する、apigateway.local というサーバーがあるように見せかけることにします。
「NGiNXでバーチャルホストを使ってみる」で書いたバーチャルホスト機能も併せて使います。
WebAPIのURLは以下の2つになるようにします。
http://gateway.local/api/v1/node/hello
http://gateway.local/api/v1/deno/hello
では、NGiNXの設定を変更していきます。
バーチャルホストとして apigateway.localを構成するため、/etc/nginx/sites-available ディレクトリの下に設定ファイルを作ります。
私の好みでファイル名はバーチャルマシン名そのまま(apigateway.local)にしています。
subro@Ubuntu2204:/etc/nginx/sites-available$ cat apigateway.local
server {
listen 80;
listen [::]:80;
server_name apigateway.local;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
location /api/v1/node {
proxy_pass http://localhost:3000/api;
}
location /api/v1/deno {
proxy_pass http://localhost:8000/api;
}
}
ピンク文字がバーチャルホスト用の設定で、水色文字がリバースプロキシの設定です。
「proxy_set_header」で始まる行は、本当の WEBサーバーがアクセス元の情報を取得できるよう(アクセスログに書いたりします)、リクエストヘッダーの中身を入れ替えているところです。
「proxy_pass」で始まっている行が NGiNXが他の URLにアクセスを代行する部分の記述です。
特に NGiNXのマニュアルを読まなくても、何をしているか何となく分かるのでないでしょうか。
次に /etc/nginx/sites-enabled ディレクトリの下に、上のファイルを指すシンボリックリンクを作ります。
これにより NGiNXが起動する時に上のファイルを読むようになります。
subro@Ubuntu2204:/etc/nginx/sites-enabled$ sudo ln -s /etc/nginx/sites-available/apigateway.local apigateway.local
subro@Ubuntu2204:/etc/nginx/sites-enabled$ ls -l
total 8
lrwxrwxrwx 1 root root 43 8月 10 13:13 apigateway.local -> /etc/nginx/sites-available/apigateway.local
lrwxrwxrwx 1 root root 34 7月 15 15:06 default -> /etc/nginx/sites-available/default
NGiNXを再起動します。
subro@Ubuntu2204:~$ sudo systemclt restart nginx
これで NGiNXの設定は終わりです。
すごく簡単です。
それから、apigateway.localというマシン名から IPアドレス変換をできないといけませんが、私は DNSを持っていませんので、代わりに WEBブラウザを実行するマシンの /etc/hosts ファイルを使います。
subro@Ubuntu2204:~$ cat /etc/hosts
127.0.0.1 localhost apigateway.local
準備が一通りできましたので、WEBブラウザで WebAPIを叩いてみましょう。
Node.jsのほう
Denoのほう
両方とも上手くいきました。
どうでしょうか。
ネットワーク上にバラバラに存在している WebAPIが、まるで1つの体系だった URLで提供されているように見えます。
これはリバースプロキシ利用方法のホンの一例で、リバースプロキシはアイデア次第で色々な使い方をできます。
かなり便利な代物の割に、NGiNXでは簡単に構成できるのが素晴らしいです。
実際の現場では、リバースプロキシ機能があるネットワークハードウェアが導入されているケースが多いと思いますが、やっていることはこういうことなので、ハードウェアをイジる前に自分でリバースプロキシを構成してみるのもお勉強としては良いと思います。
 | Web配信の技術ーHTTPキャッシュ・リバースプロキシ・CDNを活用する [ 田中 祥平 ] 価格:3,586円 |
