Nous avons déjà résumé les principes de NGINC, son processus d’ins­tal­la­tion et de mise en place, dans notre article sur les bases de NGINX. Nous vous donnons un aperçu des commandes de base et dif­fé­rentes pos­si­bi­li­tés de con­fi­gu­ra­tion du logiciel de serveur Web moderne dans ce tutoriel IONOS.

nginx.conf : l’unité de commande centrale

NGINX travaille de manière dif­fé­rente qu’Apache car il est basé sur des évè­ne­ments. Certaines demandes ne sont pas classées comme de nouveaux processus de travail pour les modules res­pec­tifs, mais plutôt en tant qu’évè­ne­ments. Ces évè­ne­ments 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è­ne­ments) ? Tout cela est défini par le fichier de con­fi­gu­ra­tion 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 con­fi­gu­ra­tions

NGINX se lance au­to­ma­ti­que­ment après l’ins­tal­la­tion, ce que vous pouvez aussi al­ter­na­ti­ve­ment effectuer avec la commande suivante :

sudo service nginx start

Si le logiciel de serveur Web fonc­tionne, vous pouvez le contrôlez en dé­ter­mi­nant les processus (le processus principal en premier lieu) avec le paramètre –s et en indiquant un certain signal. La syntaxe de la commande cor­res­pon­dante est re­la­ti­ve­ment banale :

sudo nginx -s signal

Vous avez, entre autres, quatre pos­si­bi­li­tés pour ce « signal » :  

  • stop: NGINX est in­ter­rompu im­mé­dia­te­ment.
  • quit: NGINX est in­ter­rompu après que toutes les requêtes actives ont obtenu une réponse.
  • reload: le fichier de con­fi­gu­ra­tion est à nouveau chargé.
  • reopen: les Log-Files sont relancés. 

L’option reload, avec laquelle le fichier de con­fi­gu­ra­tion est de nouveau chargé, est une bonne pos­si­bi­lité pour mettre en place les mo­di­fi­ca­tions ef­fec­tuées par vous-même, sans in­ter­rompre le logiciel de serveur Web et avoir à le re­dé­mar­rer. Vous devez dans tous les cas vous décider pour une variante, un re­dé­mar­rage complet du serveur ou un simple reload NGINX, afin que les mo­di­fi­ca­tions 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’ins­truc­tion de prendre en compte les chan­ge­ments dans le fichier nginx.conf :

sudo nginx -s reload

On vérifie dans ce but d’abord l’exac­ti­tude 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’in­ter­rup­tion des anciens processus. Si la va­li­da­tion de la syntaxe échoue, l’ancien état de con­fi­gu­ra­tion est conservé. Tous les processus de travail actifs cessent dès lors que toutes les demandes actives sont en cours de trai­te­ment.

Vous pouvez aussi aborder des processus NGINC de manière très ciblée à l’aide d’outils tels que Kill.  Vous avez uni­que­ment besoin de l’iden­ti­fiant du processus, que vous pouvez trouver dans le fichier nginx.pid sous /usr/local/nginx/logs oder al­ter­na­tiv im Ver­zeich­nis /var/run. Si le processus principal comporte par exemple l’iden­ti­fiant 1628, il peut être in­ter­rompu 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 pu­bli­ca­tion 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’ef­fi­ca­cité, il est idéal de choisir divers ré­per­toires locaux pour des types de contenus dif­fé­rents. Commencez par placer le ré­per­toire exemple /data/html et y in­tro­duire un document HTML (toujours exemple) index.html ainsi qu’un dossier /data/images com­pre­nant quelques images d’exemple.

Lors de l’étape suivante, vous devez entrer les deux ré­per­toires dans le fichier de con­fi­gu­ra­tion, en con­ser­vant les deux dans la directive du bloc serveur, qui est une sous-directive de la directive http bloc. Dif­fé­rentes ins­truc­tions sont con­ser­vées ici, que vous pourrez ensuite dé­sac­ti­ver (off). Mettez ensuite sim­ple­ment une commande de bloc de serveur :

http {
    server {
    }
}

Dans ce bloc de serveur, les deux ré­per­toires 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 con­fi­gu­ra­tion d’un réglage standard d’un serveur, à l’écoute du port 80 et ac­ces­sible via l’hébergeur local (local host). Toutes les requêtes, dont les URIs (Uniform Resource Iden­ti­fier) com­men­cent par /images/ demandent désormais des fichiers du ré­per­toire /data/images. Si un tel fichier n’existe pas à cet em­pla­ce­ment, un rapport d’erreur apparaît. Tous les évè­ne­ments NGINX dont les URIs ne com­men­cent au contraire pas par /images/, seront trans­fé­rés dans le ré­per­toire /data/html.

Pensez enfin à relancer ou ra­frai­chir NGINX, pour prendre en compte les mo­di­fi­ca­tions.

Mise en place d’un serveur proxy NGINX

NGINX est très fré­quem­ment 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 dif­fé­rents critères, puis de livrer la réponse res­pec­tive aux clients. Ce qui est par­ti­cu­liè­re­ment apprécié sont les proxys cache, qui per­met­tent de délivrer di­rec­te­ment des contenus statiques, stockés lo­ca­le­ment. Toutes les autres requêtes sont trans­mises au serveur. Les proxys Firewall sont également très répandus et per­met­tent de filtrer les con­nexions sûres et celles qui ne le sont pas. Dans l’exemple suivant, il s’agit du proxy cache, per­met­tant d’afficher les images demandées et de trans­mettre 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 dif­fé­rence de l’exemple précédent, vous utilisez ici des listes de di­rec­tives, avec les­quelles le port standard n’est pas utilisé, mais plutôt le port 8080 pour les requêtes entrantes. Placez par ailleurs le ré­per­toire /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, im­pli­quant l’uti­li­sa­tion d’in­di­ca­tions 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 cor­res­pon­dants depuis le ré­per­toire local /data/images. Toutes les autres requêtes sont trans­mises au serveur principal. Comme avec les réglages pré­cé­dents, vous en­re­gis­trez votre proxy images par reload-signal sur le processus principal avec le re­dé­mar­rage de NGINX. D’autres di­rec­tives possibles pour des pa­ra­mé­trages complexes de proxy se trouvent sur le manuel en ligne NGINX.

Créer un site Internet
Votre site en un éclair grâce à l'in­tel­li­gence ar­ti­fi­cielle
  • Éditeur de site intuitif avec fonctions d'IA
  • Gé­né­ra­teur d'images et de textes avec op­ti­mi­sa­tion SEO
  • Domaine, SSL et boîte email inclus
Aller au menu principal