Dela via

Del 2.2 – Installera Nginx och konfigurera det som en omvänd proxyserver

Gäller för: .NET Core 2.1, .NET Core 3.1, .NET 5

Den här artikeln beskriver hur du installerar Nginx och konfigurerar det som en omvänd proxyserver.

Förutsättningar

Om du vill följa övningarna i den här delen måste du ha en ASP.NET Core-webbapp som skapats och distribuerats till mappen /var .

Målet för den här delen

I föregående del skapade du ett ASP.NET Core-webbprogram med hjälp av .NET CLI-verktyget och programmet distribueras till mappen /var . Programmet har också konfigurerats för att lyssna på port 5000 för HTTP-begäranden och HTTPS-omdirigering har tagits bort.

Nu ska klienterna ange portnumret när du ansluter till programmet (till exempel http://localhost:5000). Detta är dock inte det önskade beteendet.

Våra mål i den här delen är följande:

  • Klienter bör kunna navigera utan att behöva ange ett portnummer. Klienter bör till exempel ansluta med hjälp http://localhostav .
  • Webbprogrammet bör startas automatiskt om det stoppas av någon anledning eller efter att datorn har startats om.

I nästa avsnitt använder du Nginx som proxyserver för att dirigera HTTP-begäranden som görs till port 80 till vårt .NET-program i stället. Du konfigurerar också programmet så att det startar automatiskt.

Vad är Nginx?

Nginx är en populär, lätt och snabb webbserver. Den kan köras på både Linux och Windows och kan konfigureras som en omvänd proxyserver.

Vad är en daemon?

Nginx körs som en daemon. En daemon är en alternativ term för en tjänst som körs i bakgrunden. Precis som de tjänster som körs i Windows kan daemoner konfigureras för automatisk start under start. Du konfigurerar ditt ASP.NET Core-program så att det körs som en daemon.

Installera Nginx med hjälp av APT

Det är enkelt att installera Nginx. sudo apt install nginx Kör kommandot för att installera programmet på den virtuella Ubuntu-datorn.

Skärmbild av sudo-kommandot.

När installationen är klar kör du whereis nginx för att identifiera var programmet är installerat. Du kan se var Nginx-konfigurationsfilerna finns genom att granska utdata. Följande skärmbild visar att konfigurationsfilerna finns i mappen /etc/nginx .

Skärmbild av kommandot whereis.

Kommentar

Om du kör en annan distribution än Ubuntu eller Debian hittar du motsvarande installationskommando för pakethanteraren eller instruktioner från den officiella Nginx-installationsdokumentationen.

Hantera tjänster med hjälp av systemctl

Om du inte ser att Nginx körs kan du starta det explicit genom att köra sudo systemctl start nginx. Även om den här övningen systemctl visar kommandona för Nginx används dessa kommandon för att konfigurera webbappen att starta automatiskt som en daemon.

När installationen är klar har Nginx redan konfigurerats för att starta automatiskt. Nginx körs som en daemon. Du kan kontrollera daemonens status med hjälp av systemctl.

Kommandot systemctl används för att hantera "tjänster" för sådana uppgifter som att visa status för tjänsten eller starta och stoppa den. Vissa tillgängliga parametrar är start, stopp, omstart, aktivera, inaktivera och status. Om du vill kontrollera status för Nginx kör du systemctl status nginx.

Skärmbild av systemctl-kommandot.

Det här kommandot genererar användbar information. Som den här skärmbilden visar är Nginx i active (running) status och process-ID för Nginx-instansen är 8539. Lägg också märke till - och vendor preset: enabled -uttryckenenabled. Enabled innebär att den här daemonen startar när datorn startas om och vendor preset: enabled innebär att Nginx är aktiverat som standard när den installeras. Därför startar Nginx automatiskt när servern startas.

Testa Nginx-installationen

Som standard lyssnar Nginx på port 80. Eftersom den körs bör du kunna komma åt huvudsidan för Nginx när du bläddrar i localhost. Använd curl för att testa Nginx genom att köra curl localhost. Den gulmarkerade texten i följande skärmbild visar Nginx-standardwebbsidan. Därför körs Nginx:

Skärmbild av curl-kommandot.

systemctl-kommandoalternativ

Tjänster, eller daemoner, kan hanteras med hjälp systemctl av kommandot . Att starta, stoppa eller göra ändringar kräver superanvändaråtkomst. Därför måste du lägga till prefixet sudo i dessa kommandon.

Starta om daemoner

Du kan behöva starta om daemonerna då och då. Starta om en daemon genom att köra sudo systemctl restart <daemon_name>. Starta om Nginx genom att köra sudo systemctl restart nginx. Kontrollera att du kontrollerar statusen för Nginx före och efter att du har kört det här kommandot för att övervaka ändringar i process-ID:t.

Stoppa daemoner

Om du vill stoppa en daemon kör du sudo systemctl stop <daemon_name>. Om du vill stoppa Nginx kör du sudo systemctl stop nginxoch kontrollerar sedan statusen för Nginx genom att köra systemctl status nginx igen. Den här gången visas tjänsten som inaktiv (död) men fortfarande aktiverad. Det innebär att även om tjänsten inte körs startar den automatiskt efter att servern har startats om.

Skärmbild av stoppkommandot.

Kommentar

Kommandot systemctl status visar också flera rader med tidigare loggposter för daemonen.

När du har stoppat Nginx kör du curl localhost igen.

Kommentar

Anslutningen nekas eftersom inget lyssnar efter inkommande trafik på port 80.

Skärmbild av BuggyAmb localhost.

Inaktivera daemoner

Att inaktivera en daemon skiljer sig från att stoppa en daemon. En inaktiverad daemon kan köras, men den startar inte automatiskt när servern har startats om. Om du vill inaktivera Nginx-daemonen kör du sudo systemctl disable nginxoch kontrollerar sedan statusen för Nginx.

Skärmbild av inaktivera-kommandot.

Den här skärmbilden visar att Nginx inte körs och att det är inaktiverat. Det innebär att Nginx inte startas automatiskt efter en omstart.

Starta daemoner

Starta en daemon genom att köra sudo systemctl start <daemon_name>. Starta Nginx genom att sudo systemctl start nginxköra och sedan kontrollera tjänstens status igen.

Skärmbild av startkommandot.

Den här skärmbilden visar att Nginx har startats men fortfarande är inaktiverat. Även om tjänsten körs startar inte Nginx automatiskt efter en omstart eftersom det är en inaktiverad tjänst.

Aktivera daemoner

Om du aktiverar en tjänst startas den automatiskt efter en omstart. Om du vill aktivera Nginx kör du sudo systemctl enable nginxoch kontrollerar sedan statusen för Nginx igen.

Skärmbild av aktivera-kommandot.

Den här skärmbilden visar att Nginx körs och startas när servern har startats om.

Konfigurera Nginx som omvänd proxy för att dirigera begäranden till ditt ASP.NET Core-program

Nu när du har lärt dig hur du startar, stoppar och startar om Nginx-tjänsten ska du konfigurera Nginx som en omvänd proxy för att dirigera begäranden som görs på port 80 till ditt ASP.NET Core-program som lyssnar på port 5000.

Här är den konfiguration som krävs. Några av de viktigaste delarna är markerade.

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;
    }
  }
}

Den här konfigurationen anger följande:

  • Nginx lyssnar på port 80 för alla begäranden (direktiv: listen 80).
  • Nginx dirigerar begäranden till http://localhost:5000 (direktiv: proxy_pass http://localhost:5000)

Kommentar

Raden server_name _ i koden. Detta används som ett catch-all-direktiv. Om du vill veta mer om server_name kan du läsa den officiella dokumentationen.

Konfigurationsändringarna verkar enkla. Vi använder den här koden för att ersätta direktivavsnittet server i konfigurationsfilen. Men var finns konfigurationsfilen?

Hitta rätt Nginx-konfigurationsfil

Den primära Nginx-konfigurationsfilen är /etc/nginx/nginx.conf. Om du vill kontrollera konfigurationen cat /etc/nginx/nginx.conf använder du kommandot och söker efter serverdirektivet.

Skärmbild av kommandot cat.

Bläddra igenom konfigurationen för att hitta serverdirektivet. Du bör förvänta dig att inte hitta den. Vi kan placera önskade konfigurationsändringar någonstans i konfigurationsfilen. Men helst vill du inte ersätta den ursprungliga konfigurationsfilen. Detta för att förhindra att konfigurationsfel införs som kan hindra servern från att starta korrekt. Avsnittet server finns inte i huvudkonfigurationsfilen. Om du fortsätter att bläddra igenom konfigurationsfilen upptäcker du att det finns några include direktiv.

Skärmbild av include-kommandot.

