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

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

Questo articolo illustra come configurare un secondo sito Web in Nginx usando il nome host e come testare la configurazione.

Prerequisiti

Per questa parte, è necessario configurare gli elementi seguenti:

• Nginx viene eseguito automaticamente e in ascolto delle richieste inviate sulla porta 80.
• Nginx configurato come proxy inverso e instrada tutte le richieste HTTP in ingresso alla prima applicazione ASP.NET Core in ascolto sulla porta 5000 (è possibile usare qualsiasi applicazione ASP.NET Core come applicazione back-end in esecuzione su questa porta.
• Tale prima ASP.NET'applicazione Core configurata per l'esecuzione sempre (se il processo si arresta o il server viene riavviato, l'applicazione ASP.NET Core deve essere avviata automaticamente.
• Il firewall locale Linux è abilitato e configurato per consentire il traffico SSH e HTTP in ingresso.
• Una seconda applicazione ASP.NET Core configurata per l'ascolto sulla porta 5001 (questa applicazione deve anche essere configurata per l'esecuzione sempre e l'esempio BuggyAmb ASP.NET'applicazione Core deve essere configurata come seconda applicazione nell'installazione.

Obiettivo di questa parte

Attualmente è presente un sito configurato in Nginx. Qualsiasi richiesta che arriva sulla porta 80 a Nginx viene instradata a tale sito. Il nome host non è importante in questa configurazione. Usare l'indirizzo IP o qualsiasi nome host che si risolve nell'indirizzo IP. Tutte le richieste verranno indirizzate al sito Web predefinito. Questo sito Web predefinito funge da proxy inverso e indirizza le richieste al primo ASP.NET'applicazione Core in ascolto sulla porta 5000.

In questa parte dell'esercitazione si creerà un secondo sito Web in Nginx. Tale sito Web fungerà anche da proxy inverso e qualsiasi richiesta con un nome host specifico verrà instradata alla seconda applicazione ASP.NET Core in ascolto sulla porta 5001.

Si configurerà anche il sito Web per l'ascolto di un nome host specifico. Alla fine, ci saranno due siti accessibili e con questi nomi host:

• Primo sito Web: http://myfirstwebsite indiricherà il traffico alla prima applicazione demo ASP.NET Core.
• Secondo sito Web: http://buggyamb indiricherà il traffico alla seconda applicazione di bug di esempio core ASP.NET.

Aggiungere myfirstwebsite e buggyamb al file hosts dei computer Windows client e Linux. In questo modo, è possibile usare questi URL per testare la nuova configurazione.

Questi nomi host sono solo per dimostrazione. È possibile usare qualsiasi altro nome host preferito, purché si usino in modo coerente gli stessi nomi host in questa parte.

Configurare un secondo Web usando un nome host in Nginx

Se si ricorda, una delle directory in cui Nginx carica le configurazioni del sito è /etc/nginx/sites-enabled/. Attualmente è presente un file di configurazione predefinito. Il file è simile allo screenshot seguente.

Note

Si notino le parti evidenziate perché è necessario modificarle:

• server_name: qui è possibile impostare il nome host desiderato. Attualmente, questa opzione è configurata per il valore _. Ciò significa qualsiasi nome host.
• proxy_pass: si tratta di un'applicazione ASP.NET Core in esecuzione e in ascolto su un URL specificato. Le richieste vengono instradate a questo URL.

Configurare il primo sito Web per l'ascolto sull'intestazione http://myfirstwebsitehost . A tale scopo, modificare nel server_name file di configurazione /etc/nginx/sites-enabled/default , come illustrato nello screenshot seguente. Come promemoria, è necessario usare il comando per modificare il sudo vi /etc/nginx/sites-enabled/default file.

Creare un secondo file di configurazione Nginx per il secondo sito Web. Usare questo file come modello per creare una copia di questo file nella stessa directory di configurazione. Denominare il file buggyamb.config.

sudo cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/buggyamb.config

Modificare il file di configurazione eseguendo il sudo vi /etc/nginx/sites-enabled/buggyamb.config comando . Ecco la versione finale del file /etc/nginx/sites-enabled/buggyamb.config .

L'installazione risultante deve avere due file di configurazione nella directory di configurazione del sito Nginx: buggyamb.config e impostazione predefinita. Sarà necessario impostare Nginx per ricaricare le modifiche di configurazione. Tuttavia, è necessario prima testare la nuova configurazione per assicurarsi che non siano stati introdotti errori quando sono state apportate modifiche. Eseguire il sudo nginx -t comando e verificare che la configurazione sia corretta. sudo nginx -s reload Eseguire quindi per ricaricare la configurazione e leggere le nuove modifiche.

Testare la nuova configurazione

Impostare i myfirstwebsite nomi host e buggyamb per risolvere gli indirizzi IP corretti. Quando si accede ai siti dal computer Linux, questi nomi host devono essere risolti in 127.0.0.1 e per i client esterni, ad esempio il computer Windows client. I nomi host devono essere risolti nell'indirizzo IP pubblico della macchina virtuale Linux. È possibile recuperare l'indirizzo IP dal portale di Azure.

Note

I mapping degli host vengono archiviati nel file /etc/hosts in Linux e nel file C:\WINDOWS\System32\drivers\etc\hosts in Windows.

Si tratta del contenuto del file host Linux.

È possibile eseguire i curl myfirstwebsite comandi e curl buggyamb per effettuare richieste a ognuno dei due siti.

Ecco l'output curl myfirstwebsite . La risposta sembra visualizzare correttamente il contenuto HTML dalla home page della dimostrazione ASP.NET'applicazione principale distribuita inizialmente ed è in ascolto sulla porta 5000.

Ed ecco l'output curl buggyamb . Viene visualizzato il contenuto HTML dalla home page dell'applicazione di esempio BuggyAmb in esecuzione sulla porta 5001.

Dovrebbe essere possibile esplorare gli stessi URL dal computer client usando un browser. Questo dovrebbe funzionare anche se si configura correttamente il file hosts. Questo è ciò che viene visualizzato durante l'esplorazione http://buggaymb da un browser in esecuzione in un computer Windows.

Fino a questo punto, è disponibile la configurazione seguente:

• Nginx che ospita due siti Web:

  • Il primo sito Web è in ascolto delle richieste usando l'intestazione myfirstwebsite host e instrada le richieste all'applicazione demo ASP.NET Core. Questa applicazione è in ascolto sulla porta 5000.
  • Il secondo sito Web è in ascolto del traffico HTTP in ingresso usando il valore dell'intestazione host di buggyambe instrada le richieste alla seconda applicazione buggy di esempio di ASP.NET Core. Questa applicazione è in ascolto sulla porta 5001.

• Entrambe le applicazioni core ASP.NET vengono eseguite come servizi che vengono riavviati automaticamente quando il server viene riavviato o le applicazioni non rispondono.

• Il firewall locale Linux è abilitato e configurato per consentire il traffico SSH e HTTP.

Suggerimenti per la risoluzione dei problemi

È possibile che venga visualizzato l'errore HTTP 502 - Gateway non valido quando si esplora un sito. "HTTP 502 - Gateway non valido" indica che Nginx non è riuscito a comunicare con l'applicazione back-end ASP.NET Core. Ciò si verifica se l'applicazione back-end non è in esecuzione.

In questo caso:

• Assicurarsi che entrambe le applicazioni core ASP.NET siano in ascolto su porte diverse. Uno dovrebbe essere in ascolto sulla porta 5000 mentre l'altro dovrebbe essere in ascolto sulla porta 5001.
• Assicurarsi che entrambe le applicazioni core ASP.NET siano configurate per l'avvio automatico.
• Controllare lo stato dei servizi dell'applicazione ASP.NET Core che usano i systemctl status comandi. Se non è in esecuzione, risolvere i problemi esaminando i log di sistema eseguendo il journalctl comando . Usare syslogIdentifier per filtrare i log.
• Verifica che siano installati sia .NET Core 3.1 che .NET 5.0. Un sito usa .NET Core 3.1, l'altro usa .NET 5.0.

Passaggi successivi

Parte 3.1 - Prepararsi per la risoluzione dei problemi