¿Qué mejores prácticas utilizas mientras usas NGinx?
¿Qué mejores prácticas utilizas mientras usas NGinx?
Respuestas:
De lejos, los mejores consejos que he visto son del autor en su página de trampa: https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
En general, usar "if" es una mala práctica (según el autor de nginx). si es posible, mejor usar try_file de las directivas error_page en lugar de "if (-f ...)"
Combinando tip con maintenence.html y tip con try_files obtenemos:
ubicación / { archivos_probar /maintenance.html $ uri $ uri / @wordpress; }
Cuando finaliza el mantenimiento, solo mv maintenance.html de $ root.
if (-f ...) { return 503; }
y error_page 503 /maintenance.html
. ¿Qué piensas?
Configure nginx para usar cifrados SSL más fuertes. De forma predeterminada, SSLv2 está habilitado (que debe deshabilitar si es posible).
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
A menudo es más eficiente usar la map
directiva en lugar de expresiones regulares al cambiar la raíz por subdominios coincidentes:
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;
}
El empty_gif
módulo también es muy útil, especialmente si necesita monitorear las respuestas del servidor web (usando nagios / monit / etc):
location /token {
empty_gif;
}
location /favicon.ico {
empty_gif;
}
location /img/1px.gif {
empty_gif;
}
access_log off;
para esos lugares es una práctica común
Configuramos Nginx con Chef, usando este libro de cocina que contiene scripts para manejar la configuración de nginx de forma similar a como Debian hace Apache2, y también algunas plantillas de muestra con valores predeterminados sanos.
Aquí hay un buen método para devolver una página de mantenimiento. Todas las solicitudes se reescriben y se devuelve el código http correcto. (503 Servicio no Disponible)
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
declaración si la usa correctamente; los documentos dicen que if
son seguros si usted solo lo estás haciendo return xxx;
.
location = /maintenance.html { break; }
necesario?
Desde nginx 0.7.12 y posteriores, se puede usar un "" en server_name para capturar solicitudes sin un encabezado "Host".
Puede usar lo siguiente como un catchall para hosts virtuales indefinidos.
server {
server_name _ "";
}
También publiqué hace un tiempo acerca de cómo manejar adecuadamente la compresión gzip con nginx ya que los navegadores más antiguos pueden tener problemas con solo una declaración general de gzip. HTH.
http://tumblelog.jauderho.com/post/27655495/gzip-compression-with-nginx
No sé si es una mejor práctica, pero definitivamente es un buen truco para obtener condiciones anidadas en nginx. Aquí hay una muestra de la wiki de 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 necesita alternar contextualmente entre http y https para subdominios manejados por el mismo bloque de servidor, puede usar variables para hacerlo. Puede que no sea la forma más eficiente de hacer las cosas, pero funciona:
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;
}
}
Siempre trato de usar la root
directiva en la parte superior del bloque del servidor para poder aprovechar la $document_root
variable y nunca, pero nunca, incluir la root
directiva dentro de un bloque de ubicación.
La página Pitfalls de la wiki de Nginx tiene algunos consejos excelentes sobre las mejores prácticas.
Si está usando nginx como proxy, tener la configuración de tiempo de espera ajustada puede ser importante para asegurarse de que no tenga conexiones nginx drop antes de que su aplicación termine con ellas, especialmente si se trata de una aplicación de alto tráfico:
proxy_connect_timeout
proxy_send_timeout
¿Echaste un vistazo por aquí?