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 probeerde ik erover te praten algemene structuur config, wellicht komen er later meer interessante kleine dingen en bijzonderheden. :)

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 wanneer 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 ze inwerken positieve kant zelfs de meest extreme waarden, zoals 128 processen, 128 verbindingen per proces of 1 proces, maar 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.

Hallo, beste gebruiker Habrakhabra. Mijn verhaal gaat over hoe je de basis kunt leggen voor lokale webontwikkelingsprojecten in besturingssysteem Ubuntu 16.04.1 LTS.

In dit artikel wil ik dit wegnemen en verduidelijken mogelijke moeilijkheden gerelateerd aan de installatie en configuratie van software die hiervoor nodig is moderne webontwikkeling, die beginnende ontwikkelaars kunnen tegenkomen, en niet alleen.

Technologieën die in het artikel zullen worden gebruikt: nginx, php-fpm.

Voordat ik met het verhaal begin, wil ik opmerken dat ik al deze acties op een “kaal” systeem heb uitgevoerd.
Ik ga werken met de aptitude pakketbeheerder. Ik raad ook aan om de pakketindex en de pakketten zelf bij te werken voordat u de software installeert. In dit artikel zullen we deze stappen samen uitvoeren.

Laten we gaan!

Een pakketbeheerder installeren geschiktheid, index- en pakketupdates

Installeren:

Sudo apt installeert aptitude
Wij werken de index bij.

Sudo geschiktheidsupdate
We werken pakketten bij (de opdracht werkt alle pakketten bij waarvan er nieuwe versies zijn; als pakketten moeten worden verwijderd, wordt dit gedaan).

Sudo aptitude volledige upgrade

Installatie en configuratie nginx(versie >= 1.10.0)

Wij installeren.

Sudo aptitude installeert nginx
Laten we lanceren.

Sudo-service nginx start
We controleren de versie om er zeker van te zijn dat we geen oude versie hebben geïnstalleerd, dat wil zeggen lager dan 1.10.0.

De installatie en lancering zijn voltooid, laten we nu naar de map gaan waar onze nginx is geïnstalleerd en naar de structuur ervan kijken. De nginx-map bevindt zich op dit pad:

Cd /etc/nginx/
Je kunt de inhoud van de map bekijken met het ls-commando; met de vlaggen -la is het handiger om de inhoud van de map te bekijken (in feite kan dit commando met specifieke vlaggen gedetailleerder en nauwkeuriger worden beschreven, maar we hebben vandaag een ander onderwerp).

Ls-la
Wij zijn geïnteresseerd in op dit moment de twee mappen die u in de schermafbeelding ziet. Dit zijn de mappen die beschikbaar zijn voor sites en sites die geschikt zijn voor sites.

Laten we naar de map met beschikbare sites gaan en beginnen met het configureren van onze virtuele host (site).

Cd /etc/nginx/sites-beschikbaar
Voordat we beginnen met het maken van het configuratiebestand, kijken we eerst wat er in zit deze catalogus. In mijn geval is de map niet leeg, deze bevat al configuratiebestanden, ik heb ze verwijderd om je niet te misleiden.

Belangrijke uitweiding

In het geval dat nginx-installaties“vanaf nul”, namelijk “vanaf nul”, sinds wanneer je nginx verwijdert met de opdracht
sudo apt-get remove nginx of sudo apt remove nginx configuratiebestanden blijven achter en als je plotseling niet begrijpt waarom nginx niet werkt en je het opnieuw wilt installeren (meestal nemen beginners hier hun toevlucht tot Linux-gebruikers), dan zal het zelfs na herinstallatie niet correct werken, omdat de oude configuratiebestanden (ze worden niet verwijderd na verwijdering met de verwijderopdracht) onjuiste instellingen bevatten, ze zullen moeten worden verwijderd of correct moeten worden geconfigureerd, alleen dan nginx zal werken.

Ik raad aan om te verwijderen met het commando sudo apt-get purge nginx of sudo apt purge nginx. Als u gebruikt pakketbeheerder geschiktheid dus sudo-opdracht aptitude purge nginx verwijdert het volledige pakket met alle afhankelijkheden en configuratiebestanden.

Er zal standaard één bestand in deze map staan, genaamd default. Het zal een configuratiebestand bevatten met een voorbeeld en commentaar, u kunt het op uw gemak bestuderen of u kunt het volledig verwijderen (u kunt altijd contact opnemen met officiële documentatie).

Ls-la

