Parte 2.1: Creare e configurare applicazioni ASP.NET Core in Linux

Si applica a: .NET 8 e versioni successive

Questo articolo illustra come creare e configurare applicazioni ASP.NET Core in Linux.

Prerequisiti

Per seguire gli esercizi in questa parte, è necessario avere installato .NET SDK. Per installare l'SDK, vedere le istruzioni di installazione nella parte 1, se necessario.

Obiettivo di questa parte

Informazioni su come creare un'applicazione Web ASP.NET Core usando l'interfaccia della riga di comando di .NET in Linux e come pubblicare l'applicazione nella directory /var . Man mano che si apprendono questi concetti, si eseguiranno alcune attività di base, ad esempio l'uso di file e cartelle e l'esecuzione di comandi come utente con privilegi. Si apprenderà anche come modificare i file usando l'editor di testo vi in Linux.

CLI .NET

In base a questa documentazione dell'interfaccia della riga di comando di .NET, l'interfaccia della riga di comando di .NET è una toolchain multipiattaforma per lo sviluppo, la compilazione, l'esecuzione e la pubblicazione di applicazioni .NET. L'interfaccia della riga di comando di .NET viene installata insieme a .NET SDK.

Questi training usano spesso il dotnet comando . Questo comando è potente e ha due funzioni principali:

• Fornisce comandi per l'uso di progetti .NET. Ad esempio, dotnet build compila un progetto. Ogni comando definisce le proprie opzioni e gli argomenti. Tutti i comandi supportano l'opzione --help per la stampa di brevi spiegazioni su come usare il comando .
• Esegue applicazioni .NET.

Si userà il dotnet new comando per creare il primo progetto ASP.NET Core in Linux. Questo comando ottiene il tipo del progetto come argomento. I tipi di progetto sono illustrati in questo documento. È anche possibile visualizzare un elenco di tipi eseguendo dotnet new senza un parametro . I tipi di progetto correlati al Web sono evidenziati in giallo nello screenshot seguente.

Creare un'applicazione Web ASP.NET Core con SDK

Si userà l'interfaccia della riga di comando di .NET per creare la prima applicazione Web usando il comando seguente:

dotnet new <template_type> -n <project_name> -o <output_directory>

Queste regole si applicano quando si usa dotnet new:

• Il comando crea i file di progetto nella directory di output. Se si omette il -o <output_directory> segmento, il progetto verrà creato nella directory corrente. È sempre possibile usare l'opzione -o .
• Se la cartella non esiste, il comando lo crea.
• Se si omette il -n <project_name> segmento, il nome del progetto sarà uguale al nome della directory.

È possibile trovare nomi creativi per la directory e il progetto stesso. Tenere tuttavia presente che Linux fa distinzione tra maiuscole e minuscole. Per questo esercizio, usare il valore più conservativo AspNetCoreDemo come nome del progetto e crearlo nella firstwebapp directory .

Per creare il progetto, eseguire il comando seguente:

dotnet new webapp -n AspNetCoreDemo -o firstwebapp 

Esaminare l'output per visualizzare i nomi di directory e progetto. Lo screenshot seguente elenca anche il contenuto della directory di output. È necessario avere familiarità con la struttura di directory se è stata creata un'applicazione Web ASP.NET Core in Windows in precedenza.

È stata creata la prima applicazione. L'attività successiva verrà eseguita. Modificare la directory nella cartella del progetto ed eseguire dotnet run.

Note

Gli elementi seguenti in questo screenshot:

• L'applicazione Web è in ascolto sulla porta 5001 per le richieste HTTPS e rimane in ascolto sulla porta 5000 per le richieste HTTP.
• La radice del contenuto si trova nella home directory.

È consigliabile non eseguire l'applicazione nella home directory. Verrà pubblicato in un'altra directory in un secondo momento, ma è necessario testarlo prima di pubblicarlo. È possibile premere CTRL+C per arrestare l'applicazione. Ma per il momento, mantenerlo in esecuzione e aprire una nuova sessione del terminale usando il metodo preferito per connettersi alla macchina virtuale Linux. Per questo esempio si userà di nuovo PowerShell.

