Parte 2.7: Configuración de un segundo sitio web mediante el uso del 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 enrutar todas las solicitudes HTTP entrantes a la primera aplicación 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 ejecuta en este puerto).
• Esa primera aplicación ASP.NET Core configurada para ejecutarse siempre (si el proceso se detiene o se reinicia el servidor, la aplicación ASP.NET Core debería 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 configurada para escuchar en el puerto 5001 (esta aplicación también debe configurarse para ejecutarse siempre y la aplicación BuggyAmb de ejemplo ASP.NET Core debe configurarse como la segunda aplicación de la configuració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á 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 enrutará 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 accesibles y que tienen estos nombres de host:

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

Agregue myfirstwebsite y buggyamb al archivo de hosts de los equipos Windows y Linux cliente. 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 de forma coherente los mismos nombres de host en los ejercicios de esta parte.

Configuración de una segunda web mediante un nombre de host en Nginx

Si recuerda, uno de los directorios en los que Nginx carga las configuraciones del 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 los elementos resaltados porque tendrá que modificar estos elementos:

• server_name: puede establecer el nombre de host deseado aquí. Actualmente, se configura en el valor _. Esto significa cualquier nombre de host.
• proxy_pass: se trata de una aplicación ASP.NET Core real que se ejecuta y escucha en una dirección URL determinada. Las solicitudes se enrutan a esta dirección URL.

Configure el primer sitio web para escuchar en el encabezado http://myfirstwebsitede host . Para ello, cambie en server_name el archivo de configuración /etc/nginx/sites-enabled/default , como se muestra en la captura de pantalla siguiente. Como recordatorio, tendrá 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 el nombre buggyamb.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 de Nginx: buggyamb.config y default. Tendrá 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, ejecute sudo nginx -s reload para volver a cargar la configuración y leer los nuevos cambios.

Prueba de la nueva configuración

Establezca los nombres de myfirstwebsite host y buggyamb para resolverlos en las direcciones IP correctas. Al acceder 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 equipo cliente windows. 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 en Windows.

Este es el contenido del archivo de hosts de Linux.

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

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

Y aquí está la curl buggyamb salida. Esto muestra el contenido HTML de la página principal de la aplicación de ejemplo BuggyAmb que se ejecuta en el puerto 5001.

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

Hasta este punto, tiene la siguiente configuración:

• Nginx que hospeda dos sitios web:

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

• Ambas aplicaciones 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 de solución de problemas

Es posible que reciba un error http 502: puerta de enlace incorrecta al examinar un sitio. "HTTP 502 - Puerta de enlace incorrecta" significa que Nginx no pudo comunicarse con la aplicación back-end ASP.NET Core. Esto ocurre si la aplicación back-end no se está ejecutando.

En este caso:

• Asegúrese de que ambas aplicaciones ASP.NET Core escuchen 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 aplicaciones ASP.NET Core están configuradas para iniciarse automáticamente.
• Compruebe el estado de los servicios de aplicación de ASP.NET Core que usan los systemctl status comandos . Si no se está ejecutando, solucione los problemas mediante el examen de los registros del sistema mediante la ejecución del journalctl comando . Use syslogIdentifier para filtrar los registros.
• Asegúrese de que están instalados .NET Core 3.1 y .NET 5.0. Un sitio usa .NET Core 3.1, el otro usa .NET 5.0.

Pasos siguientes

Parte 3.1: Preparación para la solución de problemas