Déployer des projets front-end avec nginx

Auparavant, le déploiement de projets front-end consistait à placer des ressources statiques dans le projet back-end et à les déployer avec le déploiement back-end. Avec la popularité des modèles de développement de séparation front-end et back-end, les projets front-end peuvent être déployés séparément, et actuellement le moyen le plus populaire est le déploiement nginx.

Pour les projets front-end, nginxil existe deux fonctions principales :

Héberger des ressources statiques, c'est-à-dire servir de serveur de ressources statiques ;
Faire un proxy inverse pour les ressources dynamiques, c'est-à-dire des services d'interface d'arrière-plan proxy pour empêcher les inter-domaines ;

configuration du routage

La configuration la plus courante nginxest la configuration de routage, et il existe plusieurs façons d'écrire la configuration de routage.

1.=

location = /111/ {
    
    
    default_type text/plain;
    return 200 "111 success";
}

locationUn est ajouté entre et le path =, ce qui signifie une correspondance exacte, c'est-à-dire que seul le même exactement urlcorrespondra à cet itinéraire.

Ajouté après le path aa, ce n'est pas une correspondance exacte, donc c'est le cas 404.

2. sans =

Représente la correspondance selon le préfixe, suivi de n'importe quel chemin

location /222 {
    
    
    default_type text/plain;
    // 这里的 $uri 是取当前路径。
    return 200 $uri;
}

3. Prise en charge de la correspondance régulière~

// 匹配以/333/bbb开头，以.html结尾的路径
location ~ ^/333/bbb.*\.html$ {
    
    
    default_type text/plain;
    return 200 $uri;
}

Ce qui précède ~est sensible à la casse, sinon la casse est sensible.~\*

// 匹配以/333/bbb开头，以.html结尾的路径
location ~* ^/333/bbb.*\.html$ {
    
    
    default_type text/plain;
    return 200 $uri;
}

4. ^~Représenter la priorité

La configuration ci-dessous comporte deux chemins qui /444commencent par :

location ~* ^/444/AAA.*\.html$ {
    
    
    default_type text/plain;
    return 200 $uri;
}
location ~ /444/ {
    
    
    default_type text/plain;
    return 200 $uri;
}

Si on y accède /444/AAA45.html, il atteindra directement le premier itinéraire. /444/Que se passe-t-il si je veux l'atteindre ? Ajoutez-le simplement ^.

location ^~ /444/ {
    
    
    default_type text/plain;
    return 200 $uri;
}

Autrement dit, ^~la priorité de la correspondance des préfixes peut être augmentée.

Pour résumer, locationil existe quatre types de syntaxe :

location = /aaaest /aaaun itinéraire qui correspond exactement ;
location /bbbest /bbbun itinéraire qui correspond au préfixe.
location ~ /ccc.*.htmlC'est une correspondance normale, vous pouvez ajouter un *pour indiquer qu'il n'est pas sensible à la casse location ~* /ccc.*.html;
location ^~ /dddest une correspondance de préfixe, mais avec une priorité plus élevée.

La priorité de ces 4 syntaxes est la suivante :

Correspondance exacte (=) > correspondance de préfixe de haute priorité (^~) > correspondance régulière (~ / ~*) > correspondance de préfixe commune

racine et alias

nginxIl existe deux manières de spécifier le chemin du fichier rootet la principale différence réside dans la manière d'interpréter cette dernière , ce qui amènera aliasles deux à mapper les requêtes aux fichiers du serveur de différentes manières root.aliasnginxlocationuri

rootLe résultat du traitement est : rootchemin + locationchemin ;
aliasLe résultat du traitement est le suivant : aliasremplacez le chemin par locationle chemin ;

aliasest la définition d'un alias de répertoire rootet est la définition du répertoire de niveau supérieur.

A noter que la fin aliasdoit être utilisée plus tard /, sinon le fichier ne sera pas trouvé, et rootil est inutile. De plus, aliasuniquement locationen blocs.

rootExemple:

location ^~ /test/ {
    
    
    root /www/root/html/;
}

Si un uri demandé est /test/a.html, le serveur Web renverra /www/root/html/test/a.htmlle fichier sur le serveur.

aliasExemple:

location ^~ /test/ {
    
    
    alias /www/root/html/new_test/;
}

Si un uri demandé est /test/a.html, le serveur Web renverra /www/root/html/new_test/a.htmlle fichier sur le serveur.

Notez qu'ici new_test, étant donné que le chemin configuré ultérieurement aliassera locationignoré, le répertoire actuellement correspondant pointera vers le répertoire spécifié.

Répertoire secondaire

Parfois, il est nécessaire de déployer plusieurs projets sous un seul port, celui-ci peut alors être déployé sous la forme d'un répertoire secondaire.

Il y aura quelques pièges lors de l'utilisation du répertoire secondaire pour déployer. Par exemple, lorsque je demande http://xxxxxxxx.com/views/basedata, le navigateur y accède automatiquement http://xxxxxxxxm:8100/store/views/basedata/.

Quelle est la raison?

