Compartir a través de

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

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 esta parte, debe tener una aplicación web ASP.NET Core instalada e implementada en Linux.

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

Objetivo de esta parte

Las partes anteriores de esta serie mostraron 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 la aplicación back-end ASP.NET Core no se estaba ejecutando cuando Nginx intentó reenviar el tráfico a él.

El problema se resolvió temporalmente mediante la ejecución manual de la aplicación 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 que 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 trabajar 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 el ASP.NET Core al tener IIS como proxy, IIS ASP.NET Core Module (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 ASP.NET Core

Recuerde que el systemctl comando se usa para administrar los "servicios" o "demonios". 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 demonios cuando se cierra el proceso. Estos 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 nginx status de systemctl.

Este es el aspecto del archivo de servicio Nginx.

Captura de pantalla del comando cat.

Archivo de servicio de ejemplo para aplicaciones de 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 es autoexplicativo. 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á después de 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 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

Usará vi para crear y editar el archivo de servicio. El archivo de servicio irá a 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 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 debe aparecer un identificador de proceso junto a él. La salida del comando también muestra las pocas líneas finales 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 después de 10 segundos.

Hay un paso final: el servicio se está ejecutando pero no 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 ASP.NET Core, ya que la ha configurado para que se inicie automáticamente después de reiniciar un servidor o una finalización del proceso.

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

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

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

Por lo tanto, siempre que se detenga el servicio ASP.NET Core, debe reiniciarse en 10 segundos. Para probar este comportamiento, forzará la detención del proceso. Puede esperar que se inicie de nuevo en 10 segundos.

Nota:

Identificador de proceso actual de la aplicación ASP.NET Core. El identificador de proceso del 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 man señal, 9 es SIGKILL (señal de eliminación). Puede abrir las páginas de Ayuda mediante el man comando "kill and signal" para obtener más información sobre este tema.

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 matara, el proceso de ASP.NET Core tenía un identificador de proceso de 5084.
  • El estado del servicio indicó que se ha eliminado el proceso que usa PID 5084 y se activa de nuevo porque se configura 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 iniciarse automáticamente en un usuario diferente.