22
0
Fork 0

corrections diverses et ajout de la partie http/2

This commit is contained in:
jlecour 2017-10-30 08:10:15 +01:00
parent 6e21632eac
commit 94dd5a089c
1 changed files with 64 additions and 56 deletions

View File

@ -13,7 +13,7 @@ title: Howto Nginx
# apt install nginx
~~~
Sous Debian Jessie, c'est la version 1.6.2 qui est présente dans les dépôts.
Sous Debian Stretch, c'est la version 1.10.3 qui est présente dans les dépôts (1.6.2 pour Debian Jessie).
## Configuration de base
@ -54,7 +54,7 @@ events {
http {
keepalive_timeout 15;
[...]
[]
~~~
L'un des paramètres à ajuster immédiatement est le *worker_processes*. Les _worker processes_ sont les processus fils lancés par le père (le cœur de nginx), ce sont eux qui font tout le travail, ils ne sont pas multi-threadés : il est recommandé de mettre autant de _worker processes_ que de cores disponibles sur votre serveur ou bien de laisser à « auto ».
@ -95,13 +95,13 @@ configuration file /etc/nginx/nginx.conf test is successful
Ajouter dans la configuration Nginx :
~~~
location /nginx_status_NNNN {
stub_status on;
access_log off;
allow 127.0.0.1;
allow <IP>;
deny all;
}
location /nginx_status_NNNN {
stub_status on;
access_log off;
allow 127.0.0.1;
allow <IP>;
deny all;
}
~~~
Puis dans la configuration Munin :
@ -135,9 +135,9 @@ rewrite ^regex$ /vers-cette/uri.exemple.php {last,break,permanent,redirect}
Les alias permettent de faire servir du contenu qui ne serait pas stocké dans un répertoire servi par nginx (/var/www/nginx par exemple).
~~~
location /crossdomain.xml {
alias /home/chemin/du/fichier.xml;
}
location /crossdomain.xml {
alias /home/chemin/du/fichier.xml;
}
~~~
### Différence entre la directive alias et root
@ -147,8 +147,8 @@ L'alias redirige la requête initiale sans le chemin complet tandis que la direc
Exemple :
~~~
location /i/ {
alias /spool/w3/images/;
location /i/ {
alias /spool/w3/images/;
}
~~~
@ -159,14 +159,13 @@ Une requête sur /i/image.png, nginx renverra le contenu de /spool/w3/images/ima
Nginx peut aussi agir comme reverse-proxy. On utilisera alors la directive **proxy_pass** pour définir le serveur vers lequel la requête est envoyée. On peut aussi définir des headers qui seront ajoutés à la requête quand elle est transmise (Notamment, l'IP du visiteur, car le serveur dernière le proxy ne peut voir l'IP de celui-ci)
~~~
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
~~~
### Restrictions d'accès derrière un proxy (Varnish par exemple)
@ -184,23 +183,22 @@ real_ip_header X-Forwarded-For;
<http://wiki.nginx.org/HttpAuthBasicModule>
Pour configurer une authentification HTTP, on ajoutera les lignes suivantes au sein d'une directive _location_ :
Pour configurer une authentification HTTP, on ajoutera les lignes suivantes au sein d'une directive `location` :
~~~
auth_basic "Restricted";
auth_basic_user_file /home/foo/.htpasswd;
auth_basic "Restricted";
auth_basic_user_file /home/foo/.htpasswd;
~~~
Attention, si l'on ne souhaite protéger tout le site (location /), il faudra se méfier et bien ajuster
la configuration pour s'assurer que tous les fichiers sont protégés (notamment les fichiers PHP par exemple).
Attention, si l'on ne souhaite protéger tout le site (location /), il faudra se méfier et bien ajuster la configuration pour s'assurer que tous les fichiers sont protégés (notamment les fichiers PHP par exemple).
Le fichier _.htpasswd_ étant généré avec l'utilitaire htpasswd (comme pour Apache). Bien vérifier les droits en lecture pour l'utilisateur qui fait tourner Nginx (www-data en général).
Le fichier `.htpasswd` étant généré avec l'utilitaire *htpasswd* (comme pour Apache). Bien vérifier les droits en lecture pour l'utilisateur qui fait tourner Nginx ("www-data" en général).
## Optimisation
### Worker Connections et Keep Alive
Il s'agit du nombre de connexions qu'un _worker processes_ peut gérer. Le nombre de connexions multiplié par le nombre de _worker processes_ détermine le nombre total de connexions qu'il est possible de gérer simultanément. Cependant un autre paramètre intervient, il s'agit du _keep-alive time-out_ qui détermine la durée d'une connexion d'un client : lorsqu'un client se connecte au site, la connexion établie n'est pas fermée tout de suite, cela permet de faire passer plusieurs requêtes dans une seule connexion. La connexion sera fermée après le timeout. Il faut donc ajuster ces 2 paramètres en fonction de votre site (astuce : surveiller ses courbes Munin puis ajuster ces paramètres). Une configuration classique est de mettre 10240 en _worker_connections_ et entre 10 et 20 secondes pour _keepalive_timeout_.
Il s'agit du nombre de connexions qu'un _worker process_ peut gérer. Le nombre de connexions multiplié par le nombre de _worker processes_ détermine le nombre total de connexions qu'il est possible de gérer simultanément. Cependant un autre paramètre intervient, il s'agit du _keep-alive time-out_ qui détermine la durée d'une connexion d'un client : lorsqu'un client se connecte au site, la connexion établie n'est pas fermée tout de suite, cela permet de faire passer plusieurs requêtes dans une seule connexion. La connexion sera fermée après le timeout. Il faut donc ajuster ces 2 paramètres en fonction de votre site (astuce : surveiller ses courbes Munin puis ajuster ces paramètres). Une configuration classique est de mettre 10240 en `worker_connections` et entre 10 et 20 secondes pour `keepalive_timeout`.
~~~
events {
@ -208,10 +206,10 @@ events {
}
http {
keepalive_timeout 15;
[...]
[]
~~~
Si l'on souhaite désactiver complètement le Keep Alive, on mettra _keepalive_timeout 0_
Si l'on souhaite désactiver complètement le Keep Alive, on mettra `keepalive_timeout 0;`
### Diminuer les I/O
@ -219,7 +217,7 @@ Afin d'éviter un goulot d'étranglement sur les I/O, on peut via certains param
#### Access Logs
À chaque requête nginx écrit dans le fichier d'access logs. Plus il y a de requêtes plus cela est coûteux en accès disque. *Il est donc recommandé d'écrire les access logs dans la mémoire RAM (via une ramdisk par exemple), et de faire un logrotate sur le disque une fois une certaine taille atteinte.*
À chaque requête nginx écrit dans le fichier d'access logs. Plus il y a de requêtes plus cela est coûteux en accès disque. Il est donc recommandé d'écrire les access logs dans la mémoire RAM (via une ramdisk par exemple), et de faire un logrotate sur le disque une fois une certaine taille atteinte.
#### Error Logs
@ -233,13 +231,13 @@ Détermine le nombre de fichiers ouverts à mettre en cache.
Si les tampons mémoire ne sont pas assez grands, nginx va devoir écrire dans des tampons temporaires sur le disque dur ce qui augmente les accès disques.
La directive _client_body_buffer_size_ détermine la taille du buffer du champ _body_ d'une requête d'un client. Selon cas il peut être intéressant de l'accorder avec une taille en concordance avec vos formulaires, typiquement si vous avez des gros formulaires avec des données à uploader il faudra augmenter le buffer.
La directive `client_body_buffer_size` détermine la taille du buffer du champ `body` d'une requête d'un client. Selon cas il peut être intéressant de l'accorder avec une taille en concordance avec vos formulaires, typiquement si vous avez des gros formulaires avec des données à uploader il faudra augmenter le buffer.
La directive _fastcgi_buffers_ et _proxy_buffers_ sont les buffers associés à php/cgi/… Le concept est le même que le buffer pour les clients. Si les tampons sont trop petits, les données vont être temporairement écrite sur le disque.
La directive `fastcgi_buffers` et `proxy_buffers` sont les buffers associés à php/cgi/… Le concept est le même que le buffer pour les clients. Si les tampons sont trop petits, les données vont être temporairement écrite sur le disque.
#### Activer la compression gzip
Cette directive permet au visiteur de télécharger des données compressées par le serveur, permettant d'alléger la bande passante. *Il est recommandé de mettre gzip_comp_level à 4-5*.
Cette directive permet au visiteur de télécharger des données compressées par le serveur, permettant d'alléger la bande passante. *Il est recommandé de mettre `gzip_comp_level` à 4 ou 5*.
On peut aussi servir directement des fichiers déjà compressés : voir <http://wiki.nginx.org/HttpGzipStaticModule>
@ -258,7 +256,6 @@ EOT
# systemctl restart nginx
~~~
## SSL
~~~
@ -268,7 +265,7 @@ ssl_certificate /etc/ssl/certs/ssl.example.com.crt;
ssl_certificate_key /etc/ssl/private/ssl.example.com.key;
~~~
Attention, ssl_certificate doit contenir toute la chaîne de certification, donc il sera nécessaire de concaténer les certificats. Par exemple, on ajoutera le certificat intermédiaire via :
Attention, `ssl_certificate` doit contenir toute la chaîne de certification, donc il sera nécessaire de concaténer les certificats. Par exemple, on ajoutera le certificat intermédiaire via :
~~~
# cd /tmp
@ -276,7 +273,17 @@ Attention, ssl_certificate doit contenir toute la chaîne de certification, donc
# cat sub.class1.server.sha2.ca.pem >> /etc/ssl/certs/ssl.example.com.crt
~~~
Pour une configuration plus avancée, voir <http://trac.evolix.net/infogerance/wiki/HowtoSSL#AvecNginx>
Pour une configuration plus avancée, voir [HowtoSSL#configuration-nginx]
## HTTP/2
En version 1.10, la plupart des fonctionnalités du protocole est supportée par Nginx. Note : une version limitée du protocole était déjà supportée depuis Nginx 1.9.5.
Il faut alors activer le protocole dans la directive `listen`. Sachant que les navigateurs courants ne supportent HTTP/2 que pour des connexions sécurisées, on activera toujours le SSL/TLS. Il est également nécessaire de désactiver le protocole SPDY s'il était utilisé.
~~~
listen 0.0.0.0:443 ssl http2;
~~~
## Divers
@ -314,42 +321,42 @@ Le but est de bloquer par adresse IP et de rediriger vers une page « Vous êtes
~~~
# Blacklisting
geo $blacklist {
default 0;
192.0.2.42/32 1;
default 0;
192.0.2.42/32 1;
}
server {
[...]
[]
# Blacklisting
if ($blacklist) {
rewrite ^ <http://donthackmeplz.fr;>
}
# Blacklisting
if ($blacklist) {
rewrite ^ http://donthackmeplz.fr;
}
~~~
### Cross-domain pour les fonts
~~~
location ~* \.(eot|ttf|woff)$ {
add_header Access-Control-Allow-Origin *;
}
location ~* \.(eot|ttf|woff)$ {
add_header Access-Control-Allow-Origin *;
}
~~~
### Selon user-agent
~~~
if ($http_user_agent ~* (DotBot|Cliqzbot|AhrefsBot|SemrushBot)) {
return 404;
}
if ($http_user_agent ~* (DotBot|Cliqzbot|AhrefsBot|SemrushBot)) {
return 404;
}
~~~
Si on doit bloquer un user-agent avec des espaces dans son nom, une solution est déchapper les espaces avec des backslash comme ceci :
~~~
if ($http_user_agent ~* (DotBot|Cliqzbot|AhrefsBot|SemrushBot|Go\ 1\.1\ package\ http)) {
return 404;
}
if ($http_user_agent ~* (DotBot|Cliqzbot|AhrefsBot|SemrushBot|Go\ 1\.1\ package\ http)) {
return 404;
}
~~~
### Page personnalisé selon code erreur HTTP
@ -366,9 +373,10 @@ location /YYYYYY/ {
error_page XXX /YYYYYY/;
~~~
_Remplacer XXX par le code erreur HTTP souhaité et YYYYY par le nom de Location souhaité (URL) - vu que global à tous les vhosts, prendre une chaîne aléatoire._
Et pour chaque conf des vhosts */etc/nginx/sites-enabled/*.conf* :
Remplacer XXX par le code erreur HTTP souhaité et YYYYY par le nom de _Location_ souhaité (URL) - vu que global à tous les vhosts, prendre une chaîne aléatoire.
Et pour chaque conf des vhosts `/etc/nginx/sites-enabled/*.conf` :
~~~
include /etc/nginx/error.conf;