Tutoriel Nginx 2 dans Centos7

Dans le tutoriel Centos7 Nginx 2, les journaux existants de
coupe de journaux Nginx
seront stockés dans le fichier access.log, mais au fil du temps, le contenu de ce fichier deviendra de plus en plus, le volume deviendra de plus en plus grand, gênant Le personnel d'exploitation et de maintenance le vérifie, afin que nous puissions couper ce grand fichier journal en plusieurs petits fichiers différents sous forme de journaux. La règle de découpe peut être en unités de jours. S'il y a des centaines de journaux G ou T par jour, vous pouvez Coupez le journal toutes les demi-journées ou toutes les heures au besoin.

1. Créez un fichier exécutable shell: cut_my_log.sh, le contenu est:

#!/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. Ajoutez des autorisations exécutables pour cut_my_log.sh:

chmod +x cut_my_log.sh

3. Le résultat après la coupe du journal de test:

./cut_my_log.sh

Nginx log coupe-synchronisation
1. Installez les tâches de synchronisation:

yum -y install crontabs

2. crontab -e éditez et ajoutez une nouvelle ligne de tâches:

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

3. Redémarrez la tâche planifiée:
redémarrage du service crond

Pièce jointe: Commandes de tâches planifiées courantes:
service crond start // Démarrer service
service crond stop // Fermer service
service crond restart // Redémarrer service
service crond reload // Recharger la configuration
crontab -e // Modifier la tâche
crontab -l // Afficher Liste des tâches

Expression de tâche régulière: l'expression
Cron est divisée en 5 ou 6 champs, chaque champ représente une signification, comme indiqué ci-dessous:

Partage de temps, jour, mois et semaine (facultatif)
Plage de valeurs 0-59 0-23 1-31 1-12 1-7 2019/2020/2021 /…

Exécution toutes les minutes:
* / 1 * * * *
Exécution tous les matins (23h59 tous les soirs):
59 23 * * * Exécution tous les jours à
01h00:
0 1 * * *

Chapitre Q & A notes matériaux
Donc, avec tant de configurations, jetons un coup d'œil aux règles de configuration de l'emplacement

root et alias
Si le chemin du serveur est: /home/huadaxia/files/img/face.png Le
chemin root correspond exactement à la
configuration d' accès quand il est:

location /huadaxia {
    root /home
}

Lorsque l'utilisateur visite, la demande est: url: port / huadaxia / files / img / face.png

l'alias peut créer un alias pour votre chemin, transparent pour les utilisateurs

location /hello {
    alias /home/huadaxia 
}

Lorsque l'utilisateur visite, la demande est: url: port / hello / files / img / face.png

Règles de correspondance pour l'
espace de localisation : correspondance par défaut, correspondance normale

location / {
     root /home;
}

=:
Correspondance exacte (c'est-à-dire dans /home/huadaxia/img/face1.png) les personnes en dehors de cette image peuvent accéder

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

~ *: Match expression régulière, insensible à la casse, qui est tout / home suivant suffixe image GIF | jpg | png | accès JPEG peuvent
# conformes à l'exposition d'image

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

~: Correspond à l'expression régulière, la casse
#GIF doit être mise en majuscule pour correspondre

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

^ ~: Commencez par un chemin de caractère

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

Prise
en charge de la configuration inter-domaines Nginx Dans notre projet Springboot, l'accès inter-domaines est également possible, j'ai donc utilisé les modes de séparation frontaux et principaux les plus courants, et j'utilise principalement Nginx pour configurer la séparation inter-domaines. C'est le courant dominant.
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' *;

La configuration de la chaîne antivol Nginx, la chaîne antivol est d'empêcher les autres de voler vos photos et autres ressources statiques
. Il existe de nombreuses façons d'empêcher
1: filigrane, promotion de la marque, votre bande passante, suffisamment de serveur
2: pare-feu, contrôle direct, à condition que vous connaissiez la source IP
3: Stratégie de chaîne antivol La méthode suivante consiste à donner directement une invite d'erreur 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;
            }

amont: équilibrage de charge
Par défaut, le
paramètre de commande amont max_conns est envoyé par polling

Un processus de travail est défini, ce qui est pratique pour tester et observer le nombre de connexions réussies

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;
}

Le paramètre de commande en amont slow_start
version commerciale, besoin de payer

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;
}

Remarque
Ce paramètre ne peut pas être utilisé dans le hachage et l'équilibrage de charge aléatoire.
S'il n'y a qu'un seul serveur en amont, ce paramètre n'est pas valide.
Chapitre Q & A notes Les
paramètres de commande amont down et backup
#down sont utilisés pour marquer le nœud de service comme indisponible:

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;
}

