Delen via

Deel 2.2: Nginx installeren en configureren als een omgekeerde proxyserver

Van toepassing op: .NET Core 2.1, .NET Core 3.1, .NET 5

In dit artikel wordt uitgelegd hoe u Nginx installeert en configureert als een omgekeerde proxyserver.

Voorwaarden

Als u de oefeningen in dit deel wilt volgen, moet u één ASP.NET Core-webtoepassing hebben gemaakt en geïmplementeerd in de map /var .

Doel van dit deel

In het vorige deel hebt u een ASP.NET Core-webtoepassing gemaakt met behulp van het .NET CLI-hulpprogramma en wordt de toepassing geïmplementeerd in de map /var . De toepassing is ook geconfigureerd om te luisteren op poort 5000 voor HTTP-aanvragen en HTTPS-omleiding is verwijderd.

Op dit moment moeten de clients het poortnummer opgeven wanneer u verbinding maakt met de toepassing (bijvoorbeeld http://localhost:5000). Dit is echter niet het gewenste gedrag.

Onze doelstellingen in dit gedeelte zijn als volgt:

  • Clients moeten kunnen navigeren zonder een poortnummer op te geven. Clients moeten bijvoorbeeld verbinding maken met behulp van http://localhost.
  • De webtoepassing moet automatisch worden gestart als deze om een of andere reden stopt of nadat de computer opnieuw is opgestart.

In de volgende sectie gebruikt u Nginx als proxyserver om de HTTP-aanvragen die worden gedaan naar poort 80 te routeren naar onze .NET-toepassing. U gaat uw toepassing ook zo configureren dat deze automatisch wordt gestart.

Wat is Nginx?

Nginx is een populaire, lichtgewicht en snelle webserver. Het kan worden uitgevoerd op linux en Windows en kan worden geconfigureerd als een omgekeerde proxyserver.

Wat is een daemon?

Nginx wordt uitgevoerd als een daemon. Een daemon is een alternatieve term voor een service die op de achtergrond wordt uitgevoerd. Net als de services die worden uitgevoerd in Windows, kunnen daemons worden geconfigureerd om automatisch te starten tijdens het opstarten. U configureert uw ASP.NET Core-toepassing om te worden uitgevoerd als een daemon.

Nginx installeren met behulp van APT

Het installeren van Nginx is eenvoudig. Voer de sudo apt install nginx opdracht uit om het programma te installeren op de virtuele Ubuntu-machine.

Schermopname van sudo-opdracht.

Nadat de installatie is voltooid, voert u uit whereis nginx om te ontdekken waar het programma is geïnstalleerd. U kunt zien waar de Nginx-configuratiebestanden zich bevinden door de uitvoer te controleren. In de volgende schermopname ziet u dat de configuratiebestanden zich in de map /etc/nginx bevinden.

Schermopname van whereis-opdracht.

Notitie

Als u een andere distributie dan Ubuntu of Debian uitvoert, vindt u de equivalente installatieopdracht voor pakketbeheer of instructies in de officiële Nginx-installatiedocumentatie.

Services beheren met systemctl

Als u niet ziet dat Nginx wordt uitgevoerd, kunt u deze expliciet starten door deze uit te voeren sudo systemctl start nginx. Hoewel deze oefening de systemctl opdrachten voor Nginx laat zien, worden deze opdrachten gebruikt om de webtoepassing zo te configureren dat deze automatisch wordt gestart als een daemon.

Nadat de installatie is voltooid, is Nginx al geconfigureerd om automatisch te starten. Nginx wordt uitgevoerd als een daemon. U kunt de status van de daemon controleren met behulp van systemctl.

De systemctl opdracht wordt gebruikt voor het beheren van 'services' voor taken, zoals het weergeven van de status van de service of het starten en stoppen ervan. Sommige beschikbare parameters zijn starten, stoppen, opnieuw opstarten, inschakelen, uitschakelen en status. Als u de status van Nginx wilt controleren, voert u het volgende uit systemctl status nginx.

Schermopname van de systemctl-opdracht.

Met deze opdracht worden nuttige informatie gegenereerd. Zoals in deze schermopname wordt weergegeven, heeft active (running) Nginx de status en is de proces-id van het Nginx-exemplaar 8539. Let ook op de enabled en vendor preset: enabled instructies. Enabled betekent dat deze daemon wordt gestart wanneer de machine opnieuw wordt opgestart en vendor preset: enabled betekent dat Nginx standaard is ingeschakeld wanneer deze is geïnstalleerd. Daarom wordt Nginx automatisch gestart wanneer de server wordt gestart.

De Nginx-installatie testen

Nginx luistert standaard op poort 80. Omdat deze wordt uitgevoerd, moet u toegang hebben tot de hoofdpagina van Nginx wanneer u door localhost bladert. Gebruik curl dit om Nginx te testen door uit te voeren curl localhost. In de gele gemarkeerde tekst in de volgende schermopname ziet u de standaardwebpagina Nginx. Daarom wordt Nginx uitgevoerd:

Schermopname van curl-opdracht.

opties voor systemctl-opdrachten

Services of daemons kunnen worden beheerd met behulp van de systemctl opdracht. Voor het starten, stoppen of aanbrengen van wijzigingen is supergebruikerstoegang vereist. Daarom moet u het sudo voorvoegsel toevoegen aan deze opdrachten.

Daemons opnieuw starten

Mogelijk moet u de daemons van tijd tot tijd opnieuw starten. Als u een daemon opnieuw wilt starten, voert u het volgende uit sudo systemctl restart <daemon_name>. Als u Nginx opnieuw wilt starten, voert u het volgende uit sudo systemctl restart nginx. Controleer de status van Nginx voor en nadat u deze opdracht hebt uitgevoerd om wijzigingen in de proces-id te controleren.

Daemons stoppen

Als u een daemon wilt stoppen, voert u het volgende uit sudo systemctl stop <daemon_name>. Als u Nginx wilt stoppen, voert u uit sudo systemctl stop nginxen controleert u de status van Nginx door opnieuw uit te voeren systemctl status nginx . Deze keer wordt de service weergegeven als inactief (dood) maar nog steeds ingeschakeld. Dit betekent dat hoewel de service niet wordt uitgevoerd, deze automatisch wordt gestart nadat de server opnieuw is opgestart.

Schermopname van de stopopdracht.

Notitie

Met systemctl status de opdracht worden ook verschillende regels met eerdere logboekvermeldingen voor de daemon weergegeven.

Nadat u Nginx hebt gestopt, voert u opnieuw uit curl localhost .

Notitie

De verbinding wordt geweigerd omdat er niets luistert naar binnenkomend verkeer op poort 80.

Schermopname van BuggyAmb localhost.

Daemons uitschakelen

Het uitschakelen van een daemon verschilt van het stoppen van een daemon. Een uitgeschakelde daemon kan worden uitgevoerd, maar deze wordt niet automatisch gestart nadat de server opnieuw is opgestart. Als u de Nginx-daemon wilt uitschakelen, voert u deze uit sudo systemctl disable nginxen controleert u de status van Nginx.

Schermopname van de opdracht uitschakelen.

In deze schermopname ziet u dat Nginx niet wordt uitgevoerd en dat deze optie is uitgeschakeld. Dit betekent dat Nginx niet automatisch wordt gestart na een herstart.

Daemons starten

Als u een daemon wilt starten, voert u het volgende uit sudo systemctl start <daemon_name>. Als u Nginx wilt starten, voert u het sudo systemctl start nginxuit en controleert u de status van de service opnieuw.

Schermopname van de startopdracht.

In deze schermopname ziet u dat Nginx is gestart, maar nog steeds is uitgeschakeld. Hoewel de service wordt uitgevoerd, wordt Nginx niet automatisch gestart na een herstart omdat deze een uitgeschakelde service is.

Daemons inschakelen

Als u een service inschakelt, wordt deze automatisch gestart na het opnieuw opstarten. Als u Nginx wilt inschakelen, voert u uit sudo systemctl enable nginxen controleert u de status van Nginx opnieuw.

Schermopname van de opdracht Inschakelen.

In deze schermopname ziet u dat Nginx wordt uitgevoerd en dat deze wordt gestart nadat de server opnieuw is opgestart.

Nginx configureren als omgekeerde proxy om de aanvragen naar uw ASP.NET Core-toepassing te routeren

Nu u hebt geleerd hoe u de Nginx-service start, stopt en opnieuw start, configureert u Nginx als een omgekeerde proxy om de aanvragen die op poort 80 worden gedaan, te routeren naar uw ASP.NET Core-toepassing die luistert op poort 5000.

Dit is de vereiste configuratie. Enkele van de belangrijkste onderdelen zijn gemarkeerd.

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

Deze configuratie geeft het volgende aan:

  • Nginx luistert op poort 80 voor alle aanvragen (richtlijn: listen 80).
  • Nginx stuurt de aanvragen door naar http://localhost:5000 (richtlijn: proxy_pass http://localhost:5000)

Notitie

De server_name _ regel in de code. Dit wordt gebruikt als een catch-all-richtlijn. Raadpleeg de officiële documentatie als u meer wilt weten over server_name.

De configuratiewijzigingen zijn eenvoudig. We gebruiken deze code om de server instructiesectie in het configuratiebestand te vervangen. Maar waar is het configuratiebestand?

Het juiste Nginx-configuratiebestand zoeken

Het primaire Nginx-configuratiebestand is /etc/nginx/nginx.conf. Als u de configuratie wilt controleren, gebruikt u de cat /etc/nginx/nginx.conf opdracht en zoekt u naar de serverrichtlijn.

Schermopname van cat-opdracht.

Blader door de configuratie om de serverrichtlijn te vinden. U zou verwachten dat u het niet kunt vinden. We kunnen de gewenste configuratiewijzigingen ergens in het configuratiebestand plaatsen. Idealiter wilt u het oorspronkelijke configuratiebestand echter niet vervangen. Dit is om te voorkomen dat er configuratiefouten worden ingevoerd waardoor de server mogelijk niet correct wordt gestart. De server sectie bevindt zich niet in het hoofdconfiguratiebestand. Als u door het configuratiebestand bladert, zult u ontdekken dat er enkele include instructies zijn.

Schermopname van de opdracht Opnemen.

Voeg instructies toe om de configuratie gemakkelijker te beheren door deze op te splitsen in segmenten die moeten worden opgenomen in het hoofdconfiguratiebestand. Het hoofdconfiguratiebestand kan eenvoudig worden bewaard en sommige specifieke configuratieonderdelen kunnen naar andere bestanden worden verplaatst. De gemarkeerde regels in deze schermopname geven het volgende aan:

  • Nginx laadt de configuratie van elk .conf-bestand dat zich in de map /etc/nginx/conf.d bevindt.
  • Nginx laadt de configuraties uit elk bestand dat zich in de map /etc/nginx/sites bevindt .

Als u deze mappen inspecteert, vindt u geen configuratiebestanden in /etc/nginx/conf.d. Er is echter één bestand in /etc/nginx/sites ingeschakeld.

Schermopname van de opdracht Conf.

Het standaardconfiguratiebestand ziet eruit als een eerste kandidaat voor het hosten van de configuratie die we zoeken. Als u het bestand /etc/nginx/sites-enabled/default by using cat /etc/nginx/sites-enabled/defaultinspecteert, ziet u dat de standaardserverrichtlijn in de volgende code wordt geplaatst.

Schermopname van standaardinformatie.

Daarom moet het bestand /etc/nginx/sites-enabled/default worden bewerkt om de configuratie te wijzigen.

Het configuratiebestand bewerken met behulp van vi

U hebt geleerd hoe u bestanden bewerkt toen u het Startup.cs-bestand bewerkt om HTTPS-omleiding uit de ASP.NET-pijplijn te verwijderen. Nu gebruikt u vi opnieuw om het nginx-configuratiebestand te wijzigen.

Tip

Maak altijd een back-up van de bestanden die u wijzigt. Als er iets mis zou gaan na het bewerken, kunt u die kopie gebruiken om het bestand te herstellen naar de vorige status. Voer in dit geval uit cp /etc/nginx/sites-enabled/default ~/nginx-default-backup om het configuratiebestand naar uw basismap te kopiëren. De naam van het back-upbestand is nginx-default-backup. U ziet dat de back-up niet is gemaakt in dezelfde map als het oorspronkelijke bestand. Dit komt doordat Nginx alle configuratiebestanden uit die map laadt en u de configuratie niet wilt verbreken door twee verschillende versies van de serverrichtlijn te laden.

Voer sudo vi /etc/nginx/sites-enabled/default deze opdracht uit om het configuratiebestand te bewerken en de serverrichtlijn te vervangen, zoals wordt weergegeven in de volgende schermopname.

Schermopname van vi-opdracht.

Hier volgen enkele tips en trucs voor het bewerken van bestanden met behulp van vi:

  • U kunt omhoog en omlaag schuiven met behulp van de pijltoetsen.
  • Als u de bewerkingsmodus wilt openen, drukt u op Invoegen of I . Terwijl u zich in de bewerkingsmodus bevindt, wordt er een bericht --INSERT- in de linkerbenedenhoek weergegeven.
  • In de bewerkingsmodus kunt u het toetsenbord gebruiken om tekens één voor één te verwijderen.
  • In de bewerkingsmodus werken kopieer- en plakbewerkingen samen met de meeste terminals. U kunt de inhoud uit dit artikel dus kopiëren en in vi plakken.
  • Druk op Esc om de bewerkingsmodus af te sluiten.
  • U kunt lijnen gemakkelijker verwijderen in de normale modus. Ga in de normale modus naar het begin van een regel die u wilt verwijderen en voer dd in. Met dd de opdracht wordt de hele regel verwijderd. U kunt ook 5dd typen om vijf regels tegelijk te verwijderen. Deze optie moet echter voorzichtig worden gebruikt om te voorkomen dat extra inhoud wordt verwijderd.
  • Het artikel Regels verwijderen in Vim/Vi is een goed artikel voor meer informatie over het verwijderen van meerdere regels in vi.
  • Als u vi wilt afsluiten en de wijzigingen wilt opslaan, voert u :wq! in en drukt u op Enter. Hier betekent de dubbele punt (:) dat u een opdracht uitvoert, w betekent dat u de wijzigingen schrijft, q de wijzigingen afsluit en ! de wijzigingen overschrijft.
  • Als u de wijzigingen wilt afsluiten zonder de wijzigingen op te slaan, voert u :q! in en drukt u op Enter.

De wijzigingen worden nu opgeslagen en u moet de Nginx-service opnieuw starten om deze wijzigingen van kracht te laten worden. Voordat u de service opnieuw start, kunt u de sudo nginx -t opdracht uitvoeren om het configuratiebestand te testen. Wanneer deze opdracht wordt uitgevoerd, controleert Nginx de syntaxis van het configuratiebestand en probeert deze vervolgens de bestanden te openen waarnaar wordt verwezen in het configuratiebestand.

Schermopname van de opdracht t.

Zoals u hier kunt zien, lijkt het configuratiebestand dat is gewijzigd correct te zijn.

We moeten Nginx opnieuw starten, zodat de wijzigingen van kracht worden:

sudo systemctl restart nginx

Na het opnieuw opstarten verwacht u een reactie van de ASP.NET Core-toepassing te zien wanneer u een aanvraag naar http://localhost indient, omdat Nginx moet werken als een omgekeerde proxy voor de aanvragen die naar poort 80 worden gedaan.

Start de Nginx-service opnieuw om de wijzigingen van kracht te laten worden en breng vervolgens een aanvraag aan localhost door deze uit te voeren curl localhost. Deze opdracht mislukt echter. De volgende stap is het uitvoeren wget localhosten vervolgens zoeken naar enkele hints over de bron van het probleem.

Schermopname van de opdracht wget.

Het probleem met de Nginx-proxy oplossen

In de vorige schermopname ziet u deze informatie:

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 eerste en tweede regel geven aan dat u localhost kunt oplossen en verbinding kunt maken op de 127.0.0.1:80 socket. Daarom moet Nginx worden uitgevoerd. U kunt dit controleren door de systemctl status nginx opdracht uit te voeren.

De derde regel geeft de bron van het probleem aan. U ontvangt een foutbericht over een ongeldige HTTP 502-gateway . HTTP 502 Bad Gateway is gerelateerd aan proxy's. Dit betekent dat de omgekeerde proxy geen verbinding kan maken met de back-endtoepassing. In dit geval is het uw ASP.NET Core-webtoepassing die moet worden uitgevoerd en moet worden geluisterd op poort 5000 voor de aanvragen. We moeten controleren of de webtoepassing ook wordt uitgevoerd.

Als u wilt beginnen met het oplossen van problemen, voert u dezelfde netstat opdracht uit als voorheen. Gebruik deze keer de grep om de poort 5000 van uw toepassing te filteren. Voer vervolgens het volgende uit netstat -tlp | grep 5000.

Schermopname van de netstat-opdracht.

Deze voorbeelduitvoer geeft aan dat er niets luistert op poort 5000. Daarom is dit de oorzaak van het HTTP 502-antwoord dat afkomstig is van Nginx, omdat er geen proces kan worden gevonden dat luistert op poort 5000.

De oplossing is om uw ASP.NET Core-toepassing te starten. Voordat u verdergaat, kunt u echter een andere benadering bekijken voor het oplossen van dit probleem. Niet elk probleem is net zo eenvoudig om op te lossen als gewoon naar een paar regels logboekinhoud kijken en de hoofdoorzaak vinden. Soms moet u dieper ingaan op andere systeem- en toepassingslogboeken.

Omdat u nauw samenwerkt met Nginx bij het instellen van ASP.NET Core-toepassingen in Linux, raden we u aan te leren welk soort logboeken Nginx en het besturingssysteem biedt voor probleemoplossing.

De Nginx-logboeken controleren

Als u opnieuw uitvoert cat /etc/nginx/nginx.conf en vervolgens zoekt naar de logging settings, ziet u het volgende.

Schermopname van logboekgegevens.

Dit laat zien dat Nginx twee soorten logboeken heeft: Toegangslogboeken en Foutenlogboeken. Deze worden opgeslagen in de map /var/log/nginx/ .

Access-logboeken zijn vergelijkbaar met IIS-logboekbestanden. Een snelle inspectie van de inhoud laat zien dat ze lijken op de volgende schermopname.

Schermopname van de toegangsopdracht.

In Access-logboeken worden geen andere gegevens weergegeven dan de HTTP 502-antwoordstatus die u al wist. U kunt ook de foutenlogboeken inspecteren door deze uit te voeren cat /var/log/nginx/error.log. Deze onthullen veel meer over de oorzaak van het probleem.

Schermopname van foutgegevens.

De aanwijzingen zijn duidelijk: Nginx kan de aanvraag van de client ophalen, maar kan geen verbinding maken met de upstream server op http://127.0.0.1:5000 en met de ASP.NET Core-toepassing die op die poort moet zijn uitgevoerd en luisteren.

Tijdelijke oplossing

U kunt dit probleem omzeilen door de ASP.NET Core-toepassing handmatig te starten. Maak verbinding met de server met behulp van een tweede terminalsessie en voer vervolgens de ASP.NET Core-toepassing uit zoals voorheen.

Schermopname van aspnet-gegevens.

Terwijl uw ASP.NET Core-toepassing wordt uitgevoerd, schakelt u over naar de andere terminalsessie en voert u dezelfde curl localhost opdracht uit. U hebt nu toegang tot uw ASP.NET Core-toepassing die achter Nginx wordt uitgevoerd. In de volgende schermopname ziet u dat u een aanvraag hebt ingediend bij localhost, dat de aanvraag is verwerkt door Nginx en naar de back-endtoepassing is doorgestuurd en u een antwoord hebt ontvangen van uw ASP.NET Core-toepassing.

Schermopname van de opdracht curllocalhost.

U hebt Nginx nu geconfigureerd om zich te gedragen als een omgekeerde proxy voor uw ASP.NET Core-toepassing die wordt uitgevoerd in Linux.

Als de ASP.NET Core-toepassing echter niet wordt gestart na het opnieuw opstarten, wat is het resultaat? Wat gebeurt er als de webtoepassing vastloopt en niet start totdat u merkt dat deze niet wordt uitgevoerd? Moet u uw ASP.NET Core-toepassing starten na elke herstart van procesbeëindiging?

Volgende stappen

Deel 2.3: de ASP.NET Core-toepassing configureren om automatisch te starten

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.