記事ディレクトリ
Nginxはサーバーサイドのクラスター構築を実装します
Nginx と Tomcat のデプロイメント
Nginx は、同時実行性の高いシナリオや静的リソースの処理において非常に高いパフォーマンスを発揮しますが、実際のプロジェクトでは静的リソースに加えてバックグラウンド ビジネス コード モジュールがあり、通常、バックグラウンド ビジネスは Tomcat、weblogic、websphere などの Web サーバー上にデプロイされます。では、Nginx を使用してユーザーリクエストを受信し、そのリクエストをバックグラウンド Web サーバーに転送するにはどうすればよいでしょうか?
ステップ分析:
1.准备Tomcat环境，并在Tomcat上部署一个web项目
2.准备Nginx环境，使用Nginx接收请求，并把请求分发到Tomat上
環境準備（Tomcat）
ブラウザアクセス:
http://192.168.200.146:8080/demo/index.html
動的リソースのリンク アドレスを取得します。
http://192.168.200.146:8080/demo/getAddress
ここでは Tomcat がバックグラウンド Web サーバーとして使用されています
(1) Centos上にTomcatを用意する
1.Tomcat官网地址:https://tomcat.apache.org/
2.下载tomcat,本次使用的是apache-tomcat-8.5.59.tar.gz
3.将tomcat进行解压缩
mkdir web_tomcat
tar -zxf apache-tomcat-8.5.59.tar.gz -C /web_tomcat
(2) Webプロジェクトを用意してwarとしてパッケージ化する
1.将资料中的demo.war上传到tomcat8目录下的webapps包下
2.将tomcat进行启动，进入tomcat8的bin目录下
./startup.sh
(3) アクセステストのために Tomcat を起動します。
静态资源: http://192.168.200.146:8080/demo/index.html
动态资源: http://192.168.200.146:8080/demo/getAddress
環境準備（Nginx）
(1) Nginx のリバース プロキシを使用して、リクエストを Tomcat に転送して処理します。
upstream webservice {
server 192.168.200.146:8080;
}
server{
listen 80;
server_name localhost;
location /demo {
proxy_pass http://webservice;
}
}
(2) アクセステストを開始する
これを知った後、あなたは混乱するかもしれません。Tomcat 経由で直接アクセスできるのに、なぜ追加の nginx を追加する必要があるのですか? これによりシステムの複雑さが増すのではありませんか? 次に、この問題を 2 つの側面から分析します
。
-
Nginx を使用して動的と静的分離を実現する
-
Nginx を使用して Tomcat クラスターを構築する
Nginxは動的と静的な分離を実現します
静的分離と動的分離とは?
-
アクション: バックグラウンドアプリケーションの業務処理
-
静的: Web サイトの静的リソース (html、JavaScript、CSS、画像、その他のファイル)
動的と静的な分離とは、動的リクエストと静的リクエストが別々に処理され、動的リクエストがアプリケーション サーバーに渡され、静的リクエストが Web サーバーから直接返されることを意味します。これにはいくつかの利点があります。
- アプリケーション サーバーの負荷を軽減し、動的リクエストの処理に集中させます。
- 静的リソースは直接キャッシュして Web サーバーから返すことができるため、より高速です。
- 異なるサーバーを使用して動的リクエストと静的リクエストを別々に処理し、パフォーマンスを最適化できます。
Nginx は動的と静的分離を非常にうまく実現できます。原理は次のとおりです。
- まず、動的リクエストと静的リクエストを区別します。これは、location ディレクティブの正規表現またはパラメータを通じて実現できます。好き：
location ~* \.(jpg|gif|png)$ { # 匹配静态资源请求 ... } location /api/ { # 匹配动态请求 ... } - 静的リクエストは Nginx によって直接返されます。Nginx はリソースを直接取得し、ローカル ファイル システムまたはリモート FastCGI/プロキシから渡されたファイルを通じてそれらを返すことができます。
- 動的リクエストは、処理のためにアプリケーション サーバーにプロキシされるか転送されます。Nginx は、FastCGI/proxy_pass などを介して動的リクエストをアプリケーション サーバーに転送し、アプリケーション サーバーの応答をクライアントに返します。
- Nginx では、静的リソースのキャッシュを有効にすることもできます。これにより、戻り速度がさらに向上し、アプリケーション サーバーへの負荷が軽減されます。
- Keepalived などを使用してホットスタンバイを実装し、高可用性を確保します。
したがって、一般に、さまざまな種類のリクエストを識別し、それらを処理のためにさまざまなサーバーに割り当てることで、Nginx は各サーバーの利点を最大化し、より高いパフォーマンスと効率を得ることができます。これは、Nginx が動的と静的を分離するための鍵です。
動的と静的な分離により、Web サービスは Nginx + アプリケーション サーバー + キャッシュ + 静的リソース サーバーのアーキテクチャを使用できるため、各部分が効率的かつ安定して動作できます。これは、トラフィックの多い Web サイトの基本的なアーキテクチャ選択です。
動的と静的な分離を実現する方法?
- 動的と静的な分離を実現するには、さまざまな方法があります。たとえば、静的リソースを CDN、Nginx、その他のサーバーにデプロイし、動的リソースを Tomcat、weblogic、または Websphere にデプロイできます。ここでは、Nginx + Tomcat を使用して、動的と静的な分離を実現します。
需要分析
動的分離と静的分離を実現する手順
1.demo.war プロジェクト内のすべての静的リソースを削除し、再パッケージ化してデータで提供される war パッケージを生成します。
2. war パッケージを Tomcat にデプロイし、以前にデプロイされたコンテンツを削除します
进入到tomcat的webapps目录下，将之前的内容删除掉
将新的war包复制到webapps下
将tomcat启动
3. Nginx が配置されているサーバー上に次のディレクトリを作成し、対応する静的リソースを指定された場所に配置します。
Index.html ページの内容は次のとおりです。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
<script src="js/jquery.min.js"></script>
<script>
$(function(){
$.get('http://192.168.200.133/demo/getAddress',function(data){
$("#msg").html(data);
});
});
</script>
</head>
<body>
<img src="images/logo.png"/>
<h1>Nginx如何将请求转发到后端服务器</h1>
<h3 id="msg"></h3>
<img src="images/mv.png"/>
</body>
</html>
4. Nginxの静的リソースと動的リソースへのアクセスを設定する
upstream webservice{
server 192.168.200.146:8080;
}
server {
listen 80;
server_name localhost;
#动态资源
location /demo {
proxy_pass http://webservice;
}
#静态资源
location ~/.*\.(png|jpg|gif|js){
root html/web;
gzip on;
}
location / {
root html/web;
index index.html index.htm;
}
}
5. テストを開始し、http://192.168.200.133/index.html にアクセスします。
ある時点で Tomcat サーバーが何らかの理由でダウンした場合、Nginx に再度アクセスすると、ユーザーは引き続きページを表示できますが、アクセス数の統計が失われます。
Nginx は Tomcat クラスター構築を実装します
Nginx と Tomcat を使用してプロジェクトをデプロイする場合、Nginx サーバーと Tomcat サーバーを使用し、レンダリングは次のようになります。
次に問題は、Tomcat が実際にダウンした場合、システム全体が不完全になるため、上記の問題をどのように解決するかです。1 つのサーバーは簡単にダウンします。その後、さらにいくつかの Tomcat サーバーを構築すると、バックエンド サーバーの可用性が向上します。これは私たちがよくクラスターと呼ぶものです。Tomcat クラスターを構築するには、Nginx のリバース プロキシとロード バランシングの知識が必要です。それを実装する方法は何ですか? まず原理を分析しましょう。
Nginx は Tomcat クラスターを非常にうまく実装できます。手順は次のとおりです。
- Tomcat をインストールし、クラスター ノードを構成します。各 Tomcat サーバーで server.xml を構成し、異なるポート (8080、8081 など) を設定し、スティッキー関連パラメーターとしてセッション構成を設定します。
- Nginx をインストールし、worker_processes の数を Tomcat サーバーの数と同じに設定します。これにより、サーバー リソースを最大限に活用できます。
- Tomcat クラスター ノードを指すように Nginx のアップストリーム プロキシを設定します。好き：
upstream tomcat_cluster { server localhost:8080; server localhost:8081; } - Tomcat クラスターへのリクエストをプロキシするためのプロキシの場所を設定します。好き：
location / { proxy_pass http://tomcat_cluster; } - 同じ Tomcat へのセッションを維持するように Nginx のスティッキー モジュールまたは Cookie を構成します。好き：
upstream tomcat_cluster { ip_hash; # 开启ip_hash,使同一IP的请求定向到同一服务器 server localhost:8080; server localhost:8081; } //或者像下面这样 upstream tomcat_cluster { server localhost:8080; server localhost:8081; } location / { proxy_pass http://tomcat_cluster; sticky cookie srv_id expires=1h domain=.example.com; # 按cookie路由 }
さて、上記の環境の展開が完了した後、Tomcat の高可用性は解決され、1 台のサーバーがダウンし、他の 2 台が外部にサービスを提供すると同時に、バックグラウンド サーバーも継続的に更新できるようになりました。しかし、上記の環境で Nginx がダウンするとシステム全体が外部にサービスを提供してしまうという新たな問題が発生しました。
Nginx 高可用性ソリューション
上記の問題を考慮して、上記の問題を解決するにはどのような問題に直面する必要があるかを分析してみましょう。
外部サービスを提供するには 2 つ以上の Nginx サーバーが必要です。このようにして、1 つがダウンしても、もう 1 つが外部サービスを提供できます。ただし、Nginx サーバーが 2 つある場合、IP アドレスは 2 つ存在します。ユーザーはどのサーバーにアクセスする必要がありますか? ユーザーは、どのサーバーが正常で、どのサーバーがダウンしているかをどのように判断するのでしょうか?
キープアライブ
この問題を解決するには、Keepalived を使用します。Keepalived ソフトウェアは C で書かれており、もともと LVS ロード バランシング ソフトウェア用に設計されました。Keepalived ソフトウェアは、主に VRRP プロトコルを通じて高可用性機能を実装します。
VRRP
VRRP (Virtual Router Redundancy Protocol) 仮想ルーター冗長プロトコルは、ルーターの高可用性を実現するためのプロトコルです。
VRRP は次のように動作します。
- VRRP は通常、同じ LAN 内にルーターのグループを構成します。このグループ内のルーターの 1 つがマスタールーター、その他のルーターがバックアップルーターになります。
- VRRP は、マルチキャスト機能を使用してこのルーター グループ間の通信を行い、VRRP メッセージを通じてマスター ルーターを選択し、他のルーターをバックアップとして選択します。
- メイン ルータが使用可能な場合、メイン ルータはルータ グループのすべてのルーティング機能を担当し、バックアップ ルータは非アクティブ状態になります。
- メイン ルータに障害が発生した場合、バックアップ ルータの 1 つがメイン ルータの機能を引き継いで新しいメイン ルータとなり、他のルータはバックアップ状態に調整されます。()
- マスター ルーターが回復すると、プリエンプティブ VRRP メッセージを送信してマスター ルーターの機能を再び引き継ぐことを通知し、バックアップ ルーターはバックアップ状態に戻ります。
- VRRP では、検出器を使用してメイン ルーターを継続的に検出し、一定時間以内に検出されない場合は、新たな選出プロセスを開始して新しいメイン ルーターを選択します。
- VRRP により、ルーターのグループ全体がホストの仮想ルーターのようなものとなり、実際のメインルーターがどのように変更されても、ホストのデフォルト ゲートウェイ アドレスは変更されません。
したがって、VRRP の主な機能は、ルーターの障害を検出して自動切り替えを実行し、LAN 内のホストに可用性の高いデフォルト ゲートウェイ サービスを提供することです。ネットワークへの影響を最小限に抑えながら、ルーターの状態監視と自動フェイルオーバーを実現します。
Keepalived を使用した後の解決策は次のとおりです。
環境構築
環境整備
| VIP | IP | CPU名 | マスタースレーブ |
|---|---|---|---|
| 192.168.200.133 | キープアライブ1 | マスター | |
| 192.168.200.222 | |||
| 192.168.200.122 | キープアライブ2 | バックアップ |
キープアライブのインストール
步骤1:从官方网站下载keepalived,官网地址https://keepalived.org/
步骤2:将下载的资源上传到服务器
keepalived-2.0.20.tar.gz
步骤3:创建keepalived目录，方便管理资源
mkdir keepalived
步骤4:将压缩文件进行解压缩，解压缩到指定的目录
tar -zxf keepalived-2.0.20.tar.gz -C keepalived/
步骤5:对keepalived进行配置，编译和安装
cd keepalived/keepalived-2.0.20
./configure --sysconf=/etc --prefix=/usr/local
make && make install
インストールが完了したら、知っておく必要があるファイルが 2 つあります。1 つは/etc/keepalived/keepalived.conf(主に操作する keepalived のシステム構成ファイル)、もう 1 つは /usr/local/sbin ディレクトリにあり、keepalived の開始と終了に使用されるシステム構成スクリプトですkeepalived。
Keepalived 設定ファイルの概要
keepalived.conf 設定ファイルを開きます
3 つの部分に分かれており、最初の部分はグローバル設定、2 番目の部分は vrrp 関連の設定、3 番目の部分は LVS 関連の設定です。
このコースでは主にキープアライブを使用して高可用性展開を実現します。LVS は使用されないため、最初の 2 つの部分に焦点を当てます。
global全局部分：
global_defs {
#通知邮件，当keepalived发送切换时需要发email给具体的邮箱地址
notification_email {
[email protected]
[email protected]
}
#设置发件人的邮箱信息
notification_email_from [email protected]
#指定smpt服务地址
smtp_server 192.168.200.1
#指定smpt服务连接超时时间
smtp_connect_timeout 30
#运行keepalived服务器的一个标识，可以用作发送邮件的主题信息
router_id LVS_DEVEL
#默认是不跳过检查。检查收到的VRRP通告中的所有地址可能会比较耗时，设置此命令的意思是，如果通告与接收的上一个通告来自相同的master路由器，则不执行检查(跳过检查)
vrrp_skip_check_adv_addr
#严格遵守VRRP协议。
vrrp_strict
#在一个接口发送的两个免费ARP之间的延迟。可以精确到毫秒级。默认是0
vrrp_garp_interval 0
#在一个网卡上每组na消息之间的延迟时间，默认为0
vrrp_gna_interval 0
}
VRRP部分，该部分可以包含以下四个子模块
1. vrrp_script
2. vrrp_sync_group
3. garp_group
4. vrrp_instance
我们会用到第一个和第四个，
#设置keepalived实例的相关信息，VI_1为VRRP实例名称
vrrp_instance VI_1 {
state MASTER #有两个值可选MASTER主 BACKUP备
interface ens33 #vrrp实例绑定的接口，用于发送VRRP包[当前服务器使用的网卡名称]
virtual_router_id 51#指定VRRP实例ID，范围是0-255
priority 100 #指定优先级，优先级高的将成为MASTER
advert_int 1 #指定发送VRRP通告的间隔，单位是秒
authentication { #vrrp之间通信的认证信息
auth_type PASS #指定认证方式。PASS简单密码认证(推荐)
auth_pass 1111 #指定认证使用的密码，最多8位
}
virtual_ipaddress { #虚拟IP地址设置虚拟IP地址，供用户访问使用，可设置多个，一行一个
192.168.200.222
}
}
設定内容は以下の通りです。
サーバー1
global_defs {
notification_email {
[email protected]
[email protected]
}
notification_email_from [email protected]
smtp_server 192.168.200.1
smtp_connect_timeout 30
router_id keepalived1
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.222
}
}
サーバー2
! Configuration File for keepalived
global_defs {
notification_email {
[email protected]
[email protected]
}
notification_email_from [email protected]
smtp_server 192.168.200.1
smtp_connect_timeout 30
router_id keepalived2
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state BACKUP
interface ens33
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.222
}
}
アクセステスト
-
keepalived を開始する前に、コマンドを使用して
ip a2 つのサーバー 192.168.200.133 と 192.168.200.122 の IP ステータスを確認しましょう。
-
2 つのサーバーのキープアライブを個別に開始します。
cd /usr/local/sbin
./keepalived
もう一度ip aIPを見てみる
- 192.168.200.133 サーバーのキープアライブをオフにした後、IP を再度確認します。
上記のテストにより、仮想 IP (VIP) が MASTER ノード上にあることがわかります。MASTER ノード上のキープアライブに失敗した場合、BACKUP は MASTER から送信された VRRP ステータス パス メッセージを受信できないため、直接 MASTER にアップグレードされます。VIPも新しいMASTERに「漂流」します。
上記のテストは Nginx とどのような関係があるのでしょうか?
サーバー 192.168.200.133 のキープアライブを再度開始します。サーバー 192.168.200.122 よりも優先度が高いため、サーバーは再び MASTER になり、VIP も過去に「ドリフト」し、ブラウザーを通じて再度アクセスします。
http://192.168.200.222/
192.168.200.133 サーバーのキープアライブがオフになっている場合は、同じアドレスに再度アクセスしてください
効果が実現すると、vip を切り替えたい場合は、サーバー上の keepalived をオフにする必要があることがわかります。また、keepalived をいつオフにするか? keepalived が配置されているサーバーの nginx に問題が発生した後、keepalived をオフにして、VIP に別のサーバーを実行させる必要がありますが、現在はすべての操作が手動で行われています。現在のサーバーの nginx が正しく起動しているかどうかをシステムに自動的に判断させるにはどうすればよいでしょうか? そうでない場合は、VIP を自動的に実行させます。ドリフト」。解決しますか？
keepalivedのvrrp_script
Keepalived はネットワーク障害と keepalived 自体のみを監視できます。つまり、ネットワーク障害が発生した場合、または keepalived 自体に問題が発生した場合に切り替えます。しかし、それだけでは十分ではなく、keepalivedが置かれているサーバ上のNginxなどの他の業務も監視する必要があります。Nginxが異常だとkeepalivedだけが正常で、システムの正常な動作ができなくなります。そのため、ビジネスプロセスの実行状況に応じてアクティブとスタンバイを切り替える必要があります。このとき、スクリプトを書くことでビジネスプロセスを検出・監視することができます。
実装手順:
- 次のようなキープアライブ設定ファイルに対応する設定を追加します。
vrrp_script 脚本名称
{
script "脚本位置"
interval 3 #执行时间间隔
weight -20 #动态调整vrrp_instance的优先级
}
- スクリプトを書く
ck_nginx.sh
#!/bin/bash
num=`ps -C nginx --no-header | wc -l`
if [ $num -eq 0 ];then
/usr/local/nginx/sbin/nginx
sleep 2
if [ `ps -C nginx --no-header | wc -l` -eq 0 ]; then
killall keepalived
fi
fi
Linux ps コマンドは、現在のプロセスのステータスを表示するために使用されます。
-C(コマンド): 指定したコマンドの全プロセス
--no-header ヘッダーを除外します
- スクリプトファイルの権限を設定する
chmod 755 ck_nginx.sh
- スクリプトを追加する
vrrp_script ck_nginx {
script "/etc/keepalived/ck_nginx.sh" #执行脚本的位置
interval 2 #执行脚本的周期，秒为单位
weight -20 #权重的计算方式
}
vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 10
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.111
}
track_script {
ck_nginx
}
}
- 効果が得られない場合は、
tail -f /var/log/messages「ログ情報の表示」で該当するエラーメッセージを確認してください。 - テスト
考えるべき質問:
通常、マスター サービスが停止するとバックアップがマスターになりますが、マスター サービスが再び正常になると、この時点でマスターが VIP を取得するため、2 回の切り替えが発生し、混雑した Web サイトにとっては好ましくありません。したがって、構成ファイルに nopreempt を追加する必要がありますが、このパラメータは状態がバックアップの場合にのみ使用できるため、HA を使用する場合は、マスターとバックアップの状態をバックアップに設定して、優先順位を競合させることが最善です。
Nginx makeのダウンロードサイト
まず、ダウンロード サイトとは何なのかを理解する必要があります。
まず Web サイトを見てみましょう。Nginx をhttp://nginx.org/download/初めて学習し始めたときに、このような Web サイトを紹介しました。この Web サイトは主にユーザーが関連リソースをダウンロードできるようにするために使用されます。ダウンロード Web サイトと呼ばれます。
ダウンロードサイトの作り方：
Nginx は、モジュール ngx_http_autoindex_module を使用して実装されます。このモジュールは、スラッシュ (「/」) で終わるリクエストを処理し、ディレクトリのリストを生成します。
このモジュールは nginx がコンパイルされるときに自動的にロードされますが、モジュールはデフォルトでは無効になっています。対応する構成を完了するには次のコマンドを使用する必要があります。
(1) autoindex: ディレクトリリスト出力を有効または無効にします。
| 文法 | 自動インデックスのオン|オフ; |
|---|---|
| デフォルト | 自動インデックスはオフです。 |
| 位置 | http、サーバー、場所 |
(2) autoindex_exact_size: HTLM形式に対応し、ディレクトリ一覧にファイルの詳細サイズを表示するかどうかを指定します
デフォルトはオンで、ファイルの正確なサイズがバイト単位で表示されます。
オフに変更すると、ファイルのおおよそのサイズが kB、MB、GB 単位で表示されます。
| 文法 | autoindex_exact_size オン|オフ; |
|---|---|
| デフォルト | autoindex_exact_size がオン。 |
| 位置 | http、サーバー、場所 |
(3) autoindex_format: ディレクトリリストのフォーマットを設定します。
| 文法 | autoindex_format html|xml|json|jsonp; |
|---|---|
| デフォルト | autoindex_format html; |
| 位置 | http、サーバー、場所 |
注: このコマンドは 1.7.9 以降のバージョンで使用されます。
(4) autoindex_localtime: HTML形式に対応し、ディレクトリ一覧に時刻を表示するかどうか。
デフォルトはオフで、表示されるファイル時間は GMT 時間です。
onに変更後、表示されるファイル時間はファイルのサーバー時間になります。
| 文法 | autoindex_localtime 上の | オフ; |
|---|---|
| デフォルト | autoindex_localtime オフ; |
| 位置 | http、サーバー、場所 |
構成は次のとおりです。
location /download{
root /usr/local;
autoindex on;
autoindex_exact_size on;
autoindex_format html;
autoindex_localtime on;
}
通常、XML/JSON はこれら 2 つの方法では使用されません。
Nginxユーザー認証モジュール
システムリソースへのアクセスに応じて、アクセスできるユーザーとアクセスできないユーザーを制限する必要があることがよくあります。これは通常認証部分と呼ばれるもので、ユーザーが入力したユーザー名とパスワードに基づいてそのユーザーが正規のユーザーであるかどうかを判断し、正規のユーザーであればアクセスを許可し、そうでない場合はアクセスを拒否します。
Nginx の対応するユーザー認証は、ngx_http_auth_basic_module モジュールを通じて実装されており、「HTTP 基本認証」プロトコルを使用してユーザー名とパスワードを検証することで、リソースへのアクセスを制限できます。デフォルトでは、nginx はこのモジュールをすでにインストールしています。必要ない場合は、-without-http_auth_basic_module を使用してください。
このモジュールの手順は比較的単純ですが、
(1) auth_basic: 「HTTP 基本認証」プロトコルを使用して、ユーザー名とパスワードの検証を有効にします。
| 文法 | auth_basic 文字列|オフ; |
|---|---|
| デフォルト | auth_basic オフ; |
| 位置 | http、サーバー、場所、制限_例外 |
これを有効にすると、サーバーは 401 を返し、指定された文字列がクライアントに返されてユーザーにプロンプトが表示されますが、ブラウザーが異なると表示される内容が一貫していません。
(2) auth_basic_user_file: ユーザー名とパスワードが格納されているファイルを指定します
| 文法 | auth_basic_user_file ファイル; |
|---|---|
| デフォルト | — |
| 位置 | http、サーバー、場所、制限_例外 |
ファイル パス、ファイル内のユーザー名とパスワードの設定を指定します。パスワードは暗号化する必要があります。ツールで自動生成できる
実装手順:
1.nginx.confに以下の内容を追加
location /download{
root /usr/local;
autoindex on;
autoindex_exact_size on;
autoindex_format html;
autoindex_localtime on;
auth_basic 'please input your auth';
auth_basic_user_file htpasswd;
}
htpasswd2.生成するにはツールを使用する必要があります。
yum install -y httpd-tools
htpasswd -c /usr/local/nginx/conf/htpasswd username //创建一个新文件记录用户名和密码
htpasswd -b /usr/local/nginx/conf/htpasswd username password //在指定文件新增一个用户名和密码
htpasswd -D /usr/local/nginx/conf/htpasswd username //从指定文件删除一个用户信息
htpasswd -v /usr/local/nginx/conf/htpasswd username //验证用户名和密码是否正确
上記の方法でもユーザー名とパスワードの検証は実現できますが、ご覧のとおり、すべてのユーザー名とパスワード情報がファイルに記録されているため、ユーザー数が多すぎる場合には少々面倒になるため、現時点ではバックグラウンドのビジネスコードを通じてユーザーの権限を検証する必要があります。