Parte 2.6: ejecutar dos aplicaciones ASP.NET Core simultáneamente

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

En este artículo se describe cómo hacer que dos aplicaciones ASP.NET Core se ejecuten en paralelo, escuchar en diferentes puertos y procesar solicitudes entrantes.

Requisitos previos

Para completar esta parte del tutorial, debe tener los siguientes elementos configurados:

• Sdk de .NET Core 3.1 y .NET 5.0 instalados.
• 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 a la aplicación ASP.NET Core (escucha en el puerto 5000).
• Una ASP.NET Core que se ejecuta y configura para iniciarse automáticamente después de reiniciar el servidor o después de detener el proceso.
• Firewall local de Linux habilitado y configurado para permitir el tráfico SSH y HTTP.
• Aplicación de ASP.NET Core de ejemplo que se descarga y extrae en el directorio /var/buggyamb_v1.1.

La primera ASP.NET Core de demostración que se usó en esta serie es una ASP.NET Core 5.0. La segunda aplicación es una ASP.NET Core 3.1. Si no tiene instalados los SDK de .NET Core 3.1 y .NET 5.0, instale el que falta antes de continuar.

Nota

Puede comprobar la versión instalada de runtimes y SDK ejecutando el dotnet --info comando. La instalación de .NET Core se ha analizado en partes anteriores de esta serie.

Objetivo de esta parte

Al final de esta parte, tendrá dos aplicaciones ASP.NET Core que se ejecutan en paralelo, escuchar en puertos diferentes y procesar solicitudes entrantes.

La mayoría de las acciones que llevará a cabo en esta parte serán similares: cree un archivo de servicio para la segunda aplicación ASP.NET Core de modo que pueda iniciarse siempre que se reinicie el servidor o se detenga el proceso.

Ejecutar la segunda aplicación

Ejecute una segunda aplicación como servicio que sea similar a la primera aplicación que se está ejecutando. Antes de crear el archivo de servicio, asegúrese de que se ejecuta correctamente.

Recuerde que, en capítulos anteriores, se le instruyó copiar la aplicación de depuración de prueba en el directorio /var/buggyamb_v1.1/ y, a continuación, ejecutar la aplicación mediante el dotnet /var/buggyamb_v1.1/BuggyAmb.dll comando. You may receive the following error message:

System.IO.IOException: No se pudo enlazar a la dirección http://127.0.0.1:5000 : dirección que ya está en uso.

Según este mensaje, otro proceso ya usa el puerto 5000. Esto es obvio. Pero, ¿cómo puede saber qué proceso está usando el puerto? Ejecutando el sudo netstat -tulpn | grep 5000 comando. En la siguiente captura de pantalla, el PID es 12536 y el nombre del proceso es dotnet . Lo más probable es que veas que el identificador del proceso será diferente:

El siguiente paso es comprender qué aplicación ASP.NET Core está hospedada por el proceso dotnet que escucha en el puerto 5000. Puedes ejecutar el cat /proc/12536/cmdline comando para obtener un resultado similar a la siguiente captura de pantalla.

Esta es la primera ASP.NET Core que se configuró en esta serie. Está escuchando en el puerto 5000. Por lo tanto, nuestra nueva ASP.NET Core de errores no puede escuchar en el mismo puerto.

Nota

Has aprendido algo nuevo aquí. Hay un directorio denominado /proc. Si enumera el contenido de este directorio, verá directorios con nombre para cada PID que se ejecuta en ese momento. Cada subcarpeta tendrá varios archivos que puede usar para obtener propiedades de cada proceso, como la línea de comandos, y la memoria o la información de la CPU. Por ahora, no se centre en esto porque lo trataremos al tratar las herramientas y los procesos.

La solución al problema de conflicto de puertos no es dejar de ejecutar la primera aplicación. Dado que el objetivo es que ambas aplicaciones se ejecuten al mismo tiempo, la solución es ejecutar la segunda aplicación ASP.NET Core en un puerto diferente.

