Condividi tramite

Parte 2.6 : eseguire due applicazioni core ASP.NET contemporaneamente

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

Questo articolo illustra come eseguire due applicazioni core ASP.NET side-by-side, restare in ascolto su porte diverse ed elaborare le richieste in ingresso.

Prerequisiti

Per completare questa parte dell'esercitazione, è necessario configurare gli elementi seguenti:

  • Sia .NET Core 3.1 che .NET 5.0 SDK installati.
  • Nginx viene eseguito automaticamente e in ascolto delle richieste inviate sulla porta 80.
  • Nginx configurato come proxy inverso e routing di tutte le richieste all'applicazione ASP.NET Core (in ascolto sulla porta 5000).
  • Una ASP.NET'applicazione Core in esecuzione e configurata per l'avvio automatico dopo il riavvio del server o dopo l'arresto del processo.
  • Firewall locale Linux abilitato e configurato per consentire il traffico SSH e HTTP.
  • Esempio di buggy ASP.NET'applicazione Core scaricata ed estratta nella directory /var/buggyamb_v1.1 .

La prima applicazione demo ASP.NET Core usata in questa serie è un'applicazione ASP.NET Core 5.0. La seconda applicazione è un'applicazione ASP.NET Core 3.1. Se non sono installati gli SDK .NET Core 3.1 e .NET 5.0, installare quello mancante prima di continuare.

Note

È possibile controllare la versione installata di runtime e SDK eseguendo il dotnet --info comando . L'installazione di .NET Core è stata illustrata nelle parti precedenti di questa serie.

Obiettivo di questa parte

Alla fine di questa parte, si avranno due applicazioni core ASP.NET in esecuzione side-by-side, in ascolto su porte diverse ed elaborazione delle richieste in ingresso.

La maggior parte delle azioni che verranno eseguite in questa parte sarà simile: creare un file di servizio per la seconda applicazione ASP.NET Core in modo che possa essere avviato ogni volta che il server viene riavviato o il processo viene arrestato.

Eseguire la seconda applicazione

Eseguire una seconda applicazione come servizio simile alla prima applicazione in esecuzione. Prima di creare il file del servizio, assicurarsi che venga eseguito correttamente.

Tenere presente che, nei capitoli precedenti, è stato richiesto di copiare l'applicazione di debug di test nella directory /var/buggyamb_v1.1/ e quindi eseguire l'applicazione usando il dotnet /var/buggyamb_v1.1/BuggyAmb.dll comando . Potrebbe essere visualizzato il messaggio di errore seguente:

System.IO.IOException: impossibile eseguire l'associazione all'indirizzo : indirizzo http://127.0.0.1:5000già in uso.

Screenshot del messaggio di errore di I/O.

Per questo messaggio, un altro processo usa già la porta 5000. Questo è ovvio. Ma come è possibile apprendere quale processo usa la porta? Eseguendo il sudo netstat -tulpn | grep 5000 comando . Nello screenshot seguente il PID è 12536 e il nome del processo è dotnet. Probabilmente si noterà che l'ID del processo sarà diverso:

Screenshot del comando sudo netstat.

Il passaggio successivo consiste nel comprendere quale ASP.NET'applicazione Core è ospitata dal processo dotnet in ascolto sulla porta 5000. È possibile eseguire il cat /proc/12536/cmdline comando per ottenere un risultato simile allo screenshot seguente.

Screenshot del comando cat.

Si tratta della prima applicazione ASP.NET Core configurata in questa serie. È in ascolto sulla porta 5000. Di conseguenza, la nuova applicazione ASP.NET Core buggy non può essere in ascolto sulla stessa porta.

Note

Hai imparato qualcosa di nuovo qui. Esiste una directory denominata /proc. Se si elenca il contenuto di questa directory, verranno visualizzate le directory denominate per ogni PID in esecuzione in quel momento. Ogni sottocartella includerà diversi file che è possibile usare per ottenere proprietà di ogni processo, ad esempio la riga di comando e le informazioni sulla memoria o sulla CPU. Per il momento, non concentrarsi su questo perché verrà illustrato quando si tratta di strumenti e processi.

