Parte 2.2: Instalación de Nginx y configuración como servidor proxy inverso

Se aplica a: .NET Core 2.1, .NET Core 3.1, .NET 5

En este artículo se presenta cómo instalar Nginx y configurarlo como servidor proxy inverso.

Requisitos previos

Para seguir los ejercicios de esta parte, debe tener una aplicación web ASP.NET Core creada e implementada en la carpeta /var .

Objetivo de esta parte

En la parte anterior, creó una aplicación web de ASP.NET Core mediante la herramienta de la CLI de .NET y la aplicación se implementa en la carpeta /var . La aplicación también se configuró para escuchar en el puerto 5000 para las solicitudes HTTP y se quitó la redirección HTTPS.

En este momento, los clientes deben proporcionar el número de puerto al conectarse a la aplicación (por ejemplo, http://localhost:5000). Sin embargo, este no es el comportamiento deseado.

Nuestros objetivos en esta parte son los siguientes:

• Los clientes deben poder navegar sin tener que proporcionar un número de puerto. Por ejemplo, los clientes deben conectarse mediante http://localhost.
• La aplicación web debe iniciarse automáticamente si se detiene por algún motivo o después de reiniciar el equipo.

En la sección siguiente, usará Nginx como servidor proxy para enrutar las solicitudes HTTP realizadas al puerto 80 a nuestra aplicación .NET en su lugar. También configurará la aplicación para que se inicie automáticamente.

¿Qué es Nginx?

Nginx es un servidor web popular, ligero y rápido. Se puede ejecutar en Linux y Windows, y se puede configurar como un servidor proxy inverso.

¿Qué es un demonio?

Nginx se ejecuta como demonio. Un demonio es un término alternativo para un servicio que se ejecuta en segundo plano. Al igual que los servicios que se ejecutan en Windows, los demonios se pueden configurar para que se inicien automáticamente durante el inicio. Configurará la aplicación ASP.NET Core para que se ejecute como demonio.

Instalación de Nginx mediante APT

La instalación de Nginx es sencilla. Ejecute el sudo apt install nginx comando para instalar el programa en la máquina virtual Ubuntu.

Una vez finalizada la instalación, ejecute whereis nginx para detectar dónde está instalado el programa. Puede ver dónde se encuentran los archivos de configuración de Nginx inspeccionando la salida. En la captura de pantalla siguiente se muestra que los archivos de configuración se encuentran en la carpeta /etc/nginx .

Nota:

Si ejecuta una distribución distinta de Ubuntu o Debian, puede encontrar el comando de instalación del administrador de paquetes equivalente o las instrucciones de la documentación oficial de instalación de Nginx.

Administración de servicios mediante systemctl

Si no ve que Nginx se está ejecutando, puede iniciarlo explícitamente ejecutando sudo systemctl start nginx. Aunque en este ejercicio se muestran los systemctl comandos de Nginx, estos comandos se usan para configurar la aplicación web para que se inicie automáticamente como demonio.

Una vez finalizada la instalación, Nginx ya está configurado para iniciarse automáticamente. Nginx se ejecuta como demonio. Puede comprobar el estado del demonio mediante systemctl.

El systemctl comando se usa para administrar "servicios" para tareas como mostrar el estado del servicio o iniciarlo y detenerlo. Algunos parámetros disponibles son start, stop, restart, enable, disable y status. Para comprobar el estado de Nginx, ejecute systemctl status nginx.

Este comando genera información útil. Como se muestra en esta captura de pantalla, Nginx está en active (running) estado y el identificador de proceso de la instancia de Nginx es 8539. Observe también las instrucciones enabled y vendor preset: enabled . Enabled significa que este demonio se iniciará cuando se reinicie la máquina y vendor preset: enabled significa que Nginx está habilitado de forma predeterminada cuando está instalado. Por lo tanto, Nginx se iniciará automáticamente cuando se inicie el servidor.

Prueba de la instalación de Nginx

De forma predeterminada, Nginx escucha en el puerto 80. Dado que se está ejecutando, debería poder acceder a la página principal de Nginx al examinar localhost. Use curl para probar Nginx mediante la ejecución curl localhostde . El texto resaltado amarillo en la captura de pantalla siguiente muestra la página web predeterminada de Nginx. Por lo tanto, Nginx se está ejecutando:

opciones de comando systemctl

Los servicios o demonios se pueden administrar mediante el systemctl comando . Iniciar, detener o realizar cambios requiere acceso de superusuario. Por lo tanto, debe agregar el sudo prefijo a estos comandos.

Reiniciar demonios

Es posible que tenga que reiniciar los demonios de vez en cuando. Para reiniciar un demonio, ejecute sudo systemctl restart <daemon_name>. Para reiniciar Nginx, ejecute sudo systemctl restart nginx. Asegúrese de comprobar el estado de Nginx antes y después de ejecutar este comando para supervisar los cambios en el identificador de proceso.

Detener demonios

Para detener un demonio, ejecute sudo systemctl stop <daemon_name>. Para detener Nginx, ejecute y, a continuación, compruebe sudo systemctl stop nginxel estado de Nginx ejecutando systemctl status nginx de nuevo. Esta vez, el servicio se muestra como inactivo (inactivo) pero aún habilitado. Esto significa que, aunque el servicio no se está ejecutando, se iniciará automáticamente después de reiniciar el servidor.

Nota:

El systemctl status comando también muestra varias líneas de entradas de registro anteriores para el demonio.

Después de detener Nginx, vuelva a ejecutar curl localhost .

Nota:

La conexión se rechaza porque nada escucha el tráfico entrante en el puerto 80.

Deshabilitar demonios

Deshabilitar un demonio es diferente de detener un demonio. Un demonio deshabilitado podría ejecutarse, pero no se iniciará automáticamente después de reiniciar el servidor. Para deshabilitar el demonio de Nginx, ejecute sudo systemctl disable nginxy compruebe el estado de Nginx.

En esta captura de pantalla se muestra que Nginx no se está ejecutando y está deshabilitado. Esto significa que Nginx no se iniciará automáticamente después de un reinicio.

Iniciar demonios

Para iniciar un demonio, ejecute sudo systemctl start <daemon_name>. Para iniciar Nginx, ejecute y sudo systemctl start nginxcompruebe de nuevo el estado del servicio.

En esta captura de pantalla se muestra que Se ha iniciado Nginx, pero sigue deshabilitado. Aunque el servicio se está ejecutando, Nginx no se iniciará automáticamente después de un reinicio porque es un servicio deshabilitado.

Habilitación de demonios

Habilitar un servicio significa que se iniciará automáticamente después de un reinicio. Para habilitar Nginx, ejecute sudo systemctl enable nginxy compruebe de nuevo el estado de Nginx.

En esta captura de pantalla se muestra que Nginx se está ejecutando y se iniciará después de reiniciar el servidor.

Configuración de Nginx como proxy inverso para enrutar las solicitudes a la aplicación ASP.NET Core

Ahora que ha aprendido a iniciar, detener y reiniciar el servicio Nginx, configurará Nginx como proxy inverso para enrutar las solicitudes realizadas en el puerto 80 a la aplicación ASP.NET Core que escucha en el puerto 5000.

Esta es la configuración necesaria. Algunas de las partes clave están resaltadas.

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen        80;
    server_name _;
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
  }
}