Laten we ons eigen configuratiebestand maken, dat overeenkomt met de domeinnaam van onze lokale site (of een echte, als u de naam al kent). Dit is handig als er in de toekomst veel configuratiebestanden zijn, zodat u geen verwarring daarin krijgt. Voor mij zal dit bestand project.local heten.

Sudo touch project.local
Laten we eens kijken wat er is gebeurd.

Laten we het nu in de editor openen, ik open het in nano.

Sudo nano-project.local
We zien dat het leeg is. Laten we nu verder gaan met het maken van ons bestand. U moet de configuratie naar het formulier brengen zoals hieronder beschreven. Ik zal alleen de essentiële richtlijnen van dit bestand beschrijven; de rest zal ik niet beschrijven, aangezien dit op dit moment immers niet belangrijk is; we hebben het over basisinstellingen. Deze “dia”-instellingen zijn voldoende om projecten lokaal te ontwikkelen, niet alleen kleine, maar ook behoorlijk grote. In de volgende artikelen zal ik elk van de gebruikte richtlijnen (zo worden de regels genoemd, bijvoorbeeld servernaam) van dit bestand afzonderlijk beschrijven.

Zie opmerkingen direct op configuratiebestand.

Server (luister 80; # poort luistert naar nginx servernaam project.local; # domeinnaam gerelateerd aan de stroom virtuele gastheer root /home/stavanger/code/project.local; # de map waarin het project zich bevindt, het pad naar het toegangspunt index index.php;
# add_header Toegangscontrole-Allow-Origin *;

# serve static files direct location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ ( access_log off; vervalt max; log_not_found off; ) location / ( # add_header Access-Control-Allow- Oorsprong *; try_files $uri $uri/ /index.php?$query_string ) locatie ~* \.php$ ( try_files $uri = 404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix; :/var/run/php/php7.0-fpm.sock; # verbind de php-fpm socket fastcgi_index.php;
Sla het bestand op. Nu moeten we controleren of er fouten in zitten. Wij kunnen dit als team doen.

Sudo nginx -t Als we dergelijke informatie zien zoals in de schermafbeelding, dan is alles correct en kunnen we doorgaan met het instellen. Als u fouten krijgt, is het de moeite waard om uw configuratiebestand nogmaals te controleren.). Als je nginx helemaal opnieuw hebt geïnstalleerd, dan staat er in deze map een symbolische link naar het standaardbestand, dat hierboven werd besproken. Je kunt het verwijderen als je het niet nodig hebt. Ga naar de gewenste map.

Cd /etc/nginx/sites-enabled/
Nu zijn we binnen de gewenste map. Laten we onze symlink maken. Gebruik om te maken de opdracht ln met de vlag -s, dan geven we het pad naar onze project.local config aan.

Sudo ln -s /etc/nginx/sites-available/project.local
Laten we eens kijken naar onze gemaakte symlink.

Om er zeker van te zijn dat we nog steeds alles correct doen, voeren we de opdracht opnieuw uit.

Bestand gastheren

Dit bestand bevindt zich in /etc/hosts. Door de aanwezigheid van vermeldingen erin kunt u nginx uitvoeren met localhost als domein. In dit bestand kunt u toewijzen alternatieve aliassen Voor ons project project.local wijzen we bijvoorbeeld het domein project.local toe.

Open het bestand in de nano-editor.

Sudo nano /etc/hosts
Er staat nog andere informatie in dit bestand, negeer deze gewoon. Je hoeft alleen maar een regel toe te voegen zoals in mijn screenshot.

Installatie php-fpm (>=7.0)

sudo aptitude installeer php-fpm
Controleren geïnstalleerde versie, voor het geval dat, hoewel in Ubuntu 16.04.1 de 7.0-versie in de repository's staat.

Php-fpm7.0 -v

Laten we ervoor zorgen dat alles in orde is. Laten we php-fpm starten.

Sudo-service php7.0-fpm start
Als u de configuraties bewerkt, vergeet dan niet de daemon opnieuw te starten. Dat doet het. Maar we zullen het niet nodig hebben.

Sudo-service php7.0-fpm opnieuw opstarten
Hiermee is de installatie en configuratie van php-fpm voltooid. Echt, dat is alles. Dit is geen magie; het pad naar de php-fpm-socket was al gespecificeerd in het configuratiebestand. Het kan natuurlijk zijn dat je er een paar nodig hebt php-extensies voor de ontwikkeling van persoonlijke projecten, maar u kunt ze leveren wanneer ze nodig zijn.

Laten we nu naar de map met ons project gaan, ik heb het langs dit pad.