Inkludera direktiv gör det enklare att hantera konfigurationen genom att dela upp den i segment som ska ingå i huvudkonfigurationsfilen. Huvudkonfigurationsfilen kan hållas enkel och vissa specifika konfigurationsdelar kan flyttas till andra filer. De markerade raderna i den här skärmbilden visar följande:

  • Nginx läser in konfigurationen från varje .conf-fil som finns i katalogen /etc/nginx/conf.d .
  • Nginx läser in konfigurationerna från varje fil som finns i katalogen /etc/nginx/sites-enabled .

Om du inspekterar dessa kataloger hittar du inga konfigurationsfiler i /etc/nginx/conf.d. Det finns dock en fil i /etc/nginx/sites-enabled.

Skärmbild av kommandot conf.

Standardkonfigurationsfilen ser ut som en huvudkandidat som värd för den konfiguration som vi letar efter. Om du inspekterar filen /etc/nginx/sites-enabled/default med hjälp cat /etc/nginx/sites-enabled/defaultav ser du att standardserverdirektivet placeras i följande kod.

Skärmbild av standardinformation.

Därför måste filen /etc/nginx/sites-enabled/default redigeras för att ändra konfigurationen.

Redigera konfigurationsfilen med hjälp av vi

Du har lärt dig hur du redigerar filer när du redigerade Startup.cs-filen för att ta bort HTTPS-omdirigering från ASP.NET pipeline. Nu ska du använda vi igen för att ändra nginx-konfigurationsfilen.

Dricks

Säkerhetskopiera alltid de filer som du ändrar. Om något skulle gå fel efter redigeringen kan du använda kopian för att återställa filen till dess tidigare tillstånd. I det här fallet kör du cp /etc/nginx/sites-enabled/default ~/nginx-default-backup för att kopiera konfigurationsfilen till din hemkatalog. Namnet på säkerhetskopian blir nginx-default-backup. Observera att säkerhetskopieringen inte gjordes i samma katalog som den ursprungliga filen. Det beror på att Nginx läser in alla konfigurationsfiler från den katalogen och du inte vill bryta konfigurationen genom att läsa in två olika versioner av serverdirektivet.

Kör sudo vi /etc/nginx/sites-enabled/default för att redigera konfigurationsfilen och ersätt serverdirektivet, enligt följande skärmbild.

Skärmbild av vi-kommandot.

Här följer några tips för att redigera filer med hjälp av vi:

  • Du kan rulla upp och ned med hjälp av piltangenterna.
  • Om du vill ange redigeringsläge trycker du på tangenten Infoga eller I . När du är i redigeringsläge kommer det att finnas ett --INSERT-- meddelande i det nedre vänstra hörnet.
  • I redigeringsläge kan du använda tangentbordet för att ta bort tecken en i taget.
  • I redigeringsläge fungerar kopierings- och inklistringsåtgärder tillsammans med de flesta terminalerna. Så du kan kopiera innehållet från den här artikeln och klistra in det i vi.
  • Tryck på Esc om du vill avsluta redigeringsläget.
  • Du kan ta bort rader enklare i normalt läge. I normalt läge går du till början av en rad som du vill ta bort och anger dd. Kommandot dd tar bort hela raden. Du kan också skriva 5dd för att ta bort fem rader i taget. Det här alternativet bör dock användas med försiktighet för att undvika att ta bort extra innehåll.
  • Så här tar du bort rader i artikeln Vim/Vi är bra om du vill lära dig hur du tar bort flera rader i vi.
  • Om du vill avsluta vi och spara ändringarna anger du :wq!och trycker sedan på Retur. Här innebär kolonet (:) att du kör ett kommando, w innebär att skriva ändringarna, q betyder avsluta och ! innebär att åsidosätta ändringarna.
  • Om du vill avsluta utan att spara ändringarna anger du :q!och trycker sedan på Retur.

Ändringarna sparas nu och du måste starta om Nginx-tjänsten för att ändringarna ska börja gälla. Innan du startar om tjänsten kan du köra sudo nginx -t kommandot för att testa konfigurationsfilen. När det här kommandot körs kontrollerar Nginx konfigurationsfilsyntaxen och försöker sedan öppna de filer som refereras i konfigurationsfilen.

Skärmbild av kommandot t.

Som du ser här verkar konfigurationsfilen som ändrades vara korrekt.

Vi måste starta om Nginx så att ändringarna börjar gälla:

sudo systemctl restart nginx