Esta configuración indica lo siguiente:

• Nginx escuchará en el puerto 80 para todas las solicitudes (directiva: listen 80).
• Nginx enrutará las solicitudes a http://localhost:5000 (directiva: proxy_pass http://localhost:5000)

Nota:

Línea server_name _ del código. Se usa como directiva catch-all. Si desea obtener más información sobre server_name, consulte la documentación oficial.

Los cambios de configuración aparecen sencillos. Usaremos este código para reemplazar la server sección de directiva en el archivo de configuración. ¿Pero dónde está el archivo de configuración?

Busque el archivo de configuración de Nginx correcto.

El archivo de configuración principal de Nginx es /etc/nginx/nginx.conf. Para inspeccionar la configuración, use el cat /etc/nginx/nginx.conf comando y busque la directiva de servidor.

Desplácese por la configuración para buscar la directiva de servidor. Debería esperar que no lo encuentre. Podemos colocar los cambios de configuración deseados en algún lugar dentro del archivo de configuración. Sin embargo, lo ideal es que no quiera reemplazar el archivo de configuración original. Esto es para evitar la introducción de errores de configuración que podrían impedir que el servidor se inicie correctamente. La server sección no está en el archivo de configuración principal. Si sigue desplazando por el archivo de configuración, descubrirá que hay algunas include directivas.

Las directivas include facilitan la administración de la configuración dividiendola en fragmentos que se incluirán en el archivo de configuración principal. El archivo de configuración principal se puede mantener sencillo y algunos elementos de configuración específicos se pueden mover a otros archivos. Las líneas resaltadas de esta captura de pantalla indican lo siguiente:

• Nginx cargará la configuración de cada archivo .conf que se encuentra en el directorio /etc/nginx/conf.d .
• Nginx cargará las configuraciones de cada archivo que se encuentra en el directorio /etc/nginx/sites-enabled .

Si inspecciona estos directorios, no encontrará ningún archivo de configuración en /etc/nginx/conf.d. Sin embargo, hay un archivo en /etc/nginx/sites-enabled.

El archivo de configuración predeterminado tiene el aspecto de un candidato primo para hospedar la configuración que estamos buscando. Si inspecciona el archivo /etc/nginx/sites-enabled/default mediante cat /etc/nginx/sites-enabled/default, verá que la directiva de servidor predeterminada se coloca en el código siguiente.

Por lo tanto, el archivo /etc/nginx/sites-enabled/default tendrá que editarse para cambiar la configuración.

Edición del archivo de configuración mediante vi

Ha aprendido a editar archivos al editar el archivo Startup.cs para quitar el redireccionamiento HTTPS de la canalización de ASP.NET. Ahora, usará vi de nuevo para cambiar el archivo de configuración nginx.

Sugerencia

Realice siempre una copia de seguridad de los archivos que va a cambiar. Si algo va mal después de la edición, puede usar esa copia para restaurar el archivo a su estado anterior. En este caso, ejecute cp /etc/nginx/sites-enabled/default ~/nginx-default-backup para copiar el archivo de configuración en el directorio principal. El nombre del archivo de copia de seguridad será nginx-default-backup. Observe que la copia de seguridad no se realizó en el mismo directorio que el archivo original. Esto se debe a que Nginx carga todos los archivos de configuración de ese directorio y no desea interrumpir la configuración cargando dos versiones diferentes de la directiva de servidor.

Ejecute sudo vi /etc/nginx/sites-enabled/default para editar el archivo de configuración y reemplazar la directiva de servidor, como se muestra en la captura de pantalla siguiente.

Estas son algunas sugerencias y trucos para editar archivos mediante vi:

• Puede desplazarse hacia arriba y hacia abajo mediante las teclas de dirección.
• Para entrar en el modo de edición, presione la tecla Insertar o I . Mientras esté en modo de edición, habrá un mensaje --INSERT-- en la esquina inferior izquierda.
• En el modo de edición, puede usar el teclado para eliminar caracteres de uno en uno.
• En el modo de edición, las operaciones de copia y pegado funcionan junto con la mayoría de los terminales. Por lo tanto, puede copiar el contenido de este artículo y pegarlo en vi.
• Para salir del modo de edición, presione Esc.
• Puede eliminar líneas más fácilmente en modo normal. En modo normal, vaya al principio de una línea que desea eliminar y escriba dd. El dd comando elimina toda la línea. También puede escribir 5dd para eliminar cinco líneas a la vez. Sin embargo, esta opción debe usarse con precaución para evitar eliminar contenido adicional.
• El artículo Sobre cómo eliminar líneas en Vim/Vi es una buena opción para aprender a eliminar varias líneas en vi.
• Para salir de vi y guardar los cambios, escriba :wq!y presione Entrar. Aquí, los dos puntos (:) significan que está ejecutando un comando, w significa escribir los cambios, q significa salir y ! significa invalidar los cambios.
• Para salir sin guardar los cambios, escriba :q!y presione Entrar.

Ahora se guardan los cambios y tiene que reiniciar el servicio Nginx para que estos cambios surtan efecto. Antes de reiniciar el servicio, puede ejecutar el sudo nginx -t comando para probar el archivo de configuración. Cuando se ejecuta este comando, Nginx comprueba la sintaxis del archivo de configuración y, a continuación, intenta abrir los archivos a los que se hace referencia en el archivo de configuración.

Como puede ver aquí, el archivo de configuración que se cambió parece ser correcto.

Tenemos que reiniciar Nginx para que los cambios surtan efecto:

sudo systemctl restart nginx

Después del reinicio, espera ver una respuesta de la aplicación ASP.NET Core al realizar una solicitud a http://localhost porque Nginx debe funcionar como proxy inverso para las solicitudes realizadas al puerto 80.

Reinicie el servicio Nginx para que los cambios surtan efecto y, a continuación, realice una solicitud a localhost mediante la ejecución curl localhostde . Sin embargo, se producirá un error en este comando. El siguiente paso consiste en ejecutar wget localhosty, a continuación, buscar algunas sugerencias sobre el origen del problema.

