Parte 2.3: Configuración de la aplicación de ASP.NET Core para que se inicie automáticamente

  • Artículo
  • Tiempo de lectura: 7 minutos

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

En este artículo se presenta cómo configurar la aplicación ASP.NET Core para asegurarse de que la aplicación se inicia automáticamente después de reiniciar el servidor.

Requisitos previos

Para seguir los ejercicios de este elemento, debe tener una aplicación web ASP.NET Core instalada e implementada en Linux.

También tiene que configurar el servidor web de Nginx como un proxy inverso para enrutar las solicitudes a la aplicación ASP.NET Core back-end desde el puerto 80.

Objetivo de esta parte

En las partes anteriores de esta serie se mostró cómo configurar Nginx como proxy inverso y cómo solucionar un error de proxy HTTP 502. La causa del código de respuesta HTTP 502 es que el back-end ASP.NET Core aplicación no se estaba ejecutando cuando Nginx intentó reenviarle el tráfico.

El problema se resolvió temporalmente mediante la ejecución manual de la aplicación de ASP.NET Core. ¿Pero qué ocurre si la aplicación se bloquea? ¿O se debe reiniciar el servidor? Reiniciar manualmente la aplicación ASP.NET Core cada vez no es una solución práctica. Por lo tanto, en esta sección, configurará Linux para iniciar la aplicación después de que se bloquee.

Hasta ahora, ha configurado Nginx y ASP.NET Core para que funcionen juntos. Nginx escucha en el puerto 80 y enruta las solicitudes a la aplicación ASP.NET Core que escucha en el puerto 5000. Aunque Nginx se inicia automáticamente, la aplicación ASP.NET Core debe iniciarse manualmente cada vez que se reinicie el servidor. De lo contrario, la aplicación ASP.NET Core se cierra correctamente o se bloquea.

Si ejecuta la ASP.NET Core con IIS como proxy, el módulo de ASP.NET Core de IIS (ANCM) controla la administración de procesos y el proceso de ASP.NET Core se inicia automáticamente. Otra opción es ejecutar el ASP.NET Core como servicio en Windows para que la característica de inicio automático se pueda configurar en cuanto se inicie el equipo.

Creación de un archivo de servicio para la aplicación de ASP.NET Core

Recuerde que el systemctl comando se usa para administrar los "servicios" o "daemons". Un demonio es un concepto similar al de un servicio de Windows. Este servicio se puede reiniciar automáticamente cuando se inicia el sistema.

¿Qué es un archivo de servicio?

En Linux, también hay archivos de configuración de unidad que tienen una extensión ".service" que se usa para controlar el comportamiento de los demonios cuando se cierra el proceso. También se conocen como archivos de servicio, archivos de unidad y archivos de unidad de servicio.

Estos archivos de servicio se encuentran en uno de los directorios siguientes:

  • /usr/lib/systemd/: almacena archivos de servicio para aplicaciones descargadas
  • /etc/systemd/system/: almacena los archivos de servicio creados por los administradores del sistema.

Inspeccione el archivo de servicio Nginx. Se instala a través de un administrador de paquetes. Su archivo de configuración debe estar en la carpeta /usr/lib/systemd/system/ . Al ejecutar el systemctl status nginx comando también se muestra la ubicación del archivo de servicio.

Captura de pantalla del comando systemctl status nginx.

Este es el aspecto del archivo de servicio de Nginx.

Captura de pantalla del comando cat.

Archivo de servicio de ejemplo para aplicaciones ASP.NET Core

El siguiente contenido de archivo de unidad de ejemplo se toma de Host ASP.NET Core en Linux con Nginx:

[Unit]
Description=Example .NET Web API App running on Ubuntu

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Estos son algunos aspectos clave de este contenido:

  • WorkingDirectory es el directorio donde se publica la aplicación.
  • ExecStart es el comando real que inicia la aplicación.
  • Restart=always se explica por sí mismo. Este proceso siempre se inicia si se detiene por algún motivo, ya sea manualmente o debido a un bloqueo.
  • RestartSec=10 también se explica por sí mismo. Una vez detenido el proceso, se iniciará una vez transcurridos 10 segundos.
  • SyslogIdentifier es importante. Significa "identificador de registro del sistema". La información sobre el demonio se registra con este nombre en los registros del sistema. También puede usar este identificador para buscar el PID del proceso.
  • User es el usuario que administra el servicio. Debe existir en el sistema y tener la propiedad adecuada de los archivos de aplicación.
  • Puede establecer cualquier número de variables de entorno en el archivo de servicio.

Nota

El www-data usuario es un usuario especial en el sistema. Puede usar esta cuenta. Creará un nuevo usuario para practicar los permisos de usuario en Linux. Sin embargo, está bien usar www-data si no desea crear otro usuario de Linux.

