NGINX en tant que serveur Web

Configuration de NGINX en tant que serveur Web

Publicité
Advertisements
(Last Updated On: 23 septembre 2021)

Comment configurer NGINX

Cet article explique comment configurer NGINX Open Source  en tant que serveur Web et comprend les sections suivantes:

  • Configuration des serveurs virtuels
  • Configurer les emplacements (location)
  • Priorité de l’emplacement
  • Utilisation de variables
  • Retour des codes d’état spécifiques
  • Réécriture des URI dans les requêtes
  • Réécriture des réponses HTTP
  • Traitement des erreurs

Pour plus d’informations sur la façon de régler NGINX Plus et NGINX Open Source, regardez notre webinaire gratuit à la demande sur l’ installation et le réglage de NGINX .

Remarque: les informations contenues dans cet article s’appliquent à la fois à NGINX Open Source et NGINX Plus. Pour faciliter la lecture, le reste de l’article se réfère uniquement à NGINX Plus.

À un niveau élevé, la configuration de NGINX Plus en tant que serveur Web consiste à définir les URL qu’il gère et la manière dont il traite les requêtes HTTP pour les ressources à ces URL. À un niveau inférieur, la configuration définit un ensemble de serveurs virtuels qui contrôlent le traitement des demandes pour des domaines ou des adresses IP particuliers. Pour plus d’informations sur les fichiers de configuration, consultez Création de fichiers de configuration NGINX Plus .

Chaque serveur virtuel pour le trafic HTTP définit des instances de configuration spéciales appelées emplacements qui contrôlent le traitement d’ensembles spécifiques d’URI. Chaque emplacement définit son propre scénario de ce qu’il advient des demandes qui sont mappées à cet emplacement. NGINX Plus offre un contrôle total sur ce processus. Chaque emplacement peut proxy la demande ou renvoyer un fichier. De plus, l’URI peut être modifié, de sorte que la demande soit redirigée vers un autre emplacement ou serveur virtuel. En outre, un code d’erreur spécifique peut être renvoyé et vous pouvez configurer une page spécifique pour qu’elle corresponde à chaque code d’erreur.

Configuration des serveurs virtuels

Le fichier de configuration NGINX Plus doit inclure au moins une directive server pour définir un serveur virtuel. Lorsque NGINX Plus traite une demande, il sélectionne d’abord le serveur virtuel qui servira la demande.

Un serveur virtuel est défini par une directive server dans le contexte http, par exemple:

http { 
     serveur { 
           # Configuration du serveur 
     } 
}

Il est possible d’ajouter plusieurs directives server dans le contexte http pour définir plusieurs serveurs virtuels.

Le bloc server de configuration comprend généralement une directivelisten pour spécifier l’adresse IP et le port (ou le socket et le chemin du domaine Unix) sur lesquels le serveur écoute les requêtes. Les adresses IPv4 et IPv6 sont acceptées; mettez les adresses IPv6 entre crochets.

L’exemple ci-dessous montre la configuration d’un serveur qui écoute sur l’adresse IP 127.0.0.1 et le port 8080:

serveur { 
       listen  127.0.0.1 : 8080 ; 
       # Configuration supplémentaire de serveur  
}

Si un port est omis, le port standard est utilisé. De même, si une adresse est omise, le serveur écoute sur toutes les adresses. Si la directive listen n’est pas du tout incluse, le port «standard» est 80/tcpet le port «par défaut» l’est 8000/tcp, selon les privilèges du superutilisateur.

S’il y a plusieurs serveurs qui correspondent à l’adresse IP et au port de la demande, NGINX Plus teste le Hostchamp d’en-tête de la demande par rapport aux directives server_name  dans les blocs server. Le paramètre à server_name peut être un nom complet (exact), un caractère générique ou une expression régulière. Un caractère générique est une chaîne de caractères qui comprend l’astérisque ( *) à son début, à sa fin ou les deux; l’astérisque correspond à n’importe quelle séquence de caractères. NGINX Plus utilise la syntaxe Perl pour les expressions régulières; les précéder du tilde ( ~). Cet exemple illustre un nom exact.

serveur  { 
    listen       80 ; 
    name_server  example.org  www.example.org ; 
    # ... 
}

Si plusieurs noms correspondent à l’en-tête  Host, NGINX Plus en sélectionne un en recherchant les noms dans l’ordre suivant et en utilisant la première correspondance trouvée:

  1. Nom exact
  2. Le plus long caractère générique commençant par un astérisque, tel que *.example.org
  3. Le plus long caractère générique se terminant par un astérisque, tel que mail.*
  4. Première expression régulière correspondante (par ordre d’apparition dans le fichier de configuration)

