Centos7のNginxチュートリアル2

Centos7 Nginxチュートリアル2では、
Nginxログのカッティングマニュアルの
既存のログはaccess.logファイルに保存されますが、時間の経過とともに、このファイルのコンテンツはますます大きくなり、ボリュームはますます大きくなり、不便になります運用および保守担当者がチェックするので、この大きなログファイルをログとして複数の小さなファイルにカットできます。カットルールは日単位にすることもできます。1日に数百のGまたはTログがある場合は、必要に応じて、半日ごとまたは1時間ごとにログをカットします。

1.シェル実行可能ファイル(cut_my_log.sh)を作成します。内容は次のとおりです。

#!/bin/bash
LOG_PATH="/var/log/nginx/"
RECORD_TIME=$(date -d "yesterday" +%Y-%m-%d+%H:%M)
PID=/var/run/nginx/nginx.pid
mv ${LOG_PATH}/access.log ${LOG_PATH}/access.${RECORD_TIME}.log
mv ${LOG_PATH}/error.log ${LOG_PATH}/error.${RECORD_TIME}.log

#向Nginx主进程发送信号,用于重新打开日志文件
kill -USR1 `cat $PID`

2. cut_my_log.shの実行権限を追加します。

chmod +x cut_my_log.sh

3.テストログをカットした後の結果:

./cut_my_log.sh

Nginxログ切断タイミング
1.タイミングタスクをインストールします。

yum -y install crontabs

2.crontab -eタスクの新しい行を編集して追加します。

*/1 * * * * /usr/local/nginx/sbin/cut_my_log.sh

3.スケジュールされたタスクを再開します:
service crond restart

添付ファイル:スケジュールされた一般的なタスクコマンド:
service crond start //サービスサービスを
開始crond stop //サービス
サービスを終了crond restart //サービス
サービスを再起動crond reload //設定を再読み込み
crontab -e //タスク
crontabを編集-l //表示タスクリスト

正規表現:
cron式は5つまたは6つのフィールドに分割され、各フィールドは以下に示すように意味を表します。

タイムシェアリング、日、月、週(オプション)
値の範囲0-59 0-23 1-31 1-12 1-7 2019/2020/2021 /…

毎分実行:
* / 1 * * * *
毎朝(毎晩23:59):
59 23 * * *
毎日午前1時:
0 1 * * *

章Q&Aの注意事項
それでは、非常に多くの構成があるので、場所の構成ルールを見てみましょう

ルートとエイリアス
サーバーパスが次の場合:/home/huadaxia/files/img/face.pngルートパスは、次の場合
、アクセス
構成と完全に一致します

location /huadaxia {
    root /home
}

ユーザーがアクセスすると、リクエストは次のようになります:url:port / huadaxia / files / img / face.png

aliasはパスのエイリアスをユーザーに透過的にすることができます

location /hello {
    alias /home/huadaxia 
}

ユーザーがアクセスすると、リクエストは次のようになります:url:port / hello / files / img / face.png

ロケーション
スペースの一致ルール:デフォルトの一致、通常の一致

location / {
     root /home;
}

=:完全一致
(つまり、/ home / huadaxia / img / face1.png内)この画像の外部の人がアクセスできます

location = /huadaxia/img/face1.png {
    root /home;
}

〜*:マッチする正規表現、絵サフィックスGIF、次のすべて/ホームの場合の小文字を区別しない、| JPG | PNG | JPEG缶アクセス
#は映像ショーに準拠します

location ~* .(GIF|jpg|png|jpeg) {
    root /home;
}

〜:正規表現
に一致します。大文字と小文字を区別する#GIFは、一致するように大文字にする必要があります

location ~ .(GIF|jpg|png|jpeg) {
    root /home;
}

^〜:文字パスで開始

location ^~ /huadaxia/img {
    root /home;
}

Nginxクロスドメイン構成のサポート
Springbootプロジェクトでは、クロスドメインアクセスも可能であるため、より一般的なフロントエンドとバックエンドの分離モードを使用し、主にNginxを使用してクロスドメインの分離を構成しています。これが主流です。
Springboot
ここに画像の説明を挿入

在nginx中
#允许跨域请求的域,*代表所有
add_header 'Access-Control-Allow-Origin' *;
#允许带上cookie请求
add_header 'Access-Control-Allow-Credentials' 'true';
#允许请求的方法,比如 GET/POST/PUT/DELETE
add_header 'Access-Control-Allow-Methods' *;
#允许请求的header
add_header 'Access-Control-Allow-Headers' *;

Nginx盗難防止チェーン構成、盗難防止チェーンは、他の人があなたの写真やその他の静的リソースを盗むの
を防ぐためのものです
。1透かし、ブランドプロモーション、帯域幅、十分なサーバー、
2ファイアウォール、直接制御、IPソースを知っていることを防ぐための多くの方法があります。
3:盗難防止チェーン戦略次の方法は、404エラープロンプトを直接表示することです
ここに画像の説明を挿入

