Parte 2.2: Instalar Nginx y configurarlo 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 este elemento, debe tener una ASP.NET Core aplicación web creada e implementada en la carpeta /var.

Objetivo de esta parte

En el elemento anterior, creó una aplicación web 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 las solicitudes HTTP y se quitó el redireccionamiento 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 que se realizan 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 iniciarse automáticamente durante el inicio. Configurará la aplicación de 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 descubrir 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 que no sea Ubuntu o Debian, puede encontrar el comando de instalación equivalente del administrador de paquetes 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 mediante la ejecución de sudo systemctl start nginx. Aunque este ejercicio mostrará 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 enabled instrucciones 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 se instala. 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 de curl localhost. 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 los 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.

Reinicio de 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 sudo systemctl stop nginxy, a continuación, vuelva a comprobar el estado de Nginx.systemctl status nginx Esta vez, el servicio se muestra como inactivo (inactivo) pero todavía 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.

Deshabilitación de demonios

Deshabilitar un demonio es diferente de detener un demonio. Un demonio deshabilitado podría estar en ejecución, pero no se iniciará automáticamente después de reiniciar el servidor. Para deshabilitar el demonio de Nginx, ejecute sudo systemctl disable nginxy, a continuación, 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.

Inicio de demonios

Para iniciar un demonio, ejecute sudo systemctl start <daemon_name>. Para iniciar Nginx, ejecute y sudo systemctl start nginxvuelva a comprobar el estado del servicio.

En esta captura de pantalla se muestra que Nginx se ha iniciado, pero que todavía está 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 vuelva a comprobar 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, a continuación, configurará Nginx como proxy inverso para enrutar las solicitudes realizadas en el puerto 80 a la aplicación de 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 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. Esto se usa como una directiva catch-all. Si desea obtener más información sobre server_name, consulte la documentación oficial.

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

Buscar 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 del servidor. Deberías esperar que no lo encuentres. Podemos colocar los cambios de configuración deseados en algún lugar dentro del archivo de configuración. Sin embargo, lo ideal sería no 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 desplazándose por el archivo de configuración, descubrirá que hay algunas include directivas.

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

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

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 parece un candidato ideal 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.

Editar el 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 de nginx.

Sugerencia

Realice siempre una copia de seguridad de los archivos que va a cambiar. Si algo iba a salir 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 quiere 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 flecha.
• 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 el 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 la eliminación de contenido adicional.
• Cómo eliminar líneas en Vim / Vi artículo es una buena 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.

Los cambios se guardan ahora 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 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 de curl localhost. Sin embargo, se producirá un error en este comando. El siguiente paso es ejecutar wget localhosty, a continuación, buscar algunas sugerencias sobre el origen del problema.

Solución del problema del proxy de 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.

La primera y segunda línea 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 Bad Gateway . Http 502 Bad Gateway está relacionado con servidores proxy. Esto significa que el proxy inverso no pudo conectarse a la aplicación back-end. En este caso, es la aplicación web ASP.NET Core la que debe ejecutarse y escuchar en el puerto 5000 para las solicitudes. Debemos 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 escucha en el puerto 5000. Por lo tanto, esta es la causa de la respuesta HTTP 502 que procede de Nginx porque puede encontrar 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 examinar 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 Core aplicaciones en Linux, se recomienda saber qué tipo de registros proporciona Nginx y el sistema operativo para la solución de 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. 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 parece 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 debería haber estado ejecutándose y escuchando en ese puerto.

Solución alternativa

Para solucionar este problema, inicie la aplicación ASP.NET Core manualmente. 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 de ASP.NET Core que se ejecuta detrás de Nginx. En la captura de pantalla siguiente se muestra que realizó una solicitud a localhost, que Nginx controló la solicitud y se enrutó a la aplicación back-end y que recibió 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? ¿Debe iniciar la aplicación ASP.NET Core después de cada reinicio de la finalización del proceso?

Pasos siguientes

Parte 2.3: Configuración de la aplicación de ASP.NET Core para que se inicie 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.