Documentation du Dr FRAPPE

Ce wiki regroupe les résultats de mes expériences en informatique accumulés au cours de mes recherches sur le net.
Dans la mesure du possible, j'ai cité mes sources ; il en manque certainement…
Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>Logiciel}}

====== Nginx : le serveur Web hautes performances (LEMP) ======

===== Introduction =====

Nginx (« engine X ») est un serveur Web, similaire à Apache, qui peut être utilisé :
  * comme serveur web autonome
  * ou comme proxy pour réduire la charge de serveurs HTTP ou de courrier électronique en arrière-plan.

Le paquet a trois versions :
  * nginx-full (par défaut), avec l’ensemble de modules standard sauf ceux qui sont dans nginx-extra
  * nginx-light
  * et nginx-extras.

Fonctionnement de **nginx** : un processus maître gère plusieurs processus de travail qui font le traitement réel des demandes.

Le fichier de configuration est **/etc/nginx/nginx.conf**.

Voir le guide du débutant : [[tutoriel:internet:nginx:debutant:start]]

===== Pré-requis =====

===== Installation =====

  - Installez le paquet **[[apt>nginx]]** ou en ligne de commande :<cli>...@...:~$ sudo apt install nginx</cli>L'installation a créé les arborescences :<cli prompt='$ '>...@...:~$ tree /var -d
/var
...
└── www
    └── html</cli>et<cli prompt='$ '>...@...:~$ tree /etc/nginx -d
/etc/nginx
├── conf.d
├── modules-available
├── modules-enabled
├── sites-available
├── sites-enabled
└── snippets</cli>
  - **Testez l'installation** (deux possibilités) :
    * en testant l'état du service :<cli prompt='$ '>...@...:~$ sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: en
   Active: active (running) since Mon 2020-10-26 16:22:02 CET; 14min ago
<...>Le statut **active** indique que le service fonctionne correctement.
</cli>
    * ou en ouvrant **[[http://localhost]]** ou [[http://IP_du_serveur]] (par ex. [[http://framboise.local]]), il s'affiche :{{ logiciel:internet:nginx:nginx_01.png |}}
  - **[[tutoriel:internet:serveur:racine:start]]**

<WRAP center round info 60%>

Installez le paquet **[[apt>php-xml]]** ou en ligne de commande :<cli>$ sudo apt install php-xml</cli>

L'utilisateur **$USER** (qui fait partie du groupe **www-data**) a lui aussi accès à ce répertoire.

N'oubliez pas de recharger la page du navigateur pour vider le cache, sinon c'est l'ancienne page qui s'affiche.
</WRAP>

===== Configuration =====

Le fichier de configuration de **nginx** est **/etc/nginx/nginx.conf**.

**Nous n'y toucherons pas** pour ne pas perdre les réglages lors des mises à jour.
<WRAP center round important 60%>
Au lieu de toucher au fichier /etc/nginx/nginx.conf, nous utiliserons certains dossiers :
  * Pour la **configuration**, des fichiers dans le répertoire **/etc/nginx/conf.d**.
  * Pour les **hôtes virtuels**, des fichiers dans le répertoire **/etc/nginx/sites-available** (le fichier default peut servir de modèle)
  * Le dossier **/etc/nginx/sites-enabled** permet de lancer les hôtes virtuels en production
</WRAP>

<WRAP center round info 60%>
Pour en savoir plus sur le fichier de configuration, voir [[logiciel:internet:nginx:nginx.conf:start]]
</WRAP>

==== Configuration de Nginx en serveur Web ====

La configuration de Nginx en serveur Web définit les URL qu'il gère et comment il traite les requêtes HTTP pour ces URL.

=== Gestion d'erreurs ===

La directive **error_page** demande à Nginx de renvoyer une page personnalisée ou un autre URI pour un code d'erreur donné.

Par exemple, pour le code 404 :<code - >
error_page 404 /404.html;
</code>
Autre exemple : si Nginx ne trouve pas une page, il remplace le code 401 par le code 301 et redirige le client vers http:/example.com/new/path.html.

Cette configuration est utile lorsque les clients tentent toujours d'accéder à une page par son ancien URI.

Le code 301 informe le navigateur que la page a été déplacée de façon permanente, et il doit remplacer automatiquement l'ancienne adresse par la nouvelle au retour.
<code - >
location /old/path.html {
    error_page 404 =301 http:/example.com/new/path.html;
}
</code>

Voici un exemple de transmission d'une requête au back end lorsqu'un fichier est introuvable.

Comme 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 proxy (pas nécessairement 404).

<code - /etc/nginx/conf.d/>
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/;
    }
}
</code>
  * **error_page** indique à Nginx 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 en cours, qui est transmise dans la redirection.
  * Par exemple, si /images/some/file n'est pas trouvé, il est remplacé par /fetch/images/some/fil et une nouvelle recherche d'emplacement commence.\\ Par conséquent, la requête se retrouve dans le deuxième contexte d'emplacement et est envoyée par proxy à http: %%http://backend/%%.
  * **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 gérés.