#对源站点验证
valid_referers *.huadaxia.com; 
#非法引入会进入下方判断
if ($invalid_referer) {
    return 404;
}
listen       90;
    server_name  localhost;
    #允许跨域请求的域,*代表所有
    add_header 'Access-Control-Allow-Origin' *;
    #允许带上cookie请求
    add_header 'Access-Control-Allow-Credentials' 'true';
    #允许请求的方法,比如 GET/POST/PUT/DELETE
    add_header 'Access-Control-Allow-Methods' *;
    #允许请求的header
    add_header 'Access-Control-Allow-Headers' *;
    #对源站点验证
    valid_referers *.huadaxia.com;
    #非法引入会进入下方判断
    if ($invalid_referer) {
            return 404;
            }

アップストリーム:ロードバランシング
デフォルトでは、
アップストリームコマンドパラメータmax_conns はポーリングによって送信されます。

1つのワーカープロセスが設定されています。これは、成功した接続の数をテストおよび監視するのに便利です。

worker_processes  1;

upstream tomcats {
        server 192.168.1.173:8080 max_conns=2;
        server 192.168.1.174:8080 max_conns=2;
        server 192.168.1.175:8080 max_conns=2;
}

上流のコマンドパラメータslow_start
商用バージョン、支払う必要があります

upstream tomcats {
        server 192.168.1.173:8080 weight=6 slow_start=60s;
#       server 192.168.1.190:8080;
        server 192.168.1.174:8080 weight=2;
        server 192.168.1.175:8080 weight=2;
}


このパラメーターは、ハッシュおよびランダムロードバランシングでは使用できません。
アップストリームにサーバーが1つしかない場合、このパラメーターは無効です。
Chapter Q&A notes
アップストリームコマンドパラメータdownおよびbackup
#downは、サービスノードを使用不可としてマークするために使用されます。

upstream tomcats {
        server 192.168.1.173:8080 down;
#       server 192.168.1.190:8080;
        server 192.168.1.174:8080 weight=1;
        server 192.168.1.175:8080 weight=1;
}

バックアップは、現在のサーバーノードがバックアップマシンであることを示しています。他のすべてのサーバーが停止した後でのみ、サーバーがクラスターに参加し、ユーザーがアクセスできるようになります。

upstream tomcats {
        server 192.168.1.173:8080 backup;
#       server 192.168.1.190:8080;
        server 192.168.1.174:8080 weight=1;
        server 192.168.1.175:8080 weight=1;
}

バックアップパラメータは、ハッシュおよびランダムロードバランシングでは使用できません。


ユーザーがリクエストにアクセスしたときのアップストリームコマンドパラメータmax_failsおよびfail_timeout は次のとおりです。url:port / huadaxia / files / img / face.pngmax_fails:サーバーが数回失敗したことを示し、サーバーをダウンとしてマークし、アップストリームサービスを削除します。
fail_timeout:失敗した再試行時間を示します。
現在の設定が次のとおりであるとします。

max_fails = 2 fail_timeout = 15s

つまり、15秒以内に2回サーバーのリクエストに失敗した後、サーバーがハングまたはダウンしたと見なされ、15秒後、15秒以内にハングしたばかりのノードに新しいリクエストが届かなくなります。代わりに、通常のサーバーを要求します。15秒後に、ハングしたサーバーへの接続を試みる新しい要求があります。それでも失敗する場合は、復元されるまで前のプロセスを繰り返します。

Keepalived
スループットを向上させますkeepalived:長い接続処理の数を設定します
proxy_http_version:長い接続のhttpバージョンを1.1に
設定しますproxy_set_header:接続ヘッダー情報をクリアします

upstream tomcats {
#       server 192.168.1.173:8080 max_fails=2 fail_timeout=1s;
        server 192.168.1.190:8080;
#       server 192.168.1.174:8080 weight=1;
#       server 192.168.1.175:8080 weight=1;
        keepalive 32;
}

server {
        listen       80;
        server_name  www.tomcats.com;

        location / {
            proxy_pass  http://tomcats;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
        }
    }

ip_hash
ip_hashの負荷分散により、ユーザーipが変更されていない場合に、ユーザーが上流サーバーに要求できる固定サーバーに確実にアクセスできるようになります。
ip_hashを使用する際の注意点:
バックエンドサーバーを直接削除することはできません。マークダウンすることしかできません。

upstream tomcats {
        ip_hash;

        server 192.168.1.173:8080;
        server 192.168.1.174:8080 down;
        server 192.168.1.175:8080;
}