La sauvegarde indique que le nœud de serveur actuel est une machine de sauvegarde. Ce n'est qu'après l'arrêt de tous les autres serveurs qu'ils rejoindront le cluster et seront accessibles aux utilisateurs:

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;
}

Le paramètre de sauvegarde ne peut pas être utilisé dans le hachage et l'équilibrage de charge aléatoire.

Les paramètres de commande en amont max_fails et fail_timeout lorsque l'
utilisateur accède à la demande sont: url: port / huadaxia / files / img / face.pngmax_fails: indique que le serveur a échoué plusieurs fois, puis le marquer comme arrêté et supprimer le service en amont.
fail_timeout: indique le temps de nouvelle tentative ayant échoué.
Supposons que les paramètres actuels soient les suivants:

max_fails = 2 fail_timeout = 15s

Cela signifie qu'après avoir échoué à demander un serveur 2 fois en 15 secondes, il est considéré que le serveur a été suspendu ou arrêté, puis 15 secondes plus tard, aucune nouvelle demande n'atteindra le nœud qui vient de se bloquer en 15 secondes. Au lieu de cela, il demandera un serveur normal. Après 15 secondes, il y aura une nouvelle demande pour essayer de se connecter au serveur bloqué. S'il échoue toujours, répétez le processus précédent jusqu'à ce qu'il soit restauré.

Keepalived améliore le débit
keepalived: définit le nombre de traitements de connexion longs
proxy_http_version: définit la version http de connexion longue sur 1.1
proxy_set_header: efface les informations d'en-tête de connexion

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 "";
        }
    }

Équilibrage de charge ip_hash
ip_hash peut garantir que les utilisateurs accèdent à des serveurs fixes qui peuvent être demandés aux services en amont, à condition que l'adresse IP de l'utilisateur n'ait pas changé.
Points à noter lors de l'utilisation de ip_hash:
Vous ne pouvez pas supprimer directement le serveur principal, vous pouvez uniquement marquer vers le bas.

upstream tomcats {
        ip_hash;

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

Ce qui suit ne compte que les trois premiers chiffres. Par exemple, si votre adresse IP est 192.168.1. *, Alors l'algorithme iphash prend par défaut les trois premiers chiffres, donc si vous êtes sur l'intranet, un seul vous donnera accès,

mais s'il y en a, C'est également très gênant, c'est-à-dire que lorsque vous perdez un tomcat (temps d'arrêt), il y a un nouveau problème. La session de l'utilisateur doit être enregistrée et une autre, la plupart de la session va changer, nous devons donc utiliser l'algorithme de hachage de cohérence suivant pour être

cohérent Comment la session sexuelle résout-elle ce problème? Il est garanti que seul l'utilisateur qui est en panne se connectera au serveur. La session des autres personnes est la même.
Vous pouvez la considérer comme une ligne droite avec l'algorithme de hachage cohérent, et les 0 et 2 suivants sont réduits par la puissance de 32 En tant qu'adresse,

traitez-les comme un anneau, et il y a tellement de nœuds lorsque le nœud 3 est en panne, donc les autres utilisateurs n'ont pas besoin de changer de serveur,

n'affectent que les utilisateurs connectés au nœud 3, les autres utilisateurs ne sont pas affectés

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;
}

Équilibrage de charge url_hash et less_conn en
fonction de l'adresse URL de chaque demande, après hachage pour visiter un nœud de serveur fixe. (Automatique)

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;
    }
}

Cache Nginx Cache du
navigateur:
accélérez l'accès des utilisateurs, améliorez l'expérience d'un seul utilisateur (visiteur du navigateur), cachez dans le
cache Nginx cache local
du côté nginx, augmentez tous les utilisateurs qui visitent le côté nginx et augmentez
la vitesse d'accès au serveur en amont
L'accès des utilisateurs générera toujours le trafic des demandes.
Contrôlez le cache du navigateur:

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

Cache proxy inverse 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;
}

Utilisez Nginx pour configurer le certificat de nom de domaine HTTPS.
Le principe est que vous devez avoir un nom de domaine. Sinon, accédez à Alibaba Cloud ou Tencent Cloud pour en demander un.

1. Installer le module SSL
2. Installer le module SSL
   Pour configurer https dans nginx, vous devez installer le module ssl, qui est: http_ssl_module.
   Accédez au répertoire de décompression de nginx: /home/software/nginx-1.16.1
   add module ssl (les modules d'origine doivent être conservés)

./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

Compiler et installer
make
make install

Configurez HTTPS
pour copier le certificat ssl * .crt et la clé privée * .key dans le répertoire / usr / local / nginx / conf

Configurer comme je le fais

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;

}

Si vous le trouvez utile, veuillez me donner un coup de pouce