Si le champ Host d’en-tête ne correspond pas à un nom de serveur, NGINX Plus achemine la demande vers le serveur par défaut pour le port sur lequel la demande est arrivée. Le serveur par défaut est le premier répertorié dans le fichier nginx.conf , sauf si vous incluez le paramètre default_server dans la directive listen pour désigner explicitement un serveur comme serveur par défaut.

server  { 
    listen  80  default_server ; 
    # ... 
}

Configurer les emplacements

NGINX Plus peut envoyer du trafic à différents proxys ou servir différents fichiers en fonction des URI de la demande. Ces blocs sont définis à l’aide de la directivelocation placée dans une directive server.

Par exemple, vous pouvez définir trois blocs location pour indiquer au serveur virtuel d’envoyer des demandes à un serveur mandaté, d’envoyer d’autres demandes à un autre serveur mandaté et de traiter le reste des demandes en livrant des fichiers à partir du système de fichiers local.

Les tests NGINX Plus demandent des URI par rapport aux paramètres de toutes les locationdirectives et appliquent les directives définies dans l’emplacement correspondant. À l’intérieur de chaque bloc location, il est généralement possible (à quelques exceptions près) de placer encore plus de directiveslocation pour affiner davantage le traitement de groupes de requêtes spécifiques.

Remarque: Dans ce guide, le mot emplacement fait référence à un seul contexte location

Il existe deux types de paramètres pour la directive location: les chaînes de préfixes (chemins) et les expressions régulières. Pour qu’un URI de demande corresponde à une chaîne de préfixe, il doit commencer par la chaîne de préfixe.

L’exemple d’emplacement suivant avec un paramètre de chemin correspond aux URI de demande commençant par / some / path / , tels que /some/path/document.html . (Il ne correspond pas à / my-site /some/path car /some /path ne se produit pas au début de cet URI.)

location  /certains/chemin/  { 
    # ... 
}

Une expression régulière est précédée du tilde ( ~) pour la correspondance sensible à la casse, ou du tilde-astérisque ( ~*) pour la correspondance insensible à la casse. L’exemple suivant correspond aux URI qui incluent la chaîne .html ou .htm à n’importe quelle position.

Priorité d’emplacement NGINX

Pour trouver l’emplacement qui correspond le mieux à un URI, NGINX Plus compare d’abord l’URI aux emplacements avec une chaîne de préfixe. Il recherche ensuite les emplacements avec une expression régulière.

Une priorité plus élevée est donnée aux expressions régulières, sauf si le ^~modificateur est utilisé. Parmi les chaînes de préfixes, NGINX Plus sélectionne la plus spécifique (c’est-à-dire la chaîne la plus longue et la plus complète). La logique exacte de sélection d’un emplacement pour traiter une demande est donnée ci-dessous:

  1. Testez l’URI par rapport à toutes les chaînes de préfixe.
  2. Le =modificateur (signe égal) définit une correspondance exacte de l’URI et d’une chaîne de préfixe. Si la correspondance exacte est trouvée, la recherche s’arrête.
  3. Si le ^~modificateur (caret-tilde) ajoute la plus longue chaîne de préfixe correspondante, les expressions régulières ne sont pas vérifiées.
  4. Stockez la chaîne de préfixe correspondante la plus longue.
  5. Testez l’URI par rapport aux expressions régulières.
  6. Arrêtez le traitement lorsque la première expression régulière correspondante est trouvée et utilisez l’emplacement correspondant.
  7. Si aucune expression régulière ne correspond, utilisez l’emplacement correspondant à la chaîne de préfixe stockée.

Un cas d’utilisation typique du =modificateur est les demandes de / (barre oblique). Si les demandes de / sont fréquentes, la spécification comme paramètre de la directive accélère le traitement, car la recherche de correspondances s’arrête après la première comparaisonlocation = /

location  =  /  { 
    # ... 
}

Un locationcontexte peut contenir des directives qui définissent comment résoudre une demande – soit servir un fichier statique, soit transmettre la demande à un serveur mandaté. Dans l’exemple suivant, les demandes qui correspondent au premier locationcontexte reçoivent des fichiers du répertoire / data et les demandes qui correspondent au second sont transmises au serveur mandaté qui héberge le contenu du domaine www.example.com

.

serveur  { 
    location /images/  { 
        root  /données ; 
    }

    location  /  { 
        proxy_pass  http://www.example.com ; 
    } 
}

La rootdirective spécifie le chemin du système de fichiers dans lequel rechercher les fichiers statiques à servir. L’URI de demande associé à l’emplacement est ajouté au chemin pour obtenir le nom complet du fichier statique à servir. Dans l’exemple ci-dessus, en réponse à une demande de /images/example.png , NGINX Plus délivre le fichier /data/images/example.png .

La directive proxy_pass transmet la demande au serveur proxy accessible avec l’URL configurée. La réponse du serveur mandaté est ensuite renvoyée au client. Dans l’exemple ci-dessus, toutes les demandes avec des URI qui ne commencent pas par /images/ sont transmises au serveur mandaté.

Utilisation de variables

Vous pouvez utiliser des variables dans le fichier de configuration pour que NGINX Plus traite les demandes différemment selon les circonstances définies. Les variables sont des valeurs nommées qui sont calculées lors de l’exécution et sont utilisées comme paramètres de directives. Une variable est indiquée par le signe \ (\) (dollar) au début de son nom. Les variables définissent des informations basées sur l’état de NGINX, telles que les propriétés de la demande en cours de traitement.

Il y a un certain nombre de variables prédéfinies, telles que les HTTP principales variables et vous pouvez définir des variables personnalisées à l’ aide des directives  set, mapet des geo. La plupart des variables sont calculées au moment de l’exécution et contiennent des informations liées à une demande spécifique. Par exemple, $remote_addrcontient l’adresse IP du client et $uricontient la valeur URI actuelle.

Retour des codes d’état spécifiques

Certains URI de sites Web nécessitent le retour immédiat d’une réponse avec une erreur spécifique ou un code de redirection, par exemple lorsqu’une page a été déplacée temporairement ou définitivement. Le moyen le plus simple de le faire est d’utiliser la directive return. Par example:

location  /faux/url  { 
    return  404 ; 
}

Le premier paramètre de returnest un code de réponse. Le second paramètre peut être l’URL d’une redirection (pour les codes 301, 302, 303, et 307) ou le texte pour revenir dans le corps de la réponse. Par example:

location  /définitivement/déplacé/url  { 
    return  301  http://www.example.com/déplacé/ici ; 
}

La directive return peut être incluse dans les contextes locationet server.

Réécriture des URI dans les requêtes

Un URI de demande peut être modifié plusieurs fois pendant le traitement de la demande grâce à l’utilisation de la directive rewrite, qui a un paramètre facultatif et deux paramètres obligatoires. Le premier paramètre (obligatoire) est l’expression régulière à laquelle l’URI de la demande doit correspondre. Le deuxième paramètre est l’URI à remplacer par l’URI correspondant. Le troisième paramètre facultatif est un indicateur qui peut interrompre le traitement d’autres rewritedirectives ou envoyer une redirection (code 301ou 302). Par example:

location  /users/  { 
    rewrite  ^ /users/(.*)$ /show?user=$1  break ; 
}

Comme le montre cet exemple, le deuxième paramètre userscapture via la mise en correspondance d’expressions régulières.

Vous pouvez inclure plusieurs directives rewrite dans les contextes serveret location. NGINX Plus exécute les directives une par une dans leur ordre d’apparition. Les directives rewrite dans un contexte server sont exécutées une fois lorsque ce contexte est sélectionné.

Une fois que NGINX a traité un ensemble d’instructions de réécriture, il sélectionne un contexte location en fonction du nouvel URI. Si l’emplacement sélectionné contient des directives rewrite, elles sont exécutées à leur tour. Si l’URI correspond à l’un de ceux-ci, une recherche du nouvel emplacement démarre après le traitement rewrite de toutes les directives définies .

L’exemple suivant montre des directives rewrite en combinaison avec une directive return.

server {
    #...
    rewrite ^(/download/.*)/media/(\w+)\.?.*$ $1/mp3/$2.mp3 last;
    rewrite ^(/download/.*)/audio/(\w+)\.?.*$ $1/mp3/$2.ra  last;
    return  403;
    #...
}

Cet exemple de configuration fait la distinction entre deux ensembles d’URI. Les URI tels que /download/some/media/file sont modifiés en /download/some/mp3/file.mp3 . En raison de l’indicateur last, les directives suivantes (la deuxième rewriteet la directivereturn) sont ignorées mais NGINX Plus continue de traiter la requête, qui a maintenant un URI différent. De même, les URI tels que / download / some / audio / file sont remplacés par /download/some/mp3/file.ra . Si un URI ne correspond à aucune rewritedirective, NGINX Plus renvoie le 403code d’erreur au client.