Cd /home/stavanger/code/project.local
Laten we naar de bovenstaande map gaan en de machtigingen 777 maken (dat wil zeggen, we zullen het doen volledige rechten directory met ons project project.local). Dit zal ons in de toekomst voor onnodige problemen behoeden.

Cd .. sudo chmod -R 777 project.local
Hiermee is de software-installatie voltooid. Laten we een testbestand maken in onze werkmap project.local en ervoor zorgen dat alles werkt. Ik zal een index.php-bestand maken met deze inhoud.

We gaan naar de browser en zien dat alles goed voor ons werkt! PHP-tolk inclusief.

Met betrekking tot de lezers, Stavanger.

Meer dan 50% van het verkeer wereldwijd wordt bediend door Apache- en Nginx-technologie– webservers die open source zijn. 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 locaties zal deze combinatie 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 snel, 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, bedient 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 is een platformonafhankelijke software die in 1995 is gemaakt. 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 krachtige cryptografische gegevensbescherming;
• de mogelijkheid om aangepaste mappen voor de website te maken;
• mogelijkheid om virtuele hosts te configureren, met behulp waarvan u meerdere virtuele op één fysieke server kunt maken;
• houdt logboeken bij van wat er op uw server gebeurt;
• actieve feedback van ontwikkelaars en tijdige oplossing van softwarefouten.

Maar ondanks alle voordelen van de Apache-webserver is deze enigszins moeilijk te configureren en te bedienen, dus niet elke beginner zal er mee om kunnen gaan. Maar als uw project deze specifieke software nodig heeft, dan maakt u de juiste keuze ten gunste van Apache.

Wilt u PHP op uw server beveiligen? Meer details hierover.

Nadat u vertrouwd bent geraakt met de voor- en nadelen van Apache en Nginx, kunt u een nuttige oplossing voor uw website kiezen, afhankelijk van de doelen die u nastreeft. Maar Misschien heb je de combinatie Apache+Nginx nodig om het beste resultaat te bereiken. 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. Nog meer informatie in .

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 alle technische ondersteuning voor hosts hetzelfde? Over de kenmerken van gratis en betaald beheer in een speciale.

17248 keer Vandaag 9 keer bekeken

Hallo! Vandaag zullen we het hebben over zo'n noodzakelijk concept als virtuele gastheren op de nginx-webserver. We zullen het Ubuntu-besturingssysteem als voorbeeld gebruiken. Voor andere Linux-systemen zal de opzet erg op elkaar lijken. Dit instructieartikel zal vooral interessant zijn voor beginnende webmasters en beheerders, omdat... zij hebben deze vraag het vaakst.

Een virtuele host is...

Laten we eerst een virtuele host definiëren. Dus, virtuele gastheer is verdeling van de adresruimte van de webserver, bijvoorbeeld op sitenaam, waardoor u meerdere websites/applicaties op één fysieke server kunt uitvoeren. In nginx-documentatieterminologie wordt ook een virtuele host genoemd "Serverblokkeren", maar om het meer op Apache te laten lijken, zal ik het uniform noemen, omdat hun doel is hetzelfde. En nog een overeenkomst: laten we voor de eenvoud een site noemen die we gaan configureren.

Een virtuele host maken

Voor veel van de opdrachten in deze handleiding is vereist dat uw gebruiker sudoer-rechten op de VPS heeft. Als u deze niet heeft, is het helaas onwaarschijnlijk dat u virtuele hosts kunt instellen.

Voorinstelling

Nu zal ik je iets vertellen dat iedereen moet weten! Om een ​​virtuele host in nginx in te stellen, hebt u een nginx-webserver nodig die op uw machine is geïnstalleerd. Kapitein Duidelijk is bij ons! Als je nginx al hebt geïnstalleerd, kun je deze stap veilig overslaan en verder gaan volgens de instructies. Als u het om de een of andere reden nog steeds niet op uw computer heeft staan, voert u de opdracht in de console in:

Sudo apt-get install -ynginx

Optie "-y" We voegen het commando apt-get toe om geen ja-ja-ja te antwoorden op de vervelende vragen van het installatieprogramma, omdat we er zeker van zijn dat we dit pakket willen installeren en akkoord gaan met het gebruik van de schijfruimte die het in beslag neemt. Als u nog steeds niet zeker weet of u het met alles eens bent, voeg deze optie dan niet toe.

Een sitemap maken

Laten we dus, voordat we een virtuele host maken, een sitemap maken waarin we alle bestanden plaatsen waarmee onze webserver zal werken.