Le problème le plus fondamental est que la redirection est déclenchée car il n'y a http://xxxxxxxx.com/views/basedatapas de suivi et que la redirection est redirigée vers , évitez donc simplement de déclencher la redirection./nginx301http://xxxxxxxxm:8100/store/views/basedata/

Si vous pouvez supporter d’utiliser directement http://xxxxxxxxm:8100/store/views/basedata/la dernière /adresse comme celle-ci, alors il n’y a pas de problème.

Alors pourquoi la redirection est-elle déclenchée ?

Lorsque l'utilisateur le demande , il s'agit http.xxxxxx.cn/ospici d' essayer de retrouver ce fichier dans le répertoire spécifié par ou .$uri/ospnginxaliasroot

S'il existe un fichier{alias指定目录}/osp nommé , notez qu'il s'agit d' un fichier et non d'un répertoire et que le contenu de ce fichier sera envoyé directement à l'utilisateur.

Évidemment, il n'y a pas ospde fichier nommé dans le répertoire, j'en ai donc vérifié osp/et ajouté un /, c'est-à-dire pour voir s'il existe un {alias指定目录}/osp/répertoire nommé .

Autrement dit, lorsque nous accédons à l'uri, si la ressource d'accès est un répertoire et que l'uri ne se /termine pas par une barre oblique, nginxle service renverra un saut 301 et l'adresse cible doit être ajoutée avec une barre oblique/ .

L'un des moyens les plus simples consiste à accéder directement à un fichier spécifique, par exemple http.xxxxxx.cn/osp/index.html, afin qu'aucune redirection ne se produise. Cependant, cette méthode n’est pas assez élégante et le chemin complet du fichier doit être saisi à chaque fois.

Une autre façon consiste à ajuster nginxla configuration de la redirection dans , nginxtrois configurations en redirection : absolute_redirect, server_name_in_redirect, port_in_redirect.

absolute_redirectUtilisez cette commande pour contrôler nginxsi l'adresse de redirection émise par est une adresse relative ou une adresse absolue :

1. S'il est défini sur off, nginxla redirection émise par sera relative 没有域名和端口et il n'y aura rien à voir server_name_in_redirectavec port_in_redirectcela.

Après avoir ajouté cette configuration, même si une redirection se produira également, elle ne sera pas ajoutée au chemin 域名和端口.

2. S'il est défini sur on, nginxla redirection émise par sera absolue, seuls les paramètres absolute_redirectde on, server_name_in_redirectet port_in_redirectauront un effet.

`nginx`Activer `gzip`la compression statique pour améliorer l’efficacité

gzipC'est un format, et c'est aussi un outil de décompression sous Linux. Après avoir compressé gziple app.jsfichier, le fichier original devient un .gzfichier se terminant par , et la taille du fichier est réduite de 42571 à 11862.

Actuellement, il existe deux formes de compression de ressources statiques :

Compression dynamique : avant que le serveur ne renvoie des fichiers statiques, chaque requête est compressée par le serveur pour la sortie.
Compression statique : Le serveur utilise directement les fichiers pré-compressés prêts à l'emploi avec l'extension .gz pour sortir directement.

Nous savons gzipque cela CPUdemande beaucoup de ressources et que la compression dynamique en temps réel consomme plus de ressources CPU. Pour améliorer encore les performances de nginx, nous pouvons utiliser la compression gzip statique pour compresser les fichiers à compresser à l'avance et envoyer les fichiers compressés directement lorsque la demande arrive, réduisant ainsi la pression sur le processeur du serveur et améliorant les performances .gz.

Par conséquent, nous utilisons généralement la compression statique , et il y a deux étapes pour obtenir une compression statique :

1. Générez un fichier compressé gzip

Lors de l'utilisation webpackdu packaging, nous compressons le fichier et le configurons comme suit :

const isProduction = process.env.NODE_ENV === 'production'

if (isProduction) {
    
    
  config.plugins.push(
    new CompressionWebpackPlugin({
    
    
      // 采用gzip进行压缩
      algorithm: 'gzip',
      test: /\.js$|\.html$|\.json$|\.css/,
      threshold: 10240
    })
  )
}

On peut voir qu'un autre .gzfichier se terminant par .gz.

2. Activer les modules prenant en charge la compression statique dans nginx

nginxAjoutez la configuration suivante à la configuration :

gzip_static on;

S'il n'est pas ajouté, il ne sera pas trouvé lors de l'accès et une erreur 404 sera signalée, car le serveur ne dispose que .gzdu fichier et n'a pas le fichier d'origine.

Résumer

La configuration principale du déploiement du projet front-end nginxest essentiellement celle mentionnée ci-dessus.

La première concerne locationles quatre façons d’écrire le routage ;

Il y a alors une distinction claire entre rootet alias;

Lorsque vous devez utiliser le routage secondaire lorsqu'il y a de nombreux projets, vous devez faire attention à la configuration de la redirection ;

Si le fichier de votre projet est volumineux, vous pouvez activer gzipla compression pour améliorer l'efficacité de la transmission.