Parte 2.7: Configurar un segundo sitio web mediante el nombre de host en Nginx

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

En este artículo se describe cómo configurar un segundo sitio web en Nginx mediante el nombre de host y cómo probar la configuración.

Requisitos previos

Para esta parte, debe tener configurados los siguientes elementos:

• Nginx se ejecuta automáticamente y escucha las solicitudes que se envían en el puerto 80.
• Nginx configurado como proxy inverso y enrutando todas las solicitudes HTTP entrantes a la primera aplicación de ASP.NET Core que escucha en el puerto 5000 (puede usar cualquier aplicación ASP.NET Core como una aplicación back-end que se ejecute en este puerto).
• Esa primera ASP.NET Core configurada para ejecutarse siempre (si el proceso se detiene o se reinicia el servidor, la aplicación ASP.NET Core debe iniciarse automáticamente).
• El firewall local de Linux habilitado y configurado para permitir el tráfico entrante SSH y HTTP.
• Una segunda aplicación ASP.NET Core que está configurada para escuchar en el puerto 5001 (esta aplicación también debe configurarse para que siempre se ejecute y la aplicación ASP.NET Core de ejemplo de BuggyAmb debe configurarse como la segunda aplicación de la instalación).

Objetivo de esta parte

Actualmente, hay un sitio configurado en Nginx. Cualquier solicitud que llegue al puerto 80 a Nginx se enruta a ese sitio. El nombre de host no importa en esta configuración. Use la dirección IP o cualquier nombre de host que se resuelva en la dirección IP. Todas las solicitudes se enrutarán al sitio web predeterminado. Ese sitio web predeterminado actúa como proxy inverso y enruta las solicitudes a la primera aplicación ASP.NET Core que escucha en el puerto 5000.

En esta parte del tutorial, crearás un segundo sitio web en Nginx. Ese sitio web también actuará como proxy inverso y cualquier solicitud que tenga un nombre de host específico se enruta a la segunda aplicación ASP.NET Core que escucha en el puerto 5001.

También configurará el sitio web para que escuche un nombre de host específico. Al final, habrá dos sitios que son accesibles y que tienen estos nombres de host:

• Primer sitio web: http://myfirstwebsite dirigirá el tráfico a la primera ASP.NET Core de demostración.
• Segundo sitio web: dirigirá el tráfico a la segunda aplicación de ASP.NET Core http://buggyamb de ejemplo de errores.

Agregue myfirstwebsite y al archivo hosts de los equipos cliente Windows y buggyamb Linux. De este modo, puede usar estas direcciones URL para probar la nueva configuración.

Estos nombres de host son solo para demostración. No dude en usar cualquier otro nombre de host que prefiera, siempre que use los mismos nombres de host de forma coherente durante los ejercicios de esta parte.

Configurar una segunda web con un nombre de host en Nginx

Si recuerda, uno de los directorios en los que Nginx carga las configuraciones de sitio es /etc/nginx/sites-enabled/. Actualmente, hay un archivo de configuración predeterminado. El archivo es similar a la siguiente captura de pantalla.

Nota

Observe las partes resaltadas porque tendrá que modificar estas:

• server_name: Puede establecer el nombre de host deseado aquí. Actualmente, se configura en el valor _ . Esto significa cualquier nombre de host.
• proxy_pass: esta es una aplicación ASP.NET Core que se está ejecutando y escuchando en una dirección URL determinada. Las solicitudes se enrutan a esta dirección URL.

Configurar el primer sitio web para escuchar en el encabezado host http://myfirstwebsite . Para ello, cambie el archivo de configuración server_name /etc/nginx/sites-enabled/default, como se muestra en la siguiente captura de pantalla. Como aviso, tendrás que usar el sudo vi /etc/nginx/sites-enabled/default comando para editar este archivo.

Cree un segundo archivo de configuración de Nginx para el segundo sitio web. Use este archivo como plantilla para crear una copia de este archivo en el mismo directorio de configuración. Asigne al archivo unbuggyamb.config.

sudo cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/buggyamb.config