Het pad naar deze map in de configuratie van de host die wordt gemaakt, zal zijn Documentwortel, een soort context, een isolatiepunt, waarboven je niet van buitenaf kunt stijgen zonder eerst de configuratie in te stellen en relatief ten opzichte van welke paden naar de opgevraagde bestanden worden gebouwd. Met optie "-P" Met het mkdir-commando hoeven we ons geen zorgen te maken over het maken van bovenliggende mappen, deze worden automatisch aangemaakt:

Sudo mkdir -p /var/www/mysite.ru/public_html

Hier gebruiken we een echt geverifieerd DNS-domein met correcte records die naar onze machine verwijzen. Om een ​​virtuele host met een niet-geregistreerd domein aan te maken, bijvoorbeeld voor lokale ontwikkeling, moet u de juiste gegevens invoeren in het bestand /etc/hosts. Meer details hierover vindt u aan het einde van het artikel.

Toegangsrechten

Nu heeft alleen de rootgebruiker rechten op onze gemaakte map. We moeten rechten op de directory geven aan de gewenste gebruiker, om er niet voortdurend mee te werken in de superuser-modus. U kunt de hieronder gebruikte "www-data"-gebruiker vervangen door een andere, maar nginx wordt standaard als deze gebruiker uitgevoerd.

Sudo chown -R www-data:www-data /var/www/mysite.ru/public_html

Laten we er nu voor zorgen dat alle gebruikers onze nieuwe bestanden kunnen lezen:

Sudo chmod 755 /var/www

We bedoelen dat we werken met een VPS waarop alle gebruikers niets slechts doen of waarop alleen jij staat. Daarom kunnen we machtigingen 755 geven aan de map /var/www. Als het in uw geval onmogelijk is om alle gebruikers van het systeem rechten te geven om deze map te lezen, bestudeer dan de kwestie van het differentiëren van rechten en stel deze zelf in.

Nu bent u helemaal klaar met uw rechten!

Een pagina maken