La soluzione al problema del conflitto di porte non consiste nell'interrompere l'esecuzione della prima applicazione. Poiché l'obiettivo è avere entrambe le applicazioni in esecuzione contemporaneamente, la soluzione consiste effettivamente nell'eseguire la seconda applicazione ASP.NET Core su una porta diversa.

Configurare la seconda applicazione ASP.NET Core per l'ascolto su una porta diversa

Esistono diversi modi per raggiungere questo obiettivo:

  • Usare UseUrls() per impostare la porta in Program.cs: significa che la porta è hardcoded nell'applicazione. Anche se è possibile leggere la porta da un file di configurazione, non si vuole modificare l'applicazione e compilarla di nuovo. Pertanto, questo training non si concentrerà su questa soluzione.
  • Argomenti della riga di comando: usare il parametro quando si esegue l'applicazione --urls .
  • Variabili di ambiente: impostare l'URL per l'ascolto per l'uso di una variabile di ambiente. Usare DOTNET_URLS o ASPNETCORE_URLS i nomi delle variabili di ambiente per ottenere questo risultato.

Entrambe le variabili di ambiente e l'approccio dell'argomento della riga di comando sono opzioni da considerare. Provare a testare l'opzione --urls , come illustrato nello screenshot seguente.

Screenshot del comando dotnet urls.

Tenere presente che l'obiettivo è eseguire l'applicazione come servizio. È quindi necessario disporre di un file di servizio in cui è possibile impostare le variabili di ambiente. È possibile impostare il comando eseguibile come illustrato in precedenza oppure impostare le variabili di ambiente. Gli esempi seguenti usano le variabili di ambiente per configurare l'applicazione per l'ascolto su una porta alternativa.

Creare un file di unità di servizio per la seconda applicazione

Nel file dell'unità di servizio si userà la definizione di servizio seguente. Tenere presente che la seconda applicazione verrà eseguita nella directory /var/buggyamb_v1.1 .

Note

La Environment=ASPNETCORE_URLS=http://localhost:5001 riga dichiarerà una variabile di ambiente denominata ASPNETCORE_URLS e indicherà all'applicazione di rimanere in ascolto sulla porta 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

Il nome del file del servizio sarà buggyamb.service e verrà creato nella directory /etc/systemd/system/. Proprio come in precedenza, usare l'editor vi ed eseguire il sudo vi /etc/systemd/system/buggyamb.service comando per creare il file di definizione del servizio. Copiare e incollare questa configurazione e salvarla. Anche in questo caso, si noti come impostare la ASPNETCORE_URLS variabile di ambiente:

Screenshot del comando sudo vi.

A questo punto è stata configurata l'applicazione Web core ASP.NET buggy per l'esecuzione come daemon. Questo è sufficiente per raggiungere l'obiettivo dichiarato all'inizio della formazione? Abilitare e avviare il servizio eseguendo i sudo systemctl enable buggyamb.service comandi e sudo systemctl start buggyamb.service . Controllare quindi lo stato del servizio eseguendo systemctl status buggyamb.service, come illustrato nello screenshot seguente.

Screenshot del comando systemctl status.

A questo punto è ora possibile verificare se l'applicazione BuggyAmb funziona come previsto. Eseguire il curl localhost:5001 comando per visualizzare la pagina iniziale di BuggyAmb HTML nella console, come illustrato nello screenshot seguente.

Screenshot del comando curl localhost.

L'applicazione non può ancora essere testata dal client perché è in ascolto sulla porta 5001. Questa porta non è consentita nelle impostazioni del firewall. Poiché Nginx non espone la porta a Internet, è possibile configurare Nginx per l'ascolto sulla porta 80 e instradare il traffico a BuggyAmb quando vengono effettuate richieste HTTP in ingresso usando un determinato nome host. Ad esempio, è possibile usare i nomi host: http://buggyamb o http://buggyweb. È anche possibile usare qualsiasi altro nome host desiderato.

Per il momento, l'obiettivo è avere il secondo ASP.NET'applicazione Core in esecuzione side-by-side con la prima applicazione demo. Nel capitolo successivo si continuerà a configurare Nginx come descritto in questa parte.

Passaggi successivi

Parte 2.7 - Configurare un secondo sito Web con nome host in Nginx