Deux paramètres interrompent le traitement des rewritedirectives:

  • last– Arrête l’exécution des directive rewrite dans le contexte actuel serverou location, mais NGINX Plus recherche les emplacements qui correspondent à l’URI réécrit, et toutes les directive rewrite du nouvel emplacement sont appliquées (ce qui signifie que l’URI peut être à nouveau modifiée).
  • break– Comme la directive break, arrête le traitement des directive rewrite dans le contexte actuel et annule la recherche d’emplacements qui correspondent au nouvel URI. Les directives rewrite du nouvel emplacement ne sont pas exécutées.

Réécriture des réponses HTTP

Parfois, vous devez rewrite ou modifier le contenu d’une réponse HTTP, en remplaçant une chaîne par une autre. Vous pouvez utiliser la directive sub_filter pour définir la réécriture à appliquer. La directive prend en charge les variables et les chaînes de substitutions, ce qui rend possible des modifications plus complexes.

Par exemple, vous pouvez modifier les liens absolus qui font référence à un serveur autre que le proxy:

location / {
    sub_filter      /blog/ /blog-staging/;
    sub_filter_once off;
}

Un autre exemple modifie le schéma de http://à https://et remplace l’ localhostadresse par le nom d’hôte du champ d’en-tête de la demande. La directive sub_filter_once indique à NGINX d’appliquer les directives sub_filter consécutivement dans un emplacement:

location / {
    sub_filter     'href="http://127.0.0.1:8080/'%20%20%20%20<span%20class="s">'href="https://<span%20class="nv">$host/';
    sub_filter     'img src="http://127.0.0.1:8080/'%20<span%20class="s">'img src="https://<span%20class="nv">$host/';
    sub_filter_once on;
}

Notez que la partie de la réponse déjà modifiée par le sub_filtern’est pas remplacée à nouveau si une autre sub_filtercorrespondance se produit.

Traitement des erreurs

Avec la directive error_page, vous pouvez configurer NGINX Plus pour renvoyer une page personnalisée avec un code d’erreur, remplacer un code d’erreur différent dans la réponse ou rediriger le navigateur vers un autre URI. Dans l’exemple suivant, la directive error_page spécifie la page ( /404.html ) à renvoyer avec le 404code d’erreur.

error_page  404  /404.html ;

Notez que cette directive ne signifie pas que l’erreur est renvoyée immédiatement (la directive return le fait), mais spécifie simplement comment traiter les erreurs lorsqu’elles se produisent. Le code d’erreur peut provenir d’un serveur mandaté ou se produire lors du traitement par NGINX Plus (par exemple, les 404résultats lorsque NGINX Plus ne trouve pas le fichier demandé par le client).

Dans l’exemple suivant, lorsque NGINX Plus ne parvient pas à trouver une page, il remplace le code 301par du code 404et redirige le client vers http: /example.com/new/path.html . Cette configuration est utile lorsque les clients essaient toujours d’accéder à une page à son ancien URI. Le 301code informe le navigateur que la page a été déplacée de façon permanente et qu’il doit remplacer l’ancienne adresse par la nouvelle automatiquement lors du retour.

location /old/path.html {
    error_page 404 =301 http:/example.com/new/path.html;
}

La configuration suivante est un exemple de transmission d’une requête au back-end lorsqu’un fichier est introuvable. Étant donné qu’aucun code d’état n’est spécifié après le signe égal dans la directive error_page, la réponse au client a le code d’état renvoyé par le serveur mandaté (pas nécessairement 404).

server {
    ...
    location /images/ {
        # Set the root directory to search for the file
        root /data/www;

        # Disable logging of errors related to file existence
        open_file_cache_errors off;

        # Make an internal redirect if the file is not found
        error_page 404 = /fetch$uri;
    }

    location /fetch/ {
        proxy_pass http://backend/;
    }
}

La directive error_page demande à NGINX Plus d’effectuer une redirection interne lorsqu’un fichier n’est pas trouvé. La variable $uri dans le paramètre final de la directive error_page contient l’URI de la requête actuelle, qui est transmise dans la redirection.

Par exemple, si /images/some/file n’est pas trouvé, il est remplacé par /fetch/images/some/file et une nouvelle recherche d’un emplacement démarre. En conséquence, la requête se termine dans le second contexte location et est envoyée par proxy à http://backend/ .

La directive  open_file_cache_errors empêche d’écrire un message d’erreur si un fichier n’est pas trouvé. Ce n’est pas nécessaire ici car les fichiers manquants sont correctement traités.

Références: Original doc : (en) version https://docs.nginx.com/nginx/admin-guide/web-server/


Merci de votez pour cet article :
Votez : Pas malMoyenBienAcès bienExcélent (1 votes, average: 4,00 out of 5)
Loading...

Une réflexion sur « Configuration de NGINX en tant que serveur Web »

Laisser un commentaire

Translate »