==== Serveur de contenu statique ====

Le fichier de configuration peut inclure plusieurs blocs server se distinguant par les ports sur lesquels ils écoutent et par les noms de serveurs.

=== location ===

Une fois que nginx décide quel serveur traite une requête, il teste l'URI spécifié dans l'en-tête de la requête par rapport aux paramètres des directives location définies dans le bloc server.

Nous allons implémenter un exemple où les fichiers seront servis à partir des répertoires locaux: **/data/www** (qui peut contenir des fichiers HTML) et **/data/images** (contenant des images).

  * Créez le répertoire **/data/www/html** et placez-y un fichier **index.html** avec un contenu textuel quelconque
  * Créez le répertoire **/data/images** et placez-y quelques images.
  * Créez un fichier **maconf.conf** et écrivez un nouveau bloc server :
<code - /etc/nginx/conf.d/maconf.conf>
    server {
        location / {
            root /data/www;
        }

        location /images/ {
            root /data;
        }
    }
</code>

Ce serveur écoute sur le port standard 80 et est accessible sur la machine locale à l'adresse %%http://localhost/%%.

Par exemple, en réponse à la requête %%http://localhost/some/example.html%%, nginx renverra le fichier /data/www/some/example.html.

  * Le bloc **location /** spécifie la racine du site. Pour les requêtes qui correspondent, l'URI sera ajouté au chemin spécifié dans la directive root, c'est-à-dire **/data/www**, pour former le chemin vers le fichier demandé sur le système de fichiers local. Si plusieurs blocs location correspondent, nginx sélectionne celui avec le préfixe le plus long. Le bloc location ci-dessus fournit le préfixe le plus court, de longueur un, et donc, seulement si tous les autres blocs d'emplacement ne parviennent pas à correspondre, c'est ce bloc qui sera utilisé.
  * Pour le second bloc **location /images/**, il y aura correspondance pour les requêtes commençant par /images/. En réponse à des requêtes dont les URI commencent par /images/, le serveur renverra des fichiers du répertoire /data/images. Par exemple, en réponse à la requête http://localhost/images/example.png, nginx renverra le fichier **/data/images/example.png**. Si ce fichier n'existe pas, nginx renverra l'erreur 404. Les demandes avec des URI ne commençant pas par /images/ seront mappées dans le répertoire /data/www.

Pour appliquer la nouvelle configuration,
  * si nginx n'est pas encore démarré, lancez-le :<cli>$ sudo nginx</cli>
  * ou envoyez le signal reload :<cli>$ sudo nginx -s reload</cli>

En cas d'erreur, recherchez la cause dans les fichiers /var/log/nginx/access.log et /var/log/nginx/error.log

=== root ===

La directive **root** spécifie le répertoire racine qui sera utilisé pour rechercher un fichier. Pour obtenir le chemin d'un fichier demandé, Nginx ajoute l'URI de la requête au chemin spécifié par la directive root.

Elle peut être placée à n'importe quel niveau dans les contextes **http**, **server** ou **location**.

Dans l'exemple ci-dessous, la directive **root** est définie pour un serveur virtuel.

Elle s'applique à tous les blocs location où la directive root n'est pas incluse pour redéfinir explicitement la racine :
<code -/etc/nginx/conf.d/maconf.conf >
server {
    root /www/data;

    location / {
    }

    location /images/ {
    }

    location ~ \.(mp3|mp4) {
        root /www/media;
    }
}
</code>

