Parte 2.3: Configurare l'applicazione ASP.NET Core per l'avvio automatico

Si applica a: .NET Core 2.1, .NET Core 3.1, .NET 5

Questo articolo illustra come configurare l'applicazione ASP.NET Core per assicurarsi che l'applicazione venga avviata automaticamente dopo il riavvio del server.

Prerequisiti

Per seguire gli esercizi in questa parte, è necessario avere un'applicazione Web ASP.NET Core installata e distribuita in Linux.

È anche necessario configurare il server Web Nginx come proxy inverso per instradare le richieste all'applicazione back-end ASP.NET Core dalla porta 80.

Obiettivo di questa parte

Le parti precedenti di questa serie hanno illustrato come configurare Nginx come proxy inverso e come risolvere un errore proxy HTTP 502. La causa del codice di risposta HTTP 502 è che l'applicazione back-end ASP.NET Core non era in esecuzione quando Nginx ha tentato di inoltrare il traffico a esso.

Il problema è stato risolto temporaneamente eseguendo manualmente l'applicazione ASP.NET Core. Ma cosa succede se l'applicazione si arresta in modo anomalo? Oppure il server deve essere riavviato? Riavviare manualmente l'applicazione ASP.NET Core ogni volta che non è una soluzione pratica. Di conseguenza, in questa sezione si configurerà Linux per avviare l'applicazione dopo l'arresto anomalo.

Finora, Nginx e ASP.NET Core sono stati configurati per lavorare insieme. Nginx è in ascolto sulla porta 80 e instrada le richieste all'applicazione ASP.NET Core in ascolto sulla porta 5000. Anche se Nginx viene avviato automaticamente, l'applicazione ASP.NET Core deve essere avviata manualmente ogni volta che il server viene riavviato. In caso contrario, l'applicazione ASP.NET Core viene chiusa correttamente o si arresta in modo anomalo.

Se si esegue ASP.NET Core con IIS come proxy, IIS ASP.NET Core Module (ANCM) gestisce la gestione dei processi e il processo di ASP.NET Core viene avviato automaticamente. Un'altra opzione consiste nell'eseguire il ASP.NET Core as a Service in Windows in modo che la funzionalità di avvio automatico possa essere configurata non appena viene avviato il computer.

Creare un file di servizio per l'applicazione ASP.NET Core

Tenere presente che il systemctl comando viene usato per gestire i "servizi" o "daemon". Un daemon è un concetto simile a quello di un servizio Windows. Tale servizio può essere riavviato automaticamente all'avvio del sistema.

Che cos'è un file di servizio?

In Linux sono presenti anche file di configurazione unità che hanno un'estensione ".service" usata per controllare il comportamento dei daemon quando il processo viene chiuso. Questi file sono noti anche come file di servizio, file di unità e file di unità di servizio.

Questi file di servizio si trovano in una delle directory seguenti:

• /usr/lib/systemd/: Archivia i file del servizio per le applicazioni scaricate
• /etc/systemd/system/: archivia i file del servizio creati dagli amministratori di sistema

Esaminare il file del servizio Nginx. Viene installato tramite una gestione pacchetti. Il file di configurazione deve trovarsi nella cartella /usr/lib/systemd/system/ . L'esecuzione del systemctl status nginx comando visualizza anche il percorso del file del servizio.

Questo è l'aspetto del file del servizio Nginx.

File di servizio di esempio per le applicazioni core ASP.NET

Il contenuto del file di unità di esempio seguente è tratto da Host ASP.NET Core in 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

Ecco alcuni aspetti chiave di questo contenuto:

• WorkingDirectory è la directory in cui si pubblica l'applicazione.
• ExecStart è il comando effettivo che avvia l'applicazione.
• Restart=always è autoesplicativo. Questo processo viene sempre avviato se si arresta per qualche motivo, sia manualmente che a causa di un arresto anomalo.
• RestartSec=10 è anche autoesplicativo. Dopo l'arresto del processo, il processo verrà avviato dopo il termine di 10 secondi.
• SyslogIdentifier è importante. Significa "identificatore del log di sistema". Le informazioni sul daemon vengono registrate con questo nome nei log di sistema. È anche possibile usare questo identificatore per trovare il PID del processo.
• User è l'utente che gestisce il servizio. Deve esistere nel sistema e avere la proprietà appropriata dei file dell'applicazione.
• È possibile impostare un numero qualsiasi di variabili di ambiente nel file del servizio.

Note

