Tutoriel NGINX : les commandes et configurations de base

Nous avons déjà résumé les principes de NGINC, son processus d’installation et de mise en place, dans notre article sur les bases de NGINX. Nous vous donnons un aperçu des commandes de base et différentes possibilités de configuration du logiciel de serveur Web moderne dans ce tutoriel 1&1 IONOS.

nginx.conf : l’unité de commande centrale

NGINX travaille de manière différente qu’Apache car il est basé sur des évènements. Certaines demandes ne sont pas classées comme de nouveaux processus de travail pour les modules respectifs, mais plutôt en tant qu’évènements. Ces évènements sont répartis sur les processus de travail existants, maintenus par le processus principal supérieur. Combien de processus de travail existent-ils et de quelle manière sont réparties les requêtes serveur (ou évènements) ? Tout cela est défini par le fichier de configuration nginx.conf. Ce fichier se trouve par défaut dans le dossier /usr/local/nginx/conf, /etc/nginx ou /usr/local/etc/nginx

Les processus gèrent et prennent en charge les nouvelles configurations

NGINX se lance automatiquement après l’installation, ce que vous pouvez aussi alternativement effectuer avec la commande suivante :

sudo service nginx start

Si le logiciel de serveur Web fonctionne, vous pouvez le contrôlez en déterminant les processus (le processus principal en premier lieu) avec le paramètre –s et en indiquant un certain signal. La syntaxe de la commande correspondante est relativement banale :

sudo nginx -s signal

Vous avez, entre autres, quatre possibilités pour ce « signal » :  

  • stop: NGINX est interrompu immédiatement.
  • quit: NGINX est interrompu après que toutes les requêtes actives ont obtenu une réponse.
  • reload: le fichier de configuration est à nouveau chargé.
  • reopen: les Log-Files sont relancés. 

L’option reload, avec laquelle le fichier de configuration est de nouveau chargé, est une bonne possibilité pour mettre en place les modifications effectuées par vous-même, sans interrompre le logiciel de serveur Web et avoir à le redémarrer. Vous devez dans tous les cas vous décider pour une variante, un redémarrage complet du serveur ou un simple reload NGINX, afin que les modifications soient prises en compte. Si vous vous êtes décidé pour cette dernière option et que vous avez exécuté la commande suivante, le processus principal reçoit l’instruction de prendre en compte les changements dans le fichier nginx.conf :

sudo nginx -s reload

On vérifie dans ce but d’abord l’exactitude de la syntaxe. En cas de retour positif, le processus principal initie de nouveaux processus de travail avec les nouveaux réglages ainsi que l’interruption des anciens processus. Si la validation de la syntaxe échoue, l’ancien état de configuration est conservé. Tous les processus de travail actifs cessent dès lors que toutes les demandes actives sont en cours de traitement.

Vous pouvez aussi aborder des processus NGINC de manière très ciblée à l’aide d’outils tels que Kill.  Vous avez uniquement besoin de l’identifiant du processus, que vous pouvez trouver dans le fichier nginx.pid sous /usr/local/nginx/logs oder alternativ im Verzeichnis /var/run. Si le processus principal comporte par exemple l’identifiant 1628, il peut être interrompu avec Kill et le signal Quit : 

sudo kill -s quit 1628

Avec le programme de service ps, vous pouvez afficher une liste de tous les processus NGINX exécutés :

sudo ps -ax | grep nginx

Voici comment organiser la publication de contenus statiques

Il est fort probable que vous utilisiez votre serveur Web pour publier des fichiers tels que des images, vidéos ou contenus HTML statiques. Pour des raisons d’efficacité, il est idéal de choisir divers répertoires locaux pour des types de contenus différents. Commencez par placer le répertoire exemple /data/html et y introduire un document HTML (toujours exemple) index.html ainsi qu’un dossier /data/images comprenant quelques images d’exemple.

Lors de l’étape suivante, vous devez entrer les deux répertoires dans le fichier de configuration, en conservant les deux dans la directive du bloc serveur, qui est une sous-directive de la directive http bloc. Différentes instructions sont conservées ici, que vous pourrez ensuite désactiver (off). Mettez ensuite simplement une commande de bloc de serveur :

http {
  server {
  }
}

Dans ce bloc de serveur, les deux répertoires contenant les images et documents HTML doivent être indiqués. Cela donne le résultat suivant :

server {
  location / {
    root /data/html;
  }

  location /bilder/ {
    root /data;
  }
}

Il s’agit dans le cas de cette configuration d’un réglage standard d’un serveur, à l’écoute du port 80 et accessible via l’hébergeur local (local host). Toutes les requêtes, dont les URIs (Uniform Resource Identifier) commencent par /images/ demandent désormais des fichiers du répertoire /data/images. Si un tel fichier n’existe pas à cet emplacement, un rapport d’erreur apparaît. Tous les évènements NGINX dont les URIs ne commencent au contraire pas par /images/, seront transférés dans le répertoire /data/html.

Pensez enfin à relancer ou rafraichir NGINX, pour prendre en compte les modifications.

Mise en place d’un serveur proxy NGINX

NGINX est très fréquemment utilisé en tant que serveur proxy, dans le but d’accepter des demandes entrantes à la place du véritable serveur et filtrer ces dernières selon différents critères, puis de livrer la réponse respective aux clients. Ce qui est particulièrement apprécié sont les proxys cache, qui permettent de délivrer directement des contenus statiques, stockés localement. Toutes les autres requêtes sont transmises au serveur. Les proxys Firewall sont également très répandus et permettent de filtrer les connexions sûres et celles qui ne le sont pas. Dans l’exemple suivant, il s’agit du proxy cache, permettant d’afficher les images demandées et de transmettre toutes les autres demandes au serveur Web.

La première étape consiste à définir le serveur principal dans nginx.conf :

server {
  listen 8080;
  root /data/up1;

  location / {
  }
}

A la différence de l’exemple précédent, vous utilisez ici des listes de directives, avec lesquelles le port standard n’est pas utilisé, mais plutôt le port 8080 pour les requêtes entrantes. Placez par ailleurs le répertoire /data/up1 et retirez la page index.html de cet endroit.

Le serveur proxy et ses fonctions sont définis pour livrer des contenus d‘images, impliquant l’utilisation d’indications sur le serveur principal : le protocole (http), le nom ( localhost), et le port (80800).

server {
  location / {
    proxy_pass http://localhost:8080;
  }

  location ~ \.(gif|jpg|png) $ {
    root /data/bilder;
  }
}

Le second location-block renvoie au serveur proxy toutes les demandes dont les URIs se terminent par .gif, .jpg et .png, en chargeant les contenus correspondants depuis le répertoire local /data/images. Toutes les autres requêtes sont transmises au serveur principal. Comme avec les réglages précédents, vous enregistrez votre proxy images par reload-signal sur le processus principal avec le redémarrage de NGINX. D’autres directives possibles pour des paramétrages complexes de proxy se trouvent sur le manuel en ligne NGINX.