Nu moeten we een aantal statische bestanden (HTML-pagina's, afbeeldingen, scripts, stijlen, enz.) in onze map plaatsen die onze server zal distribueren. Laten we een HTML-pagina index.htm maken, die de hoofdpagina van onze site zal zijn:

Sudo nano /var/www/mysite.ru/public_html/index.htm

En voeg er wat markeringen aan toe die aan de gebruiker worden getoond:

Hoera! Je kon Virtual Host in nginx configureren!

Opslaan en afsluiten.

Een virtuele hostconfiguratie maken

We zijn op het punt gekomen om ons nieuwe virtuele hostconfiguratiebestand te maken, dat alle site-informatie zal bevatten die de webserver nodig heeft.

In nginx bevindt zich in de map /etc/nginx/sites-available een sjabloon voor de configuraties die moeten worden gemaakt. Laten we het kopiëren voor onze site:

Sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/mysite.ru

Virtuele hostconfiguratie

Open het nieuwe configuratiebestand en u ziet alle benodigde informatie die u moet invullen.

Sudo nano /etc/nginx/sites-available/mysite.ru

We moeten wijzigingen aanbrengen in de huidige configuratie. Het resultaat voor ons eenvoudige geval zou ongeveer zo moeten zijn:

Server ( luister 80; root /var/www/mijnsite.ru/public_html; index index.html index.htm; servernaam mijnsite.ru www.mijnsite.ru; )

Hier moet u het pad naar de map met sitestatistieken en de naam van de server waarmee u toegang krijgt tot uw site correct opgeven. Als u het pad onjuist of helemaal niet opgeeft, kunt u de virtuele host niet configureren. Als servernaam kunt u ook een IP-adres of meerdere namen opgeven, gescheiden door een spatie, waarmee de host toegankelijk zal zijn, zoals wij deden.

Dat is alles, we zijn klaar met dit bestand. Sla het op en sluit het.

Virtuele hostactivering

Nginx heeft mappen die beschikbaar zijn voor sites en mappen die voor sites zijn ingeschakeld. De eerste slaat de configuraties op van ALLE virtuele hosts die zich op een bepaalde server kunnen bevinden, en de directory met sites bevat symbolische links naar actieve. Niemand verbiedt het plaatsen van het originele configuratiebestand in sites-enabled in plaats van in een link, maar dit zal minder handig zijn, omdat als het nodig is om het uit te schakelen, moet je het bestand verwijderen (dan zal het problematisch zijn om het weer in te schakelen) of het naar een andere map verplaatsen (dan moeten we onthouden waar we het naartoe hebben verplaatst). Het is veel gemakkelijker om een ​​symbolische link te laten crashen!

Daarom moeten we, om onze virtuele host te activeren, een symbolische link creëren tussen de directory die beschikbaar is voor sites, waar ons configuratiebestand zich bevindt, en sites die ingeschakeld zijn. Apache heeft hiervoor een speciaal commando, a2ensite. Er bestaat niet zo'n commando in nginx, dus laten we het volgende doen:

Sudo ln -s /etc/nginx/sites-available/mysite.ru /etc/nginx/sites-enabled/mysite.ru

Om “conflicterende servernaamfouten” te voorkomen en er zeker van te zijn dat uw site de nodige informatie verstrekt, kunt u de standaardhost uit de lijst met actieve hosts verwijderen:

Sudo rm /etc/nginx/sites-enabled/default

Opnieuw opstarten

We hebben al heel wat stappen doorlopen en vrijwel alles ingericht. Laten we nu onze webserver opnieuw opstarten zodat deze de nieuwe configuratie toepast, maar daarvoor is het een goede gewoonte om te controleren of alles met de configuratie correct is en dat nginx het correct begrijpt. Om dit te doen, moet u nginx diagnostics uitvoeren met de volgende opdracht:

Sudo nginx -t

Een dergelijke controle is uiterst noodzakelijk bij het configureren op productieservers, zodat niet blijkt dat we het nginx restart-commando hebben gebeld, maar door een onjuiste configuratie niet kon starten en al onze virtuele hosts niet reageren.

Als het antwoord dat u heeft ontvangen er ongeveer zo uitziet:

Nginx: de syntaxis van het configuratiebestand /etc/nginx/nginx.conf is ok nginx: de test van het configuratiebestand /etc/nginx/nginx.conf is succesvol

Dan is alles in orde en kun je de server veilig opnieuw opstarten met het commando:

Sudo-service nginx opnieuw opstarten

Anders moet u naar het hostconfiguratiebestand kijken. Daar gaf je aan dat er iets mis was.

Lokale hosts instellen

Als u een IP-adres als servernaam hebt opgegeven, kunt u deze stap overslaan, omdat U hoeft geen lokale host te configureren; uw virtuele host werkt zonder deze. Maar als u met uw virtuele host wilt werken zonder een echte domeinnaam, kunt u localhosts op uw machine instellen. Zoals ik hierboven al zei, is dit erg handig, bijvoorbeeld tijdens de ontwikkeling. Ik kan mysite.dev maken, en er zal een lokale onstabiele versie van de site op draaien. Voor MacOS- en Linux-systemen moet u de volgende opdracht uitvoeren:

Sudo nano /etc/hosts

Als u onder Windows werkt, moet het bestand van lokale hosts zich ongeveer op dit pad bevinden: C:\Windows\System32\drivers\etc\hosts.

Voeg een vermelding over de nieuwe lokale host toe aan het bestand. In ons geval moeten we twee records toevoegen, omdat in servernaam hebben we twee domeinen opgegeven.

12.34.56.789 mijnsite.ru 12.34.56.789 www.mijnsite.ru

Totdat dit item wordt verwijderd, ontvangen oproepen naar mysite.ru informatie over deze host uit dit bestand en worden u doorgestuurd naar uw externe server. Als de server lokaal is geïmplementeerd, moet u “127.0.0.1” schrijven in plaats van “12.34.56.789”.

Om toekomstige problemen te voorkomen, is het een goede gewoonte om hostvermeldingen te verwijderen nadat ze hun doel hebben bereikt.

Resultaten

Nu kunnen we de resultaten van ons werk zien! We voeren het adres http://mysite.ru of http://www.mysite.ru in de browser in en bewonderen de startpagina die we hebben gemaakt op basis van index.htm. Beide adressen moeten onze startpagina weergeven. Dat is het! Onze virtuele host werkt geweldig.

En anderen). De huidige versie, 0.6.x, wordt als stabiel beschouwd in termen van betrouwbaarheid, terwijl releases van de 0.7-tak als onstabiel worden beschouwd. Het is belangrijk op te merken dat de functionaliteit van sommige modules zal veranderen, waardoor de richtlijnen ook kunnen veranderen, waardoor achterwaartse compatibiliteit in nginx vóór versie 1.0.0 niet gegarandeerd is.

Waarom is nginx zo goed en waarom zijn beheerders van projecten met een hoge belasting er zo dol op? Waarom gebruik je niet gewoon Apache?

Waarom is Apache slecht?

Eerst moeten we uitleggen hoe netwerkservers over het algemeen werken. Degenen die bekend zijn met netwerkprogrammering weten dat er in wezen drie modellen voor serverwerking zijn:

