Nginx-fijnafstemming. Bescherming, optimalisatie. Hoe virtuele hosts te maken in nginx

Onderwerp juiste instellingen nginx is erg groot, en ik ben bang dat het niet past in het raamwerk van één artikel over Habré. In deze tekst heb ik geprobeerd te praten over de algemene structuur van de configuratie; meer interessante details en bijzonderheden komen later. :)

Een goed startpunt voor het opzetten van nginx is de configuratie die bij de distributie wordt geleverd, maar veel van de mogelijkheden van deze server worden daarin niet eens genoemd. Veel meer gedetailleerd voorbeeld beschikbaar op de website van Igor Sysoev: sysoev.ru/nginx/docs/example.html. Laten we echter beter proberen onze configuratie helemaal opnieuw op te bouwen, met bridge en dichteressen. :)

Laten we beginnen met algemene instellingen. Eerst geven we de gebruiker aan namens wie nginx zal draaien (het is slecht om als root te werken, iedereen weet het :))

Laten we nu nginx vertellen hoeveel werkprocessen er moeten worden gegenereerd. Gebruikelijk, goede keuze er is een aantal processen gelijk aan het aantal processorkernen op uw server, maar het is de moeite waard om met deze instelling te experimenteren. Indien verwacht hoge belasting op harde schijf, kunt u voor elke fysieke harde schijf één proces uitvoeren, aangezien al het werk nog steeds wordt beperkt door de prestaties ervan.

Werknemersprocessen 2;

Laten we verduidelijken waar we foutenlogboeken moeten schrijven. Dan voor individueel virtuele servers, kan deze parameter worden overschreven, zodat alleen “algemene” fouten, bijvoorbeeld gerelateerd aan het opstarten van de server, in dit logboek verschijnen.

Error_log /spool/logs/nginx/nginx.error_log kennisgeving; # Het meldingsniveau "kennisgeving" kan uiteraard worden gewijzigd

Nu komt het zeer interessante gedeelte ‘evenementen’. Daarin kun je instellen maximale hoeveelheid verbindingen die één werkproces tegelijkertijd zal verwerken, en een methode die zal worden gebruikt om asynchrone meldingen te ontvangen over gebeurtenissen in het besturingssysteem. Uiteraard kunt u alleen die methoden selecteren die beschikbaar zijn op uw besturingssysteem en zijn opgenomen tijdens de compilatie.

Deze instellingen kunnen een aanzienlijke impact hebben op de prestaties van uw server. Ze moeten afzonderlijk worden geselecteerd, afhankelijk van het besturingssysteem en de hardware. Ik kan slechts een paar algemene regels geven.

Modules voor het werken met gebeurtenissen:
- select en poll zijn meestal langzamer en belasten de processor behoorlijk zwaar, maar ze zijn bijna overal beschikbaar en werken bijna altijd;
- kqueue en epoll - efficiënter, maar alleen beschikbaar op respectievelijk FreeBSD en Linux 2.6;
- rtsig - mooi effectieve methode, en wordt zelfs ondersteund door zeer oude Linux-versies, maar kan problemen veroorzaken bij een groot aantal verbindingen;
- /dev/poll - voor zover ik weet, werkt het iets meer exotische systemen, zoals Solaris, en is daarin behoorlijk effectief;

worker_connections-parameter:
- Het totale maximale aantal klanten dat wordt bediend, is gelijk aan worker_processes * worker_connections;
- Soms kunnen zelfs de meest extreme waarden positief werken, zoals 128 processen, 128 verbindingen per proces of 1 proces, maar dan met de parameter worker_connections=16384. In het laatste geval zult u echter hoogstwaarschijnlijk het besturingssysteem moeten afstemmen.

Evenementen (
werkerverbindingen 2048;
gebruik kqueue; # We hebben BSD :)
}

Het volgende gedeelte is het grootste en bevat de meest interessante dingen. Dit is een beschrijving van virtuele servers en enkele parameters die voor alle servers gelden. Ik zal het weglaten standaard instellingen, die in elke configuratie voorkomen, zoals paden naar logboeken.

Http(
# Alle onderstaande code bevindt zich in deze sectie %)
# ...
}

Binnen deze sectie kunnen er enkele behoorlijk interessante parameters zijn.

De sendfile systeemaanroep is relatief nieuw voor Linux. Hiermee kunt u gegevens naar het netwerk verzenden zonder deze naar de adresruimte van de toepassing te hoeven kopiëren. In veel gevallen verbetert dit de serverprestaties aanzienlijk, dus het is het beste om altijd de optie sendfile in te schakelen.

De parameter keepalive_timeout is verantwoordelijk voor maximale tijd het onderhouden van een keepalive-verbinding als de gebruiker er niets via aanvraagt. Bedenk hoe uw site verzoeken verzendt en pas deze instelling aan. Voor sites die actief gebruik maken van AJAX is het beter om de verbinding langer te behouden; voor statische pagina's die gebruikers lang zullen lezen is het beter om de verbinding vroegtijdig te verbreken. Houd er rekening mee dat u, door een inactieve keepalive-verbinding te onderhouden, een verbinding tot stand brengt die op een andere manier kan worden gebruikt. :)

Keepalive_timeout 15;

Afzonderlijk is het de moeite waard om de nginx-proxy-instellingen te benadrukken. Meestal wordt nginx juist als proxyserver gebruikt, en dienovereenkomstig hebben ze dat behoorlijk grote waarde. In het bijzonder is het zinvol om de buffergrootte voor proxy-aanvragen niet kleiner in te stellen dan de verwachte responsgrootte van de backend-server. Bij langzame (of omgekeerd: zeer snelle) backends is het zinvol om de time-outs voor het wachten op een reactie van de backend te wijzigen. Houd er rekening mee dat hoe langer deze time-outs duren, hoe langer uw gebruikers zullen wachten op een reactie als de backend traag is.

Proxy_buffers 8 64k;
proxy_intercept_errors ingeschakeld;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Een kleine truc. In het geval dat nginx meer dan één virtuele host bedient, is het zinvol om een ​​“standaard virtuele host” te creëren die verzoeken verwerkt in gevallen waarin de server geen ander alternatief kan vinden met behulp van de Host-header in het clientverzoek.

# standaard virtuele host
server(
luister 80 standaard;
servernaam localhost;
alles ontkennen;
}

Dit kan worden gevolgd door één (of meerdere) “server”-secties. Elk van hen beschrijft een virtuele host (meestal op naam gebaseerd). Voor eigenaren van veel sites op één hosting, of voor hosters, kan er zoiets als een richtlijn bestaan

Inclusief /spool/users/nginx/*.conf;

De rest zal hoogstwaarschijnlijk hun virtuele host rechtstreeks in de hoofdconfiguratie beschrijven.

Server (
luister 80;

# Houd er rekening mee dat de server_name-richtlijn meerdere namen tegelijkertijd kan specificeren.
servernaam mijnserver.ru mijnserver.com;
access_log /spool/logs/nginx/myserver.access_log getimed;
error_log /spool/logs/nginx/myserver.error_log waarschuwing;
# ...

Laten we de standaardcodering voor uitvoer instellen.

Tekenset utf-8;

En laten we zeggen dat we geen verzoeken willen accepteren van klanten die langer zijn dan 1 megabyte.

Klant_max_lichaamsgrootte 1m;

Laten we SSI inschakelen voor de server en vragen om niet meer dan 1 kilobyte te reserveren voor SSI-variabelen.

Si op;
ssi_waarde_lengte 1024;

En ten slotte zullen we twee locaties beschrijven, waarvan er één naar de backend zal leiden, naar Apache die op poort 9999 draait, en de tweede statische afbeeldingen zal verzenden vanaf de lokale locatie. bestandssysteem. Voor twee locaties heeft dit weinig zin, maar voor een groter aantal is het ook zinvol om direct een variabele te definiëren waarin de hoofdmap van de server wordt opgeslagen, en deze vervolgens te gebruiken in locatiebeschrijvingen.

Vandaag kijken we naar het opzetten van een virtuele host die een site met statische inhoud bedient. Dat wil zeggen, geen CGI, Perl, PHP of wat dan ook. Alle in het artikel genoemde voorbeelden verwijzen naar en zijn getest Debian Linux 5,0 Lenny. Eigenaren van andere systemen mogen hierdoor op geen enkele manier in verwarring worden gebracht, aangezien alleen de paden naar de configuratiebestanden kunnen veranderen, terwijl de inhoud ervan van toepassing is op elk systeem waarop Nginx draait.

Methode voor het opslaan van configuratiebestanden

Zoals je je misschien nog herinnert uit het vorige artikel, kun je de richtlijn gebruiken in Nginx-configuratiebestanden erbij betrekken, die de inhoud van andere bestanden in het hoofdconfiguratiebestand kan bevatten. Deze aanpak biedt beheerders extra flexibiliteit bij de serverconfiguratie, wat vaak tijd en moeite bespaart.

Als je het gemerkt hebt, in het hoofdconfiguratiebestand /etc/nginx/nginx.conf er wordt met geen woord gerept over de configuratie van virtuele servers. Er wordt helemaal niets gezegd over waar de root van het serverdocument zich bevindt, op welke poort de server moet luisteren naar inkomende verbindingen, enz. De voorlaatste regel in het configuratiebestand is echter de volgende:

Inclusief /etc/nginx/sites-enabled/*;

Dat wil zeggen, uit de catalogus /etc/nginx/sites-enabled de inhoud van alle bestanden wordt gelezen en toegepast huidige configuratie server. Als u in de genoemde map kijkt, ziet u daar één bestand standaard, wat een symbolische link naar het bestand is /etc/nginx/sites-available/default. Ook heel handige aanpak: je moet plotseling een virtuele host uitschakelen, je verwijdert gewoon symbolische link, maar doe geen moeite om het bestand heen en weer te verplaatsen.

Een virtuele server creëren

Voor de “zuiverheid van het experiment” stel ik voor om de symbolische link die bij de distributie wordt geleverd, te verwijderen /etc/nginx/sites-enabled/default en begin, om zo te zeggen, met een schone lei.

Maak een bestand /etc/nginx/sites-available/myvhost met de volgende inhoud:

Server ( luister 80; servernaam mijnvhost; access_log /var/log/nginx/myvhost.log; locatie / ( root /var/www/myvhost/; index index.htm index.html; autoindex aan; ) )

Dit is zichzelf eenvoudige configuratie virtuele server in Nginx. Nu over de parameters die in volgorde worden gebruikt.

Eerste optie server, gevolgd door beugel, begint een nieuw gedeelte. Het staat in de secties server en beschrijft de configuraties van alle virtuele servers in Nginx.

Optie luisteren we vertellen Nginx het poortnummer waarop onze virtuele server naar verbindingen moet luisteren. De standaardwaarde van deze optie is 80 , en in het gegeven voorbeeld is de waarde alleen voor de duidelijkheid gedefinieerd. Met deze optie kunt u ook niet alleen het poortnummer opgeven, maar ook het adres van de netwerkinterface waaraan u wilt “koppelen” deze server. In de volgende twee voorbeelden 'hangt' de server bijvoorbeeld op alle TCP/IP-interfaces die beschikbaar zijn in het systeem, op poort 8080:

Luister 8080 luister *:8080

In het volgende voorbeeld wordt een virtuele server gekoppeld aan een specifiek netwerkinterface met IP-adres 192.168.0.1, luisterend naar inkomende verbindingen op poort 8080:

Luister 192.168.0.1:8080

Optie servernaam definieert de virtuele servernaam die wordt gebruikt wanneer de webserver de HTTP-header parseert Gastheer, afkomstig van de klant. Het is deze optie die de configuratie van op naam gebaseerde virtuele hosts implementeert. Zo zal een fragment van de configuratie van twee virtuele hosts op één server er bijvoorbeeld zo uitzien:

Server ( ... luister 80; servernaam voorbeeld-1.com ... ) server ( ... luister 80; servernaam voorbeeld-2.com ... )

De optie servernaam kan meer dan één parameter hebben, zodat u aliassen voor uw server kunt definiëren, bijvoorbeeld:

Servernaam voorbeeld-1.com www.voorbeeld-1.com www1.voorbeeld-1.com

U kunt ook het sterretje gebruiken om een ​​willekeurige reeks tekens in de servernaam te vervangen:

Servernaam voorbeeld-1.com *.voorbeeld-1.com

Met parameter toegang_log we ontmoetten elkaar. De waarde van deze parameter bepaalt de locatie en het formaat van het logbestand voor toegang tot de serverinhoud.

Optie locatie verdient aandacht in een aparte opmerking, dus in dit artikel zullen we slechts in beperkte mate ingaan op de betekenis en mogelijkheden ervan, voor zover voldoende voor het configureren van een statische webserver. Met behulp van de locatieoptie kunt u het gedrag van de server aanpassen, afhankelijk van de URI-waarde die u van de client ontvangt. De sectie dus server kan verschillende geneste locatiesecties bevatten die de configuratie beschrijven op basis van een deel van de URI. In het voorbeeld aan het begin van het artikel is slechts één locatie gedefinieerd, die overeenkomt met elke URI die van de client wordt ontvangen, aangezien elke URI een slash-teken bevat.

Als u er bijvoorbeeld voor moet zorgen dat wanneer een subtekenreeks in een URI wordt gevonden /afbeeldingen/, Nginx heeft geen toegang gekregen tot de hoofdmap van de server, maar heeft gezocht naar bestanden in de map /mnt/server2/var/www/images/, kunt u de volgende twee locaties definiëren:

Locatie / ( root /var/www/myvhost/; ) locatie /images/ ( root /mnt/server2/var/www/; )

In de bovenstaande locatievoorbeelden wordt gezocht naar een subtekenreeks binnen een URI-tekenreeks. Dat wil zeggen: de subtekenreeks /afbeeldingen/ zal worden gevonden als in http://server/afbeeldingen/, En http://server/mijn/images/. Als je Nginx nodig hebt om te zoeken nauwkeurig correspondentie, hiervoor kunt u het symbool gebruiken "=" , waardoor de server op deze manier moet zoeken:

Locatie = /images/ ( root /mnt/server2/var/www/; )

Ook kunt u de substring definiëren waarmee u dit moet doen beginnen URI. Hiervoor wordt een constructie van twee symbolen gebruikt "^~" :

Locatie ^~ /afbeeldingen/ ( ... )

Reguliere expressies worden uiteraard ondersteund en bieden meer flexibiliteit bij het beschrijven van de locatie. De volgende locatie komt overeen met alle URI's die aan het einde namen bevatten grafische bestanden(niet hoofdlettergevoelig):

Locatie ~* \.(gif|jpg|jpeg)$ ( ... )

Hetzelfde, maar hoofdlettergevoelig:

Locatie ~ \.(gif|jpg|jpeg)$ ( ... )

En een beetje over de volgorde van verwerking van locatieopties in Nginx. In tegenstelling tot wat velen op het eerste gezicht lijken, maakt het helemaal niets uit (behalve reguliere expressies, uiteraard) in welke volgorde de locatie is gedefinieerd in het configuratiebestand. Hoe u ze ook verwisselt, het resultaat zal hetzelfde zijn. Bij het zoeken naar de gewenste locatie volgt Nginx het volgende algoritme:

  1. Zoekt naar een regel die begint met "=" . Zodra een dergelijke regel wordt gevonden, wordt het verdere zoeken stopgezet.
  2. Er wordt gezocht naar “reguliere” regels, d.w.z. niet-reguliere expressies. Als er onder hen een regel wordt gevonden die begint met "^~" , wordt verder zoeken gestopt.
  3. Reguliere expressies worden verwerkt in de volgorde waarin ze in het configuratiebestand verschijnen.
  4. Indien er een match wordt gevonden volgens punt 3, dan wordt deze locatie gebruikt, anders wordt de locatie gevonden in punt 2 gebruikt.

Optie wortel de waarde ervan definieert het pad naar de hoofdmap van de virtuele serverdocumenten op het bestandssysteem.

De optie gebruiken index u kunt de namen definiëren van de indexdocumentbestanden die Nginx aan klanten zal "geven" als toegang tot de map is gevraagd. Als er geen dergelijk bestand in de map staat en de optie voor deze locatie is uitgeschakeld autoindex, waarna de client als reactie een HTTP-code ontvangt 403 , wat aangeeft dat de toegang is geweigerd.

Optie autoindex configureert het gedrag van Nginx als het gevraagde indexbestand niet in de map wordt gevonden. Als de waarde van de autoindex-optie, zoals in het bovenstaande voorbeeld, is "op", dan zal de server de inhoud van de directory terugsturen naar de client in de vorm van een HTML-lijst met bestanden. Autoindex is standaard uitgeschakeld, dus wees er voorzichtig mee en zorg ervoor dat u niet per ongeluk kritieke informatie plaatst die iedereen kan zien.

De server opnieuw opstarten

Nu het configuratiebestand klaar is, moet u er vanuit de directory een symbolische link naar maken /etc/nginx/sites-enabled/ zodat wanneer Nginx opnieuw wordt opgestart, het de inhoud ervan in de configuratie zal opnemen:

# ln -s /etc/nginx/sites-available/myvhost /etc/nginx/sites-enabled/myvhost

# mkdir /var/www/myvhost

Het enige dat overblijft is het opnieuw opstarten van de server:

# /etc/init.d/nginx opnieuw opstarten

En als alle instellingen zonder fouten zijn voltooid, kunt u via een webbrowser verbinding maken met uw eerste virtuele Nginx-server en een lege index van bestanden in de hoofdmap van de server bekijken. Probeer een paar statische HTML-bestanden in de map te plaatsen /var/www/myshost en open ze vervolgens vanuit uw browser.

In het volgende artikel zullen we kijken naar de SSL-serverconfiguratie in Nginx.

Meer dan 50% van het verkeer wereldwijd wordt bediend door Apache- en Nginx-technologie– webservers die open zijn broncode. Nginx voert de frontend-functie uit, Apache voert de backend-functie uit. Nginx is de eerste die gebruikersverzoeken accepteert en hierop reageert met de benodigde inhoud: afbeeldingen, bestanden, scripts. Heavy Apache houdt zich hier op zijn beurt niet mee bezig, maar verwerkt de dynamiek. Nginx-proxyverzoeken en retourantwoorden. Deze combinatie is geweldig voor grote sites die door veel gebruikers worden bezocht. Voor kleine sites dit stel zal de productiviteit niet verhogen. Apache en Nginx verminderen de belasting van de server in het algemeen vanwege het feit dat Nginx verwerkt statische inhoud, terwijl Apache dynamische inhoud verwerkt.

Apache en Nginx mogen niet als uitwisselbare technologieën worden beschouwd, ook al hebben ze veel vergelijkbare kenmerken. Elke webserver heeft zijn eigen voordelen en het gebruik ervan hangt af van de taak die moet worden uitgevoerd. In dit artikel Laten we elke technologie bekijken, afhankelijk van het toepassingsgebied. Het artikel zal nuttig zijn voor eigenaren van virtuele en speciale fysieke servers.

Functioneel en snelle Nginx werd uitgebracht in 2004 en begon na deze release aan populariteit te winnen. Vanwege het lichte gewicht en de schaalbaarheid werkt het goed op elke hardware. Nginx wordt op twee manieren gebruikt: als webserver of als proxy.

Wat doet Nginx als webserver?

  • creëert automatisch cachedescriptors en bestandslijsten, onderhoudt indexbestanden en statische zoekopdrachten;
  • versnelt fouttolerantie, proxying en taakverdeling;
  • cachet met FastCGI en versnelt proxying;
  • ondersteunt SSL;
  • ondersteunt Perl;
  • heeft filters en modulariteit;
  • verifieert HTTP en filtert SSL.

Als een Nginx-proxy:

  • volledige levering van StartTLS en SSL;
  • gemakkelijke authenticatie (USER/PASS, LOGIN);
  • gebruikt een externe HTTP-server om door te sturen naar de POP3/IMAP-backend.

Zoals je kunt zien, voert Nginx veel functies uit zonder het systeem te overbelasten. Volgens officiële gegevens wordt de technologie gebruikt door meer dan 56 miljoen sites over de hele wereld (bijvoorbeeld Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), maar Nginx is inferieur aan Apache in populariteit. Waarom is Apache zo populair?

Apache-webserver – platformonafhankelijk software, opgericht in 1995. Dankzij uitgebreide documentatie en goede integratie met software van derden heeft Apache enorm aan populariteit gewonnen. Ondersteunt de volgende besturingssystemen: Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. .

Voordelen van Apache-webserver:

  • steun programmeertalen PHP, Python, Ruby, Perl, ASP, Tcl;
  • gemak van het aansluiten van externe modules;
  • technologische ondersteuning CGI en FastCGI;
  • de aanwezigheid van mechanismen die de veiligheid en differentiatie van gegevenstoegang garanderen;
  • de mogelijkheid om een ​​DBMS te gebruiken voor gebruikersauthenticatie;
  • flexibele en betrouwbare systeemconfiguratie;
  • geschikt voor toepassingen die dit vereisen krachtig cryptografische bescherming gegevens;
  • mogelijkheid tot creëren gebruikersmappen voor de website;
  • mogelijkheid om virtuele hosts te configureren, met behulp waarvan op één fysieke server je kunt verschillende virtuele maken;
  • houdt logboeken bij van wat er op uw server gebeurt;
  • actief feedback met ontwikkelaars en tijdige oplossing van softwarefouten.

Maar ondanks alle voordelen Apache-webserver enigszins moeilijk op te zetten en te bedienen, dus niet elke beginner zal er mee om kunnen gaan. Maar als uw project deze specifieke software nodig heeft, dan zult u dat ook doen juiste keuze ten gunste van Apache.

Wilt u beveiligen PHP-werk op de server? Meer details hierover.

Nadat je de voor- en nadelen van Apache en Nginx kent, kun je kiezen nuttige oplossingen voor uw website, afhankelijk van de doelen die u nastreeft. Maar Misschien heb je de combinatie Apache+Nginx nodig bereiken beste resultaat. Nginx wordt bijvoorbeeld vóór Apache vaak gebruikt als een reverse proxy. Met deze combinatie kunt u veel concurrerende verzoeken afhandelen en sorteert ze. De verzoeken die Nginx niet kan afhandelen, worden naar Apache gestuurd, waardoor de belasting van Apache wordt verminderd. In dit geval neemt de fouttolerantie toe. Voordat u een webserver kiest, moet u verplichte tests uitvoeren op de prestaties en mogelijkheden van elke oplossing.

Voor meer informatie over alle technologieën die door HyperHost-hosting worden ondersteund, gaat u naar.

Dit artikel is bedoeld om algemene bekendheid te geven met de mogelijkheden van het combineren van Apache- en Nginx-webservers. Meer meer informatie V.

Als u onze hulp nodig heeft, neem dan contact met ons op!

Wij beantwoorden graag al uw vragen over het opzetten van webservers. Bovendien kunt u bij ons altijd gratis administratie krijgen. Is het allemaal technische ondersteuning hosters zijn hetzelfde? Over de kenmerken van gratis en betaald beheer in een speciale.

17248 keer Vandaag 9 keer bekeken

Nginx-webserver is een van de meest populaire webservers met zeer hoge prestaties en snelle verwerking van statische verzoeken van gebruikers. Met de juiste opstelling kun je heel veel bereiken hoge prestaties vanaf deze webserver. Nginx is erg snel in de afhandeling statische bestanden, zij het html-pagina's of andere soorten hulpbronnen.

In een van de vorige artikelen hebben we al gekeken naar het instellen van de belangrijkste parameters, in dit artikel wil ik meer stilstaan ​​bij de prestaties en voorbereiding van de webserver voor gebruik in gevechtsomstandigheden. Met betrekking tot Linux-distributie, dan zullen we vandaag CentOS overwegen, dit systeem wordt vaak gebruikt op servers en er kunnen zich enkele problemen voordoen bij het opzetten van Nginx. Vervolgens zullen we kijken naar het instellen van Nginx CentOS, laten we het hebben over hoe we volledige ondersteuning voor http2 kunnen inschakelen, Google paginasnelheid en configureer het hoofdconfiguratiebestand.

De officiële CentOS-repository's bevatten Nginx en het is waarschijnlijk al op uw systeem geïnstalleerd. Maar we willen dat de site werkt met het http2-protocol, waarmee je alle gegevens met één verbinding kunt overbrengen, en dit verhoogt de prestaties. Om via http2 te werken, moet u configureren SSL-certificaat, maar dit staat al geschreven in het artikel over het verkrijgen van een Lets Encrypt Nginx-certificaat. Maar dat is niet alles. Om over te schakelen van regulier SSL naar HTTP2.0 gebruiken de meeste browsers nu het ALPN-protocol, en dit wordt ondersteund sinds OpenSSL 1.02. Terwijl er in de repositories alleen OpenSSL 1.01 is. Daarom moeten we een versie van Nginx installeren die is gebouwd met OpenSSL 1.02. Hiervoor kunt u Broken Repo gebruiken:

sudo yum -y installeer yum-utils
# sudo yum-config-manager --add-repo https://brouken.com/brouken.repo

Als u de EPEL-repository gebruikt, moet u aangeven dat u Nginx er niet uit hoeft te halen:

sudo yum-config-manager --save --setopt=epel.exclude=nginx*;

Om nu de juiste versie van Nginx te installeren, typt u gewoon:

sudo yum installeer nginx

Het meest nieuwste versie Nginx 1.13.2, met volledige ondersteuning ALPN. Laten we vervolgens verder gaan met de installatie.

2. Nginx instellen

Het eerste waar u rekening mee moet houden is de structuur configuratiebestand. Op het eerste gezicht lijkt alles hier erg verwarrend, maar alles is vrij logisch:

mondiale opties
evenementen()
http(
server(
locatie()
}
server()
}

Eerst komen de globale opties, die de basisparameters van het programma instellen, bijvoorbeeld door welke gebruiker het zal worden gestart en het aantal processen. Vervolgens is er een sectie evenementen, waarin wordt beschreven hoe Nginx zal reageren op inkomende verbindingen, gevolgd door de sectie http, waarin alle instellingen met betrekking tot werk worden gecombineerd http-protocol. Het bevat een sectie server, is elk van deze secties verantwoordelijk voor een afzonderlijk domein; de serversectie bevat secties locatie, die elk verantwoordelijk zijn voor een specifiek Verzoek-URL Houd er rekening mee dat het geen bestand op de server is, zoals in Apache, maar de verzoek-URL.

Basis globale instellingen we zullen het doen in het bestand /etc/nginx/nginx.conf. Laten we vervolgens kijken naar wat we precies gaan veranderen en welke waarden het raadzaam is om in te stellen. Laten we beginnen met de globale opties:

  • gebruiker- de gebruiker namens wie de server wordt gestart moet de eigenaar zijn van de directory met de sitebestanden, en php-fpm moet namens hem worden uitgevoerd;
  • werkprocessen- het aantal Nginx-processen dat wordt gelanceerd moet precies zo groot zijn als je kernen hebt, ik heb er bijvoorbeeld 4;
  • worker_cpu_affinity- met deze parameter kunt u elk proces aan een afzonderlijke processorkern toewijzen; stel de waarde in op auto, zodat het programma zelf kiest waaraan het moet worden gekoppeld;
  • worker_rlimit_nofile- het maximale aantal bestanden dat het programma kan openen, voor elke verbinding heb je minimaal twee bestanden nodig en elk proces heeft het aantal verbindingen dat je opgeeft, dus de formule is: werker_processen * werker_verbindingen * 2, parameters werknemer_verbindingen Laten we het hieronder bekijken;
  • pcre_jit- schakel deze optie in om de verwerking van reguliere expressies te versnellen met behulp van JIT-compilatie;

In de evenementensectie moet u twee parameters configureren:

  • werknemer_verbindingen- het aantal verbindingen voor één proces moet voldoende zijn om inkomende verbindingen te verwerken. Eerst moeten we weten hoeveel van deze inkomende verbindingen er zijn, hiervoor kijken we naar de statistieken op de server ip_address/nginx_status. We zullen hieronder bekijken hoe u dit kunt inschakelen. In de regel Actieve verbindingen zien we het aantal actieve verbindingen met de server; we moeten er ook rekening mee houden dat verbindingen met php-fpm ook worden meegeteld. Let vervolgens op de geaccepteerde en afgehandelde velden, de eerste geeft de verwerkte verbindingen weer, de tweede - het aantal geaccepteerde verbindingen. De waarden moeten hetzelfde zijn. Als ze verschillen, betekent dit dat er niet genoeg verbindingen zijn. Zie de voorbeelden, de eerste foto is het probleem, de tweede is de volgorde. Voor mijn configuratie kan het optimale aantal 200 verbindingen zijn (800 in totaal, rekening houdend met 4 processen):

  • multi_accepteren- zorgt ervoor dat het programma meerdere verbindingen tegelijk accepteert, versnelt ook het werk wanneer grote hoeveelheden verbindingen;
  • accept_mutex- stel de waarde van deze parameter in op uit, zodat alle processen onmiddellijk een melding ontvangen van nieuwe verbindingen;

Het wordt ook aanbevolen om de use epoll-richtlijn te gebruiken in de gebeurtenissensectie, omdat dit de meest efficiënte methode is voor het verwerken van inkomende verbindingen voor Linux, maar deze methode wordt standaard gebruikt, dus ik zie geen zin om deze handmatig toe te voegen. Laten we nog een paar parameters uit de http-sectie bekijken:

  • verzendbestand- gebruik de sendfile-gegevensverzendmethode. De meest effectieve methode voor Linux.
  • tcp_nodelay, tcp_nopush- verzendt headers en hoofdtekst van het verzoek in één pakket, werkt iets sneller;
  • keepalive_time-out- time-out voor het onderhouden van een verbinding met de client, als u geen erg trage scripts heeft, dan is 10 seconden voldoende, stel de waarde zo lang in als nodig is zodat de gebruiker verbinding kan maken met de server;
  • reset_timedout_verbinding- verbreek verbindingen na een time-out.
  • open_bestand_cache- cache-informatie over bestanden openen. Bijvoorbeeld open_file_cache max=200000 inactief=120s; max - maximaal aantal bestanden in de cache, cachetijd.
  • open_file_cache_valid- wanneer u de relevantie van bestanden moet controleren. Bijvoorbeeld: open_file_cache_valid 120s;
  • open_file_cache_min_uses- alleen bestanden in de cache opslaan die het opgegeven aantal keren zijn geopend;
  • open_file_cache_fouten- onthoud fouten bij het openen van bestanden.
  • if_modified_sinds- stelt in hoe if-modified-since headers worden verwerkt. Met deze header kan de browser een 304-reactie ontvangen als de pagina sindsdien niet is gewijzigd laatst bekeken. Mogelijke opties: niet versturen - versturen, versturen als de tijd exact overeenkomt - exact, versturen als de tijd exact klopt of meer - eerder;

Dit is hoe de nginx conf-installatie eruit zal zien:

gebruiker nginx;
werkprocessen 4;
worker_cpu_affinity auto;
werknemer_rlimit_nofile 10000;
pcre_jit aan;

error_log /var/log/nginx/error.log waarschuwing;
load_module "modules/ngx_pagespeed.so";

evenementen (
multi_accepteren aan;
accept_mutex uit;
werkerverbindingen 1024;
}

verzendbestand aan;
tcp_nopush aan;
tcp_nodelay aan;

open_file_cache max=200000 inactief=20s;
open_file_cache_valid 120s;
open_file_cache_errors ingeschakeld;

reset_timedout_connection aan;
client_body_time-out 10;
keepalive_timeout 65;

omvatten /etc/nginx/sites-enabled.*.conf

3. http2 instellen

Ik zal het instellen van het servergedeelte niet in detail beschrijven, omdat ik dit al in het artikel heb gedaan Nginx-installatie in Ubuntu en ik heb hier niets toe te voegen, SSL-installatie Dit is een vrij breed onderwerp en zal ook in een apart artikel worden besproken. Maar om http2 te configureren moet u al over SSL beschikken. Pas vervolgens eenvoudig de luisterinstructie in uw serversectie aan:

luister 194.67.215.125:443 standaard_server;

luister 194.67.215.125:443 http2 standaard_server;

Zoals dit op een eenvoudige manier je kunt http2 inschakelen als je het eerder hebt geïnstalleerd juiste versie Nginx.

4. Paginasnelheid instellen

Google Pagespeed is een Nginx-module die verschillende optimalisaties uitvoert om ervoor te zorgen dat pagina's sneller laden, de webserver efficiënter draait en gebruikers minder ongemak ervaren. Dit omvat caching en optimalisatie html-code, beeldoptimalisatie, javascript samenvoegen En css-code en nog veel meer. Dit gebeurt allemaal op Nginx-niveau, dus het is efficiënter dan wanneer je het in PHP zou doen. Maar er is één nadeel: de module verwijdert de Last Modified-header.

Feit is dat PageSpeed ​​een zeer lange cacheregel voor alle bestanden instelt en de hash aan de bestandsnaam toevoegt. Op deze manier is de snelheid van het laden van bronnen veel hoger, omdat de browser alleen bestanden met de nieuwe hash opvraagt, en LastModified wordt verwijderd zodat gebruikers de wijzigingen kunnen zien als een bestand wordt gewijzigd. Laten we nu kijken hoe we de module kunnen installeren. We zullen het moeten bouwen vanuit de broncode.

Installeer eerst de gereedschappen voor montage, het is erg belangrijk, als u deze niet installeert, krijgt u een foutmelding en weet u niet wat u moet doen:

yum installeer wget gcc cmake unzip gcc-c++ pcre-devel zlib-devel

Download en extraheer Nginx-bronnen voor uw versie, bijvoorbeeld 1.13.3:

wget -c https://nginx.org/download/nginx-1.13.3.tar.gz
# tar -xzvf nginx-1.13.3.tar.gz

Instellingen nginx-server omvat niet het opnieuw samenstellen en vervangen van het programma uit de repository, we gebruiken eenvoudigweg deze bronnen om de module te bouwen. Download en extraheer PageSpeed-bronnen:

wget -c https://github.com/pagespeed/ngx_pagespeed/archive/v1.12.34.2-stable.zip
# pak v1.12.34.2-stable.zip uit

Download en pak de PageSpeed-optimalisatiebibliotheek uit in de map met de modulebronnen:

cd ngx_pagespeed-1.12.34.2-stable/
# wget -c https://dl.google.com/dl/page-speed/psol/1.12.34.2-x64.tar.gz
# tar -xvzf 1.12.34.2-x64.tar.gz

OpenSSL 1.02-bronnen downloaden en uitpakken:

wget -c https://www.openssl.org/source/openssl-1.0.2k.tar.gz -O /opt/lib/$OPENSSL.tar.gz
# tar xvpzf openssl-1.0.2k.tar.gz

Nu moeten we de module monteren. Laten we eerst eens kijken naar de opties waarmee de huidige Nginx is gebouwd:

Laten we nu naar de map met Nginx gaan, alle ontvangen opties vervangen door de --add-dynamic-module optie voor PageSpeed, OpenSSL en proberen te bouwen:

cd nginx-1.13.3
# ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx .conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx .pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache /nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path= /var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --met-http_flv_module --met-http_gunzip_module --met-http_gzip_static_module --met-http_mp4_module --met-http_random_index_module --met-http_realip_module --met-http_secure_link_module --met-http_slice_module --met-http_ssl_module --met-http_stub_status_module --met-http_sub_module --met-http_v2_module --met-mail --met-mail_ssl_module --met-stream --met-stream_realip_module --met-stream_ssl_module --met-stream_ssl_preread_module --met-cc-opt="- O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic" --with- ld-opt= --with-openssl=$HOME/openssl-1.0.2k --add-dynamic-module=$HOME/ngx_pagespeed-1.12.34.2-stable $(PS_NGX_EXTRA_FLAGS)
#maken

Als alles correct is gedaan, ontvang je bij de uitvoer de module ngx_pagespeed.so in de map obj, je moet deze naar de map /etc/nginx/modules kopiëren:

cp ngx_pagespeed.so /etc/nginx/modules/ngx_pagespeed.so

Maak een map voor de cache:

mkdir -p /var/ngx_pagespeed_cache
# chown -R nginx:nginx /var/ngx_pagespeed_cache

Voeg nu de volgende regel toe om de module in /etc/nginx/nginx.conf in te schakelen:

load_module "modules/ngx_pagespeed.so";

14 augustus 2009 om 19:29 uur

Nginx instellen

  • Nginx

Het onderwerp van het correct configureren van nginx is erg uitgebreid, en ik ben bang dat het niet past in het raamwerk van één artikel over Habré. In deze tekst heb ik geprobeerd te praten over de algemene structuur van de configuratie; meer interessante details en bijzonderheden komen later. :)

Een goed startpunt voor het opzetten van nginx is de configuratie die bij de distributie wordt geleverd, maar veel van de mogelijkheden van deze server worden daarin niet eens genoemd. Een veel gedetailleerder voorbeeld staat op de website van Igor Sysoev: sysoev.ru/nginx/docs/example.html. Laten we echter beter proberen onze configuratie helemaal opnieuw op te bouwen, met bridge en dichteressen. :)

Laten we beginnen met algemene instellingen. Eerst geven we de gebruiker aan namens wie nginx zal draaien (het is slecht om als root te werken, iedereen weet het :))

Laten we nu nginx vertellen hoeveel werkprocessen er moeten worden gegenereerd. Normaal gesproken is een aantal processen dat gelijk is aan het aantal processorkernen op uw server een goede keuze, maar het is de moeite waard om met deze instelling te experimenteren. Als er een hoge belasting van de harde schijf wordt verwacht, kunt u voor elke fysieke harde schijf één proces uitvoeren, aangezien al het werk nog steeds wordt beperkt door de prestaties.

Werknemersprocessen 2;

Laten we verduidelijken waar we foutenlogboeken moeten schrijven. Vervolgens kan deze parameter voor individuele virtuele servers worden overschreven, zodat alleen “algemene” fouten, bijvoorbeeld gerelateerd aan het opstarten van de server, in dit logboek verschijnen.

Error_log /spool/logs/nginx/nginx.error_log kennisgeving; # Het meldingsniveau "kennisgeving" kan uiteraard worden gewijzigd

Nu komt het zeer interessante gedeelte ‘evenementen’. Daarin kunt u het maximale aantal verbindingen instellen dat één werkproces tegelijkertijd zal verwerken, en de methode die zal worden gebruikt om asynchrone meldingen te ontvangen over gebeurtenissen in het besturingssysteem. Uiteraard kunt u alleen die methoden selecteren die beschikbaar zijn op uw besturingssysteem en zijn opgenomen tijdens de compilatie.

Deze instellingen kunnen een aanzienlijke impact hebben op de prestaties van uw server. Ze moeten afzonderlijk worden geselecteerd, afhankelijk van het besturingssysteem en de hardware. Ik kan slechts een paar algemene regels geven.

Modules voor het werken met gebeurtenissen:
- select en poll zijn meestal langzamer en belasten de processor behoorlijk zwaar, maar ze zijn bijna overal beschikbaar en werken bijna altijd;
- kqueue en epoll - efficiënter, maar alleen beschikbaar op respectievelijk FreeBSD en Linux 2.6;
- rtsig is een redelijk effectieve methode, en wordt zelfs door zeer oude Linuxes ondersteund, maar kan problemen veroorzaken bij een groot aantal verbindingen;
- /dev/poll - voor zover ik weet werkt het in wat exotischere systemen, zoals Solaris, en is daar behoorlijk effectief;

worker_connections-parameter:
- Het totale maximale aantal klanten dat wordt bediend, is gelijk aan worker_processes * worker_connections;
- Soms kunnen zelfs de meest extreme waarden positief werken, zoals 128 processen, 128 verbindingen per proces of 1 proces, maar dan met de parameter worker_connections=16384. In het laatste geval zult u echter hoogstwaarschijnlijk het besturingssysteem moeten afstemmen.

Evenementen (
werkerverbindingen 2048;
gebruik kqueue; # We hebben BSD :)
}

Het volgende gedeelte is het grootste en bevat de meest interessante dingen. Dit is een beschrijving van virtuele servers en enkele parameters die voor alle servers gelden. Ik zal de standaardinstellingen weglaten die in elke configuratie voorkomen, zoals paden naar logboeken.

Http(
# Alle onderstaande code bevindt zich in deze sectie %)
# ...
}

Binnen deze sectie kunnen er enkele behoorlijk interessante parameters zijn.

De sendfile systeemaanroep is relatief nieuw voor Linux. Hiermee kunt u gegevens naar het netwerk verzenden zonder deze naar de adresruimte van de toepassing te hoeven kopiëren. In veel gevallen verbetert dit de serverprestaties aanzienlijk, dus het is het beste om altijd de optie sendfile in te schakelen.

De parameter keepalive_timeout is verantwoordelijk voor de maximale tijd die nodig is om een ​​keepalive-verbinding in stand te houden als de gebruiker er niets over vraagt. Bedenk hoe uw site verzoeken verzendt en pas deze instelling aan. Voor sites die actief gebruik maken van AJAX is het beter om de verbinding langer te behouden; voor statische pagina's die gebruikers lang zullen lezen is het beter om de verbinding vroegtijdig te verbreken. Houd er rekening mee dat u, door een inactieve keepalive-verbinding te onderhouden, een verbinding tot stand brengt die op een andere manier kan worden gebruikt. :)

Keepalive_timeout 15;

Afzonderlijk is het de moeite waard om de nginx-proxy-instellingen te benadrukken. Meestal wordt nginx juist als proxyserver gebruikt, dus ze zijn behoorlijk belangrijk. In het bijzonder is het zinvol om de buffergrootte voor proxy-aanvragen niet kleiner in te stellen dan de verwachte responsgrootte van de backend-server. Bij langzame (of omgekeerd: zeer snelle) backends is het zinvol om de time-outs voor het wachten op een reactie van de backend te wijzigen. Houd er rekening mee dat hoe langer deze time-outs duren, hoe langer uw gebruikers zullen wachten op een reactie als de backend traag is.

Proxy_buffers 8 64k;
proxy_intercept_errors ingeschakeld;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Een kleine truc. In het geval dat nginx meer dan één virtuele host bedient, is het zinvol om een ​​“standaard virtuele host” te creëren die verzoeken verwerkt in gevallen waarin de server geen ander alternatief kan vinden met behulp van de Host-header in het clientverzoek.

# standaard virtuele host
server(
luister 80 standaard;
servernaam localhost;
alles ontkennen;
}

Dit kan worden gevolgd door één (of meerdere) “server”-secties. Elk van hen beschrijft een virtuele host (meestal op naam gebaseerd). Voor eigenaren van veel sites op één hosting, of voor hosters, kan er zoiets als een richtlijn bestaan

Inclusief /spool/users/nginx/*.conf;

De rest zal hoogstwaarschijnlijk hun virtuele host rechtstreeks in de hoofdconfiguratie beschrijven.

Server (
luister 80;

# Houd er rekening mee dat de server_name-richtlijn meerdere namen tegelijkertijd kan specificeren.
servernaam mijnserver.ru mijnserver.com;
access_log /spool/logs/nginx/myserver.access_log getimed;
error_log /spool/logs/nginx/myserver.error_log waarschuwing;
# ...

Laten we de standaardcodering voor uitvoer instellen.

Tekenset utf-8;

En laten we zeggen dat we geen verzoeken willen accepteren van klanten die langer zijn dan 1 megabyte.

Klant_max_lichaamsgrootte 1m;

Laten we SSI inschakelen voor de server en vragen om niet meer dan 1 kilobyte te reserveren voor SSI-variabelen.

Si op;
ssi_waarde_lengte 1024;

En ten slotte zullen we twee locaties beschrijven, waarvan er één naar de backend zal leiden, naar Apache die op poort 9999 draait, en de tweede statische afbeeldingen zal verzenden vanuit het lokale bestandssysteem. Voor twee locaties heeft dit weinig zin, maar voor een groter aantal is het ook zinvol om direct een variabele te definiëren waarin de hoofdmap van de server wordt opgeslagen, en deze vervolgens te gebruiken in locatiebeschrijvingen.



GERELATEERDE ARTIKELEN