L'utente www-data è un utente speciale nel sistema. È possibile usare questo account. Verrà creato un nuovo utente per la pratica delle autorizzazioni utente in Linux. Tuttavia, è consigliabile usare www-data se non si vuole creare un altro utente Linux.

Creare un file di servizio per l'applicazione ASP.NET Core

Si userà vi per creare e modificare il file del servizio. Il file del servizio verrà inserito nella cartella /etc/systemd/system/ . Tenere presente che, in questa serie, è stata pubblicata la prima applicazione nella cartella /var/firstwebapp/ . Pertanto, WorkingDirectory deve puntare a questa cartella.

Ecco il file di configurazione finale:

[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

Eseguire sudo vi /etc/systemd/system/myfirstwebapp.service , incollare la configurazione finale e salvare il file.

In questo modo viene completata la configurazione necessaria per l'esecuzione dell'applicazione Web ASP.NET Core come daemon.

Poiché l'applicazione Web è ora configurata come servizio, è possibile controllarne lo stato eseguendo systemctl status myfirstwebapp.service. Come si può vedere nello screenshot seguente, l'applicazione è disabilitata (non verrà avviata automaticamente dopo un riavvio del sistema) e non è attualmente in esecuzione.

Per avviare il servizio, eseguire il sudo systemctl start myfirstwebapp.service comando e quindi controllare di nuovo lo stato. Questa volta dovrebbe essere visualizzato il servizio in esecuzione e accanto all'ID del processo dovrebbe essere elencato. L'output del comando mostra anche le poche righe finali dei log di sistema per il servizio appena creato e mostra che il servizio è in ascolto su http://localhost:5000.

Se l'applicazione Web si arresta in modo imprevisto, verrà avviata automaticamente dopo 10 secondi.

È presente un passaggio finale: il servizio è in esecuzione ma non abilitato. "Abilitato" significa che viene avviato automaticamente dopo l'avvio del server. Si tratta della configurazione finale desiderata. Eseguire il comando seguente per assicurarsi che il servizio sia abilitato:

sudo systemctl enable myfirstwebapp.service

Questa è un'attività cardine per l'applicazione ASP.NET Core perché è stata configurata per l'avvio automatico dopo un riavvio del server o una terminazione del processo.

Verificare se ASP.NET'applicazione Core viene riavviata automaticamente

Prima di passare alla parte successiva, assicurarsi che tutto funzioni come previsto. La configurazione corrente è la seguente

• Nginx viene eseguito automaticamente e rimane in ascolto delle richieste inviate sulla porta 80.
• Nginx è configurato come proxy inverso e instrada le richieste all'applicazione ASP.NET Core. L'applicazione è in ascolto sulla porta 5000.
• L'applicazione ASP.NET Core è configurata per l'avvio automatico dopo il riavvio del server o se il processo si arresta o si arresta in modo anomalo.

Pertanto, ogni volta che si arresta il servizio ASP.NET Core, deve essere riavviato in 10 secondi. Per testare questo comportamento, si forza l'arresto del processo. Ci si può aspettare che inizi di nuovo in 10 secondi.

Note

ID del processo corrente dell'applicazione ASP.NET Core. L'ID del processo per il tentativo mostrato qui è stato 5084 prima dell'interruzione del processo. Per trovare l'ID processo per l'applicazione ASP.net Core, eseguire il systemctl status myfirstwebapp.service comando .

Per forzare l'arresto del processo, eseguire il comando seguente:

sudo kill -9 <PID>

Note

9 ecco il tipo di segnale. Secondo il comando signal man , 9 è SIGKILL (segnale kill). Per altre informazioni su questo argomento, è possibile aprire le pagine della Guida usando il man comando "kill and signal".

Eseguire il systemctl status myfirstwebapp.service comando immediatamente dopo il kill comando, attendere circa 10 secondi e quindi eseguire di nuovo lo stesso comando.

In questo screenshot è possibile visualizzare le informazioni seguenti:

• Prima dell'interruzione, il processo ASP.NET Core aveva un ID processo 5084.
• Lo stato del servizio indica che il processo che usa PID 5084 è stato terminato e viene attivato di nuovo perché il riavvio automatico è configurato.
• Pochi secondi dopo, è stato avviato un nuovo processo (PID 5181).

Se si tenta di accedere al sito usando curl localhost, si noterà che l'applicazione ASP.NET Core continua a rispondere.

Passaggi successivi

Parte 2.3.1 - [Facoltativo] Configurare l'applicazione ASP.NET Core in Linux per l'avvio automatico con un utente diverso.