Compartir a través de

Parte 2.6: Ejecución de dos aplicaciones ASP.NET Core al mismo tiempo

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 principales de ASP.NET se ejecuten en paralelo, escuchen en puertos diferentes y procesen solicitudes entrantes.

Requisitos previos

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

  • Los SDK de .NET Core 3.1 y .NET 5.0 están 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 (escuchando en el puerto 5000).
  • Una ASP.NET aplicación Core que se está ejecutando y configurada 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.
  • Ejemplo de error ASP.NET aplicación Core que se descarga y extrae en el directorio /var/buggyamb_v1.1 .

La primera aplicación de demostración de ASP.NET Core que se usó en esta serie es una aplicación ASP.NET Core 5.0. La segunda aplicación es una aplicación 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:

Para comprobar la versión instalada de los entornos de ejecución y los SDK, ejecute el dotnet --info comando . La instalación de .NET Core se ha analizado en las 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, escuchando en puertos diferentes y procesando solicitudes entrantes.

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

Ejecución de la segunda aplicación

Ejecute una segunda aplicación como servicio 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 indicó que copie la aplicación de depuración de pruebas en el directorio /var/buggyamb_v1.1/ y, a continuación, ejecute la aplicación mediante el dotnet /var/buggyamb_v1.1/BuggyAmb.dll comando . Puede aparecer el siguiente mensaje de error:

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

Captura de pantalla del mensaje de error de E/S.

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

Captura de pantalla del comando sudo netstat.

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

Captura de pantalla del comando cat.

Esta es la primera aplicación ASP.NET Core que se configuró en esta serie. Escucha en el puerto 5000. Por lo tanto, nuestra nueva ASP.NET aplicación de buggy Core no puede escuchar en el mismo puerto.

Nota:

Has aprendido algo nuevo aquí. Hay un directorio denominado /proc. Si muestra 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 información de memoria o CPU. Por ahora, no se centre en esto porque lo analizaremos cuando tratamos 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 realmente la segunda aplicación ASP.NET Core en un puerto diferente.

Configuración de la segunda aplicación ASP.NET Core para escuchar en un puerto diferente

Hay diferentes maneras de lograr este objetivo:

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

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

Captura de pantalla del comando dotnet urls.

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

Creación de 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 Environment=ASPNETCORE_URLS=http://localhost:5001 línea declarará una variable de entorno denominada ASPNETCORE_URLS e indicará a nuestra aplicación que escuche 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/ . Como hizo antes, use el editor vi 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 variable de ASPNETCORE_URLS entorno:

Captura de pantalla del comando sudo vi.

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

Captura de pantalla del comando systemctl status.

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

Captura de pantalla del comando localhost de curl.

La aplicación aún no se puede probar desde el cliente porque está escuchando en el puerto 5001. Este puerto no se permite en la configuración del firewall. Dado que 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 determinado nombre de host. Por ejemplo, podría 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, continuaremos configurando Nginx como lo describimos en esta parte.

Pasos siguientes

Parte 2.7: Configuración de un segundo sitio web con nombre de host en Nginx