nginxのインストールと使い方（学習メモ）

1. nginx の概要

• Nginx は、高性能の HTTP およびリバース プロキシ Web サーバーであり、高同時実行の処理において非常に強力であり、高負荷のテストに耐えることができます。
• nginx は、少ないメモリと強力な同時実行機能を特徴としており、実際、nginx の同時実行機能は、同じタイプの Web サーバー間でより優れたパフォーマンスを発揮します。

1.1 フォワードプロキシ

Nginx は、負荷分散を実現するリバース プロキシとして機能するだけではありません。プロキシ サーバーを介してサーバーにアクセスするプロセスは、フォワード プロキシと呼ばれます。指定された Web サイトにアクセスするには、クライアント側でプロキシ サーバーを構成する必要があります

1.2 リバースプロキシ

リバース プロキシ: クライアントは構成なしでアクセスできます。リクエストをリバース プロキシ サーバーに送信するだけで済みます。リバース プロキシ サーバーは、データを取得するターゲット サーバーを選択してからクライアントに戻ります。このとき、リバース プロキシ サーバーは、逆の処理を実行します。プロキシ サーバーとターゲット サーバーは外部に対しては同じサーバーであるため、プロキシ サーバーのアドレスは公開され、実際のサーバーの IP アドレスは隠蔽されます。

1.3 負荷分散

• サーバーの数を増やして各サーバーにリクエストを分散したり、元のリクエストを 1 つのサーバーに変更して複数のサーバーにリクエストを分散したり、負荷を別のサーバーに分散したりすることをロード バランシングと呼びます。
• クライアントは複数のリクエストをサーバーに送信し、サーバーはそのリクエストを処理しますが、そのうちの一部はデータベースとの対話が必要になる場合があります。サーバーは処理を完了すると、結果をクライアントに返します。

1台のサーバーでは解決できないため、サーバーを増やして各サーバーにリクエストを分散することで、元のリクエストを1台のサーバーに集中させるのではなく、複数のサーバーにリクエストを分散して負荷を分散します。 . いわゆるロードバランシングです

1.4 動的分離と静的分離

従来の方法:

• サーバー側には静的リソース (JS、HTML など) と動的リソース (JSP、サーブレットなど) がデプロイされます。
  

Web サイトの解析速度を高速化するために、動的および静的分離方法が採用されています。

• 動的ページと静的ページは異なるサーバーによって解析されるため、解析速度が向上し、元の単一サーバーへの負荷が軽減されます。

2 nginx のインストール、一般的なコマンドと設定ファイル

2.1 Linux システムに nginx をインストールする

ダウンロード

まず、nginx 公式 Web サイトを開きます: http://nginx.org/
2017 バージョンを入力し、nginx 1.12.1 バージョンを見つけて、クリックしてダウンロードし

、1.12.2 圧縮パッケージをダウンロードします。

pcre.8.37 バージョンをダウンロードし、
公式 Web サイトにアクセスします: https://sourceforge.net/projects/pcre/files/pcre/8.37/

インストール

1. openssl、zlib、gcc の依存関係をインストールします。

yum -y install make zlib zlib-devel gcc-c++ libtool openssl openssl-devel

2. pcre の依存関係をインストールする

• usr/src ディレクトリに入り、ダウンロードした pcre-8.37.tar.gz 圧縮パッケージを xshell に直接ドラッグします。
• 解凍コマンド tar –xvf pcre-8.37.tar.gz を使用します。
  
• 解凍した pcre-8.37 フォルダーに入り、./configure コマンドが
  表示された場合はそれを使用します。エラー: $PATH に許容可能な C コンパイラが見つかりません現象
  適切なコンパイラがインストールされていないことが原因です。
  次のコマンドを実行します。

sudo yum install gcc-c++

(sudo yum install gcc-c++ を使用すると、gcc およびその他の依存パッケージが自動的にインストール/アップグレードされます。)
コマンド ./configure を再実行すると、正常に
完了します。

• pcre-8.37 フォルダーで、最後に make && make install コマンドを使用します。つまり、最初にコンパイルしてからインストールします。
• バージョンの表示 pcre-config --version

3. 同様に、usr/src ディレクトリで、ダウンロードした nginx.tar.gz 圧縮パッケージを xshell に直接ドラッグします。

