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 つまたは複数、1 つの中間 Web サーバー(この場合、これをプロキシと呼びます)と 1 つのサーバーがあります。この中で最も重要なことは、サーバーはどのクライアントがリクエストを送信しているかを知らないということです。少し混乱しますか?図を使って説明しましょう。

この場合、クライアント 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 のアーキテクチャでは、通常、ワーカーの数を示すために使用されるからです。ここでは、Nginx に 5000 ポートをリッスンさせ、/nginx-demo/mainフォルダー内の静的ファイルを指すようにします。http { server { listen 5000; root /path/to/nginx-demo/main/; } } events {} -
次に、
/contentと/outsiderURL に追加のルールを追加します。ここで 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、フロントエンド、バックエンド、ブロックチェーン、製品、デザイン、人工知能 などの分野をカバーしています。質の高い翻訳をもっと見たい方は、掘金翻訳計画、公式微博、知乎専門 をフォローしてください。