NGINX

NGINX

NGINX
Desarrollador	Igor Sysoev
Datos técnicos
Web	https://nginx.org/
Genero	Servidor web, Proxy
Licencia	Licencia BSD simplificada

Introducción

Nginx (pronunciado en inglés «ényin-ex», /ˈɛndʒɪn-ɛks/)​ es un servidor web/Proxy inverso ligero de alto rendimiento y un proxy para protocolos de correo electrónico (IMAP/POP3).​

Es software libre y de código abierto, licenciado bajo la Licencia BSD simplificada; también existe una versión comercial distribuida bajo el nombre de Nginx Plus.​ Es multiplataforma, por lo que corre en sistemas tipo Unix (GNU/Linux, BSD, Solaris, Mac OS X, etc.) y Windows.

El sistema es usado por una larga lista de sitios web conocidos,​ como: WordPress, Netflix, Hulu, GitHub, Ohloh, SourceForge, TorrentReactor y partes de Facebook (como el servidor de descarga de archivos zip pesados).

Su creador, Igor Sysoev, en su página personal desde 2009 escribe el nombre totalmente en minúsculas,​ mientras que el nombre de la empresa propietaria desde 2011 lo escribe totalmente en mayúsculas,​ lo cual se corresponde con el nombre que devuelve el encabezado HTTP en todas y cada una de las solicitudes de conexión con que inicia la visita de cada página web.

Para complicar más el asunto el logotipo tiene caracteres tanto en mayúsculas y minúsculas del alfabeto cirílico,​ no obstante se ha logrado un consenso en denominar nginx al servidor web,​ NGINX a los productos y servicios derivados que maneja la empresa y Nginx para referirse a ambos en conjunto.

Comparación con Apache

Nginx fue inicialmente desarrollado con el fin explícito de superar el rendimiento ofrecido por el servidor web Apache.​ Sirviendo archivos estáticos, Nginx usa dramáticamente menos memoria que Apache, y puede manejar aproximadamente cuatro veces más solicitudes por segundo. Este aumento de rendimiento viene con un costo de disminuida flexibilidad, como por ejemplo la capacidad de anular las configuraciones de acceso del sistema por archivo (Apache logra esto con un archivo .htaccess, mientras que Nginx no tiene desarrollada tal funcionalidad). Anteriormente, incorporar módulos de terceros en Nginx requería recompilar la aplicación fuente con los módulos enlazados estáticamente. Esto fue parcialmente superado en la versión 1.9.11 de febrero de 2016, con la adición de carga dinámica de módulos. Sin embargo, los módulos aun deben ser compilados al mismo tiempo que Nginx, y no todos los módulos son compatibles con este sistema; algunos requieren el antiguo proceso de enlazado estático.

Instalación

En nuestros servidores Fedora o derivados podemos instalarlo con:

sudo dnf install nginx php-fpm

Añado el paquete "php-fpm" para tener la integración con el lenguaje PHP. Una vez instalado lo iniciamos:

sudo systemctl start nginx php-fpm

Y lo habilitamos para persistir el servicio en el inicio de sistema:

sudo systemctl enable nginx php-fpm

Seguimos añadiendo una regla permanente del cortafuegos:

sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https

Y recargamos el cortafuegos:

sudo firewall-cmd --reload

Ahora basta con abrir el navegador web y escribir la IP del servidor web:, por ejemplo:

http://192.168.1.3

Y ya debería mostrar la página de ejemplo.

Antes que nada, no abrimos https porque el servicio está configurado para tener el SSL comentado.

Estructura de ficheros y directorios

Como todos los servicios instalados, el directorio de configuración se encuentra en:

/etc/nginx

De todos los ficheros nos quedaremos con el fichero de configuración:

nginx.conf

En el que se muestra la configuración general del servidor como el directorio, el puerto de trabajo y que, como es recomendable, las configuraciones adicionales se realizan en la linia:

include /etc/nginx/conf.d/*.conf;

Es decir, aplicará todos los ficheros con extensión "conf" de este directorio. Por defecto, el directorio de publicación es:

/usr/share/nginx/hmtl

Aunque podemos cambiar el directorio, pero recordemos que hay que aplicar las reglas de SELinux para el directorio. Por otro lado, el registro de la navegación se encuentra en los ficheros:

/var/log/nginx/access.log ##para los registros de acceso /var/log/nginx/error.log ##Para los errores de carga de páginas.

NOTA - en la navegación, entre otras cosas, se muestra el navegador utilizado.

Configuraciones

A continuación vamos a explicar las configuraciones más utilizadas por este servicio:

Balanceo de carga

Esta opción nos permite a un equipo nodo poder permitir que una página web se cargue por otros equipos, por ejemplo, tenemos el equipo principal con NGINX y queremos que la página no se cargue de este equipo sino que, cada vez que se haga la petición, se cargue de un equipo o de otro, eso nos permite que, si un equipo está saturado de peticiones, la carga la haga desde otro.

Tenemos el equipo que responde a www.ejemplo.com y dentro de esta red ( o de internet ) tenemos otros equipos con la misma página o contenido, cada vez que se haga una petición a www.ejemplo.com, se cargará la web de uno de los nodos especificados en la configuración del nodo de balanceo, siendo menos costoso para el equipo principal.

Primero nos situaremos en nuestro equipo proxy con NGINX y editamos el fichero de configuración

sudo vi /etc/nginx/nginx.conf

NOTA - se recomienda siempre una copia de seguridad del fichero. Nos situamos dentro de la directiva "http { " y en la siguiente línea especificamos el balanceo añadiendo:

upstream servidores {

server 192.168.1.240;

server 192.168.1.241;

}

NOTA - son las IP o los nombres de los servidores web que se realizaran las peticiones de balanceo.

Ahora vamos a la directiva "server {" donde lo más importante se especifica el puerto de 80 de navegación. En esta directiva iremos a "location / {" y en la siguiente linia agregamos:

proxy_pass http://servidores;

Es decir, aplicamos que las peticiones que entren por la puerta 80 ( o 443 si así lo hemos especificado ), se ejecuta el bloque "servidores" que especificamos. Cerramos, guardando y reiniciamos el servicio:

sudo systemctl restart nginx

Y cada petición de carga de web al proxy será cargado por uno de los servidores.

NOTA - seguramente SELinux bloquee la navegación de proxy y se soluciona aplicando:

sudo setsebool httpd_can_network_connect 1

Con lo que se permite el tráfico en la red por el protocolo http.

¡IMPORTANTE! Hay que tener en cuenta las páginas dinámicas, es decir, cuando se precisa un usuario y contraseña para acceder a una web, obviamente, no va a replicar una validación, por lo que eso ya se vería reflejado en la configuración de la base de datos.

Bloques de servidor

Un caso práctico sería, tener un servidor que publica la web www.empresa.com, pero ha crecido y quiere otro servidor exclusivo para las ventas, bajo el dominio ventas.empresa.com. Esto implicaría la compra de dos equipos, pero eso se puede realizar desde el mismo equipo servidor NGINX.

En Apache sería comparable a los VirtualHost pero más avanzado.

Un ejemplo de bloque nos lo encontramos en la directiva por defecto "server" en la que se especifican los valores por defecto como la ruta del directorio, los ficheros de log de acceso o error o el puerto de escucha ( 80).

NOTA  - por una cuestión de organización, los ficheros de cada bloque, igual que cualquier añadido, serán individuales en el directorio "/etc/nginx/conf.d/".

Un ejemplo, tengamos presente que queremos que "www.empresa.com" tenga otro directorio de alojamiento, para ello creamos el fichero:

/etc/nginx/conf.d/www.com

Con este contenido:

server {

   listen 80;  #puerto de escucharoot

   root /var/www/html/www;

   index index.html;

   server_name www.empresa.com empresa.com;

   access_log /var/log/nginx/www.access.log;

   error_log /var/log/nginx/www.error.log;

   location /(

     try_files $uri $uri/ =404; # en caso de no encontrar la página

   )

}

En este caso, el web estaría en "/var/www/html/www", que escucharía todas las peticiones del puerto por defecto, cargaría el fichero "index.html", generaría los correspondientes informes de tráfico de acceso o errores y una alternativa a los mensajes de error.

Recordemos, con esto, tenemos la página por defecto "empresa.com" y la página "www.empresa.com" totalmente diferente.

También, por seguridad, podemos hacer que no se carguen las páginas por IP interna, sino por dominio, haciendo así una redirección, para eso añadiremos después de "listen 80;" las siguientes líneas de directivas:

server_name 192.168.1.240; #IP local que responde el servidor return 301 $scheme://www.empresa.com$request_uri; #scheme sirve para aplicar tanto en http como https y request_uri sirve para asociar la página solicitada por el cliente

NOTA - recordemos reiniciar el servidor en cada cambio.

Proxy inverso

En Nginx, un proxy inverso es un servidor que actúa como intermediario entre los clientes y los servidores de origen. Funciona de la siguiente manera:

1. Los clientes solicitan recursos a un nombre de dominio o dirección IP virtual. Esta dirección está configurada para apuntar al proxy inverso.
2. El proxy inverso recibe la solicitud del cliente y la analiza. Determina qué servidor de origen es responsable de atender la solicitud.
3. El proxy inverso se comunica con el servidor de origen correspondiente y solicita el recurso.
4. El servidor de origen envía el recurso al proxy inverso.
5. El proxy inverso recibe el recurso del servidor de origen y lo envía al cliente.

Los proxies inversos ofrecen varias ventajas, entre ellas:

• Seguridad: El proxy inverso puede ocultar los servidores de origen a Internet, lo que dificulta su ataque. También puede agregar funciones de seguridad adicionales, como autenticación y autorización.
• Rendimiento: El proxy inverso puede mejorar el rendimiento al almacenar en caché contenido estático, como imágenes y CSS. También puede distribuir la carga entre varios servidores de origen.
• Escalabilidad: El proxy inverso puede facilitar la adición de nuevos servidores de origen a medida que crece la demanda.
• Alta disponibilidad: El proxy inverso puede enrutar el tráfico alrededor de los servidores de origen que no están disponibles.

Dado que todo el tráfico y peticiones web pasarán por el equipo, hace falta configurar SELinux para permitir el tráfico con:

sudo setsebool –P httpd_can_network_connect on

Resumiendo, el cliente pedirá acceder a diferentes lugares de la web de la empresa, y estos lugares son gestionados por diferentes servidores, por ejemplo:

Accederá a empresa.com y de aquí a www.empresa.com ( que está en un servidor en la red interna), a ventas.empresa.com ( que está en otro servidor) o a nextcloud.empresa.com ( ubicado en un tercer equipo interno), haciendo un total de 4 equipos: el proxy y tres equipos destino con sus correspondientes configuraciones.

Un punto a favor, si tenemos contratado un certificado SSL para hacer peticiones seguras, este certificado basta conque esté en el servidor proxy inverso y no hace falta que lo tengan los demás equipos. Tampoco es obligatorio que el resto de equipos se administren con NGINX, pueden ser Apache u otro servicio.

NGINX y HTTPS

Para hacer que nuestro web sea considerado seguro, éste debe tener un certificado SSL.

Una vez creado, alquilado o auto-generado, deberemos especificarlo en nuestro fichero de configración añadiendo

listen 443 ssl; # managed by Certbot

    # RSA certificate
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot

    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

    # Redirect non-https traffic to https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    } # managed by Certbot

NOTA - en este ejemplo hemos generado un certificado con letsencrypt .