Efter omstarten förväntar du dig att se ett svar från ASP.NET Core-programmet när du skickar en begäran till http://localhost eftersom Nginx bör fungera som en omvänd proxy för de begäranden som görs till port 80.

Starta om Nginx-tjänsten för att ändringarna ska börja gälla och gör sedan en begäran till localhost genom att köra curl localhost. Det här kommandot misslyckas dock. Nästa steg är att köra wget localhostoch sedan söka efter tips om orsaken till problemet.

Skärmbild av kommandot wget.

Felsöka Nginx-proxyproblemet

I föregående skärmbild visas den här informationen:

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.

De första och andra raderna anger att du kan lösa localhost och ansluta på socketen 127.0.0.1:80 . Därför bör Nginx köras. Du kan kontrollera detta genom att systemctl status nginx köra kommandot .

Den tredje raden anger orsaken till problemet. Du får ett felmeddelande om felaktig HTTP 502-gateway . HTTP 502 Bad Gateway är relaterat till proxyservrar. Det innebär att den omvända proxyn inte kunde ansluta till serverdelsprogrammet. I det här fallet är det din ASP.NET Core-webbapp som ska köras och lyssna på port 5000 för begäranden. Vi bör kontrollera om webbprogrammet också körs.

Starta felsökningen genom att köra samma netstat kommando som tidigare. Den här gången använder du grep för att filtrera programmets port 5000. netstat -tlp | grep 5000Kör sedan .

Skärmbild av netstat-kommandot.

Det här exemplet visar att inget lyssnar på port 5000. Det här är därför orsaken till HTTP 502-svaret som kommer från Nginx eftersom det inte går att hitta en process som lyssnar på port 5000.

Lösningen är att starta ditt ASP.NET Core-program. Innan du går vidare kan du dock granska en annan metod för att felsöka det här problemet. Alla problem är inte lika enkla att åtgärda som att bara titta på några rader med logginnehåll och hitta rotorsaken. Ibland måste du fördjupa dig i andra system- och programloggar.

Eftersom du har ett nära samarbete med Nginx när du konfigurerar ASP.NET Core-program i Linux rekommenderar vi att du lär dig vilken typ av loggar Nginx och operativsystemet tillhandahåller för felsökning.

Kontrollera Nginx-loggarna

Om du kör cat /etc/nginx/nginx.conf igen och sedan letar logging settingsefter bör du se följande.

Skärmbild av logginformation.

Detta visar att Nginx har två typer av loggar: Åtkomstloggar och felloggar. Dessa lagras i katalogen /var/log/nginx/ .

Åtkomstloggar liknar IIS-loggfiler. En snabb inspektion av innehållet visar att de liknar följande skärmbild.

Skärmbild av åtkomstkommandot.

Åtkomstloggar visar ingen annan information än http 502-svarsstatusen som du redan kände till. Du kan också kontrollera felloggarna genom att köra cat /var/log/nginx/error.log. Dessa avslöjar mycket mer om orsaken till problemet.

Skärmbild av felinformation.

Indikationerna är tydliga: Nginx kan hämta begäran från klienten, men den kan inte ansluta till upstream servern på http://127.0.0.1:5000 och till ASP.NET Core-programmet som borde ha körts och lyssnat på den porten.

Lösning

Du kan lösa det här problemet genom att starta ditt ASP.NET Core-program manuellt. Anslut till servern med hjälp av en andra terminalsession och kör sedan ASP.NET Core-programmet som tidigare.

Skärmbild av aspnet-information.

Medan ditt ASP.NET Core-program körs växlar du till den andra terminalsessionen och kör samma curl localhost kommando. Nu kan du komma åt ditt ASP.NET Core-program som körs bakom Nginx. Följande skärmbild visar att du har gjort en begäran till localhost, att begäran hanterades av Nginx och dirigerades till serverdelsprogrammet och att du fick ett svar från ditt ASP.NET Core-program.

Skärmbild av kommandot curllocalhost.

Nu har du konfigurerat Nginx att fungera som en omvänd proxy för ditt ASP.NET Core-program som körs i Linux.

Men om ASP.NET Core-programmet inte startar efter en omstart, vad blir resultatet? Vad händer om webbprogrammet kraschar och inte startar förrän du märker att det inte körs? Ska du starta ditt ASP.NET Core-program efter varje omstart av processens avslutning?

Nästa steg

Del 2.3 – Konfigurera ASP.NET Core-programmet så att det startas automatiskt

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.