Comment configurer le serveur Web Nginx sur un serveur privé virtuel
Statut : Obsolète
Cet article couvre une version d'Ubuntu qui n'est plus prise en charge. Si vous utilisez actuellement un serveur exécutant Ubuntu 12.04, nous vous recommandons fortement de mettre à niveau ou de migrer vers une version prise en charge d'Ubuntu :
- Mise à niveau vers Ubuntu 14.04.
- Mise à niveau d'Ubuntu 14.04 vers Ubuntu 16.04
- Migrer les données du serveur vers une version prise en charge
Raison : Ubuntu 12.04 a atteint sa fin de vie (EOL) le 28 avril 2017 et ne reçoit plus de correctifs ni de mises à jour de sécurité. Ce guide n'est plus maintenu.
Voir plutôt :
Ce guide peut toujours être utile comme référence, mais peut ne pas fonctionner sur d'autres versions d'Ubuntu. S'il est disponible, nous vous recommandons fortement d'utiliser un guide écrit pour la version d'Ubuntu que vous utilisez. Vous pouvez utiliser la fonctionnalité de recherche en haut de la page pour trouver une version plus récente.
Qu'est-ce que Nginx ?
Nginx est un serveur Web et un serveur proxy inverse. Il a connu une large adoption et remplace de nombreuses autres options courantes.
Bien que Nginx soit un outil puissant, sa configuration peut être intimidante pour ceux qui viennent d'autres serveurs ou qui découvrent les serveurs Web en général. Dans ce guide, nous allons explorer les principaux fichiers de configuration de Nginx et démystifier certaines syntaxes et options.
Nous utiliserons une installation Ubuntu 12.04, mais la plupart des distributions seront configurées avec des emplacements de fichiers similaires.
Hiérarchie du répertoire de configuration Nginx
Nginx stocke ses fichiers de configuration dans le répertoire "/etc/nginx".
À l'intérieur de ce répertoire, vous trouverez quelques répertoires et divers fichiers de configuration modulaire :
cd /etc/nginx ls -F
conf.d/ koi-win naxsi.rules scgi_params uwsgi_params fastcgi_params mime.types nginx.conf sites-available/ win-utf koi-utf naxsi_core.rules proxy_params sites-enabled/
Si vous venez d'Apache, les répertoires "sites-available" et "sites-enabled" vous seront familiers.
Ces répertoires sont utilisés pour définir les configurations de vos sites Web. Les fichiers sont généralement créés dans le répertoire "sites-available", puis symboliquement liés au répertoire "sites-enabled" lorsqu'ils sont prêts à être mis en ligne.
Le répertoire "conf.d" peut également être utilisé pour la configuration du site. Chaque fichier de ce répertoire se terminant par ".conf" est lu dans la configuration au démarrage de Nginx. Assurez-vous donc que chaque fichier définit une syntaxe de configuration Nginx valide.
La plupart des autres fichiers du répertoire "/etc/nginx" contiennent des détails de configuration de processus spécifiques ou de composants facultatifs.
Cependant, le fichier "nginx.conf" est le fichier de configuration principal. Nous allons explorer ce dossier plus en profondeur.
Explorer le fichier nginx.conf
Le fichier nginx.conf est le point de contrôle principal de Nginx. Ce fichier lit tous les autres fichiers de configuration appropriés et les combine dans un fichier de configuration monolithique au démarrage du serveur.
Ouvrez le fichier afin que nous puissions discuter du format général :
sudo nano /etc/nginx/nginx.conf
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
. . .
Les premières lignes sont utilisées pour définir quelques faits généraux sur le fonctionnement de Nginx.
Par exemple, le serveur décide sous quel utilisateur exécuter la ligne "user www-data". C'est l'utilisateur typique du serveur Web pour Ubuntu.
La directive "pid" spécifie où le pid du processus sera stocké pour référence interne. Le "worker_processes" définit le nombre de processus simultanés que Nginx utilisera.
Cette partie du fichier de configuration peut également inclure des éléments tels que les emplacements des journaux d'erreurs à l'aide de la directive "error_log".
La section suivante de notre fichier est la section des événements. Il s'agit d'un emplacement spécial qui contrôle la façon dont Nginx gérera les connexions. Nous n'avons pas besoin d'ajuster quoi que ce soit dans cette section dans notre exemple, nous allons donc continuer.
La section suivante est le bloc http. Cela conduit à une discussion plus complexe sur la façon dont le fichier de configuration Nginx est formaté.
Disposition du fichier de configuration Nginx
Le fichier de configuration Nginx est géré en "blocs".
Le premier bloc que nous avons vu était le bloc des événements. Le suivant est le bloc http et le début de la hiérarchie principale dans le fichier de configuration.
Les détails de configuration dans le bloc http sont en couches, les blocs inclus héritant des propriétés du bloc dans lequel ils se trouvent. La majeure partie de la configuration générale de Nginx se déroule dans le bloc http, qui abrite les blocs de serveur, qui, à leur tour, contiennent des blocs d'emplacement.
La partie importante est que vous devez toujours placer les détails de configuration dans le conteneur le plus élevé auquel ils s'appliquent. Cela signifie que si vous souhaitez que le paramètre X s'applique à chaque bloc de serveur, le placer dans le bloc http entraînera sa propagation à chaque configuration de serveur.
Si vous regardez notre fichier, vous remarquerez qu'il comporte de nombreuses options qui dictent le fonctionnement du logiciel dans son ensemble. C'est l'endroit approprié pour ce genre de directives.
Par exemple, nous avons des options de compression de fichiers configurées avec ces lignes :
gzip on; gzip_disable "msie6";
Cela indique à Nginx d'activer gzip pour compresser les données envoyées aux clients, mais de désactiver la compression gzip lorsque le client est Internet Explorer version 6, car ce navigateur ne comprend pas la compression gzip.
Si vous avez des options qui doivent avoir des valeurs différentes pour certains blocs de serveur, vous pouvez les spécifier à un niveau supérieur, puis les remplacer dans le bloc de serveur. Nginx prendra la spécification de niveau le plus bas qui s'applique à un paramètre.
Ce style d'application des paramètres au niveau le plus élevé possible vous évite d'avoir à gérer plusieurs déclarations identiques. Il a également l'avantage de fournir des valeurs par défaut qui peuvent être utilisées au cas où vous oublieriez de déclarer quelque chose au niveau du bloc "serveur" ou en dessous.
Dans le fichier "nginx.conf", on peut voir que la fin du bloc "http" a :
include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*;
Cela nous indique que les blocs de serveur et d'emplacement qui définissent des sites spécifiques et des emplacements de correspondance d'URL auront lieu en dehors de ce fichier.
Cela nous permet de maintenir un arrangement de configuration modulaire où nous pouvons créer de nouveaux fichiers lorsque nous souhaitons desservir de nouveaux sites. Cela nous permet de regrouper le contenu connexe, tout en masquant les détails qui ne changent pas dans la plupart des situations.
Quittez le fichier "nginx.conf" afin que nous puissions examiner une configuration de site individuelle dans la section suivante.
Explorer le bloc de serveur par défaut
Nginx utilise des blocs de serveur pour accomplir les fonctionnalités trouvées dans les hôtes virtuels de Apache. Considérez les blocs de serveur comme des spécifications pour des sites Web individuels que votre serveur peut héberger.
Nous examinerons la configuration de bloc de serveur par défaut incluse située dans le répertoire "sites-available". Ce fichier contient toutes les informations nécessaires pour servir la page Web par défaut.
cd sites-available sudo nano default
server {
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {
try_files $uri $uri/ /index.html;
}
location /doc/ {
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
}
}
Le fichier par défaut est très bien commenté, mais j'ai supprimé les commentaires ici pour gagner de la place et montrer à quel point la définition d'un site peut être simple.
Nous avons un bloc serveur qui inclut tout ce qui se trouve entre les parenthèses ouvrantes et fermantes associées :
server {
. . .
}
Ce bloc est placé dans le fichier "nginx.conf" vers la fin du bloc http, en utilisant la directive "include", comme nous l'avons vu dans la dernière section.
La directive "root" définit le répertoire où se trouve le contenu du site Web. C'est l'endroit où Nginx commencera à rechercher les fichiers demandés par le navigateur. Le site Web par défaut recherche son contenu dans "/usr/share/nginx/www".
Remarquez comment chaque ligne se termine par un point-virgule (;). C'est ainsi que Nginx sait qu'une directive est terminée et que la suivante va commencer. N'oubliez pas le point-virgule, sinon Nginx traitera les lignes qui suivent comme des arguments supplémentaires à la directive. Il le fera jusqu'à ce qu'il atteigne un point-virgule.
La ligne suivante implique la directive "index".
Cela configure les pages par défaut servies pour le domaine. Si aucune page n'a été demandée, le bloc serveur recherchera un fichier appelé "index.html" et le renverra. S'il ne trouve pas ce fichier, il essaiera de servir un fichier appelé "index.htm".
Utilisation de la directive nom_serveur
La directive "server_name" contient une liste de noms de domaine qui seront servis à partir de ce bloc serveur. Vous pouvez inclure autant de noms que vous le souhaitez, séparés par des espaces.
Vous pouvez également utiliser le caractère astérisque au début ou à la fin du nom du serveur comme caractère générique qui correspond à tout. Par exemple, "*.example.com" correspondrait aux requêtes pour "forum.example.com" et "animals.example.com".
Si une URL demandée correspond à plus d'une directive "server_name", elle choisira celle qui correspond exactement en premier. Si aucun ne correspond exactement, il choisira le nom générique le plus long qui commence par un astérisque.
S'il n'a toujours pas trouvé de correspondance, il recherchera le nom générique correspondant le plus long qui se termine par un astérisque. Si aucun de ceux-ci n'est trouvé, il renverra la première correspondance d'expression régulière correspondante.
Les noms de serveur qui utilisent des expressions régulières pour correspondre commencent par le caractère tilde (~). Les expressions régulières sont très puissantes, mais sortent du cadre de cet article.
Utilisation des blocs d'emplacement
La partie suivante du fichier de configuration ouvre un bloc d'emplacement. Les blocs d'emplacement sont utilisés pour spécifier comment certaines demandes de ressources sont gérées au sein d'un serveur.
La ligne "location /" spécifie que les directives entre parenthèses s'appliqueront à toutes les ressources demandées par le client qui ne correspondent pas à d'autres blocs d'emplacement.
Les blocs d'emplacement peuvent contenir un chemin uri comme le chemin "/doc/" spécifié plus bas dans le fichier, peuvent avoir un signe égal (=) entre l'emplacement et l'uri pour spécifier une correspondance exacte, ou utiliser des caractères tilde (~) pour indiquer correspondances d'expressions.
Un tilde simple indique une correspondance sensible à la casse, un tilde suivi d'un astérisque (~*) signifie une correspondance insensible à la casse, et un tilde précédé d'un carat (^~) indique à Nginx de ne pas effectuer de recherches d'expressions régulières si l'uri correspond à cet emplacement.
La correspondance d'emplacement est similaire à la correspondance de nom_serveur dans la mesure où Nginx dispose d'un processus bien défini pour décider quel bloc utiliser.
Si la requête correspond à un emplacement avec le signe égal, cet emplacement est utilisé et la recherche s'arrête. Si ce n'est pas le cas, les emplacements des uri littéraux réguliers sont recherchés. Si un tilde carat (^~) a été utilisé et qu'un emplacement uri correspond, ce bloc sera sélectionné.
Si cette option n'est pas utilisée, il sélectionnera la correspondance la plus spécifique et conservera la valeur. Il effectuera ensuite une correspondance d'expression régulière pour voir s'il peut correspondre à l'un de ces modèles. S'il en trouve un, le bloc d'expression régulière est utilisé. Si ce n'est pas le cas, l'emplacement de l'URI correspondant précédemment est utilisé.
En résumé, Nginx préfère les correspondances exactes, suivies des correspondances d'expressions régulières, puis des correspondances d'URI littérales, mais les correspondances d'URI littérales peuvent être explicitement rendues plus importantes en les faisant précéder de "^~".
Cette liste définit ces préférences :
<ol>
<li>Equal sign matches</li>
<li>Literal URI matches with "^~"</li>
<li>Most specific regular expression match</li>
<li>Most specific literal URI match</li>
</ol>
Bien que cela puisse sembler déroutant, ces règles définies sont nécessaires pour que Nginx puisse prendre une décision sans ambiguïté.
Comment utiliser try_files
La directive try_files est un outil très utile pour définir une chaîne de tentatives à effectuer pour les demandes de ressources.
Cela signifie que vous pouvez déclarer comment vous souhaitez que Nginx tente de répondre à une demande via une série d'options alternatives.
L'exemple dans le fichier de configuration par défaut est :
try_files $uri $uri/ /index.html;
Cela signifie que lorsqu'une demande est faite et servie par ce bloc d'emplacement, Nginx essaiera d'abord de servir l'uri littéral en tant que fichier. Ceci est déclaré en utilisant la variable "$uri", qui contiendra la ressource demandée.
S'il n'y a pas de fichier correspondant à la valeur de $uri, il essaiera d'utiliser l'uri comme répertoire. Il tentera de servir le fichier par défaut (le nôtre est index.html, si vous vous en souvenez) pour le répertoire uri.
S'il n'y a pas de répertoire correspondant à la valeur de $uri, il utilise un fichier par défaut, qui est le fichier "index.html" dans le répertoire racine du bloc du serveur. Chaque directive "try_files" utilise le dernier paramètre comme paramètre par défaut, il doit donc s'agir d'un fichier réel connu.
L'autre option si vous ne souhaitez pas renvoyer un fichier si les paramètres précédents ne correspondent pas est de renvoyer une page d'erreur. Ceci est accompli en utilisant un signe égal et un code d'erreur.
Par exemple, si nous voulions que notre bloc "location /" renvoie une erreur 404 si une ressource ne pouvait pas être localisée au lieu de servir la page "index.html" par défaut, nous pourrions remplacer le dernier fichier par "=404":
try_files $uri $uri/ =404;
Cela lancera la page d'erreur appropriée à l'utilisateur s'il demande une ressource qui n'existe pas.
Options additionelles
Le reste du fichier de configuration contient d'autres directives intéressantes.
La directive "alias" indique à Nginx que les pages de ce bloc d'emplacement doivent être servies à partir du répertoire spécifié. Ceux-ci peuvent se trouver en dehors du répertoire racine.
Dans notre exemple, les ressources demandées dans "/doc/" seront servies à partir de "/usr/share/doc/".
La directive "autoindex on" permet à Nginx de générer une liste de répertoires pour l'emplacement spécifié. Celui-ci sera renvoyé lorsque le répertoire sera demandé.
Les lignes "allow" et "deny" configurent le contrôle d'accès pour le répertoire. Les lignes de notre fichier permettent de lire le contenu lorsque l'utilisateur tente d'accéder à l'emplacement à partir du serveur local.
Conclusion
Nginx utilise une terminologie différente pour certaines de ses fonctionnalités, mais c'est un serveur extrêmement performant avec de nombreuses options de configuration.
Apprendre à configurer correctement un serveur web Nginx vous permettra de profiter pleinement d'un logiciel à la fois très puissant et très peu gourmand en ressources. Cela en fait un choix idéal pour les sites Web de toute taille.