Edite el archivo de configuración ejecutando el sudo vi /etc/nginx/sites-enabled/buggyamb.config comando. Esta es la versión final del archivo /etc/nginx/sites-enabled/buggyamb.config.

La configuración resultante debe tener dos archivos de configuración en el directorio de configuración del sitio Nginx: buggyamb.config y predeterminado. Tendrás que establecer Nginx para volver a cargar los cambios de configuración. Sin embargo, primero debe probar la nueva configuración para asegurarse de que no se introdujeron errores al realizar cambios. Ejecute el sudo nginx -t comando y compruebe que la configuración es correcta. A continuación, sudo nginx -s reload ejecute para volver a cargar la configuración y lea los nuevos cambios.

Probar la nueva configuración

Establezca los myfirstwebsite nombres de host y para que se buggyamb resuelvan en las direcciones IP correctas. Al tener acceso a los sitios desde el equipo Linux, estos nombres de host deben resolverse en 127.0.0.1 y para los clientes externos, como el cliente Windows equipo. Los nombres de host deben resolverse en la dirección IP pública de la máquina virtual Linux. Puede recuperar esa dirección IP desde Azure Portal.

Nota

Las asignaciones de hosts se almacenan en el archivo /etc/hosts en Linux y en el archivo C:\WINDOWS\System32\drivers\etc\hosts de Windows.

Este es el contenido del archivo hosts de Linux.

Puede ejecutar los curl myfirstwebsite comandos y para realizar solicitudes a cada uno de los dos curl buggyamb sitios.

Este es el curl myfirstwebsite resultado. La respuesta parece mostrar correctamente el contenido HTML de la página principal de la aplicación principal de demostración ASP.NET que se implementó inicialmente y escucha en el puerto 5000.

Y este es el curl buggyamb resultado. Muestra el contenido HTML de la página principal de la aplicación de ejemplo BuggyAmb que se ejecuta en el puerto 5001.

Debe poder examinar las mismas direcciones URL desde el equipo cliente mediante un explorador. Esto también debe funcionar si configura el archivo hosts correctamente. Esto es lo que se muestra al navegar desde un explorador que se ejecuta http://buggaymb en un Windows equipo.

Hasta este punto, tiene la siguiente configuración:

• Nginx que hospeda dos sitios web:

  • El primer sitio web escucha las solicitudes mediante el encabezado host y enruta las solicitudes a nuestra myfirstwebsite aplicación ASP.NET Core demostración. Esta aplicación escucha en el puerto 5000.
  • El segundo sitio web escucha el tráfico HTTP entrante mediante el valor de encabezado de host de y enruta las solicitudes a la segunda aplicación de ASP.NET Core buggyamb de ejemplo. Esta aplicación escucha en el puerto 5001.

• Ambas ASP.NET Core se ejecutan como servicios que se reinician automáticamente cuando se reinicia el servidor o las aplicaciones dejan de responder.

• El firewall local de Linux está habilitado y configurado para permitir tráficos SSH y HTTP.

Sugerencias para solucionar problemas

Puede recibir HTTP 502: error de puerta de enlace no segura al examinar un sitio. "HTTP 502- Bad Gateway" significa que Nginx no pudo comunicarse con la aplicación back-end ASP.NET Core cliente. Esto ocurre si la aplicación back-end no se está ejecutando.

En este caso:

• Asegúrese de que ambas ASP.NET Core escuchan en puertos diferentes. Uno debe escuchar en el puerto 5000 mientras que el otro debe escuchar en el puerto 5001.
• Asegúrese de que ambas ASP.NET Core están configuradas para iniciarse automáticamente.
• Compruebe el estado de los ASP.NET Core de aplicaciones que usan los systemctl status comandos. Si no se está ejecutando, para solucionar problemas, examine los registros del sistema ejecutando el journalctl comando. Se syslogIdentifier usa para filtrar los registros.
• Se asegura de que .NET Core 3.1 y .NET 5.0 estén instalados. Un sitio usa .NET Core 3.1 y el otro usa .NET 5.0.

Siguientes pasos

Parte 3.1: Prepararse para la solución de problemas