• 解压、./configure、make && make install
• /usr/local/nginx/sbin/nginx ディレクトリに入力してサービスを開始します。
  
  
  4. インストールが成功したかどうかを確認します。
• ブラウザに Linux アドレス (http://192.168.xx.xxx/ など) を入力します。
• ページが表示されない場合は、ファイアウォールをオフにすることができます

关闭防火墙：systemctl stop firewalld

开启防火墙：systemctl start firewalld

查看防火墙状态：systemctl status firewalld

インストール成功！

ファイアウォールが Nginx のポートをブロックしないようにするには、次の設定を行うことができます。

• 開いているポート番号を表示: firewall-cmd --list-all
• 開いているポート番号を設定します: firewall-cmd --add-port=80/tcp --permanent
• ファイアウォールを再起動します: firewall-cmd --reload

2.2 nginxの共通コマンド

nginx ディレクトリを入力します。nginx コマンドは nginx の sbin ディレクトリで使用する必要があります。

cd /usr/local/nginx/sbin

バージョン番号を表示する

./nginx -v

nginxを起動する

./nginx

nginxを停止する

./nginx -s stop

nginxをリロードする

./nginx -s reload

2.3 nginx設定ファイル

nginx設定ファイルの場所

cd /usr/local/nginx/conf/nginx.conf

設定ファイルの内容

• グローバル ブロック:構成ファイルからイベント ブロック間のコンテンツまで、主に Nginx サーバーを実行するユーザー (グループ) の構成、許可されるワーカー プロセスの数など、nginx サーバー
  の全体的な操作に影響を与えるいくつかの構成命令を設定します。生成されるプロセス、プロセス PID の保存パス、ログの保存パスと種類、設定ファイルの導入など。
  例えば: worker_processes の値が大きいほど、より多くの同時処理をサポートできます。
• イベント ブロック:
  イベント ブロックに含まれるコマンドは、主に Nginx サーバーとユーザーの間のネットワーク接続に影響します。一般的に使用される設定には、複数のワーク プロセスでのネットワーク接続のシリアル化を有効にするかどうか、複数のネットワーク接続の受信を許可するかどうかなどが含まれます。どのイベント ドライバを選択するか、接続要求を処理するモデル、各ワード プロセスが同時にサポートできる接続の最大数など。
• http ブロック:
  構成の最も頻繁に使用される部分、プロキシ、キャッシュ、ログ定義などのほとんどの機能、およびサードパーティ モジュールの構成がここにあります。http ブロックには、http グローバル ブロックと http グローバル ブロックも含めることができることに注意してください。サーバーブロック。
  • httpグローバルブロック
    http グローバル ブロック設定のディレクティブには、ファイルのインポート、MIME-TYPE 定義、ログのカスタマイズ、接続タイムアウト、単一リンク リクエストの最大数などが含まれます。
  • サーバーブロック
    • 各 http ブロックには複数のサーバー ブロックを含めることができ、各サーバー ブロックは仮想ホストに相当します。
    • 各サーバー ブロックはグローバル サーバー ブロックにも分割されており、同時に複数のロケーション ブロックを含めることができます。

3. nginx設定例-1-リバースプロキシ

達成された効果

ブラウザを開き、ブラウザのアドレスバーにアドレス www.123.com を入力し、liunx システムの Tomcat メイン ページにジャンプします。

準備

• デフォルトのポート 8080 を使用して、Linux システムに Tomcat をインストールします。

  • Tomcat インストール ファイルを Linux システムの usr/src フォルダーに置き、解凍します。
  • Tomcat の bin ディレクトリに入り、./startup.sh で Tomcat サーバーが起動します。

• 外部へのアクセスポートを開く権限を追加する

添加8080端口：firewall-cmd --add-port=8080/tcp --permanent

重载防火墙：firewall-cmd –reload

查看已经开放的端口号： firewall-cmd --list-all

• テスト: Windows システムに Linux サーバーを入力して、Tomcat サーバー ページにアクセスできるかどうかを確認します。
  

• 具体的な操作:
  1. Windows システムのホスト ファイルにドメイン名と IP アドレス間のマッピングを追加し、ブラウザが www.123.com に入った後に nginx サーバーにジャンプできるようにします。
  
  ファイルwww.123.com を自分の IP アドレスに追加します
  2. nginx 設定ファイルで、リクエスト転送を設定します (リバース プロキシ設定)。
  

3. テスト: リクエストが nginx サーバーによって転送された後、最終的に www.123.com にアクセスし、tomcat サーバーに転送します。

リバース プロキシ インスタンス 2

効果を達成する

nginx リバース プロキシを使用する: アクセス パスに従って、nginx サーバーを処理する必要があり、リクエストは別のポート サービスにリダイレクトされます。nginx サーバーのリスニング ポートは 9001 です。

• http://192.168.11.129:9001/edu/ にアクセスして、127.0.0.1:8080 に直接ジャンプします。
• http://192.168.11.129:9001/vod/ にアクセスし、127.0.0.1:8081 に直接ジャンプします。

準備

1. 最初のステップ: 2 つの Tomcat サーバー、1 つのポート 8001、1 つのポート 8002 を準備し、テスト ページを準備します。
2. ステップ 2: フォルダー ( edu および vod ) とテスト ページを作成する

特定の構成

• リバース プロキシ構成用の nginx 構成ファイルを見つけます。

• location コマンドの説明

• このディレクティブは URL を照合するために使用されます

• 構文は次のとおりです。

  • = : 正規表現のない URI の場合、リクエスト文字列は URI と厳密に一致する必要があります。一致した場合は、検索を停止してリクエストをすぐに処理します。
  • ~: URI に正規表現が含まれており、大文字と小文字が区別されることを示すために使用されます。
  • ~*: URI に正規表現が含まれており、大文字と小文字が区別されないことを示すために使用されます。
  • ^~: 正規表現を使用しない URI の前に、Nginx サーバーは、識別 URI とリクエスト文字列の間で一致度が最も高い場所を見つけ、通常の URI とリクエストを使用する代わりに、この場所をすぐに使用してリクエストを処理する必要があります。一致するロケーションブロック文字列内。
  • 注: uri に正規表現が含まれる場合は、~ または ~ マークが必要です。*

• 外部アクセス用のポート番号は 9001 8080 8081

テスト

4. nginx 設定インスタンス-2-負荷分散

効果を達成する

ブラウザのアドレス バーに、アドレス http://192.168.17.129/edu/a.html を入力します。これは負荷分散の効果があります。つまり、平均ポート 8080 と 8081

準備

• ステップ 1: 2 つの Tomcat サーバー (8080 と 8081) を準備します。
• ステップ 2: 2 つの Tomcat の webapps ディレクトリに、edu という名前のフォルダを作成し、edu フォルダ内にテスト用のページ a.html を作成します。

特定の構成 (ここでは主に平均分散、つまりポーリング)

nginx 構成ファイル (主に構成用の http ブロック) でロード バランシングを構成します。

• アップストリーム コマンドの使用: 負荷を引き受けるために 2 つのサーバーを追加します
• サーバー ブロックで構成します。server_name と listen は nginx サーバーのアドレス ポートであり、location ブロックで proxy_pass を構成し、バランスの取れた負荷を負担する 2 つのサーバーを導入します。毎回、nginx サーバーは負荷を異なるサービス ユニットに分散します。
  

テスト

ポート 8080 と 8081 でページを表示し、前後に切り替えるリクエスト

nginx 配布サーバー ポリシー

• ポーリング (デフォルト)

  • 各リクエストは時系列に 1 つずつ異なるバックエンド サーバーに割り当てられ、バックエンド サーバーがダウンした場合は自動的に排除されます。

• 重さ

  • Weight は重みを表します。デフォルトは 1 です。重みが大きいほど、より多くのクライアントが割り当てられます。
  • ポーリング確率を指定します。重みはアクセス率に比例し、バックエンドサーバーのパフォーマンスが不均一な場合に使用されます。
    

• ip_ハッシュ

  • 各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、各訪問者はバックエンド サーバーに固定的にアクセスし、セッションの問題を解決できます。
    

• フェア（第三者）

  • バックエンドサーバーの応答時間に応じてリクエストを振り分け、応答時間の短いリクエストを優先します。
    

5. nginx設定例-3-動的・静的分離

基本的な紹介

• 動的リクエストと静的リクエストを分離する 現在の実装の観点から、動的リクエストと静的リクエストの分離は、次の 2 つのタイプに大別できます。

  • 1. 静的ファイルを純粋に個別のドメイン名に分離し、独立したサーバーに配置することも、現在の主流の推奨ソリューションです。
  • 2. 動的ファイルと静的ファイルが混在してリリースされ、nginx によって分離されます。

異なるリクエスト転送を実現するには、場所ごとに異なるサフィックス名を指定します。
Expires パラメータを設定する (場所に追加する) ことで、ブラウザのキャッシュの有効期限を設定し、以前のリクエストとサーバーとのトラフィックを減らすことができます。 特定の Expires の定義: リソースの有効期限を設定します。サーバー側の検証の場合は、ブラウザ自体を通じて有効期限が切れているかどうかを直接確認できるため、追加のトラフィックは生成されません。このアプローチは、頻繁に変更されないリソースに最適です。(ファイルが頻繁に更新される場合は、Expires を使用してキャッシュすることはお勧めできません)。ここでは 3d を設定します。これは、3 日以内にこの URL にアクセスし、リクエストを送信し、ファイルの最終更新時刻を比較することを意味します。変更がない場合は、サーバーが取得してステータス コード 304 を返します。変更がある場合は、サーバーから直接ダウンロードしてステータス コード 200 を返します。

準備

静的リソースを保存するために、イメージ フォルダーや www フォルダーなどの静的リソースを Linux システムに準備します。

特定の構成

1. nginx 構成ファイルで構成し、nginx インストール ディレクトリを見つけて、/conf/nginx.conf 構成ファイルを開きます。
   

• リスニングポートとアクセスアドレスを追加
• 各静的リソース アクセス ディレクトリは場所のセクションに対応します。root - Linux におけるリソースのルート ディレクトリの場所を示します。
• autoindex on: 静的リソースディレクトリ配下のリソースリストを表示します。

テスト

• 最後に、Nginx の設定が正しいかどうかを確認し、動的と静的分離が成功したかどうかをテストします。バックエンド Tomcat サーバー上の静的ファイルを削除して、アクセスできるかどうかを確認する必要があります。アクセスできた場合は、これは、静的リソース nginx が直接返され、バックエンド Tomcat サーバーには行かないことを意味します。

• 画像にアクセスします（アクセスしたい静的リソースの名前をパスに直接追加することもできます）
  

• wwwにアクセスしてください
  

6. nginx 構成の高可用性クラスター

Keepalived + Nginx 高可用性クラスター (マスター/スレーブ モード)

nginxの高可用性とは何ですか

• 以前の構成では nginx サーバーが 1 台しかなく、このサーバーがダウンするとクライアントは要求したサーバーにアクセスできなくなりますが、高可用性クラスターはこのような問題を解決するものです。
  
• サーバーのダウンタイムによって nginx サービスがクラッシュしないように、マスター サーバーとスレーブ サーバーの 2 台の nginx サーバーが使用されます。
• ソフトウェア Keepalived サポートが必要です
  • Keepalived の機能はサーバーの状態を検出することであり、Web サーバーがダウンしたり、作業が失敗したりした場合、Keepalived がそれを検出し、障害のあるサーバーをシステムから削除し、他のサーバーを使用してサーバーの作業を置き換えます。 Keepalived は、作業が正常に完了すると、サーバーをサーバー グループに自動的に追加します。これらのタスクはすべて、手動介入なしで自動的に完了します。手動作業が必要なのは、障害のあるサーバーの修復です。
• 仮想 IP を外部に公開し、ルーティングを通じて 2 台の nginx サーバーに転送してリクエストの転送を処理します。

高可用性クラスターを構成するための準備

• 2 つの nginx サーバーが必要です (例: 192.168.11.129 と 192.168.11.133)。
• 両方のサーバーにnginxをインストールします
• 両方のサーバーにキープアライブをインストールします
  • yum install keepalived –y
  • インストール後、etc にディレクトリ keepalived が生成され、ファイル keepalived.conf が作成されます。
• 完全な高可用性構成 (マスター/スレーブ構成)
  • /etc/keepalived/keepalivec.conf 構成ファイルを変更します。

global_defs {
    
     #全局配置
	notification_email {
    
    
         acassen@firewall.loc
         failover@firewall.loc
         sysadmin@firewall.loc
 	}
     notification_email_from Alexandre.Cassen@firewall.loc
     smtp_server 192.168.11.129
     smtp_connect_timeout 30
     router_id LVS_DEVEL #主机的名字
}
vrrp_script chk_http_port {
    
     # 检测脚本配置
     script "/usr/local/src/nginx_check.sh" # 脚本文件位置
     interval 2 # 检测脚本执行的间隔
     weight 2 # 权重，一旦校测脚本中的条件成立，就修改为这个新权重（比如检测到这个服务器宕机，那么就将权重降低）
}
vrrp_instance VI_1 {
    
     # 虚拟ip配置
    state BACKUP # 备份服务器上将 MASTER 改为 BACKUP 
    interface ens33 //网卡
    virtual_router_id 51 # 主、备机的 virtual_router_id 必须相同
    priority 90 # 主、备机取不同的优先级，主机值较大，备份机值较小（主机100，备机90）
    advert_int 1 # 默认每隔一秒检测主机状态
    authentication {
    
    
         auth_type PASS
         auth_pass 1111
     }
     virtual_ipaddress {
    
    
     	192.168.11.88 // VRRP H 虚拟地址 (对外暴露的虚拟ip地址)
     }
}

• /usr/local/src に検出スクリプトを追加します (メインサーバーがダウンしているかどうかを検出するため)

#!/bin/bash
A=`ps -C nginx –no-header |wc -l`
if [ $A -eq 0 ];then
     /usr/local/nginx/sbin/nginx # nginx位置
     sleep 2
     if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
     	killall keepalived
     fi
fi

• 2 つのサーバーで nginx と keepalived を起動します。
  • nginx を開始します: ./nginx
  • 启アニメーション keepalived：systemctl start keepalived.service

最終試験

• ブラウザのアドレスバーに仮想 IP アドレス 192.168.11.88 を入力します。
  

• メインサーバー (192.168.11.129) nginx と keepalived を停止し、192.168.11.88 を入力します。内部アクセスはスタンバイ nginx サーバー (192.168.17.133) です。
  まだアクセス可能です！

7. nginxの原理

1.マスターとワーカーの作業モードを採用する

• 管理者として、作業プロセスを管理および監視します

• 実際の処理プロセスとしては、ワーカーがスクランブル方式で処理要求を処理する
  
  
  2.ワーカーの
  
  仕組み3. 1 つのマスターと複数のワーカーが有利

• nginx –s リロード ホット デプロイメントを使用したり、ホット デプロイメントに nginx を使用したりできます。

  • サーバーのダウンタイムを避けるためにnginxを再起動する必要はありません
  • ワーカーがリクエストを処理している場合、残りのワーカーのみがホット デプロイメントを実行します。

• 各ワーカーは独立したプロセスであり、いずれかのワーカーに問題が発生した場合、他のワーカーはサービスを中断することなく要求処理を実現するために独立して競合し続けます。

4.ワーカーの数を設定するのが適切ですか

• ワーカーの数はサーバーの CPU の数と同じであることが最も適切です
  。
• リクエストを送信するときにワーカーはいくつの接続を使用しましたか?
  • 2 または 4
    • 静的リソースにアクセスする場合、クライアントはリクエストを送信し、ワーカーが応答します。
    • 動的リソースにアクセスする場合、ワーカーは上記に基づいて、Tomcat と対話し、データベース アクセスを要求するためにさらに 2 つの接続を追加します。
• Nginx にはマスターと 4 つのワーカーがあり、各ワーカーは最大接続数 1024 をサポートします。サポートされる同時実行の最大数はどれくらいですか?
  • 通常の静的リソースへの最大同時アクセスは次のとおりです:worker_connections *worker_processes /2 (ワーカーあたりの最大接続数 × ワーカーの数を、静的リソースにアクセスするための 2 つの接続で割ったもの)
  • HTTP がリバース プロキシとして使用される場合、同時実行の最大数は、worker_connections*worker_processes / 4 となる必要があります。

来て！プログラマー！