以下は、最初の3桁のみをカウントします。たとえば、IPが192.168.1。*の場合、iphashアルゴリズムはデフォルトで最初の3桁になるため、イントラネットに接続している場合は1つだけでアクセスできますが、
ここに画像の説明を挿入
ある場合は、また、我々は以下のハッシュアルゴリズムの一貫使用して新しい問題の出現は、ユーザーのセッションを維持するだけでなく、別の1、セッションのほとんどが変更されますので、あなたがTomcatの(ダウン)を失ったときにすることは非常に面倒で
ここに画像の説明を挿入
一貫し性的セッションはどのようにこの問題を解決しますか?ダウンしているユーザーだけがサーバーに接続することが保証されます。他の人のセッションは同じです。
一貫したハッシュアルゴリズムを使用した直線と考えることができ、次の0と2は32の累乗で削減されますアドレスとして、
ここに画像の説明を挿入
それらをリングとして扱います。ノード3がダウンしているときはノードが非常に多いため、他のユーザーはサーバーを変更する必要
ここに画像の説明を挿入
がなく、ノード3に接続しているユーザーのみ影響します。他のユーザーは影響を受けません
ここに画像の説明を挿入

consistent_hash
upstream tomcats {
        consistent_hash $request_uri;

        server 192.168.1.173:8080;
        server 192.168.1.174:8080 down;
        server 192.168.1.175:8080;
}


ハッシュして固定サーバーノードにアクセスした後、各リクエストのURLアドレスに従ってurl_hashとleast_connの負荷分散を行います。(自動)

upstream tomcats {
    # url hash
    hash $request_uri;
    # 最少连接数
    # least_conn

    server 192.168.1.173:8080;
    server 192.168.1.174:8080;
    server 192.168.1.175:8080;
}


server {
    listen 80;
    server_name www.tomcats.com;

    location / {
        proxy_pass  http://tomcats;
    }
}

Nginxキャッシュ
ブラウザーキャッシュ:
ユーザーアクセスの高速化、シングルユーザー(ブラウザーのビジター)のエクスペリエンスの向上、nginx側のローカル
Nginxキャッシュ
キャッシュへのキャッシュ、nginx側
にアクセスするすべてのユーザーの増加、および上流サーバーへのアクセス速度の向上
ユーザーアクセスは引き続きリクエストトラフィックを生成します。
ブラウザのキャッシュを制御します

location /files {
    alias /home/huadaxia;
    # expires 10s;
    # expires @22h30m;
    # expires -1h;
    # expires epoch;
    # expires off;
    expires max;
}

ここに画像の説明を挿入
Nginxリバースプロキシキャッシュ

#keys_zone 设置共享内存以及占用空间大小
#keys_zone 设置共享内存以及占用的空间大小
#max_size 设置缓存大小
#inactive 超过此时间则缓存自动清理
#use_temp_path 关闭零时目录
proxy_cache_path /usr/local/nginx/upsteam_cache keys_zone=mycache:5m max_size=1g inactive=30s use_temp_path=off



location / {
    proxy_pass  http://tomcats;

    # 启用缓存,和keys_zone一致
    proxy_cache mycache;
    # 针对200和304状态码缓存时间为8小时
    proxy_cache_valid   200 304 8h;
}

ここに画像の説明を挿入

Nginxを使用してHTTPSドメイン名証明書を構成します。
前提として、ドメイン名が必要です。そうでない場合は、Alibaba CloudまたはTencent Cloudにアクセスしてドメイン名を申請してください。

  1. SSLモジュールをインストールする
  2. SSLモジュール
    インストールするnginxでhttpsを構成するには、sslモジュール(http_ssl_module)をインストールする必要があります。
    nginxの解凍ディレクトリに移動し
    ます:/home/software/nginx-1.16.1 add ssl module(元のモジュールを保持する必要があります)
./configure \
--prefix=/usr/local/nginx \
--pid-path=/var/run/nginx/nginx.pid \
--lock-path=/var/lock/nginx.lock \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log \
--with-http_gzip_static_module \
--http-client-body-temp-path=/var/temp/nginx/client \
--http-proxy-temp-path=/var/temp/nginx/proxy \
--http-fastcgi-temp-path=/var/temp/nginx/fastcgi \
--http-uwsgi-temp-path=/var/temp/nginx/uwsgi \
--http-scgi-temp-path=/var/temp/nginx/scgi  \
--with-http_ssl_module

コンパイルしてインストールする
make
make install

HTTPS
構成して、SSL証明書* .crtおよび秘密鍵* .keyを/ usr / local / nginx / confディレクトリーにコピーします

私と同じように構成する

server {
listen       443 ssl;
 server_name 你的域名;
root html;
keepalive_timeout 70;
location / {
        root   html;
        index index.html index.htm;
        }
ssl_protocols        TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers         AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
 ssl_certificate     你自己的pem.pem;
 ssl_certificate_key 你自己的key.key;
ssl_session_cache    shared:SSL:10m;
 ssl_session_timeout 10m;
ssl_prefer_server_ciphers on;

}

ここに画像の説明を挿入

役に立ったと思ったら、高く評価してください

8つのオリジナル記事を公開 89のような 30,000以上の訪問

おすすめ

転載: blog.csdn.net/BryantJamesHua/article/details/105553528