Creación de un archivo de servicio para la aplicación ASP.NET Core

vi Usará para crear y editar el archivo de servicio. El archivo de servicio entrará en la carpeta /etc/systemd/system/ . Recuerde que, en esta serie, publicó la primera aplicación en la carpeta /var/firstwebapp/ . Por lo tanto, WorkingDirectory debe apuntar a esta carpeta.

Este es el archivo de configuración final:

[Unit]
Description=My very first ASP.NET Core applications running on Ubuntu

[Service]
WorkingDirectory=/var/firstwebapp/
ExecStart=/usr/bin/dotnet /var/firstwebapp/AspNetCoreDemo.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=myfirstapp-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Ejecute sudo vi /etc/systemd/system/myfirstwebapp.service , pegue la configuración final y guarde el archivo.

Captura de pantalla del comando sudo.

Esto completa la configuración necesaria para que la aplicación web de ASP.NET Core se ejecute como demonio.

Dado que la aplicación web ahora está configurada como un servicio, puede comprobar su estado ejecutando systemctl status myfirstwebapp.service. Como puede ver en la captura de pantalla siguiente, la aplicación está deshabilitada (no se iniciará automáticamente después de reiniciar el sistema) y no se está ejecutando actualmente.

Captura de pantalla del comando systemctl status.

Para iniciar el servicio, ejecute el sudo systemctl start myfirstwebapp.service comando y vuelva a comprobar el estado. Esta vez, debería ver el servicio en ejecución y debería aparecer un identificador de proceso junto a él. La salida del comando también muestra las últimas líneas de los registros del sistema para el servicio recién creado y muestra que el servicio está escuchando en http://localhost:5000.

Captura de pantalla del comando sudo systemctl start.

Si la aplicación web se detiene inesperadamente, se iniciará automáticamente de nuevo después de 10 segundos.

Hay un paso final: el servicio se está ejecutando pero no está habilitado. "Habilitado" significa que se inicia automáticamente después de iniciar el servidor. Esta es la configuración final deseada. Ejecute el siguiente comando para asegurarse de que el servicio está habilitado:

Sudo systemctl enable myfirstwebapp.service

Captura de pantalla del comando sudo systemctl enable.

Este es un hito para la aplicación de ASP.NET Core porque la ha configurado para que se inicie automáticamente después de un reinicio del servidor o una finalización del proceso.

Prueba de si ASP.NET Core aplicación se reinicia automáticamente

Antes de avanzar a la siguiente parte, asegúrese de que todo funciona según lo esperado. La configuración actual es la siguiente:

  • Nginx se ejecuta automáticamente y escucha las solicitudes enviadas en el puerto 80.
  • Nginx está configurado como un proxy inverso y enruta las solicitudes a la aplicación ASP.NET Core. La aplicación escucha en el puerto 5000.
  • La aplicación ASP.NET Core está configurada para iniciarse automáticamente después de reiniciar el servidor o si el proceso se detiene o se bloquea.

Por lo tanto, cada vez que se detenga el servicio de ASP.NET Core, debe reiniciarse en 10 segundos. Para probar este comportamiento, forzará que el proceso se detenga. Puede esperar que se inicie de nuevo en 10 segundos.

Nota

Identificador de proceso actual de la aplicación ASP.NET Core. El identificador del proceso para el intento que se muestra aquí era 5084 antes de que se matara el proceso. Para buscar el identificador de proceso de la aplicación ASP.net Core, ejecute el systemctl status myfirstwebapp.service comando .

Para forzar la detención del proceso, ejecute el siguiente comando:

sudo kill -9 <PID>

Nota

9 este es el tipo de señal. Según el comando de señal man , 9 es SIGKILL (señal de eliminación). Para obtener más información sobre este tema, puede abrir las páginas de Ayuda mediante el man comando "kill and signal".

Ejecute el systemctl status myfirstwebapp.service comando inmediatamente después del kill comando, espere unos 10 segundos y vuelva a ejecutar el mismo comando.

Captura de pantalla del comando kill.

En esta captura de pantalla, puede ver la siguiente información:

  • Antes de que se eliminara, el proceso de ASP.NET Core tenía un identificador de proceso de 5084.
  • El estado del servicio indicó que el proceso que usa PID 5084 se ha eliminado y se está activando de nuevo porque se ha configurado el reinicio automático.
  • Unos segundos después, se inició un nuevo proceso (PID 5181).

Si intenta acceder al sitio mediante curl localhost, debería ver que la aplicación ASP.NET Core sigue respondiendo.

Pasos siguientes

Parte 2.3.1: [Opcional] Configure la aplicación ASP.NET Core en Linux para que se inicie automáticamente en un usuario diferente.