Servidor web nginx

AISI
Administración de Servidores Web: NGINX

MWS NGINX
Proyecto de código abierto
https://nginx.org/en/docs/
Servidor web, proxy HTTP y correo
Event Drive y asíncrono*
Presenta buen rendimiento y escalabilidad
(problema C10K: https://es.wikipedia.org/wiki/Problema_C10k)
Modular
Proceso master y varios procesos
worker
HTTP2
*Comparativa con Apache https://anturis.com/blog/nginx-vs-apache/
introducción

MWS nginx
Arquitectura
De http://www.aosabook.org/en/nginx.html#fig.nginx.arch

MWS nginx
sudo apt-get install nginx (como el resto)
Proceso master: debe iniciarse como 'root'
Procesos workers: se inician por master con
usuario indicado en configuración.
Ficheros configuración (puede cambiarse)
l
/etc/nginx/nginx.conf: configuración básica
l
mime.types
l
fastcgi_params:
l
Proxy.conf
l
sites.conf
Podemos tener más con directiva include:
include otra_configuracion.conf;
include sites/*.conf;
Configuración

MWS nginx
Directivas:
l
worker_processes: Número máximo de
procesos para el servidor web. ¿Cuál?
Recomendación:
grep processor /proc/cpuinfo | wc -l
l
worker_connections: Número máximo de
conexiones simultáneas para workers
l
keepalive_timeout: Tiempo de espera (75”
por defecto)
l
user nobody nobody;
l
error_log logs/error.log;
l
pid logs/nginx.pid;
Directivas de configuración

MWS nginx
Directivas, sintaxis:
l
k, m, g (K, M, G) kilobytes, Mega, Giga→
l
ms,s,m,h,d-> Milisegundos, segundos, minutos,
horas, días
l
w, M, y semanas, meses, años→
Variables: pueden ser usadas en la definición de
valores de las directivas. Siempre comienzan con $.
l
Referidas a las cabeceras cliente: $http_hosts,
$http_user_agent, $http_referer,
$http_x_forwarded_for (ip del cliente si está tras
proxy), $http_cookie, $http_ (para cabeceras
adicionales enviadas por cliente, con nombre
cabecera en minúsculas y '-' remplaza a '_')
l
$nginx_version
Configuración: variables

MWS nginx
Sobre las cabeceras de respuesta:
l
$sent_http_content_type
l
$sent_http_content_length
l
$sent_http_location
l
$sent_http_last_modified
l
$sent_http_connection (si keepalive o cerrada)
l
$sent_http_keep_alive (tiempo que estará “viva”)
l
$sent_http_transfer_encoding
l
$sent_http_cache_control
l
$sent_http_

MWS nginx
Sobre Nginx
l
$arg-XXX: query_string con XXX el nombre
parámetro
l
$args: todos los args de query_string
l
$binary_remote_addr: IP en binario (4 bytes)
l
$body_bytes_sent: número bytes (sin cabeceras)
l
$bytes_sent: total
l
$connection: num serie que identifica la conexión
l
$connection_requests: num request de conexión
activa
l
$cookie_XXX: acceso a cookies, con XXX nombre
l
$document_root
l
$host: la de la cabecera HTTP
l
$hostname: del servidor
l
$https: se usa o no (vacía)

MWS nginx
Sobre Nginx
l
$limit_rate
l
$msec: tiempo actual en ms
l
$remote_addr, $remote_port,
$remote_user, $query_string,
$request_method,....
l
$status: código de respuesta
l
$uri: igual a $document_uri: uri de la
petición
l
...

MWS nginx
Directivas de bloque: Admiten otras directivas, pero
no cualquiera y pueden anidarse y se hereda la del
bloque superior
l
events { worker_connections 1024; }
l
http { server {
l
listen 80;
l
server_name example.com;
l
access_log /var/log/nginx/example.com.log;
l
location ^~ /admin/ {
l
index index.php;
l
access_log off;
l
}
l
}
l
include mime.types;
l
}
Directivas de bloque

MWS nginx
Módulos base:
l
“core”,
l
eventos
l
configuración
Tienen una gran cantidad de directivas
Configuración

MWS nginx
daemon (on|off); Modo background o no. Por
defecto on. Útil para depurar.
debug_points (stop|abort); Por defecto
inhabilitada
env MI_VARIABLE=mi_valor;
error_log fichero nivel; (nivel: debug, info,
notice, warn, error, crit, alert, emerg de→
más a menos detallado, emerg solo reporta
los críticos) Para deshabilitar: /dev/null
l
Contexto: main, http, server y location
log_not_found (on|off); registra HTTP 404
master_process (on|off); Habilitar 1 master
más workers. Si no, solo 1 proceso.
Core module directives

MWS nginx
pcre_jit (on|off); Habilita Just-in-Time
compilation para expresiones regulares
(rendimiento) Exige –with-pcre-jit y –enable-
jit en compilación de nginx
pid fichero; Por defecto, en compilación
ssl_engine enginename; Por defecto, none.
Enginename es el nombre del acelerador SSL
HW en tu sistema (openssl engine -t para
comprobar)
thread_pool name threads=number
[max_queue=number]; (defecto threads=32
y max_queu=65536) Pool para la directiva
aio para servir grandes ficheros

MWS nginx
user username groupname;
worker_processes number;
worker_directory directorio; Directorio de
trabajo (para ficheros core) y debe tener +w
para username
worker_rlimit_nofile número; De ficheros que
un worker puede procesar simultáneamente
worker_rlimit_core tam; Tamaño de los
ficheros core por worker.
worker_aio_request número; aio+epoll →
número máximo de operaciones I/O
pendiente por worker

MWS nginx
Permite configurar los
mecanismos/funcionamiento de red
En events bloks (events {})
Directivas:
l
accept_mutex (on|off); Exclusión mútua para→
escuchar sockets
l
accept_mutex_delay time; Espera para adquirir
un recurso (solo si anterior ON)
l
debug_connection IP; Logs detallados para un
equipo concreto (exige compilación con
--debug)
l
worker_connections number; Número de
conexiones que un worker puede procesar
simultáneamente
events module

MWS nginx
use kqueue; Modelo de eventos:
l
select: Es el de defecto. No recomendado para
elevada carga.
l
poll: Es mejor que select para gran carga, pero
no admitido por todos los sistemas
l
Kqueue: eficiente para FreeBSD 4.1+, MacOS
X, OpenBSD 2.9+
l
epoll: Eficiente para Linux 2.6+
l
/dev/poll: Eficiente para Solaris 7 11/99+, IRIX
6.5.15+
events module directives

MWS nginx
Solo es para habilitar la inclusión de ficheros:
include sites/*.conf
Importante: si el path es relativo, siempre se
toma como base el directorio de configuración
configuration module

MWS nginx
Contiene todo lo relacionado con bloques,
directivas y variables del servidor HTTP
Dispone de 3 bloques lógicos:
l
http: define faceta HTTP server de Nginx
l
server: relacionado con los “servidores web”
Solo se usa con un bloque http
l
location: define un grupo de configuraciones
para aplicar a una localización concreta del sitio
web. Puede ser usado en un bloque server o en
otro location
HTTP Core module

MWS nginx
Directivas de socket y host
l
listen [address][:port] [options];
Context:server
l
Options: ssl, default_server (web site por
defecto), spdy, proxy_protocol
l
server_name name [*.domain name2 ...];
Context: server
l
server_name *.website.*;
l
server_name ~^(www).example.com$;
l
server_name _ "";
l
server_name_in_redirect (on|off);
l
Context: http, server, location
l
port_in_redirect (on|off); (Añadir o no el puerto
en la URL de redirección)
HTTP Core module

MWS nginx
Directivas de paths y documentos
l
root directorio; Define documentroot
l
Context: http, server, location, if Acepta variables
l
alias directorio;
l
Context: location Acepta variables
l
error_page codigo1 [codig2 …] [=otro_code]
[=@block | URI ]
l
Context: http, server, location, if. Acepta vars
l
error_page 404 =200 /index.html
l
error_page 404 @notfound; #va al bloque de
location “notfound”
l
index file1 [file2...];
l
Context: http, server, location Acepta vars
l
try_files file1 [file2...] [@block | URI ];
l
Context: http, server, location Acepta vars
HTTP Core module

MWS nginx
Directivas sobre las peticiones de los clientes
l
keepalive_requests num; Número máx de
peticiones por conexión
l
l
keepalive_timeout secs [secs2];timeout
header=secs2
l
l
send_timeout secs; Para cerrar conexión inactiva
l
l
client_body_* Sobre el cuerpo de la petición→
l
l
types { mimetype1 extension1;[...]}
l
l
→ include mime.types; (para incluir todos)
l
default_type mimetype; para los tipo no incluidos→
HTTP Core module

MWS nginx
Directivas sobre límites y restricciones
l
limit_except método {allow,deny}; previene el uso de
métodos excepto el que explícitamente se habilita
l
Context: location
l
limit_rate bps; Limita ratios de transferencia de
conexiones individuales de clientes
l
Context: http, server, location,if
l
limit_rate_after bytes; Pasada la cantidad marcada
por bytes a máxima velocidad, se aplica la de
limit_rate
l
satisfay uri {}; Marca condiciones que debe cumplir
el cliente (allow, deny, auth_basic,...,any, all)
l
Context: location
l
Internal;-> No puede ser accedido desde exterior
l
Context: location
HTTP Core module

MWS nginx
Directivas sobre caché y procesamiento de ficheros
l
disable_symlinks (on|if_not_owner)
l
directio (off|value); Ficheros > value, serán leídos
con mecanismos Direct I/O
l
Context: http,server, location
l
open_file_cache max=N inactive=T; N entradas
como máximo y T segundos sin acceso en caché.
Guarda info sobre el fichero, no contenido.
l
l
log_not_found (on|off);
l
l
resolver IP_DNS [valid=time];
l
l
resolver_timeout time; Timeout para la query DNS
l
HTTP Core module

MWS nginx
LOCATION: permite especificar un patrón que se
comprobará con el documento en las URI de las
peticiones. Sintaxis:
location [= |~|~*|^~|@] pattern { ... }
La parte opcional se denomina location modifier y
define qué debe hacer nginx con el patrón indicado
l
Sin modifier El inicio del documento debe→
concordar con el patrón
l
= Documento debe concordar exactamente y el→
patrón debe ser una cadena literal
l
~ Debe concordar case-sensitive con la expresión→
regular; ~* case-insensitive→
l
^~ Similar al 1º, pero parando la búsqueda de→
otros
l
@ referencia a un bloque
HTTP Core module: location block

MWS nginx
LOCATION: Se pueden definir múltiples bloques con
diferentes patrones, buscando la concordancia en
este orden:
l
Con modifier =
l
Sin modifier, coincidencia exacta
l
Con modifier ^~
l
Con modifier ~ o ~*
l
Sin modifier Si el string coincide con el inicio de la
URI, se devuelve el bloque

MWS nginx
server{
server_name website.com;
location /files/ {
# applies to any request starting with "/files/"
# for example /files/doc.txt, /files/, /files/temp/
}
location = /files/ {
# applies to the exact request to "/files/"
# and as such does not apply to /files/doc.txt
# but only /files/
}
}
URI: http://website.com/files/doc.txt se aplica 1º→
URI: http://website.com/files/ se aplica el 2º→

MWS nginx
server{
server_name website.com;
location /doc {
[...] # requests beginning with "/doc"
}
location ~* ^/document$ {
[...] # requests exactly matching "/document"
}
}
URI: http://website.com/document Ambos coinciden, se→
aplica orden de prioridad y el seleccionado será el 2º
Si en el 1º, ponemos ^~, se aplicaría el 1º (por prioridad)

MWS nginx
server {
server_namewebsite.com;
root /var/www/vhosts/website.com/httpdocs/;
location /storage/ {
internal;
alias /var/www/storage/;
}
location /documents/ {
rewrite ^/documents/(.*)$ /storage/$1;
}
}
Rewrite module

MWS nginx
server {
If ($request_method = POST) {
[….]
}
}
Rewrite module: Conditional structure
Para aplicar configuraciones de acuerdo a condiciones
específicas
Operadores:
l
None: Condición true si la variable o datos no es
vacia
l
=, !=
l
~ , ~* , Coincide con expresión regular. ~ es
case-sensitive, ~* es case-insensitive. Negación: !
~ , !~*
l
-f , !-f fichero
l
-d , !-d Directorio
l
-x , !-x Como -f, que existe y, además, ejecutable

MWS nginx
if (-f $uri) {
break; # break if the file exists
}
if ($uri ~ ^/search/(.*)$) {
set $query $1;
rewrite ^ /search.php?q=$query?;
Rewrite module: Directivas
rewrite regexp replacement [flag]
l
Context: server, location, if
l
Flag: last, break, redirect (302), permanet (301)
Break. Ejemplo. SI existe, no reescribe
return code | text;
set $var1 “some”
uninitialized_variable_warn; Log cuando se use una no→
inicializada
rewrite_log (on|off) registrará cada operación realizada→

MWS nginx
Rewrite module: ejemplos reescrituras
rewrite ^/([0-9]+)/.*$ /article.php?id=$1?;
l
URI: http://website.com/33526/us-economy-strengthens
l
Rewritten: http://website.com/article.php?id=33526
rewrite ^/topic-([0-9]+)-([0-9]+)-(.*).html$
/viewtopic.php?topic=$1&start=$2?;
l
URI: http://website.com/topic-1234-50-some-
keywords.html
l
RW: http://website.com/viewtopic.php?
topic=1234&start=50
rewrite ^/wiki/(.*)$ /wiki/index.php?title=$1?;
l
URI:http://website.com/wiki/Some_keyword
l
RW: http://website.com/wiki/index.php?
title=Some_keyword

MWS nginx
Módulos
l
HTTP Referer: filtrar peticiones en función de la
cabecera HTTP Referer *
l
HTTP Limit Zone: Limita el nº conexiones
simultáneas del mismo cliente
l
User ID: cookies identificativas
l
FLV: reproducir vídeos en streaming
l
Perl: Ejecución de guiones Perl
l
WebDAV
l
SecureLink: para proteger páginas con claves
secretas
l
XSLT: postprocesamiento de páginas mediante
XSLT
* http://www.elladodelmal.com/2017/04/pon-un-referrer-policy-y-mejora-la.html Y https://securityheaders.io
Configuración

MWS nginx
En un servidor Nginx se debe ajustar:
l
user -> no privilegiado
l
worker_process auto Por defecto es 1,→
aunque lo mejor es uno por CPU disponible
l
worker_priority 0; Reasignar prioridad en→
función del servidor (recordad -20 max
prioridad, 20 min prioridad y el kernel suele
tener -5)
l
log_not_found on;Puede ser interesante para
depurar nuestro sitio
l
worker_connections 1024; Para definir al
número total de conexiones que acepta tu
servidor (junto con worker_process) y depende
de RAM y CPU
Ajustes necesarios

MWS nginx
NGINX puede ser muy útil a APPS en:
l
Caching integration
l
Changing content on-the-fly
l
Using Server Side Includes
l
Decision-making in NGINX
l
Creating a secure link
l
Generating images
l
Tracking website visitors
l
Preventing inadvertent code execution
Para desarrolladores

MWS nginx
Para desarrolladores: Caching integration
Objetivo: mejorar el rendimiento de nuestra
app
App no usa caché:
l
Uso de proxy_cache_ * y/o fastcgi_cache_*
l
Para páginas individuales, cabeceras: Expires
and Cache-Control headers y X-Accel-Expires
Las interpreta NGINX y no las envía al cliente.
l
Ejemplo: Página de noticias en la que se
decide
l
Página frontal será cacheada 1'
l
Cada artículo 1 día
l
Cada imagen tanto como sea posible

MWS nginx
Para desarrolladores: Caching integration
http {
# here we configure two separate shared memory zones for the keys/metadata
# and filesystem paths for the cached objects themselves
proxy_cache_path /var/spool/nginx/articles keys_zone=ARTICLES:16m
levels=1:2 inactive=1d;
proxy_cache_path /var/spool/nginx/images keys_zone=IMAGES:128m levels=1:2
inactive=30d;
# but both paths still lie on the same filesystem as proxy_temp_path
proxy_temp_path /var/spool/nginx;
server {
location / {
# this is where the list of articles is found
proxy_cache_valid 1m;
}
location /articles {
# each article has a URI beginning with "/articles"
proxy_cache_valid 1d;
}
location /img {
# every image is referenced with a URI under "/img"
proxy_cache_valid 10y;
}
}

MWS nginx
Para desarrolladores: Caching DB
Si tu app almacena páginas prerenderizadas en base
de datos, NGINX puede servirlas directamente desde
memcached
l
SI URI está en caché, se sirve
l
Si no, se pide a la app
location / {
set $memcached_key “$uri?$args”;
memcached_pass 127.0.0.1:11211;
error_page 404 502 504 = @app; //sustituirá el
código de error por el que devuelva app
}
Location @app {
proxy_pass 127.0.0.1:8080;

MWS nginx
Para desarrolladores: Caching FS
Si tu app escribe páginas prerenderizadas en el FS,
NGINX puede servirlas con cabeceras apropiadas:
Expires and Cache-Control
server{
root /var/www
location / {
location = /index.html {
expires 5m;
}
location ~* /.*.(js|css)$ {
expires 24h;
}
location ~* /.*.html$ {
expires 3d;
}
location /img {
expires max;
}

MWS nginx
Para desarrolladores: on-the-fly
Post-process: añadir un string, transformación del
HTML,... NGINX proporciona módulos para ello: addition,
sub y xslt (transformar XML usando XSLT)
server{
root /var/www
location / {
location / {
add_before_body /header;
add_after_body /footer;
}
location /header {
proxy_pass http://127.0.0.1:8080/header;
}
location /footer {
proxy_pass http://127.0.0.1:8080/footer;
}
}
sub_filter_once off;
sub_filter '<img src="img/' '<img src="/img/';
sub_filter </head> '<meta name="frontend" content="web3"></head>';
sub_filter_types text/css;

MWS nginx
Para desarrolladores: secure link
Protección de ciertas partes sin autenticación completa.
HASH MD5 del link + secret
location /downloads/ {
secure_link_secret supersecreto;
If ($secure_link = “”) {
Return 403;
}
try_files /downloads/$secure_link =404;
}
HTML:
<a href="/downloads/<hash>/libro_del_curso.pdf">Descarga libro del máster</a>
http://wiki.nginx.org/HttpSecureLinkModul
e

MWS nginx
Para desarrolladores: generating images
NGINX puede aplicar transformaciones simples a las
imágenes (rotar, redimensionar, cortar,...)
location /img {
try_files $uri /resize/$uri;
}
location ~* /resize/(?.<name>.*)_(?<width>[[:digit:]]*)x(?
<height>[[:digit:]]*).(?<extension>gif|jpe?g|png)$ {
error_page 404 = /resizer/$name.$extension?
width=$width&height=$height;
}
location /resizer {
image_filter resize $arg_width $arg_height;
}

MWS nginx
Para desarrolladores: tracking web visitors
Para rastrear visitantes únicos: userid module. Configura una
cookie por cliente cuyo valor tenemos en $uid_set. Cuando
vuelve y la cookie es válida, estará en $uid_got
http {
log_format useridcomb '$remote_addr - $uid_got [$time_local] '
'"$request" $status $body_bytes_sent ' '"$http_referer"
"$http_user_agent"';
server {
server_name .example.com;
access_log logs/example.com-access.log useridcomb;
userid on;
userid_name uid;
userid_domain example.com;
userid_path /;
userid_expires 365d;
userid_p3p 'policyref="/w3c/p3p.xml", CP="CUR ADM OUR
NOR”';
}

MWS nginx
Para desarrolladores: preventing code exe
Para mandar todos los requerimiento PHP a FastCGI server,
tenemos la opción A. Si nuestros usuarios suben ficheros a la
misma estructura de directorio, puede ser un problema (podrían
subir ficheros .jpg, etc con php embebido que se interpretaría)
Para prevenir esta posibilidad, opción B. Con try_files nos
aseguramos que el fichero exista.
B
location ~* .php {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
}
A
location ~* .php {
include fastcgi_params;
fastcgi_pass
127.0.0.1:9000;
}

MWS nginx
Para desarrolladores: proxy inverso URL
Ejemplo: la parte cliente y todas las rutas del frontend (con
AngularJS) se sirvan a través de la ruta /. Y que nuestra API
(con, por ejemplo, Node.js) se sirva a través de la ruta /api
# HTTP proxy
server {
listen 80;
server_name midominio.com;
access_log /var/log/nginx/nginx.access.log;
error_log /var/log/nginx/nginx.error.log;
client_max_body_size 5M;
location / {
add_header Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0";
# Ruta de los ficheros estáticos
root /var/www;
try_files $uri $uri/ /index.html =404;
}
location /api {
proxy_set_header 'Access-Control-Allow-Origin' 'http://midominio.com';
proxy_set_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
proxy_set_header 'Access-Control-Allow-Headers' 'X-Requested-With,Accept,Content-Type,
Origin';
proxy_pass http://127.0.0.1:3000;
proxy_redirect off;
proxy_buffering on;
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 origin 'http://midominio.com';
}
}

MWS nginx
Balanceo de carga: round robin
peticiones distribuidas entre los servidores de forma cíclica.
Las más pesadas pueden asignarse al mismo servidor
Distribuye las peticiones de forma ecuánime pero la carga no
salvo que usemos la directiva weight
upstream app {
server app1:8080;weight=3;
server app2:8080;
server app3:8080;
}
server {
listen 80;
location / {
proxy_pass http://app;
add_header X-Upstream $upstream_addr;
}
}

MWS nginx
Balanceo de carga: least-conected
La siguiente petición es atendida por el servidor con menos
conexiones activas.
Como el anterior, no reparte por sesión
upstream app {
least_conn;
server app1:8080;
server app2:8080;
server app3:8080;
}
server {
listen 80;
location / {
}
}

MWS nginx
Balanceo de carga: ip-hash
Se usará la dirección IP de origen para redirigir todas las peticiones
al mismo servidor que se conoce como sticky session
También: hash $cookie_username; en vez de IP, usa la cookie de
usuario
upstream app {
ip_hash;
server app1:8080;
server app2:8080;
server app3:8080;
}
server {
listen 80;
location / {
}
}

MWS nginx
Balanceo de carga
Los chequeos de salud se hacen de forma pasiva según el
resultado de las peticiones que se envían.
>max_fails, estado erróneo y estará durante fail_timeout
Tras fail_timeout, se le envía nueva petición. Si se responde
bien, pasa estado correcto.
La directiva health_check permite configurar la pruebas de
funcionamiento que se realizan a los servidores
upstream app {
ip_hash;
server app1:8080 max_fails=5 fail_timeout=30s;
server app2:8080;
server app3:8080;
}

MWS nginx
HTTP2
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
location / {
try_files $uri $uri/ =404;
}
ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_session_cache shared:SSL:5m;
ssl_session_timeout 1h;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains"
always;
}
server {
listen 80;
listen [::]:80;
return 301 https://$server_name$request_uri;
}

MWS nginx
nginx -t
nginx -t -c fichero_de_configuración
nginx -V información sobre el→
argumentos de compilación, módulo
incluídos.
nginx -g Permite incluir→
configuraciones de directivas que no
estén en el fichero de configuración:
nginx -g “timer_resolution 200ms”
Testing configuration

MWS apache
“Nginx HTTP server”, 3ª
edición, Clément Nedelcu, Packt
Publishing, 2015
“Mastering, Nginx”, Dimitri
Aivaliotis, Packet Publishing,
2013
Referencias

Servidor web nginx

Más contenido relacionado

La actualidad más candente (20)

Similar a Servidor web nginx (20)

Más de Juan Antonio Gil Martínez-Abarca (11)

Último (20)

Servidor web nginx

Notas del editor