Parte 2.2: Instalar Nginx y configurarlo como un 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 un servidor proxy inverso.

Requisitos previos

Para seguir los ejercicios de este elemento, debe tener una ASP.NET Core web creada e implementada en la carpeta /var.

Objetivo de esta parte

En el elemento anterior, creó una ASP.NET Core web 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 siguiente sección, 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 un 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.

Instalar Nginx mediante APT

Instalar Nginx es sencillo. Ejecute el sudo apt install nginx comando para instalar el programa en la máquina virtual de 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 el resultado. La siguiente captura de pantalla 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, encontrará el comando de instalación equivalente del administrador de paquetes o las instrucciones de la documentación oficial de instalación de Nginx.

Administrar servicios mediante systemctl

Si no ve que Nginx se está ejecutando, puede iniciarlo explícitamente ejecutando sudo systemctl start nginx . Aunque este ejercicio mostrará los comandos de Nginx, estos comandos se usan para configurar la aplicación web para que se inicie automáticamente systemctl 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 comando se usa para administrar "servicios" para tareas como mostrar el estado del servicio systemctl 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 estado y el identificador de proceso de la instancia active (running) de Nginx es 8539. Observe también las enabled instrucciones vendor preset: enabled and. Enabled significa que este demonio se iniciará cuando se reinicie la máquina y significa que Nginx está habilitado de forma predeterminada vendor preset: enabled cuando está instalado. Por lo tanto, Nginx se iniciará automáticamente cuando se inicie el servidor.

Probar la instalación de Nginx

De forma predeterminada, Nginx escucha en el puerto 80. Dado que se está ejecutando, debería tener acceso a la página principal de Nginx al examinar localhost. Se curl usa para probar Nginx ejecutando curl localhost . El texto resaltado amarillo de la siguiente captura de pantalla 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.

Demonioes de reinicio

Es posible que deba 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 del 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 nginx el estado de Nginx ejecutándose de systemctl status nginx nuevo. Esta vez, el servicio se muestra como inactivo (inactivo) pero aún está 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 curl localhost ejecutar.

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 estar en ejecución, pero no se iniciará automáticamente después de reiniciar el servidor. Para deshabilitar el demonio Nginx, ejecute y compruebe sudo systemctl disable nginx el estado de Nginx.

Esta captura de pantalla 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 el y, a continuación, compruebe de nuevo el sudo systemctl start nginx estado del servicio.

Esta captura de pantalla muestra que Nginx se ha iniciado pero aún está deshabilitado. Aunque el servicio se está ejecutando, Nginx no se iniciará automáticamente después de un reinicio porque es un servicio deshabilitado.

Habilitar demonios

Habilitar un servicio significa que se iniciará automáticamente después de un reinicio. Para habilitar Nginx, ejecute y vuelva a comprobar sudo systemctl enable nginx el estado de Nginx.

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

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

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

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

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 keep-alive;
        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 enruta las solicitudes a http://localhost:5000 (directiva: proxy_pass http://localhost:5000 )

Nota

La server_name _ línea 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 server de directiva 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 de servidor. Debe esperar no encontrarlo. 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 sigues desplazándose por el archivo de configuración, descubrirás 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 en 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 principal para hospedar la configuración que estamos buscando. Si inspecciona el archivo /etc/nginx/sites-enabled/default mediante , verá que la directiva de servidor predeterminada se coloca dentro cat /etc/nginx/sites-enabled/default del 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

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

Sugerencia

Siempre hacer una copia de seguridad de los archivos que está cambiando. 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 desea interrumpir la configuración cargando dos versiones diferentes de directiva de servidor.

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

Estos son algunos consejos 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 uno a uno.
• En el modo de edición, las operaciones de copiar y pegar 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.
• Cómo eliminar líneas en vim / vi artículo es un buen para aprender a eliminar varias líneas en vi.
• Para salir de vi y guardar los cambios, escriba :wq! y, a continuación, presione ENTRAR. Aquí, los dos puntos ( ) significa que está ejecutando un comando, significa escribir los cambios, significa salir y significa : w invalidar los q ! cambios.
• Para salir sin guardar los cambios, escriba :q! y, a continuación, presione ENTRAR.

Los cambios se guardan ahora y debe reiniciar el servicio Nginx para que estos cambios entren en vigor. 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 tengan efecto:

sudo systemctl restart nginx

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

Reinicie el servicio Nginx para que los cambios entren en vigor y, a continuación, realice una solicitud a localhost ejecutando curl localhost . Sin embargo, este comando producirá un error. El siguiente paso es ejecutar wget localhost y, a continuación, buscar algunas sugerencias sobre el origen del problema.

Solucionar el problema de 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.

La primera y la segunda 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 Bad Gateway. Http 502 Bad Gateway está relacionado con servidores proxy. Significa que el proxy inverso no se pudo conectar a la aplicación back-end. En este caso, es la aplicación ASP.NET Core web que debe ejecutarse y escuchar las solicitudes en el puerto 5000. 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 .

Este resultado de ejemplo indica que no se escucha nada en el puerto 5000. Por lo tanto, esta es la causa de la respuesta HTTP 502 que viene de Nginx porque puede encontrar un proceso que esté escuchando en el puerto 5000.

La solución es iniciar la ASP.NET Core aplicación. Sin embargo, antes de ir más lejos, puede revisar otro enfoque para solucionar este problema. No todos los problemas son tan fáciles de solucionar como simplemente mirar unas pocas líneas de contenido de registro y encontrar la causa raíz. A veces, tienes que profundizar en otros registros del sistema y de la aplicación.

Dado que trabaja estrechamente con Nginx al configurar aplicaciones ASP.NET Core en Linux, le sugerimos que aprenda qué tipo de registros Nginx y el sistema operativo proporciona para la solución de problemas.

Comprobar los registros de Nginx

Si vuelve a ejecutar y, a cat /etc/nginx/nginx.conf continuación, busque el , debe tener en cuenta lo logging settings 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 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 acerca de la causa del problema.

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

Solución alternativa

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

Mientras se ASP.NET Core aplicación, cambie a la otra sesión de terminal y ejecute el mismo curl localhost comando. Ahora, puede obtener acceso a la ASP.NET Core que se ejecuta detrás de Nginx. La siguiente captura de pantalla muestra que realizó una solicitud a localhost, que Nginx la controló y enrutó a la aplicación back-end y que recibió una respuesta de la aplicación ASP.NET Core cliente.

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 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 terminación del proceso?

Siguientes pasos

Parte 2.3: configurar la 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.