Testare il sito Web da un altro terminale

Nella nuova sessione del terminale verificare che l'applicazione sia in ascolto sulle porte 5000 e 5001. Linux ha lo stesso netstat comando di Windows. Eseguire netstat insieme all'opzione -tlp . È possibile acquisire familiarità con le netstat opzioni in questo articolo oppure esaminare il file della Guida eseguendo man netstat o info netstat.

Ecco l'output del netstat -tlp comando dalla seconda sessione del terminale. Mostra che il processo AspNetCoreDemo è in esecuzione usando PID 781 ed è in ascolto sulle porte 5000 e 5001 sia per IPv4 che per IPv6.

È possibile usare curl e wget per testare il sito Web. Entrambi i comandi effettuano una chiamata HTTP sul lato di destinazione, ma si comportano in modo diverso:

• Curl è semplicemente uno strumento del browser da riga di comando. Effettua una richiesta HTTP alla destinazione specificata e mostra solo l'output normale della risposta HTTP. Ad esempio, mostra il markup di origine HTML per un'applicazione Web.
• Wget è un downloader HTTP. Effettua una richiesta HTTP e scarica la risorsa specificata. Ad esempio, wget http://server/file.zip scarica file.zip da http://server e lo salva nella directory corrente.

Il wget comando mostra anche altri dettagli, ad esempio il reindirizzamento e i messaggi di errore che è possibile ricevere. Pertanto, è possibile usarlo come versione primitiva di uno strumento di traccia HTTP ogni volta che è necessario.

Per altre informazioni sulla differenza tra curl e wget, vedere la pagina Web StackExchange.

In questa serie di training è stato usato wget in precedenza per scaricare il file di gestione pacchetti .deb dai server Microsoft prima di installare .NET.

Se si esegue curl http://localhost, non si verifica nulla. Questo significa molto probabilmente che non esiste alcuna risposta HTTP. È quindi possibile eseguire wget http://localhost per verificare se vengono visualizzate altre informazioni quando si tenta di accedere al sito.

Questo è ciò che si verifica ora:

• Si effettua una richiesta HTTP a http://localhost:5000e ci si connette correttamente. Ciò significa che l'applicazione accetta le connessioni sulla porta 5000.
• Si riceve una risposta http 307 di reindirizzamento temporaneo dall'applicazione che punta a una posizione HTTPS sicura: https://localhost:5001.
• Wget è abbastanza intelligente da seguire questo reindirizzamento e effettuare una nuova richiesta a https://localhost:5001.
• Ci si connette di nuovo. Tuttavia, wget non considera attendibile il certificato SSL. Pertanto, la connessione non riesce.

Il wget comando consiglia di risolvere questo problema usando l'opzione --no-check-certificate per connettersi in modo non sicuro. Tuttavia, questo approccio prevede le impostazioni del certificato SSL che non rientrano nell'ambito per questo training. È invece possibile configurare l'applicazione ASP.NET Core in modo che non reindirizzi le richieste HTTP a HTTPS. Se si ha familiarità con ASP.NET Core application development (o solo configurazione), modificare il file Startup.cs per rimuovere la configurazione di reindirizzamento.

Modificare i file usando vi

È possibile usare l'editor di testo vi per le distribuzioni Linux per modificare tutti i tipi di file di testo normale. Verrà usato in questo training per riconfigurare l'applicazione.

Prima di poterla modificare, è necessario chiudere l'applicazione. Chiudere prima di tutto la sessione del terminale aperta. Premere quindi CTRL+C per arrestare l'applicazione.

Per modificare Startup.cs file, eseguire il comando seguente:

vi ~/firstwebapp/Startup.cs

Note

Questo comando avvia l'editor vi e quindi carica il file. Il collegamento ~ (tilde) si riferisce alla home directory in cui è stato creato il progetto. Ovvero, il comando punta a /home/<YourName>/firstwebapp/Startup.cs.

