Introducción a NGINX para desarrolladores

Imagínese esto: ha creado una aplicación web y ahora está buscando el servidor web adecuado para alojarla.

Su aplicación puede constar de varios archivos estáticos: HTML, CSS y JavaScript, un servicio de API de backend o incluso varios servicios web. Usar Nginx puede ser lo que está buscando, y hay un par de razones para ello.

NGINX es un potente servidor web y utiliza una arquitectura no subprocesada y basada en eventos que le permite superar a Apache si se configura correctamente. También puede hacer otras cosas importantes, como el equilibrio de carga, el almacenamiento en caché HTTP o usarse como proxy inverso.

En este artículo, cubriré algunos pasos básicos sobre cómo instalar y configurar las partes más comunes de NGINX.

Instalación básica: arquitectura

Hay dos formas de instalar NGINX, ya sea utilizando un binario prediseñado o compilándolo desde la fuente.

El primer método es mucho más fácil y rápido, pero construirlo desde la fuente brinda la capacidad de incluir varios módulos de terceros que hacen que NGINX sea aún más poderoso. Nos permite personalizarlo para que se ajuste a las necesidades de la aplicación.

Para instalar un paquete Debian precompilado, lo único que tiene que hacer es:

sudo apt-get updatesudo apt-get install nginx

Una vez finalizado el proceso de instalación, puede verificar que todo está bien ejecutando el siguiente comando, que debería imprimir la última versión de NGINX.

sudo nginx -vnginx version: nginx/1.6.2

Su nuevo servidor web se instalará en la ubicación . Si ingresa a esta carpeta, verá varios archivos y carpetas. Los más importantes que requerirán nuestra atención más adelante son el archivo y la carpeta ./etc/nginx/nginx.confsites-available

Ajustes de configuración

La configuración principal de NGINX está en el nginx.confarchivo, que por defecto tiene este aspecto.

user www-data;worker_processes 4;pid /run/nginx.pid;events { worker_connections 768; # multi_accept on;}http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # server_tokens off; # server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; # gzip_vary on; # gzip_proxied any; # gzip_comp_level 6; # gzip_buffers 16 8k; # gzip_http_version 1.1; # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*;}

El archivo está estructurado en contextos . El primero es el contexto de eventos y el segundo es el contexto http . Esta estructura permite algunas capas avanzadas de su configuración, ya que cada contexto puede tener otros contextos anidados que heredan todo de su padre, pero también pueden anular una configuración según sea necesario.

Varias cosas en este archivo se pueden modificar según sus necesidades, pero NGINX es tan simple de usar que puede seguir incluso con la configuración predeterminada. Algunas de las piezas más importantes del archivo de configuración NGINX son:

  • worker_processes: esta configuración define el número de procesos de trabajo que utilizará NGINX. Debido a que NGINX es de un solo subproceso, este número generalmente debe ser igual al número de núcleos de CPU.
  • worker_connections: este es el número máximo de conexiones simultáneas para cada proceso de trabajador y le dice a nuestros procesos de trabajador cuántas personas pueden ser atendidas simultáneamente por NGINX. Cuanto más grande sea, más usuarios simultáneos podrá atender el NGINX.
  • access_log & error_log: Estos son los archivos que NGINX usará para registrar cualquier error e intento de acceso. Estos registros generalmente se revisan para depurarlos y solucionar problemas.
  • gzip: Estos son los ajustes para la compresión GZIP de las respuestas NGINX. Habilitar este junto con las diversas subconfiguraciones que por defecto están comentadas resultará en una gran mejora de rendimiento. A partir de la configuración secundaria de GZIP, se debe tener cuidado con gzip_comp_level, que es el nivel de compresión y varía de 1 a 10. En general, este valor no debe ser superior a 6; la ganancia en términos de reducción de tamaño es insignificante, ya que necesita mucho más uso de la CPU. gzip_types es una lista de tipos de respuesta a los que se aplicará la compresión.

Su instalación de NGINX puede admitir mucho más de un sitio web, y los archivos que definen los sitios de su servidor se encuentran en el directorio / etc / nginx / sites-available.

Sin embargo, los archivos de este directorio no están "activos"; puede tener tantos archivos de definición de sitios aquí como desee, pero NGINX no hará nada con ellos a menos que estén vinculados simbólicamente a / etc / nginx / directorio habilitado para sitios (también puede copiarlos allí, pero el enlace simbólico garantiza que solo haya una copia de cada archivo para realizar un seguimiento).

Esto le brinda un método para poner rápidamente sitios web en línea y desconectarlos sin tener que eliminar realmente ningún archivo: cuando esté listo para que un sitio se conecte, vincúlelo en sitios habilitados y reinicie NGINX.

El sites-availabledirectorio incluye configuraciones para hosts virtuales. Esto permite que el servidor web se configure para varios sitios que tienen configuraciones independientes. Los sitios dentro de este directorio no están activos y solo se habilitan si creamos un enlace simbólico en la sites-enabledcarpeta.

Cree un nuevo archivo para su aplicación o edite el predeterminado. Una configuración típica se parece a la siguiente.

upstream remoteApplicationServer { server 10.10.10.10;}upstream remoteAPIServer { server 20.20.20.20; server 20.20.20.21; server 20.20.20.22; server 20.20.20.23;}server { listen 80; server_name www.customapp.com customapp.com root /var/www/html; index index.html location / { alias /var/www/html/customapp/; try_files $uri $uri/ =404; } location /remoteapp { proxy_set_header Host $host:$server_port; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass //remoteAPIServer/; } location /api/v1/ { proxy_pass //remoteAPIServer/api/v1/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_redirect // //; }}

Al igual que el nginx.conf, este también usa el concepto de contextos anidados (y todos estos también están anidados dentro del contexto HTTP de nginx.conf, por lo que también heredan todo).

El contexto del servidor define un servidor virtual específico para manejar las solicitudes de sus clientes. Puede tener varios bloques de servidor, y NGINX elegirá entre ellos según las directivas listeny server_name.

Dentro de un bloque de servidor, definimos múltiples contextos de ubicación que se utilizan para decidir cómo manejar las solicitudes del cliente. Siempre que ingrese una solicitud, NGINX intentará hacer coincidir su URI con una de esas definiciones de ubicación y manejarla en consecuencia.

Hay muchas directivas importantes que se pueden utilizar en el contexto de la ubicación, como:

  • try_files intentará servir un archivo estático que se encuentra en la carpeta que apunta a la directiva raíz.
  • proxy_pass enviará la solicitud a un servidor proxy especificado.
  • rewrite reescribirá el URI entrante basado en una expresión regular para que otro bloque de ubicación pueda manejarlo.

El contexto ascendente define un grupo de servidores a los que NGINX enviará las solicitudes por proxy. Después de crear un bloque ascendente y definir un servidor dentro de él, podemos hacer referencia a él por su nombre dentro de nuestros bloques de ubicación. Además, un contexto ascendente puede tener muchos servidores asignados debajo de él para que NGINX realice un equilibrio de carga al procesar las solicitudes.

Iniciar NGINX

Una vez que hayamos terminado con la configuración y hayamos movido nuestra aplicación web a la carpeta apropiada, podemos iniciar NGINX usando el siguiente comando:

sudo service nginx start

Después de eso, cada vez que cambiamos algo en nuestra configuración, solo tenemos que volver a cargarlo (sin tiempo de inactividad) usando el comando a continuación.

service nginx reload

Por último, podemos verificar el estado de NGINX usando el comando a continuación.

service nginx status

Conclusión

Con tantas funciones listas para usar, NGINX puede ser una excelente manera de servir su aplicación o incluso usarse como un proxy HTTP o equilibrador de carga para sus otros servidores web. Comprender la forma en que NGINX funciona y maneja las solicitudes le dará mucho poder para escalar y equilibrar la carga de sus aplicaciones.