Quelles meilleures pratiques utilisez-vous lorsque vous utilisez NGinx?
Quelles meilleures pratiques utilisez-vous lorsque vous utilisez NGinx?
Réponses:
De loin, les meilleurs conseils que j'ai jamais vus sont ceux de l'auteur sur sa page de piège: https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
Généralement, utiliser "si" est une mauvaise pratique (selon l'auteur de nginx). si possible, utilisez plutôt try_file des directives error_page à la place "if (-f ...)"
En combinant tip avec le fichier maintenence.html et tip avec try_files, nous obtenons:
emplacement / { try_files /maintenance.html $ uri $ uri / @wordpress; }
Lorsque la maintenance est terminée, il suffit de mv maintenance.html à partir de $ root.
if (-f ...) { return 503; }
et error_page 503 /maintenance.html
. Qu'est-ce que tu penses?
Configurez nginx pour utiliser des chiffrements SSL plus puissants. Par défaut, SSLv2 est activé (vous devez le désactiver si possible).
ssl_ciphers DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5;
http://tumblelog.jauderho.com/post/121851623/nginx-and-stronger-ssl
Il est souvent plus efficace d’utiliser la map
directive à la place des expressions régulières lors du changement de racine pour faire correspondre les sous-domaines:
server {
server_name mysite.tld ~^.+\.mysite\.tld$;
map $host $files {
default common;
mysite.tld common;
www.mysite.tld common;
admin.mysite.tld admin;
system.mysite.tld system;
*.mysite.tld users;
}
root /var/www/mysite/$files;
}
Le empty_gif
module est également très utile, en particulier si vous avez besoin de surveiller le serveur Web (en utilisant nagios / monit / etc):
location /token {
empty_gif;
}
location /favicon.ico {
empty_gif;
}
location /img/1px.gif {
empty_gif;
}
access_log off;
pour ces lieux est une pratique courante
Nous avons configuré Nginx avec Chef à l’aide de ce livre de recettes, qui contient des scripts de gestion de la configuration de Nginx similaires à ceux utilisés par Apol2 par Debian, ainsi que des exemples de modèles avec des valeurs par défaut sane.
Voici une bonne méthode pour retourner une page de maintenance. Toutes les demandes sont réécrites et le code http correct est renvoyé. (503 Service Indisponible)
error_page 503 /maintenance.html;
location /
{
if (-f $document_root/maintenance.html)
{
return 503;
}
try_files $uri /index.php?$args;
}
location = /maintenance.html
{
rewrite ^ /maintenance.html break;
}
if
déclaration si vous l' utilisez correctement - les docs disent que if
s sont en sécurité si vous faites juste return xxx;
.
location = /maintenance.html { break; }
nécessaire?
À partir de nginx 0.7.12 et ultérieur, un "" est utilisable dans nom_serveur pour intercepter les demandes sans en-tête "Host".
Vous pouvez utiliser ce qui suit comme fourre-tout pour des hôtes virtuels non définis.
server {
server_name _ "";
}
J'ai également posté il y a quelque temps sur la façon de gérer correctement la compression gzip avec nginx, car les anciens navigateurs pourraient avoir des problèmes avec une simple déclaration gzip globale. HTH.
http://tumblelog.jauderho.com/post/27655495/gzip-compression-with-nginx
Je ne sais pas si c'est une pratique recommandée, mais c'est vraiment un bidouillage génial pour obtenir des conditions imbriquées dans nginx. Voici un exemple du wiki nginx .
location /xxxx/ {
set $test "";
if ($request_method = POST) {
set $test P;
}
if ($http_cookie ~* "CCCC=.+(?:;|$)" ) {
set $test "${test}C";
}
if ($test = PC) {
#rewrite rule goes here.
}
}
Si vous devez basculer de manière contextuelle entre http et https pour les sous-domaines gérés par le même bloc de serveur, vous pouvez utiliser des variables pour le faire. Ce n'est peut-être pas la manière la plus efficace de faire les choses, mais ça marche:
server {
server mysite.tld ~^.+\.mysite\.tld$;
set $req_ssl = 0;
map $host $files {
default common;
mysite.tld common;
www.mysite.tld common;
admin.mysite.tld admin;
system.mysite.tld system;
*.mysite.tld users;
}
root /var/www/mysite/$files;
if ( $files = "admin" ){
set $req_ssl 1;
}
if ( $files = "common" ){
set $req_ssl 2;
}
if ( $scheme = http )
{
set $req_ssl $req_ssl.1;
}
if ( $scheme = https )
{
set $req_ssl $req_ssl.2;
}
if ($req_ssl = 1.1){
rewrite ^ https://$host$uri;
}
if ($req_ssl = 2.2){
rewrite ^ http://$host$uri;
}
}
J'essaie toujours d'utiliser la root
directive dans la partie supérieure du bloc serveur pour pouvoir tirer parti de la $document_root
variable et ne jamais, mais jamais, inclure la root
directive dans un bloc d'emplacement.
La page des pièges du wiki Nginx propose des conseils judicieux sur les meilleures pratiques.
Si vous utilisez nginx en tant que proxy, il peut être important de régler les paramètres de délai d'attente pour éviter toute interruption de la connexion nginx avant que votre application ne soit terminée, en particulier si vous utilisez une application à trafic élevé:
proxy_connect_timeout
proxy_send_timeout
Avez-vous jeter un oeil ici?