Ici, pour un URI qui commence par **/images/**, Nginx recherche dans le répertoire **/www/data/images/** du système de fichiers.

Mais si l'URI se termine par l'extension **.mp3** ou **.mp4**, Nginx recherche plutôt le fichier dans le répertoire /www/media/ comme défini dans le bloc d'emplacement correspondant.

Si une requête se termine par une barre oblique, Nginx la traite comme une demande de répertoire et essaie de trouver un fichier d'index dans le répertoire.

=== index ===

La directive **index** définit le nom du fichier d'index (par défaut index.html).

Pour continuer avec l'exemple, si l'URI de la requête est **/images/some/path/**,
  * Nginx délivre le fichier /www/data/images/some/path/index.html s'il existe.
  * Si ce n'est pas le cas, Nginx renvoie le code HTTP 404 (non trouvé) par défaut.

Pour configurer Nginx pour qu'il renvoie une liste de répertoires générée automatiquement, incluez le paramètre **on** dans la directive **autoindex** :
<code - >
location /images/ {
    autoindex on;
}
</code>

Vous pouvez lister plus d'un nom de fichier dans la directive index. Nginx recherche les fichiers dans l'ordre spécifié et renvoie le premier qu'il trouve :
<code - >
location / {
    index index.htm index.html;
}
</code>

Pour retourner le fichier d'index, Nginx vérifie son existence puis effectue une redirection interne vers l'URI obtenue en ajoutant le nom du fichier d'index à l'URI de base.

La redirection interne entraîne une nouvelle recherche d'un emplacement et peut aboutir à un autre emplacement, comme dans l'exemple suivant :

<code - >
location / {
    root /data;
    index index.html index.php;
}

location ~ \.php {
    fastcgi_pass localhost:8000;
    ...
}
</code>

Si l'URI d'une requête est /path/, et que /data/path/index.html n'existe pas mais que /data/path/index.php existe, la redirection interne vers /path/index.php est mappée au deuxième emplacement.

Par conséquent, la demande est envoyée par proxy.

=== Essayer plusieurs options ===

La directive **try_files** vérifie si le fichier ou le répertoire spécifié existe ; Nginx effectue une redirection interne si c'est le cas, ou renvoie un code d'état si ce n'est pas le cas.

Par exemple, pour vérifier l'existence d'un fichier correspondant à l'URI de la requête, utilisez la directive **try_files** et la variable $uri comme suit :

<code - >
server {
    root /www/data;

    location /images/ {
        try_files $uri /images/default.gif;
    }
}
</code>

Le fichier est spécifié sous forme de l'URI, qui est traité à l'aide des directives **root** ou **alias** définies dans le contexte de l'emplacement actuel ou du serveur virtuel.

Dans ce cas, si le fichier correspondant à l'URI d'origine n'existe pas, Nginx effectue une redirection interne vers l'URI spécifié par le dernier paramètre, en renvoyant /www/data/images/default.gif.

Le dernier paramètre peut également être un code d'état (directement précédé du signe égal) ou le nom d'un emplacement.

Dans l'exemple suivant, une erreur 404 est renvoyée si aucun des paramètres de la directive **try_files** ne se résout en un fichier ou un répertoire existant.

<code - >
location / {
    try_files $uri $uri/ $uri.html =404;
}
</code>

Dans l'exemple suivant, si ni l'URI d'origine ni l'URI avec la barre oblique finale ajoutée ne se résolvent en un fichier ou répertoire existant, la requête est redirigée vers l'emplacement nommé qui le transmet à un serveur proxy.

<code - >
location / {
    try_files $uri $uri/ @backend;
}

location @backend {
    proxy_pass http://backend.example.com;
}
</code>

Pour plus d'informations, visionnez le webinaire à la demande [[https://www.nginx.com/resources/webinars/content-caching-nginx-plus/|Content Caching]] pour apprendre à améliorer considérablement les performances d'un site Web et approfondir les capacités de mise en cache de Nginx.

==== Configuration d'un serveur proxy simple ====

L'une des utilisations fréquentes de nginx consiste à le configurer en tant que serveur proxy, ce qui signifie qu'un serveur reçoit les demandes, les transmet aux serveurs proxy, récupère les réponses et les envoie aux clients.

Nous allons configurer un serveur proxy de base, qui sert les demandes d'images avec des fichiers du répertoire local et envoie toutes les autres demandes à un serveur proxy.

Dans cet exemple, les deux serveurs seront définis sur une seule instance de nginx.

Tout d'abord, définissez le serveur proxy en ajoutant un bloc server supplémentaire au fichier de configuration de nginx :

<code - >
    server {
        listen 8080;
        root /data/up1;

        location / {
        }
    }
</code>

Ce sera un serveur simple qui écoute sur le port 8080 (précédemment, la directive listen n'a pas été spécifiée puisque le port 80 standard était utilisé) et mappe toutes les demandes vers le répertoire /data/up1 sur le système de fichiers local.

Créez ce répertoire et placez-y le fichier index.html.

Notez que la directive root est placée dans le contexte server.

Cette directive root est utilisée lorsque le bloc location sélectionné pour traiter une requête n'a pas sa propre directive racine.

Ensuite, utilisez la configuration du serveur de la section précédente et modifiez-la pour en faire une configuration de serveur proxy.

Dans le premier bloc location, mettez la directive proxy_pass en spécifiant le protocole, le nom et le port du serveur proxy dans le paramètre (dans notre cas, c'est http://localhost:8080) :

<code - >
    server {
        location / {
            proxy_pass http://localhost:8080;
        }

        location /images/ {
            root /data;
        }
    }
</code>

Nous allons modifier le second bloc location, qui pour l'instant mappe les demandes avec le préfixe /images/ vers les fichiers du répertoire /data/images, pour qu'il corresponde aux demandes d'images avec des extensions de fichier typiques. Le bloc location modifié ressemble à ceci :

<code - >
    location ~ \.(gif|jpg|png)$ {
        root /data/images;
    }
</code>

Le paramètre est une expression régulière qui correspond à tous les URI se terminant par .gif, .jpg ou .png.

Une expression régulière devrait être précédée par ~.

Les requêtes correspondantes seront mappées dans le répertoire /data/images.

Quand nginx choisit un bloc location pour servir une demande, il vérifie d'abord des directives location qui spécifient des préfixes, en se souvenant de l'endroit avec le plus long préfixe et vérifie ensuite les expressions régulières.

S'il y a correspondance avec une expression régulière, nginx choisit cet endroit ; sinon, il choisit celui retenu plus tôt.

La configuration résultante d'un serveur proxy ressemblera à ceci :

<code - >
    server {
        location / {
            proxy_pass http://localhost:8080/;
        }

        location ~ \.(gif|jpg|png)$ {
            root /data/images;
        }
    }
</code>

Ce serveur filtre les requêtes se terminant par .gif, .jpg, ou .png et les mappe dans le répertoire /data/images (en ajoutant l'URI au paramètre de la directive root) et transmet toutes les autres requêtes au serveur mandaté configuré ci-dessus.

Pour appliquer la nouvelle configuration, envoyez le signal de rechargement à nginx comme décrit plus haut.

De nombreuses autres directives peuvent être utilisées pour configurer davantage une connexion proxy.

==== Configuration de la fonction proxy de FastCGI ====

nginx peut être utilisé pour router des requêtes vers des serveurs FastCGI qui exécutent des applications construites avec différents frameworks et langages de programmation tels que PHP.

La configuration nginx la plus basique pour travailler avec un serveur FastCGI comprend l'utilisation de la directive fastcgi_pass au lieu de la directive proxy_pass, et des directives fastcgi_param pour définir les paramètres transmis à un serveur FastCGI.

Supposons que le serveur FastCGI soit accessible sur localhost:9000.

En prenant pour base la configuration du proxy de la section précédente, remplacez la directive proxy_pass par la directive fastcgi_pass et remplacez le paramètre par localhost:9000.

En PHP, le paramètre SCRIPT_FILENAME est utilisé pour déterminer le nom du script et le paramètre QUERY_STRING est utilisé pour transmettre les paramètres de la requête.

La configuration résultante serait:

<code - >
    server {
        location / {
            fastcgi_pass  localhost:9000;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param QUERY_STRING    $query_string;
        }

        location ~ \.(gif|jpg|png)$ {
            root /data/images;
        }
    }
</code>

Cela va mettre en place un serveur qui acheminera toutes les demandes à l'exception des demandes d'images statiques au serveur proxy opérant sur localhost:9000 via le protocole FastCGI.

==== Serveurs Virtuels ====

Voir [[tutoriel:internet:nginx:vhosts:start]]

Nginx Server Block Setup
Configure Nginx Ubuntu

Les blocs server de Nginx permettent d'héberger plusieurs sites sur un seul serveur.

Nous allons utiliser le domaine example.com.

Par défaut, Nginx traite toujours le contenu du répertoire /var/www/html/.

Cette configuration ne convient que si vous hébergez un seul site.

Here:

Nous allons créer un autre répertoire pour servir le domaine exemple.com.

DNous laisserons le répertoire /var/www/html pour le cas où aucun domaine de la configuration nginx ne correspond.

Créez le répertoire :<cli>$ sudo mkdir -p /var/www/example.com/html</cli>

<WRAP center round info 60%>
Le -p crée le ou les répertoires parents si nécessaire.
</WRAP>

Après cela, nous assignerons le propriétaire du répertoire en utilisant la variable $USER :<cli>$ sudo chown -R $USER:$USER /var/www/example.com/html</cli>

Définissez les autorisations pour la racine Web :<cli>$ sudo chmod -R 755 /var/www/example.com</cli>

Then, you have to create the index.html page using the nano editor as mentioned below.

Éditez avec les droits d'administration le fichier **/var/www/example.com/html/index.html** pour y écrire :