Configurar la segunda ASP.NET Core para escuchar en un puerto diferente

Hay diferentes maneras de lograr este objetivo:

• Se UseUrls() usa para establecer el puerto en Program.cs: esto significa que el puerto está codificado de forma hard en la aplicación. Aunque podemos leer el puerto desde un archivo de configuración, no desea cambiar la aplicación y compilar de nuevo. Por lo tanto, este aprendizaje no se centrará en esta solución.
• Argumentos de línea de comandos: use --urls el parámetro al ejecutar la aplicación.
• Variables de entorno: establezca la dirección URL para escuchar el uso de una variable de entorno. Use DOTNET_URLS o nombres de variables de entorno para ASPNETCORE_URLS lograrlo.

Tanto las variables de entorno como el enfoque del argumento de línea de comandos son opciones a tener en cuenta. Intente probar la --urls opción, como se muestra en la siguiente captura de pantalla.

Recuerde que el objetivo es ejecutar la aplicación como servicio. Esto requiere que tenga un archivo de servicio donde pueda establecer variables de entorno. Puede establecer el comando ejecutable como se muestra anteriormente o puede establecer variables de entorno. En los ejemplos siguientes se usan variables de entorno para configurar la aplicación para que escuche en un puerto alternativo.

Crear un archivo de unidad de servicio para la segunda aplicación

Usará la siguiente definición de servicio en el archivo de unidad de servicio. Recuerde que la segunda aplicación se ejecutará en el directorio /var/buggyamb_v1.1.

Nota

La línea declarará una variable de entorno denominada y le dirá a nuestra aplicación que escuche Environment=ASPNETCORE_URLS=http://localhost:5001 ASPNETCORE_URLS en el puerto 5001:

[Unit]
Description=BuggyAmb is a really buggy application
 
[Service]
WorkingDirectory=/var/buggyamb_v1.1/
ExecStart=/usr/bin/dotnet /var/buggyamb_v1.1/BuggyAmb.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=buggyamb-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
Environment=ASPNETCORE_URLS=http://localhost:5001
 
[Install]
WantedBy=multi-user.target

El nombre del archivo de servicio será buggyamb.service y se creará en el directorio /etc/systemd/system/. Al igual que antes, use el vi editor y ejecute el sudo vi /etc/systemd/system/buggyamb.service comando para crear el archivo de definición de servicio. Copie y pegue esta configuración y guárdela. De nuevo, observe cómo se establece la ASPNETCORE_URLS variable de entorno:

Ahora ha configurado el buggy ASP.NET Core web para que se ejecute como demonio. ¿Es suficiente para cumplir el objetivo que declaramos al principio del entrenamiento? Habilite e inicie el servicio ejecutando los sudo systemctl enable buggyamb.service sudo systemctl start buggyamb.service comandos and. A continuación, compruebe el estado del servicio ejecutando systemctl status buggyamb.service , como se muestra en la siguiente captura de pantalla.

Está en el punto en el que ahora puede comprobar si la aplicación BuggyAmb funciona según lo esperado. Ejecute el comando para que la página de bienvenida del HTML de BuggyAmb se muestre en la consola, como curl localhost:5001 se muestra en la siguiente captura de pantalla.

La aplicación aún no se puede probar desde el cliente porque está escuchando en el puerto 5001. Este puerto no está permitido en la configuración del firewall. Como Nginx no expone el puerto a Internet, puede configurar Nginx para que escuche en el puerto 80 y enrutar el tráfico a BuggyAmb cuando se realizan las solicitudes HTTP entrantes mediante un nombre de host determinado. Por ejemplo, puede usar los nombres de host: http://buggyamb o http://buggyweb . También puede usar cualquier otro nombre de host que desee.

Por ahora, se cumple el objetivo de que la segunda aplicación ASP.NET Core se ejecute en paralelo con la primera aplicación de demostración. En el siguiente capítulo, seguiremos configurando Nginx tal como lo describimos en esta parte.

Siguientes pasos

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