Premere il tasto I (Inserisci) per abilitare la modalità di modifica. A questo punto dovrebbe essere visualizzato -- INSERT - nella parte inferiore della riga di comando. Usare i tasti di direzione per spostarsi all'interno del file. Impostare come app.UseHsTs()commento le righe ; e app.UseHttpsRedirection(); aggiungendole // all'inizio, come illustrato nello screenshot seguente.

Premere ESC per uscire dalla modalità di modifica, immettere :wq!, quindi premere INVIO. Si noti che il carattere due punti (:) indica che si sta immettendo un comando, w significa scrivere, q significa uscire e ! forza la scrittura.

Dopo aver premuto INVIO, le modifiche devono essere salvate. È possibile verificare le modifiche eseguendo cat ~/firstwebapp/Startup.cs. Questo comando visualizza il contenuto del file Startup.cs .

Riavviare l'applicazione. A tale scopo, modificare la directory corrente nella ~/firstwebapp directory ed eseguire dotnet run di nuovo. Aprire quindi un'altra sessione del terminale nel server ed eseguire di nuovo il curl http://localhost:5000 comando. Questa volta, il comando deve restituire il contenuto HTML della home page.

È stata eseguita correttamente la prima app Web core ASP.NET in Linux.

Distribuire l'applicazione nella directory /var

L'obiettivo principale di questo esercizio è ospitare l'applicazione Web dietro un proxy inverso in modo che i client connessi possano accedere all'applicazione da un altro computer usando solo il nome host senza il numero di porta. Questo è ciò che ci si aspetta di verificarsi in scenari reali. Per completare questa attività, si userà Nginx in un secondo momento. Ma prima di eseguire questa operazione, pubblicare l'applicazione nella directory /var . Ciò è dovuto al fatto che è consigliabile non eseguire l'applicazione nella home directory di un utente.

Tenere presente che la directory /var viene usata per archiviare i file di contenuto e di log da diverse applicazioni, ad esempio Apache e Nginx. Questa procedura verrà seguita pubblicando l'applicazione Web appena creata in /var.

Passare alla cartella del progetto e quindi eseguire dotnet publish per creare una cartella di pubblicazione. Copiare la cartella nella directory /var .

Lo screenshot mostra che il dotnet publish comando ha creato file di pubblicazione nella cartella ~/firstwebapp/bin/Debug/net5.0/publish/ . Il comando seguente è stato quindi usato per copiare tutti i file nella cartella /var/firstwebapp/ :

sudo cp -a ~/firstwebapp/bin/Debug/net5.0/publish/ /var/firstwebapp/

Note

Si noti l'utilizzo di sudo prima del comando di copia. Questa operazione viene usata perché gli utenti standard non dispongono dell'autorizzazione di scrittura per la directory /var . Pertanto, è necessario eseguire il comando come utente con privilegi avanzati.

Per eseguire l'applicazione da una cartella pubblicata, eseguire il comando seguente:

dotnet /var/firstwebapp/AspNetCoreDemo.dll

Se si vuole, è possibile eseguire questi test usando gli stessi curl comandi e wget . Ciò è dovuto al fatto che l'applicazione rimarrà in ascolto sulla porta 5000 per le richieste HTTP.

Durata del processo e passaggi successivi

Se l'applicazione richiede un tempo di attività costante, l'esecuzione di applicazioni .NET all'interno di una sessione utente interattiva non è una procedura consigliata per i motivi seguenti:

• Se gli utenti devono terminare le sessioni, ad esempio chiudendo PuTTY o il client SSH di PowerShell o chiudendo la sessione, l'applicazione verrà arrestata.
• Se il processo viene terminato per qualche motivo (ad esempio, il processo si arresta in modo anomalo a causa di un'eccezione non gestita), non viene avviato automaticamente e deve essere riavviato manualmente.
• Se il server viene riavviato, l'applicazione non verrà avviata automaticamente.

Passaggi successivi

Parte 2.2 - Installare Nginx e configurarlo come server proxy inverso

Assicurarsi che l'applicazione Web venga avviata automaticamente. Installare e configurare Nginx come proxy inverso per instradare le richieste HTTP effettuate alla porta 80 all'applicazione dotnet ( in modo che i client possano connettersi senza dover fornire il numero di porta).

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti