title: 【転載】数年前に知っておきたかった Nginx の概念
date: 2021-08-14 09:32:45
comment: false
toc: true
category:
- シェア
tags: - 転載
- nginx
- 概念
この記事は、[訳] 数年前に知っておきたかった Nginx の概念から転載されています。
- 原文アドレス:Nginx concepts I wish I knew years ago
- 原文著者:Aemie Jariwala
- 訳文出自:掘金翻訳計画
- この記事の永久リンク:github.com/xitu/gold-m…
- 訳者:joyking7
- 校正者:PassionPenguin、ningzhy3
Nginx はマスター・スレーブアーキテクチャに従った Web サーバーで、リバースプロキシ、ロードバランサー、メールプロキシ、HTTP キャッシュとして使用できます。
わあ!複雑な用語と混乱した定義がたくさん詰まっていますよね?心配しないでください。まずは Nginx の基本的なアーキテクチャと用語を理解し、その後に Nginx の設定をインストールして作成します。
物事を簡単にするために、次のことを覚えておいてください:Nginx は魔法の Web サーバーです 。
簡単に言うと、Web サーバーは仲介者のようなものです。たとえば、dev.to にアクセスしたい場合、アドレス https://dev.to
を入力すると、ブラウザは https://dev.to
の Web サーバーのアドレスを見つけ、その後バックエンドサーバーにリダイレクトし、バックエンドサーバーは応答をクライアントに返します。
プロキシ vs リバースプロキシ#
Nginx の基本機能はプロキシですので、プロキシとリバースプロキシの違いを理解する必要があります。
プロキシ#
さて、クライアントが 1 つ以上、仲介の Web サーバー(この場合はプロキシと呼びます)、そしてサーバーがあります。この中で最も重要なことは、サーバーはどのクライアントがリクエストを送信しているのかを知らないということです。少し混乱しますか?図を使って説明しましょう。
この場合、クライアント client1 と client2 はプロキシサーバーを介してサーバーにリクエスト request1 と request2 を送信しますが、バックエンドサーバーは request1 が client1 から送信されたのか client2 から送信されたのかを知りません。ただ操作を実行するだけです。
リバースプロキシ#
最も簡単に言うと、リバースプロキシはプロキシの役割を逆にしたものです。たとえば、1 つのクライアント、1 つの仲介 Web サーバー、そして 1 つ以上のバックエンドサーバーがあるとしましょう。図を使って説明を続けましょう!
この場合、クライアントは Web サーバーを介してリクエストを送信し、Web サーバーはアルゴリズムを使用してリクエストを多数のサーバーのいずれかにリダイレクトします。そのアルゴリズムの 1 つはラウンドロビン(Round-Robin)です(最も可愛いもの!)、そして応答を Web サーバーを介してクライアントに返します。したがって、ここではクライアントはどのバックエンドサーバーと対話しているのかを知りません。
ロードバランシング#
また新しい用語が出てきましたが、この用語は理解しやすいです。なぜなら、これはリバースプロキシ自体の実際のアプリケーションだからです。
まず基本的な違いを説明しましょう。ロードバランシングでは、2 つ以上のバックエンドサーバーが必要ですが、リバースプロキシの設定では必ずしもそうではなく、単一のバックエンドサーバーと一緒に使用することもできます。
では、裏側を見てみましょう。クライアントからのリクエストが大量にある場合、このロードバランサーは各バックエンドサーバーの状態を確認し、リクエストの負荷を分配し、応答をより早くクライアントに送信します。
有状態アプリ vs 無状態アプリ#
さて、皆さん、私はすぐに Nginx コードについて話し始めることを約束しますので、まずはすべての基本概念を明確にしましょう!
有状態アプリ#
このアプリケーションは、単一のサーバーインスタンスにのみ適用される情報を保存するための追加の変数を保存します。
私が言いたいのは、バックエンドサーバー server1 が何らかの情報を保存している場合、それは server2 には保存されないため、対話しているクライアント(ここではボブ)は期待する結果を得られない可能性があるということです。なぜなら、彼は server1 または server2 と対話する可能性があるからです。この場合、server1 はボブに設定ファイルを表示させますが、server2 は許可しません。したがって、有状態アプリは多くの API 呼び出しをデータベースに制限し、速度は速くなりますが、異なるサーバー間で上記の問題を引き起こす可能性があります。
無状態アプリ#
さて、無状態はデータベースへの API 呼び出しが多くなりますが、クライアントが異なるバックエンドサーバーと対話する際の問題は少なくなります。
私の言いたいことがわからないことは知っています。簡単に言うと、クライアントから Web サーバーを介してバックエンドサーバー server1 にリクエストを送信すると、それはクライアントに他のリクエストにアクセスするためのトークンを提供します。クライアントはそのトークンを使用してリクエストを Web サーバーに送信し、Web サーバーはリクエストとトークンを任意のバックエンドサーバーに送信します。各サーバーは同じ期待される出力を返します。
Nginx とは何ですか?#
Nginx は Web サーバーで、これまでのブログ全体で Web サーバーという言葉を使ってきましたが、正直なところ、それは仲介者のようなものです。
この図は理解しやすく、これまで説明してきたすべての概念を組み合わせたものです。この図では、3001、3002、3003 ポートでそれぞれ実行されている 3 台のバックエンドサーバーがあり、これらのバックエンドサーバーは 5432 ポートで実行されているデータベースを共同で使用しています。
さて、クライアントが https://localhost
(デフォルトの 443 ポート)にリクエスト GET /employees
を送信すると、Nginx はアルゴリズムに基づいてこのリクエストを任意のバックエンドサーバーに送信し、バックエンドサーバーはデータベースから情報を取得し、JSON 結果を Nginx Web サーバーに返し、Nginx はそれをクライアントに返します。
もし私たちが ラウンドロビン のようなアルゴリズムを使用する場合、Nginx はこうします:たとえば client2 が https://localhost
にリクエストを送信した場合、Nginx サーバーは最初にリクエストを 3001 ポートに送信し、その後応答をクライアントに返します。別のリクエストの場合、Nginx はリクエストを 3002 ポートに送信し、同様に続きます。
これだけの概念があるのですね!しかし、ここまでで、あなたは Nginx とその関連用語について明確に理解しているはずです。さて、次は Nginx のインストールと設定について学びましょう。
インストールプロセス#
ついにこのステップに来ました!もしあなたが Nginx の概念を理解し、コードの部分を見たなら、それは素晴らしいことです!
さて、正直なところ、どのオペレーティングシステムでも Nginx をインストールするには 1 行のコマンドだけで済みます。私は Mac OSX ユーザーなので、それに基づいてコマンドを書きます。しかし、Ubuntu や Windows などの他の Linux ディストリビューションでも、同様のコマンドがあります。
brew install Nginx
1 行のコマンドだけで、あなたのシステムに Nginx がインストールされます!非常に素晴らしい!
実行 So easy!😛#
次のコマンドを実行して、Nginx があなたのシステムで実行されているかどうかを確認します。これも非常に簡単なステップです。
nginx
# OR
sudo nginx
コマンドを実行した後、お気に入りのブラウザで http://localhost:8080/
にアクセスすると、画面に以下の画面が表示されます!
基本設定と例#
さて、Nginx の素晴らしさを示すために、例を通じて説明します。まず、ローカルマシンに次のようなディレクトリ構造を作成します:
.
├── nginx-demo
│ ├── content
│ │ ├── first.txt
│ │ ├── index.html
│ │ └── index.md
│ └── main
│ └── index.html
└── temp-nginx
└── outsider
└── index.html
同時に、html と md ファイルに基本的なコンテキスト内容を書きます。
私たちが達成したい効果は?#
ここでは、nginx-demo
と temp-nginx
の 2 つの別々のフォルダーがあり、それぞれ静的 HTML ファイルを含んでいます。私たちは、共通のポートでこれらの 2 つのフォルダーを実行し、好きなルールを設定することに集中します。
さて、本題に戻りましょう。/usr/local/etc/nginx
(訳者注:デフォルトのインストールパス)にある nginx.conf
ファイルを変更することで、Nginx のデフォルト設定に対して任意の変更を行うことができます。また、私のシステムには Vim があるので、Vim を使って変更しますが、あなたは好きなエディタを自由に使用できます。
cd /usr/local/etc/nginx
vim nginx.conf
これにより、デフォルトの Nginx 設定ファイルが開きますが、私は本当にそのデフォルト設定を使用したくありません。したがって、通常はこの設定ファイルをコピーして、元のファイルを変更します。ここでも同様に行います。
cp nginx.conf copy-nginx.conf
rm nginx.conf && vim nginx.conf
今、空のファイルが開かれますので、そこに私たちの設定を追加します。
-
基本設定を追加します。
events {}
を追加することは必須です。なぜなら、Nginx アーキテクチャでは、通常は Worker の数を示すために使用されるからです。ここではhttp
を使用して、Nginx に OSI モデル の第 7 層を使用することを伝えます。
ここでは、Nginx に 5000 ポートをリッスンさせ、/nginx-demo/main
フォルダー内の静的ファイルを指し示します。http { server { listen 5000; root /path/to/nginx-demo/main/; } } events {}
-
次に、
/content
と/outsider
URL に追加のルールを追加します。ここで outsider は、最初のステップで言及したルートディレクトリ(/nginx-demo
)以外のディレクトリを指します。
ここでlocation /content
は、私がサブディレクトリでどのルートディレクトリを定義したとしても、content サブ URL が定義されたルートディレクトリの末尾に追加されることを示します。したがって、ここでルートディレクトリをroot /path/to/nginx-demo/
と指定すると、単に Nginx にhttp://localhost:5000/path/to/nginx-demo/content/
でフォルダー内の静的ファイルの内容を表示するように指示していることになります。http { server { listen 5000; root /path/to/nginx-demo/main/; location /content { root /path/to/nginx-demo/; } location /outsider { root /path/temp-nginx/; } } } events {}
すごい!今、Nginx はルート URL を定義するだけでなく、クライアントが特定のファイルにアクセスするのを防ぐためのルールを設定することもできます。
-
定義されたメインサーバーに、すべての .md ファイルへのアクセスを防ぐための追加のルールを書きます。Nginx では正規表現を使用でき、ルールは次のように定義されます:
location ~ .md { return 403; }
-
最後に、人気のあるコマンド
proxy_pass
について学びましょう。今、私たちはプロキシとリバースプロキシが何であるかを理解しましたので、ここで 8888 ポートで実行されている別のバックエンドサーバーを定義します。したがって、現在、5000 ポートと 8888 ポートでそれぞれ実行されている 2 台のバックエンドサーバーがあります。
私たちがやるべきことは、クライアントが Nginx を介して 8888 ポートにアクセスする際に、このリクエストを 5000 ポートに渡し、クライアントに応答を返すことです!server { listen 8888; location / { proxy_pass http://localhost:5000/; } location /new { proxy_pass http://localhost:5000/outsider/; } }
最後に、完全なコードを見てみましょう!😁#
http {
server {
listen 5000;
root /path/to/nginx-demo/main/;
location /content {
root /path/to/nginx-demo/;
}
location /outsider {
root /path/temp-nginx/;
}
location ~ .md {
return 403;
}
}
server {
listen 8888;
location / {
proxy_pass http://localhost:5000/;
}
location /new {
proxy_pass http://localhost:5000/outsider/;
}
}
}
events {}
sudo nginx
を使ってコードを実行します。
追加の Nginx コマンド!#
-
Nginx Web サーバーを初めて起動します。
nginx #OR sudo nginx
-
実行中の Nginx Web サーバーを再読み込みします。
nginx -s reload #OR sudo nginx -s reload
-
実行中の Nginx Web サーバーを停止します。
nginx -s stop #OR sudo nginx -s stop
-
システムで実行中の Nginx プロセスを確認します。
ps -ef | grep Nginx
4 番目のコマンドは重要です。最初の 3 つのコマンドにエラーが発生した場合、4 番目のコマンドを使用してすべての実行中の Nginx プロセスを見つけ、それらのプロセスを kill して Nginx サービスを再起動できます。
プロセスを kill するには、まずその PID を知る必要があり、次のコマンドを使用してそれを kill します:
kill -9 <PID>
#OR
sudo kill -9 <PID>
この記事を終える前に、私が使用した画像と視覚効果は Google 画像と Hussein Nasser が提供した YouTube チュートリアルからのものであることを明言します。
Nginx の基本的な理解と設定についてはここまでです。Nginx の高度な設定に興味がある場合は、コメントで教えてください。それまでの間、プログラミングの楽しさを楽しみ、Nginx の魔法を探求してください!👋
訳文に誤りや改善が必要な点があれば、掘金翻訳計画 で訳文を修正し PR することを歓迎します。また、相応の報酬ポイントも得られます。記事の冒頭にある この記事の永久リンク は、この記事の GitHub 上の MarkDown リンクです。
掘金翻訳計画 は、質の高いインターネット技術記事を翻訳するコミュニティで、記事の出典は 掘金 上の英語のシェア記事です。内容は Android、iOS、フロントエンド、バックエンド、ブロックチェーン、製品、デザイン、人工知能 などの分野をカバーしています。質の高い翻訳をもっと見たい方は、掘金翻訳計画、公式微博、知乎専欄 をフォローしてください。