<code html /var/www/example.com/html/index.html>
<html>
    <head>
        <title>Welcome to Example.com!</title>
    </head>
    <body>
        <h1>Success!  The example.com server block is working!</h1>
    </body>
</html>

Pour que le contenu ci-dessus soit servi, nous devons créer un bloc de serveur Nginx dans /etc/nginx/sites-available/example.com.
éditez avec les droits d'administration le fichier **/etc/nginx/sites-available/example.com** pour y écrire :

<code nginx /etc/nginx/sites-available/example.com>
server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }
}</code>

Activez en créant le lien :<cli>$ sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/</cli>

Nous avons configuré deux blocs pour les requêtes du serveur:
  * **example.com** qui servira le contenu par exemple.com et www.example.com
  * **default** qui servira le contenu de la demande sur le port 80.

Nous devons faire une petite modification dans le fichier de configuration Nginx pour éviter un problème de mémoire. le problème se pose lorsque vous ajoutez plusieurs noms de serveur.
éditez avec les droits d'administration le fichier **/etc/nginx/nginx.conf** pour dé-commenter la ligne :
<code nginx>
...
http {
    ...
    server_names_hash_bucket_size 64;
    ...
}
</code>

Une fois terminées les étapes ci-dessus, testez la syntaxe du fichier Nginx :<cli>$ sudo nginx -t</cli>

Puis redémarrez le serveur Nginx :<cli>$ sudo systemctl restart nginx</cli>

si vous allez à votre adresse IP sur votre navigateur, vous devriez voir «Succès! Le bloc de serveur example.com fonctionne !>>

==== Sécurisation avec OpenSSL ====

  * [[tutoriel:internet:nginx:ssl:autosigne:start]]
    * [[tutoriel:internet:nginx:ssl:autosigne:raspi:start]]
  * [[tutoriel:internet:nginx:ssl:letsencrypt:start]]

===== Utilisation =====

==== Commandes de gestion de Nginx ====

Le serveur est en cours d'exécution.

^                                     Pour l'arrêter | <cli>$ sudo systemctl stop nginx</cli>                                                                                              |
^                                   Pour le démarrer | <cli>$ sudo systemctl start nginx</cli>                                                                                             |
^                                 Pour le redémarrer | <cli>$ sudo systemctl restart nginx</cli>                                                                                           |
^  Si vous avez apporté des modifications au serveur | <cli>$ sudo systemctl reload nginx</cli>ne coupera pas les connexions existantes\\ et ne fera que mettre à jour les modifications.  |
^    Pour empêcher Nginx de démarrer avec le système | <cli>$ sudo systemctl disable nginx</cli>                                                                                           |
^               Pour démarrer Nginx  avec le système | <cli>$ sudo systemctl enable nginx</cli>                                                                                            |

Autre méthode :
Démarrer, arrêter et recharger la configuration
^ <cli>$ sudo nginx -s stop</cli>    | arrêt rapide                                                                                                                 |
^ <cli>$ sudo nginx -s quit</cli>    | arrêt propre\\ à exécuter sous l' utilisateur qui a démarré nginx\\ arrête nginx en attendant la fin des processus en cours  |
^ <cli>$ sudo nginx -s reload</cli>  | recharge le fichier de configuration                                                                                         |
^ <cli>$ sudo nginx -s reopen</cli>  | rouvrir les fichiers journaux                                                                                                |

On peut aussi tuer les processus nginx avec l'utilitaire kill.

Pour obtenir la liste de tous les processus nginx en cours d'exécution, vous pouvez lancer :<cli>$ sudo ps -ax | grep nginx</cli>

===== Désinstallation =====

Comme d'habitude, <cli>$ sudo apt remove nginx</cli>

===== Voir aussi =====

  * **(en)** [[https://nginx.org/en/docs/beginners_guide.html]]
  * **(en)** documentation :[[https://docs.nginx.com/nginx/admin-guide/]]
  * **(fr)** [[https://web.developpez.com/tutoriels/creer-serveur-web-nginx-php-mariadb/|Créer un serveur Web Nginx + PHP7 + Maria DB (Mysql) + PhpMyAdmin sous Debian 9 Stretch]]  * 

----
//Basé sur << [[http://|Article]] >> par Auteur.//
Piste : • Supprimer un RAID logiciel pour récupérer ses disques • Programmation en VBA - Excel : graphiques • Nginx : Guide du débutant • Keepass 2 Gestion sécurisée des mots de passe • tab : syntaxe spéciale pour les tabulations • Modules de GRUB • Formatting Syntax • Systemctl - Contrôler Systemd et le gestionnaire de services
Documentation du Dr FRAPPE

Recherche

Navigation

Imprimer/exporter

Outils