Solución de problemas del proxy nginx

En la captura de pantalla anterior, verá esta información:

Resolving localhost (localhost)... 127.0.0.1  
Connecting to localhost (localhost)|127.0.0.1|:80... connected.  
HTTP request sent, awaiting response... 502 Bad Gateway  
2020-12-27 21:15:53 ERROR 502: Bad Gateway.

Las primeras y segundas líneas indican que puede resolver localhost y conectarse en el 127.0.0.1:80 socket. Por lo tanto, Nginx debe estar en ejecución. Para comprobarlo, puede ejecutar el systemctl status nginx comando .

La tercera línea indica el origen del problema. Recibe un mensaje de error HTTP 502 Puerta de enlace incorrecta . La puerta de enlace incorrecta HTTP 502 está relacionada con servidores proxy. Significa que el proxy inverso no pudo conectarse a la aplicación back-end. En este caso, es la aplicación web de ASP.NET Core que debe ejecutarse y escuchar en el puerto 5000 para las solicitudes. Deberíamos comprobar si la aplicación web también se está ejecutando.

Para empezar a solucionar problemas, ejecute el mismo netstat comando que antes. Esta vez, use el grep para filtrar el puerto 5000 de la aplicación. A continuación, ejecute netstat -tlp | grep 5000.

Esta salida de ejemplo indica que nada está escuchando en el puerto 5000. Por lo tanto, esta es la causa de la respuesta HTTP 502 procedente de Nginx porque no encuentra un proceso que escucha en el puerto 5000.

La solución consiste en iniciar la aplicación ASP.NET Core. Sin embargo, antes de continuar, puede revisar otro enfoque para solucionar este problema. No todos los problemas son tan fáciles de corregir como simplemente mirar algunas líneas de contenido de registro y encontrar la causa principal. A veces, tiene que profundizar en otros registros del sistema y de la aplicación.

Dado que trabaja estrechamente con Nginx al configurar ASP.NET aplicaciones core en Linux, se recomienda saber qué tipo de registros proporciona Nginx y el sistema operativo para solucionar problemas.

Comprobación de los registros de Nginx

Si vuelve a ejecutar cat /etc/nginx/nginx.conf y, a continuación, busca , logging settingsdebe observar lo siguiente.

Esto muestra que Nginx tiene dos tipos de registros: Registros de acceso y Registros de errores. Estos se almacenan en el directorio /var/log/nginx/ .

Los registros de acceso son similares a los archivos de registro de IIS. Una inspección rápida del contenido revela que se asemejan a la siguiente captura de pantalla.

Los registros de acceso no muestran información nueva que no sea el estado de respuesta HTTP 502 que ya conocía. También puede inspeccionar los registros de errores ejecutando cat /var/log/nginx/error.log. Estos revelan mucho más sobre la causa del problema.

Las indicaciones son claras: Nginx puede obtener la solicitud del cliente, pero no puede conectarse al upstream servidor en http://127.0.0.1:5000 y a la aplicación ASP.NET Core que debe haber estado ejecutando y escuchando en ese puerto.

Solución alternativa

Para solucionar este problema, inicie manualmente la aplicación ASP.NET Core. Conéctese al servidor mediante una segunda sesión de terminal y, a continuación, ejecute la aplicación ASP.NET Core como antes.

Mientras se ejecuta la aplicación ASP.NET Core, cambie a la otra sesión de terminal y ejecute el mismo curl localhost comando. Ahora, puede acceder a la aplicación ASP.NET Core que se ejecuta detrás de Nginx. En la captura de pantalla siguiente se muestra que ha realizado una solicitud a localhost, nginx administra la solicitud y se enruta a la aplicación back-end y ha recibido una respuesta de la aplicación ASP.NET Core.

Ahora ha configurado Nginx para que se comporte como un proxy inverso para la aplicación ASP.NET Core que se ejecuta en Linux.

Sin embargo, si la aplicación ASP.NET Core no se inicia después de un reinicio, ¿cuál será el resultado? ¿Qué ocurrirá si la aplicación web se bloquea y no se inicia hasta que observe que no se está ejecutando? ¿Debería iniciar la aplicación ASP.NET Core después de cada reinicio de la terminación del proceso?

Pasos siguientes

Parte 2.3: Configuración de la aplicación ASP.NET Core para iniciarse automáticamente

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.