1. Consistent. De server opent een luistersocket en wacht tot er een verbinding verschijnt (tijdens het wachten bevindt deze zich in een geblokkeerde status). Wanneer er een verbinding tot stand komt, verwerkt de server deze in dezelfde context, verbreekt de verbinding en wacht opnieuw op de verbinding. Dit is uiteraard verre van de beste manier, vooral als het werken met een klant lang duurt en er veel verbindingen zijn. Bovendien heeft het sequentiële model nog veel meer nadelen (bijvoorbeeld het onvermogen om meerdere processors te gebruiken) en wordt het in reële omstandigheden praktisch niet gebruikt.
2. Multi-process (multi-threaded). De server opent een luistersocket. Wanneer er een verbinding binnenkomt, accepteert deze deze, waarna er een nieuw proces of thread wordt gecreëerd (of uit een verzameling van vooraf gemaakte verbindingen wordt gehaald) die zo lang als gewenst met de verbinding kan werken, en na voltooiing van het werk wordt beëindigd of keer terug naar het zwembad. De rode draad is ondertussen klaar om een ​​nieuwe verbinding te accepteren. Dit is het meest populaire model omdat het relatief eenvoudig te implementeren is, complexe en tijdrovende berekeningen op elke client mogelijk maakt en alle beschikbare processors gebruikt. Een voorbeeld van het gebruik ervan is de Apache-webserver. Deze aanpak heeft echter ook nadelen: bij een groot aantal gelijktijdige verbindingen worden er veel threads (of, erger nog, processen) gecreëerd en verspilt het besturingssysteem veel bronnen aan contextwisselingen. Het is vooral slecht als klanten erg traag zijn in het accepteren van inhoud. Dit resulteert in honderden threads of processen die bezig zijn met het verzenden van gegevens naar langzame clients, wat extra belasting voor de OS-planner creëert, het aantal interrupts verhoogt en behoorlijk veel geheugen verbruikt.
3. Niet-blokkerende stopcontacten/statusmachine. De server werkt binnen een enkele thread, maar maakt gebruik van niet-blokkerende sockets en een polling-mechanisme. Die. de server selecteert bij elke iteratie van de eindeloze lus uit alle sockets degene die klaar is om gegevens te ontvangen/verzenden met behulp van de select()-aanroep. Nadat de socket is geselecteerd, verzendt de server er gegevens naartoe of leest deze, maar wacht niet op bevestiging, maar gaat naar de beginstatus en wacht op een gebeurtenis op een andere socket of verwerkt de volgende waarin de gebeurtenis plaatsvond tijdens het verwerken van de socket. vorige. Dit model maakt zeer efficiënt gebruik van de processor en het geheugen, maar is vrij complex om te implementeren. Bovendien moet binnen dit model de verwerking van gebeurtenissen op een socket zeer snel plaatsvinden, anders stapelen veel gebeurtenissen zich op in de wachtrij en loopt deze uiteindelijk over. Dit is precies het model waar nginx op werkt. Bovendien kunt u hiermee meerdere werkprocessen (zogenaamde werknemers) uitvoeren, d.w.z. kan meerdere processoren gebruiken.

Stel je dus de volgende situatie voor: 200 clients met een kanaal van 256 Kbit/s maken verbinding met een HTTP-server met een kanaal van 1 Gbit/s:

Wat gebeurt er in het geval van Apache? Er worden 200 threads/processen gecreëerd die relatief snel inhoud genereren (dit kunnen dynamische pagina's zijn of statische bestanden die van schijf worden gelezen), maar deze langzaam aan klanten afleveren. Het besturingssysteem wordt gedwongen om te gaan met een heleboel threads en I/O-vergrendelingen.

In deze situatie besteedt Nginx een orde van grootte minder OS-bronnen en geheugen aan elke verbinding. Dit brengt echter een beperking van het nginx-netwerkmodel aan het licht: het kan intern geen dynamische inhoud genereren, omdat dit zal leiden tot blokkades binnen nginx. Uiteraard is er een oplossing: nginx kan dergelijke verzoeken (voor het genereren van inhoud) proxyen naar elke andere webserver (bijvoorbeeld dezelfde Apache) of naar een FastCGI-server.

Laten we het werkingsmechanisme van de nginx-combinatie als de “hoofd”-server en Apache als de server voor het genereren van dynamische inhoud beschouwen:

Nginx accepteert de verbinding van de client en leest de volledige aanvraag ervan. Hierbij moet worden opgemerkt dat totdat nginx het volledige verzoek niet heeft gelezen, het het niet ter “verwerking” indient. Hierdoor zijn bijna alle voortgangsindicatoren voor het uploaden van bestanden meestal defect. Het is echter mogelijk om deze te repareren met behulp van de upload_progress-module van derden (hiervoor is een aanpassing van de applicatie vereist).

Nadat nginx het volledige antwoord heeft gelezen, wordt er een verbinding met Apache geopend. Deze laatste doet zijn werk (genereert dynamische inhoud), waarna hij zijn antwoord naar nginx stuurt, die het in het geheugen of een tijdelijk bestand buffert. In de tussentijd maakt Apache bronnen vrij. Vervolgens levert nginx de inhoud langzaam aan de klant, terwijl het ordes van grootte minder middelen besteedt dan Apache.

Dit schema heet frontend + backend en wordt heel vaak gebruikt.

Installatie

Omdat nginx begint net aan populariteit te winnen, er zijn enkele problemen met binaire pakketten, dus wees voorbereid om het zelf te compileren. Meestal zijn hier geen problemen mee, u hoeft alleen maar de uitvoer van het commando./configure --help zorgvuldig te lezen en de compilatie-opties te selecteren die u nodig heeft, bijvoorbeeld deze:

./configure\
--prefix=/opt/nginx-0.6.x \ # installatievoorvoegsel
--conf-path=/etc/nginx/nginx.conf \ # locatie van het configuratiebestand
—pid-path=/var/run/nginx.pid \ # ... en pid-bestand
—user=nginx \ # gebruikersnaam waaronder nginx zal draaien
—with-http_ssl_module —with-http_gzip_static_module —with-http_stub_status_module \ # lijst met vereiste
—zonder-http_ssi_module —zonder-http_userid_module —zonder-http_autoindex_module —zonder-http_geo_module —zonder-http_referer_module —zonder-http_memcached_module —zonder-http_limit_zone_module # ... en onnodige modules

Na de configuratie dient u de standaard make && make install uit te voeren, waarna u nginx kunt gebruiken.

Bovendien kun je in Gentoo een ebuild uit de standaard ports-boom gebruiken; in RHEL/CentOS door de epel-repository (die nginx 0.6.x bevat) of srpm voor versie 0.7, die hier kan worden gedownload: http://blogs.mail.ru/community/nginx; op Debian kun je het nginx-pakket uit de onstabiele branch gebruiken.

Configuratiebestand

Het nginx-configuratiebestand is erg handig en intuïtief. Het heet gewoonlijk nginx.conf en bevindt zich in $prefix/conf/ als de locatie niet werd overschreven tijdens het compileren. Ik plaats het graag in /etc/nginx/, net als de ontwikkelaars van alle bovengenoemde pakketten.

De structuur van het configuratiebestand is als volgt:

gebruiker nginx; # gebruikersnaam met wiens rechten nginx zal draaien
werkprocessen 1; # aantal werkprocessen
evenementen (
<…># dit blok specificeert het pollingmechanisme dat zal worden gebruikt (zie hieronder) en het maximale aantal mogelijke verbindingen
}

Http(
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;

# beschrijving van servers (dit is wat VirtualHost wordt genoemd in apache)
server(
# serveradres en naam
luister *:80;
servernaam aaa.bbb;

<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;

# en zo kun je een locatie definiëren, waarvoor je ook bijna alle richtlijnen kunt overschrijven die op meer globale niveaus zijn gespecificeerd
locatie /abcd/ (
<директивы>;
}
# Bovendien kunt u de locatie maken met behulp van een reguliere expressie, bijvoorbeeld als volgt:
locatie ~ \.php$ (
<директивы>;
}
}

# een andere server
server(
luister *:80;
servernaam ccc.bbb;

<директивы>
}
}

Houd er rekening mee dat elke richtlijn moet eindigen met een puntkomma.
Reverse proxying en FastCGI

Dus hierboven hebben we gekeken naar de voordelen van het frontend + backend-schema, de installatie, structuur en syntaxis van het configuratiebestand uitgezocht, en nu zullen we kijken hoe we reverse proxying in nginx kunnen implementeren.

En het is heel eenvoudig! Bijvoorbeeld als volgt:

locatie/(
proxy_pass http://1.2.3.4:8080;
}

In dit voorbeeld worden alle verzoeken die in locatie / vallen, geproxyd naar server 1.2.3.4, poort 8080. Dit kan Apache zijn of een andere http-server.

Er zijn echter verschillende subtiliteiten die verband houden met het feit dat de applicatie ervan uitgaat dat in de eerste plaats alle verzoeken van hetzelfde IP-adres afkomstig zijn (wat bijvoorbeeld kan worden beschouwd als een poging tot een DDoS-aanval of het raden van wachtwoorden), en ten tweede, neem aan dat het draait op host 1.2.3.4 en poort 8080 (genereert respectievelijk onjuiste omleidingen en absolute links). Om deze problemen te voorkomen zonder de applicatie te hoeven herschrijven, vind ik de volgende configuratie handig:
Nginx luistert naar de externe interface op poort 80.

Als de backend (laten we zeggen Apache) zich op dezelfde host bevindt als nginx, dan “luistert” deze op poort 80 op 127.0.0.1 of een ander intern IP-adres.

De nginx-configuratie ziet er in dit geval als volgt uit:

server (
luister 4.3.2.1:80;
# stel de Host- en X-Real-IP-header in: voor elk verzoek dat naar de backend wordt verzonden
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host:$proxy_port;
# of “proxy_set_header Host $host;” de applicatie zal:80 aan alle links toevoegen
}

Om ervoor te zorgen dat de applicatie de IP-adressen van bezoekers kan onderscheiden, moet u ofwel de module mod_extract_forwarded installeren (als deze wordt uitgevoerd door de Apache-server), of de applicatie aanpassen zodat deze informatie over het IP-adres van de gebruiker van de X- Real-IP HTTP-header.

Een andere backend-optie is het gebruik van FastCGI. In dit geval zal de nginx-configuratie er ongeveer zo uitzien:

server (
<…>

# locatie waar verzoeken voor php-scripts naartoe zullen gaan
locatie ~ .php$ (
fastcgi_pass 127.0.0.1:8888; # bepaal het adres en de poort van de fastcgi-server,
fastcgi_index index.php; # ...indexbestand

# en enkele parameters die moeten worden doorgegeven aan de fastcgi-server, zodat deze begrijpt welk script moet worden uitgevoerd en met welke parameters:
fastcgi_param SCRIPT_FILENAME /usr/www/html$fastcgi_script_name; # scriptnaam
fastcgi_param QUERY_STRING $query_string; # querytekenreeks
# en verzoekparameters:
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
}

# vanwege het feit dat locaties met reguliere expressies een hoge “prioriteit” hebben, zullen alle niet-php-verzoeken hier terechtkomen.

locatie/(
root /var/www/html/
}

Statica

Om de backend minder te laden, is het beter om statische bestanden alleen via nginx aan te bieden - het kan deze taak beter aan, omdat het besteedt aanzienlijk minder bronnen aan elk verzoek (het is niet nodig om een ​​nieuw proces voort te brengen, en het Nginx-proces verbruikt doorgaans minder geheugen en kan veel verbindingen onderhouden).

In het configuratiebestand ziet het er ongeveer zo uit:

server (
luister *:80;
servernaam mijnserver.com;

Locatie/(
proxy_pass


">http://127.0.0.1:80;

}

# neem aan dat alle statische bestanden in /files staan
locatie /bestanden/ (
root /var/www/html/; # geeft het pad naar fs aan
verloopt op 14d; # voeg de Expires-header toe:
error_page 404 = @terug; # en als het bestand niet wordt gevonden, sturen we het naar de genoemde locatie @back
}

# verzoeken van /files waarvoor geen bestand is gevonden, worden naar de backend gestuurd en deze kan het vereiste bestand genereren of een mooie foutmelding weergeven
locatie @terug (
proxy_pass
"title="http://127.0.0.1:80;

">http://127.0.0.1:80;

}

Als niet alle statische gegevens in een specifieke map zijn geplaatst, gebruik dan een reguliere expressie:

locatie ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf |js)$ (
# vergelijkbaar met wat hierboven staat, alleen alle verzoeken die eindigen op een van de opgegeven achtervoegsels gaan naar deze locatie
root /var/www/html/;
error_page 404 = @terug;
}

Helaas implementeert nginx geen asynchroon werken met bestanden. Met andere woorden: de nginx-werknemer wordt geblokkeerd bij I/O-bewerkingen. Dus als je veel statische bestanden hebt en, vooral als ze van verschillende schijven worden gelezen, is het beter om het aantal werkprocessen te verhogen (tot een aantal dat 2-3 keer groter is dan het totale aantal heads op de schijf ). Dit verhoogt uiteraard de belasting van het besturingssysteem, maar de algehele prestaties nemen toe. Om met een typische hoeveelheid statische inhoud te werken (niet een heel groot aantal relatief kleine bestanden: CSS, JavaScript, afbeeldingen), zijn een of twee workflows voldoende.

Wordt vervolgd

Koppelingen

Hier vindt u aanvullende informatie over nginx: