Parte 2.2 - Installare Nginx e configurarlo come server proxy inverso

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

Questo articolo illustra come installare Nginx e configurarlo come server proxy inverso.

Prerequisiti

Per seguire gli esercizi in questa parte, è necessario avere un'applicazione Web core ASP.NET creata e distribuita nella cartella /var .

Obiettivo di questa parte

Nella parte precedente è stata creata un'applicazione Web ASP.NET Core usando lo strumento dell'interfaccia della riga di comando di .NET e l'applicazione viene distribuita nella cartella /var . L'applicazione è stata configurata anche per l'ascolto sulla porta 5000 per le richieste HTTP e il reindirizzamento HTTPS è stato rimosso.

A questo punto, i client devono fornire il numero di porta quando ci si connette all'applicazione , ad esempio http://localhost:5000. Tuttavia, questo non è il comportamento desiderato.

I nostri obiettivi in questa parte sono i seguenti:

• I client devono essere in grado di spostarsi senza dover fornire un numero di porta. Ad esempio, i client devono connettersi usando http://localhost.
• L'applicazione Web deve essere avviata automaticamente se si arresta per qualche motivo o dopo il riavvio del computer.

Nella sezione successiva si userà Nginx come server proxy per instradare le richieste HTTP effettuate alla porta 80 all'applicazione .NET. Si configurerà anche l'applicazione per l'avvio automatico.

Che cos'è Nginx?

Nginx è un server Web popolare, leggero e veloce. Può essere eseguito sia in Linux che in Windows e può essere configurato come server proxy inverso.

Che cos'è un daemon?

Nginx viene eseguito come daemon. Un daemon è un termine alternativo per un servizio eseguito in background. Proprio come i servizi eseguiti in Windows, i daemon possono essere configurati per l'avvio automatico durante l'avvio. Si configurerà l'applicazione ASP.NET Core per l'esecuzione come daemon.

Installare Nginx usando APT

L'installazione di Nginx è semplice. Eseguire il sudo apt install nginx comando per installare il programma nella macchina virtuale Ubuntu.

Al termine dell'installazione, eseguire whereis nginx per individuare dove è installato il programma. È possibile vedere dove si trovano i file di configurazione Nginx esaminando l'output. Lo screenshot seguente mostra che i file di configurazione si trovano nella cartella /etc/nginx .

Note

Se si esegue una distribuzione diversa da Ubuntu o Debian, è possibile trovare il comando di installazione di Gestione pacchetti equivalente o le istruzioni della documentazione ufficiale sull'installazione di Nginx.

Gestire i servizi tramite systemctl

Se non si noterà che Nginx è in esecuzione, è possibile avviarlo in modo esplicito eseguendo sudo systemctl start nginx. Sebbene questo esercizio dimostri i systemctl comandi per Nginx, questi comandi vengono usati per configurare l'applicazione Web per l'avvio automatico come daemon.

Al termine dell'installazione, Nginx è già configurato per l'avvio automatico. Nginx viene eseguito come daemon. È possibile controllare lo stato del daemon usando systemctl.

Il systemctl comando viene usato per gestire i "servizi" per attività quali la visualizzazione dello stato del servizio o l'avvio e l'arresto. Alcuni parametri disponibili sono avvio, arresto, riavvio, abilitazione, disabilitazione e stato. Per controllare lo stato di Nginx, eseguire systemctl status nginx.

Questo comando genera alcune informazioni utili. Come illustrato nello screenshot, Nginx è in active (running) stato e l'ID processo dell'istanza Nginx è 8539. Si notino anche le enabled istruzioni e vendor preset: enabled . Enabled significa che questo daemon verrà avviato al riavvio del computer e vendor preset: enabled significa che Nginx è abilitato per impostazione predefinita quando è installato. Pertanto, Nginx verrà avviato automaticamente all'avvio del server.

Testare l'installazione di Nginx

Per impostazione predefinita, Nginx è in ascolto sulla porta 80. Poiché è in esecuzione, dovrebbe essere possibile accedere alla pagina principale di Nginx quando si esplora localhost. Usare curl per testare Nginx eseguendo curl localhost. Il testo evidenziato giallo nello screenshot seguente mostra la pagina Web predefinita di Nginx. Di conseguenza, Nginx è in esecuzione:

opzioni di comando systemctl

I servizi o i daemon possono essere gestiti usando il systemctl comando . L'avvio, l'arresto o l'esecuzione di modifiche richiedono l'accesso con privilegi avanzati. Pertanto, è necessario aggiungere il sudo prefisso a questi comandi.

Riavviare i daemon

Potrebbe essere necessario riavviare i daemon di volta in volta. Per riavviare un daemon, eseguire sudo systemctl restart <daemon_name>. Per riavviare Nginx, eseguire sudo systemctl restart nginx. Assicurarsi di controllare lo stato di Nginx prima e dopo l'esecuzione di questo comando per monitorare le modifiche apportate all'ID processo.

Arrestare i daemon

Per arrestare un daemon, eseguire sudo systemctl stop <daemon_name>. Per arrestare Nginx, eseguire sudo systemctl stop nginxe quindi controllare lo stato di Nginx eseguendo systemctl status nginx di nuovo. Questa volta, il servizio viene visualizzato come inattivo (inattivo), ma ancora abilitato. Ciò significa che, anche se il servizio non è in esecuzione, verrà avviato automaticamente dopo il riavvio del server.

Note

Il systemctl status comando visualizza anche diverse righe di voci di log precedenti per il daemon.

Dopo aver arrestato Nginx, eseguire curl localhost di nuovo.

Note

La connessione viene rifiutata perché nulla è in ascolto del traffico in ingresso sulla porta 80.

Disabilitare i daemon

La disabilitazione di un daemon è diversa dall'arresto di un daemon. Un daemon disabilitato potrebbe essere in esecuzione, ma non verrà avviato automaticamente dopo il riavvio del server. Per disabilitare il daemon Nginx, eseguire sudo systemctl disable nginxe quindi controllare lo stato di Nginx.

Questo screenshot mostra che Nginx non è in esecuzione ed è disabilitato. Ciò significa che Nginx non verrà avviato automaticamente dopo un riavvio.

Avviare i daemon

Per avviare un daemon, eseguire sudo systemctl start <daemon_name>. Per avviare Nginx, eseguire sudo systemctl start nginxe quindi controllare di nuovo lo stato del servizio.

Questo screenshot mostra che Nginx è stato avviato ma è ancora disabilitato. Anche se il servizio è in esecuzione, Nginx non viene avviato automaticamente dopo un riavvio perché è un servizio disabilitato.

Abilitare i daemon

L'abilitazione di un servizio significa che verrà avviata automaticamente dopo un riavvio. Per abilitare Nginx, eseguire sudo systemctl enable nginxe quindi controllare di nuovo lo stato di Nginx.

Questo screenshot mostra che Nginx è in esecuzione e verrà avviato dopo il riavvio del server.

Configurare Nginx come proxy inverso per instradare le richieste all'applicazione ASP.NET Core

Dopo aver appreso come avviare, arrestare e riavviare il servizio Nginx, si configurerà Nginx come proxy inverso per instradare le richieste effettuate sulla porta 80 all'applicazione ASP.NET Core in ascolto sulla porta 5000.

Ecco la configurazione necessaria. Alcune delle parti chiave sono evidenziate.

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen        80;
    server_name _;
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
  }
}

Questa configurazione indica quanto segue:

• Nginx sarà in ascolto sulla porta 80 per tutte le richieste (direttiva: listen 80).
• Nginx instrada le richieste a http://localhost:5000 (direttiva: proxy_pass http://localhost:5000)

Note

Riga server_name _ nel codice. Viene usato come direttiva catch-all. Per altre informazioni su server_name, vedere la documentazione ufficiale.

Le modifiche alla configurazione vengono visualizzate in modo semplice. Questo codice verrà usato per sostituire la server sezione della direttiva nel file di configurazione. Ma dov'è il file di configurazione?

Trovare il file di configurazione Nginx corretto

Il file di configurazione Nginx primario è /etc/nginx/nginx.conf. Per esaminare la configurazione, usare il cat /etc/nginx/nginx.conf comando e cercare la direttiva server.

Scorrere la configurazione per individuare la direttiva server. Dovresti aspettarti di non trovarlo. È possibile inserire le modifiche di configurazione desiderate in un punto qualsiasi all'interno del file di configurazione. Tuttavia, idealmente, non si vuole sostituire il file di configurazione originale. Ciò impedisce l'introduzione di errori di configurazione che potrebbero impedire l'avvio corretto del server. La server sezione non è presente nel file di configurazione principale. Se si continua a scorrere il file di configurazione, si scoprirà che esistono alcune include direttive.

Le direttive di inclusione semplificano la gestione della configurazione suddividendola in blocchi da includere nel file di configurazione principale. Il file di configurazione principale può essere mantenuto semplice e alcune parti di configurazione specifiche possono essere spostate in altri file. Le righe evidenziate in questo screenshot indicano quanto segue:

• Nginx caricherà la configurazione da ogni file conf che si trova nella directory /etc/nginx/conf.d .
• Nginx caricherà le configurazioni da ogni file che si trova nella directory /etc/nginx/sites-enabled .

Se si esaminano queste directory, non saranno presenti file di configurazione in /etc/nginx/conf.d. Esiste tuttavia un file in /etc/nginx/sites-enabled.

Il file di configurazione predefinito è simile a un candidato primo per ospitare la configurazione che si sta cercando. Se si esamina il file /etc/nginx/sites-enabled/default usando cat /etc/nginx/sites-enabled/default, si noterà che la direttiva server predefinita viene inserita nel codice seguente.

Pertanto, il file /etc/nginx/sites-enabled/default dovrà essere modificato per modificare la configurazione.

Modificare il file di configurazione usando vi

Si è appreso come modificare i file quando è stato modificato il file di Startup.cs per rimuovere il reindirizzamento HTTPS dalla pipeline di ASP.NET. A questo punto, si userà di nuovo vi per modificare il file di configurazione nginx.

Suggerimento

Eseguire sempre il backup dei file che si stanno modificando. Se si è verificato un problema dopo la modifica, è possibile usare tale copia per ripristinare lo stato precedente del file. In questo caso, eseguire cp /etc/nginx/sites-enabled/default ~/nginx-default-backup per copiare il file di configurazione nella home directory. Il nome del file di backup sarà nginx-default-backup. Si noti che il backup non è stato eseguito nella stessa directory del file originale. Ciò è dovuto al fatto che Nginx carica tutti i file di configurazione da tale directory e non si vuole interrompere la configurazione caricando due versioni diverse della direttiva server.

Eseguire sudo vi /etc/nginx/sites-enabled/default per modificare il file di configurazione e sostituire la direttiva server, come illustrato nello screenshot seguente.

Ecco alcuni suggerimenti e consigli per modificare i file usando vi:

• È possibile scorrere verso l'alto e verso il basso usando i tasti di direzione.
• Per attivare la modalità di modifica, premere il tasto Inserisci o I . Mentre si è in modalità di modifica, verrà visualizzato un messaggio --INSERT-- nell'angolo inferiore sinistro.
• In modalità di modifica è possibile usare la tastiera per eliminare caratteri uno alla volta.
• In modalità di modifica, le operazioni di copia e incolla funzionano insieme alla maggior parte dei terminali. È quindi possibile copiare il contenuto da questo articolo e incollarlo in vi.
• Per uscire dalla modalità di modifica, premere ESC.
• È possibile eliminare più facilmente le righe in modalità normale. In modalità normale passare all'inizio di una riga che si desidera eliminare e immettere dd. Il dd comando elimina l'intera riga. È anche possibile digitare 5dd per eliminare cinque righe contemporaneamente. Tuttavia, questa opzione deve essere usata con cautela per evitare di eliminare contenuto aggiuntivo.
• Come eliminare righe nell'articolo Vim/Vi è un buon articolo Per informazioni su come eliminare più righe in vi.
• Per uscire da vi e salvare le modifiche, immettere :wq!, quindi premere INVIO. In questo caso, i due punti (:) indicano che si sta eseguendo un comando, w significa scrivere le modifiche, q significa uscire e ! significa eseguire l'override delle modifiche.
• Per uscire senza salvare le modifiche, immettere :q!, quindi premere INVIO.

Le modifiche vengono ora salvate ed è necessario riavviare il servizio Nginx per rendere effettive queste modifiche. Prima di riavviare il servizio, è possibile eseguire il sudo nginx -t comando per testare il file di configurazione. Quando questo comando viene eseguito, Nginx controlla la sintassi del file di configurazione e quindi tenta di aprire i file a cui si fa riferimento nel file di configurazione.

Come si può vedere qui, il file di configurazione modificato sembra essere corretto.

È necessario riavviare Nginx in modo che le modifiche abbiano effetto:

sudo systemctl restart nginx

Dopo il riavvio, si prevede di visualizzare una risposta dall'applicazione ASP.NET Core quando si effettua una richiesta a http://localhost perché Nginx dovrebbe funzionare come proxy inverso per le richieste effettuate sulla porta 80.

Riavviare il servizio Nginx per rendere effettive le modifiche e quindi effettuare una richiesta a localhost eseguendo curl localhost. Tuttavia, questo comando avrà esito negativo. Il passaggio successivo consiste nell'eseguire wget localhoste quindi cercare alcuni suggerimenti relativi all'origine del problema.

Risolvere il problema del proxy Nginx

Nello screenshot precedente vengono visualizzate queste informazioni:

Resolving localhost (localhost)... 127.0.0.1  
Connecting to localhost (localhost)|127.0.0.1|:80... connected.  
HTTP request sent, awaiting response... 502 Bad Gateway  
2020-12-27 21:15:53 ERROR 502: Bad Gateway.

Le prime e le seconde righe indicano che è possibile risolvere localhost e connettersi al 127.0.0.1:80 socket. Pertanto, Nginx deve essere in esecuzione. Per verificarlo, è possibile eseguire il systemctl status nginx comando .

La terza riga indica l'origine del problema. Viene visualizzato un messaggio di errore HTTP 502 Gateway non valido. HTTP 502 Gateway non valido è correlato ai proxy. Significa che il proxy inverso non è riuscito a connettersi all'applicazione back-end. In questo caso, si tratta dell'applicazione Web ASP.NET Core che deve essere in esecuzione e in ascolto sulla porta 5000 per le richieste. È consigliabile verificare se l'applicazione Web è in esecuzione.

Per avviare la risoluzione dei problemi, eseguire lo stesso netstat comando di prima. Questa volta, usare grep per filtrare la porta 5000 dell'applicazione. Quindi eseguire netstat -tlp | grep 5000.

Questo output di esempio indica che nulla è in ascolto sulla porta 5000. Pertanto, questa è la causa della risposta HTTP 502 proveniente da Nginx perché non riesce a trovare un processo in ascolto sulla porta 5000.

La soluzione consiste nell'avviare l'applicazione ASP.NET Core. Tuttavia, prima di continuare, è possibile esaminare un altro approccio per la risoluzione del problema. Non tutti i problemi sono facili da risolvere, come semplicemente esaminando alcune righe di contenuto del log e trovando la causa radice. In alcuni casi, è necessario approfondire altri log di sistema e applicazioni.

Poiché si lavora a stretto contatto con Nginx quando si configurano applicazioni ASP.NET Core in Linux, è consigliabile apprendere quale tipo di log Nginx e il sistema operativo fornisce per la risoluzione dei problemi.

Controllare i log Nginx

Se si esegue cat /etc/nginx/nginx.conf di nuovo e quindi si cerca , logging settingssi noterà quanto segue.

Ciò mostra che Nginx ha due tipi di log: log di accesso e log degli errori. Questi vengono archiviati nella directory /var/log/nginx/ .

I log di accesso sono simili ai file di log iis. Una rapida ispezione del contenuto rivela che assomigliano allo screenshot seguente.

I log di accesso non mostrano nuove informazioni diverse dallo stato della risposta HTTP 502 già saputo. È anche possibile esaminare i log degli errori eseguendo cat /var/log/nginx/error.log. Questi rivelano molto di più sulla causa del problema.

Le indicazioni sono chiare: Nginx può ottenere la richiesta dal client, ma non può connettersi al upstream server all'indirizzo http://127.0.0.1:5000 e all'applicazione ASP.NET Core che dovrebbe essere in esecuzione e in ascolto su tale porta.

Soluzione alternativa

Per risolvere questo problema, avviare manualmente l'applicazione ASP.NET Core. Connettersi al server usando una seconda sessione del terminale e quindi eseguire l'applicazione ASP.NET Core come in precedenza.

Mentre l'applicazione ASP.NET Core è in esecuzione, passare all'altra sessione del terminale ed eseguire lo stesso curl localhost comando. A questo punto, è possibile accedere all'applicazione ASP.NET Core in esecuzione dietro Nginx. Lo screenshot seguente mostra che è stata effettuata una richiesta a localhost, la richiesta è stata gestita da Nginx e indirizzata all'applicazione back-end ed è stata ricevuta una risposta dall'applicazione ASP.NET Core.

Nginx è stato configurato in modo da comportarsi come proxy inverso per l'applicazione ASP.NET Core in esecuzione in Linux.

Tuttavia, se l'applicazione ASP.NET Core non viene avviata dopo un riavvio, quale sarà il risultato? Cosa si verifica se l'applicazione Web si arresta in modo anomalo e non si avvia finché non si nota che non è in esecuzione? È necessario avviare l'applicazione ASP.NET Core dopo ogni riavvio della terminazione del processo?

Passaggi successivi

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

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