Tere, Hea kasutaja Habrakhabra. Minu jutt tuleb sellest, kuidas operatsioonisaalis kohalike veebiarendusprojektide jaoks pinnast ette valmistada Ubuntu süsteem 16.04.1 LTS.

Selles artiklis tahaksin hajutada ja selgitada võimalikud raskused mis on seotud vajaliku tarkvara installimise ja konfigureerimisega kaasaegne veebiarendus, millega algajad arendajad võivad kokku puutuda ja mitte ainult.

Tehnoloogiad, mida artiklis kasutatakse: nginx, php-fpm.

Enne loo alustamist tahan märkida, et tegin kõik need toimingud "palja" süsteemiga.
Ma töötan koos aptitude pakettide halduriga. Samuti soovitan enne tarkvara installimist uuendada paketiindeksit ja pakette ennast. Selles artiklis teeme need sammud koos.

Mine!

Paketihalduri installimine sobivus, indeksi ja paketi värskendused

Installige:

Sudo apt install aptitude
Uuendame indeksit.

Sudo sobivuse värskendus
Uuendame pakette (käsk värskendab kõiki pakette, mille jaoks on uued versioonid; kui pakette on vaja eemaldada, siis seda tehakse).

Sudo aptitude täielik täiendus

Paigaldamine ja seadistamine nginx(versioon >= 1.10.0)

Paigaldame.

Sudo aptitude installige nginx
Käivitame.

Sudo teenuse nginx algus
Kontrollime versiooni, veendumaks, et me pole installinud vana, st madalamat versiooni kui 1.10.0.

Installimine ja käivitamine on lõpule viidud, nüüd läheme kataloogi, kuhu meie nginx on installitud, ja vaatame selle struktuuri. Nginxi kataloog asub sellel teel:

CD /etc/nginx/
Kataloogi sisu saab vaadata käsuga ls, lippudega -la on kataloogi sisu vaatamine mugavam (tegelikult saab seda konkreetsete lippudega käsku täpsemalt ja täpsemalt kirjeldada, aga meil on täna teine ​​teema).

Ls-la
Oleme huvitatud Sel hetkel kaks kataloogi, mida näete ekraanipildil. Need on saitide jaoks saadaolevad ja saitide lubatud kataloogid.

Läheme saadaolevate saitide kataloogi ja alustame oma virtuaalse hosti (saidi) seadistamist.

CD /etc/nginx/sites-available
Enne konfiguratsioonifaili loomise alustamist kontrollime, mis meil on see kataloog. Minu puhul pole kataloog tühi, see sisaldab juba konfiguratsioonifaile, kustutasin need, et mitte eksitada.

Oluline kõrvalekalle

Millal nginxi installid"nullist", nimelt "nullist", alates nginxi desinstallimisest käsuga
sudo apt-get eemalda nginx või sudo apt eemalda nginxi konfiguratsioonifailid jäävad alles ja kui sa äkki ei saa aru, miks nginx ei tööta ja soovid selle uuesti installida (tavaliselt kasutavad seda algajad Linuxi kasutajad), siis isegi pärast uuesti installimist ei tööta see õigesti, kuna vanad konfiguratsioonifailid (neid ei kustutata pärast eemaldamist käsuga eemaldada) sisaldavad valesid sätteid, need tuleb kustutada või õigesti seadistada, alles siis töötab nginx.

Soovitan kustutada käsuga sudo apt-get purge nginx või sudo apt purge nginx. Kui kasutate paketihaldur sobivus siis sudo käsk aptitude purge nginx eemaldab kogu paketi koos kõigi sõltuvuste ja konfiguratsioonifailidega.

Vaikimisi on selles kataloogis üks fail, mida nimetatakse vaikimisi. See sisaldab konfiguratsioonifaili koos näitega koos kommentaaridega, saate seda vabal ajal uurida või täielikult kustutada (saate alati ühendust võtta ametlik dokumentatsioon).

Ls-la

Loome oma konfiguratsioonifaili, mis vastab meie kohaliku saidi domeeninimele (või päris domeeninimele, kui te juba teate selle nime). See on mugav, kuna tulevikus, kui konfiguratsioonifaile on palju, säästab see teid nendes segaduse eest. Minu jaoks kannab see fail nime project.local.

Sudo touch project.local
Vaatame, mis juhtus.

Nüüd avame selle redaktoris, ma avan selle nanos.

Sudo nano projekt.kohalik
Näeme, et see on tühi. Liigume nüüd oma faili loomise juurde. Peate viima konfiguratsiooni vormile, nagu allpool kirjutatud. Kirjeldan ainult selle faili olulisi juhiseid, ülejäänuid ma ei kirjelda, kuna see pole hetkel oluline, meil on ju teema põhiseaded. Nendest "slaidi" sätetest piisab, et arendada kohapeal projekte, mitte ainult väikeseid, vaid ka üsna suuri. Järgmistes artiklites kirjeldan eraldi kõiki selle faili kasutatavaid direktiive (nii nimetatakse ridu, näiteks serveri_nimi).

Vaadake kommentaare otse aadressil konfiguratsioonifail.

Server ( kuula 80; # port kuulab nginxi serveri_nimi projekt.local; # Domeeninimi vooluga seotud virtuaalne host root /home/stavanger/code/project.local; # kataloog, kus projekt asub, sisenemispunkti tee indeks index.php; # add_header Access-Control-Allow-Origin *; # serveeri staatilisi faile otse asukoht ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ ( juurdepääs_logi välja; aegub max; logi_not_found off; ) asukoht / ( # add_header Access-Control-Allow- Päritolu *; try_files $uri $uri/ /index.php?$query_string; ) asukoht ~* \.php$ ( try_files $uri = 404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix :/var/run/php/php7.0-fpm.sock; # ühendage php-fpm pesa fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; ) asukoht ~ all\.ht) ( deny )
Salvestage fail. Nüüd peame kontrollima, kas selles on vigu. Me saame seda teha meeskonnana.

Sudo nginx -t
Kui näeme sellist teavet nagu ekraanipildil, siis on kõik õige ja saame seadistamist jätkata. Kui näete tõrkeid, tasub konfiguratsioonifaili veel kord üle kontrollida.

Nüüd peame aktiveerima konfiguratsioonifaili, kataloogis /etc/nginx/sites-enabled/ peame looma sümlingi ( sümboolne link). Kui installisite nginxi nullist, on selles kataloogis vaikefaili sümlink, millest oli eespool juttu; saate selle kustutada, kui te seda ei vaja. Minge soovitud kataloogi.

CD /etc/nginx/sites-enabled/
Nüüd oleme sees soovitud kataloog. Loome oma sümboolika. Loomiseks kasutage käsku ln koos lipuga -s, seejärel näitame oma projekti.local config tee.

Sudo ln -s /etc/nginx/sites-available/project.local
Vaatame meie loodud sümlinki.

Veendumaks, et teeme kõike ikka õigesti, käivitame käsu uuesti.

Fail võõrustajad

See fail asub aadressil /etc/hosts. Kirjete olemasolu selles võimaldab teil käivitada nginxi, kasutades domeenina localhosti. Selles failis saate määrata alternatiivsed varjunimed, näiteks meie projekti project.local jaoks määrame domeeni project.local.

Avage fail nanoredaktoris.

Sudo nano /etc/hosts
Selles failis on muud teavet, lihtsalt ignoreerige seda. Peate lihtsalt lisama rea, nagu minu ekraanipildil.

Paigaldamine php-fpm (>=7.0)

sudo aptitude install php-fpm
Kontrollimine installitud versioon, igaks juhuks, kuigi Ubuntu 16.04.1-s on 7.0 versioon hoidlates.

Php-fpm7.0 -v

Teeme kindlaks, et kõik on korras. Alustame php-fpm.

Sudo teenuse php7.0-fpm algus
Kui muudate konfiguratsioone, ärge unustage deemonit taaskäivitada. See teeb nii. Aga meil pole seda vaja.

Sudo teenuse php7.0-fpm taaskäivitamine
See on paigaldus ja php-fpm seadistus lõpetanud. Tõesti, see on kõik. See pole maagia, php-fpm pesa tee oli juba konfiguratsioonifailis määratud. Muidugi võib teil vaja minna php laiendused isiklike projektide arendamiseks, kuid saate neid vajadusel pakkuda.

Nüüd läheme oma projektiga kataloogi, mul on see sellel teel.

Cd /home/stavanger/code/project.local
Liigume ülaltoodud kataloogi ja teeme load 777 (st me teeme täielikud õigused kataloog meie projektiprojektiga.kohalik). See säästab meid tarbetute probleemide eest tulevikus.

Cd .. sudo chmod -R 777 projekt.kohalik
See lõpetab tarkvara seadistamise, loome oma töökataloogi project.local testfaili ja veendume, et kõik töötab. Loon selle sisuga faili index.php.

Me läheme brauserisse ja näeme, et kõik töötab meie jaoks suurepäraselt! PHP tõlk, sealhulgas.

Lugejate suhtes, Stavanger.

Hetkel on enim populaarsust kogunud kaks veebiserverit. Need on Apache ja Ngnix. Igal neist on oma plussid ja miinused. Apache töötati välja juba 1995. aastal ja selle väljatöötamisel ei võetud arvesse kõiki võimalikke kasutaja vajadusi, see kulutab palju mälu ja süsteemiressursse, kuid seda on lihtne seadistada. Nginx töötati välja veidi hiljem 2002. aastal, võttes arvesse Apache'i vigu ja keskendudes maksimaalsele jõudlusele.

Me ei hakka üksikasjalikult kirjeldama mõlema veebiserveri plusse ja miinuseid. Igal neist on oma rakendusala. See juhend hõlmab Nginx Ubuntu 16.04 installimist. Kuigi ma räägin Ubuntu 16.04-st, töötavad kõik sammud ka teiste distributsioonide puhul. Nginxi seadistamine on igal pool sama, erinev on ainult installikäsk.

Esimene samm on veebiserveri enda installimine süsteemi. Programm on ametlikes hoidlates, kuid selle versioon on juba veidi vananenud, nii et kui soovite uusimat versiooni, peate lisama PPA:

sudo apt-add-hoidla ppa:nginx/stable

Praegu on versioon 1.10.0 saadaval ametlikes hoidlates ja 1.10.1 on juba saadaval stabiilses PPA-s. Kui te versiooni ei vaja, saate ilma PPAta hakkama. Järgmisena värskendage hoidlate pakettide loendeid:

Ja installige ngnix:

sudo apt install nginx

Kui Nginxi serveri installimine on lõpule jõudnud, lisage programm käivitumisse, et see käivituks automaatselt:

sudo systemctl lubab nginx

Kui avate oma brauseri praegu, näete, et nginx töötab, kuid me peame selle ikkagi konfigureerima.

Nginx Ubuntu seadistamine

Nginx Ubuntu seadistamine on palju keerulisem kui Apache. Siin ei käsitle me kõiki programmi võimalusi ja võimalusi, vaid räägime ainult peamistest. On erinevaid konfiguratsioone, milles Nginxi kasutatakse puhverserverina ja põhiserver on Apache, kuid meid see ei huvita. Peame installima Nginxi eraldiseisva veebiserverina.

Nginxi sätted on väga erinevad – virtuaalsetele hostidele on ainult üks põhikonfiguratsioonifail ja failid. Iga kataloogi konfigureerimist, nagu Apache'is, ei toetata.

• /etc/nginx/nginx.conf- peamine konfiguratsioonifail
• /etc/nginx/sites-available/*- virtuaalsete hostide konfiguratsioonifailid, teisisõnu iga saidi jaoks.
• /etc/nginx/sites-enabled/*- aktiveeritud saitide konfiguratsioonifailid.

Tegelikult loetakse virtuaalsete hostide konfiguratsioonifaile ainult saitide lubatud kataloogist, kuid see sisaldab linke saadaolevatele saitidele. See süsteem leiutati selleks, et võimaldada teatud saitide ajutiselt keelata ilma nende konfiguratsiooni kustutamata. Kõik muud failid sisaldavad ainult muutujate deklaratsioone ja standardsätteid, mida ei ole vaja muuta. Mis puutub faili nginx.conf, siis kõik saidi lubade failid on sellesse kaasatud ja seetõttu võivad need sisaldada täpselt samu juhiseid. Vaatame nüüd peamist konfiguratsioonifaili:

sudo vi /etc/nginx/nginx.conf

Nagu näete, on fail jagatud osadeks. Üldine struktuur on järgmine:

globaalsed valikud
sündmused ()
http(
server (
asukoht ()
}
server ()
}
mail()

• globaalsed valikud vastutavad kogu programmi toimimise eest.
• sündmused- see jaotis sisaldab võrguga töötamise sätteid.
• http- sisaldab veebiserveri sätteid. Peaks sisaldama serverijaotist iga saidi peenhäälestamiseks.
• server- see jaotis sisaldab iga veebiserveris hostitava saidi sätteid.
• asukoht- asukoha jaotis võib asuda ainult serveri jaotises ja sisaldab sätteid ainult konkreetse päringu jaoks.
• mail- sisaldab meili puhverserveri sätteid.

Enne valikute juurde asumist peame ütlema veel paar sõna konfiguratsioonifaili reasüntaksi kohta. See näeb välja selline:

parameetri väärtus lisaväärtus...;

Rida peab lõppema tähega ";" ja kõik avatud sulud ( peavad olema suletud.

Nüüd, kui olete globaalset struktuuri veidi uurinud, võite liikuda edasi parameetrite endi vaatamise juurde. Globaalseid valikuid pole palju:

• kasutaja- kasutaja, kelle nimel programm töötab.
• töötaja_protsessid- määrab, mitu protsessi tuleb programmi töö paralleelseks käivitamiseks käivitada; te ei pea käivitama rohkem protsesse, kui teil on tuumasid. Saate määrata parameetri auto ja siis määrab programm selle numbri ise.
• pid= programmi pid-fail.
• worker_rlimit_nofile- näitab maksimaalset failide arvu, mida programm saab avada. Arvutatakse kui worker_processes * worker_connections* 2.

Oleme globaalsete võimalustega lõpetanud; neid ei olnud palju ja need polnud ka nii huvitavad. Optimeerimise osas on palju huvitavamad sündmuste jaotise valikud:

• töötaja_ühendused- ühenduste arv, mida programm saab ühe protsessiga üheaegselt töödelda. Kui me korrutame selle parameetriga worker_process, saame maksimaalse arvu kasutajaid, kes saavad samal ajal serveriga ühenduse luua. Soovitatav on määrata väärtus vahemikus 1024 kuni 4048.
• multi_accept- võimaldab korraga vastu võtta palju ühendusi, seada parameeter sisse või välja.
• kasutada- viis võrgupinuga töötamiseks. Vaikimisi on küsitlus, kuid Linuxis on epolli kasutamine tõhusam.

• saada fail- kasutage sendfile andmete saatmise meetodit. Väärtus on sisse lülitatud.
• tcp_nodelay, tcp_nopush- saatke päised ja faili algus ühes paketis. Väärtus on sisse lülitatud.
• Keepalive_timeout- ooteaeg, enne kui ühendus suletakse, vaikimisi on 65, kuid seda saab vähendada 10 sekundini.
• elushoidmise_taotlused- maksimaalne säilitusühenduste arv ühelt kliendilt, soovitatav 100.
• reset_timedout_connection- katkestada ühendused pärast ajalõpu. Väärtus on sisse lülitatud.
• open_file_cache- vahemälu teave avatud failide kohta. Seadistuste rida näeb välja selline: open_file_cache max=200000 inactive=20s; max - maksimaalne failide arv vahemälus, vahemällu salvestamise aeg.
• open_file_cache_valid- näitab, mis aja pärast tuleb teave vahemälust kustutada. Näiteks: open_file_cache_valid 30s;
• open_file_cache_min_uses- vahemällu teavet failide kohta, mis on avatud vähemalt teatud arv kordi.
• open_file_cache_errors- vahemälu teave puuduvate failide kohta, väärtus sees.

Peamised parameetrid on üle vaadatud. Need sätted aitavad teil saada nginxi paremat jõudlust. Virtuaalsete hostide seadistamisel vaatame serveri ja asukoha jaotisi.

Gzipi tihendamise seadistamine

Sisu tihendamine on vajalik brauseri allalaaditavate andmete mahu vähendamiseks. See kiirendab saidi laadimist, kuid lisab serveriprotsessorile lisakoormust. Pakkimise lubamiseks jaotises http peate lisama järgmise parameetri:

Seda direktiivi saab kasutada ka serveri jaotises, siis töötab see ainult määratud virtuaalse domeeni jaoks. Järgmisena konfigureerime tihendusparameetrid järgmiste valikute abil:

• gzip_min_length- minimaalne lehe pikkus baitides, mille puhul tuleb tihendamist kasutada, näiteks 1000 (1 kb)
• gzip_proxyed- kas puhverserveri päringuid on vaja tihendada, mõni ütleb, et kõik tuleb tihendada.
• gzip_types- tihendamist vajavad failitüübid, näiteks: text/plain application/xml application/x-javascript text/javascript text/css text/json;
• gzip_disable "msie6"- IE 6 ei toeta tihendamist, seega keelame selle.
• gzip_comp_level- tihendusaste, valikud 1 kuni 10. 1 - minimaalne, 10 - maksimaalne tihendus.

Virtuaalsete hostide seadistamine

Nagu teate, võib server majutada mitut veebisaiti. Kõik päringud tulevad serveri IP-le ja nginx määrab juba domeeni põhjal, millist sisu tuleb teenindada. Selleks, et nginx teaks, millisesse domeeni see kuulub, peate konfigureerima virtuaalsed hostid. Iga host paigutatakse tavaliselt eraldi faili. Hosti konfiguratsioon asub serveri jaotises, kuid kuna kõik saidi toega failid imporditakse jaotisesse http, ei ole konfiguratsioonifaili struktuuri loogika katki.

Vaatame seadistuse näidet:

vi /etc/nginx/sites-enabled/site.conf

• kuula 80- määrab, et ühendust tuleb kuulata pordis 80, võib sisaldada ka valikut vaikeserver, mis tähendab, et see domeen avatakse, kui domeen ei olnud päringus määratud.
• juur /var/www/html- kataloog, kus saidi failid asuvad.
• indeks index.html- vaikimisi avanev leht.
• serveri_nimi- saidi domeeninimi.
• juurdepääsu_log- fail serverisse päringute logi salvestamiseks, mida saab kasutada nii globaalselt jaotises http kui ka teatud tüüpi faili jaoks asukohas.
• error_log- veebiserveri tõrkelogi, võib aktsepteerida täiendavat parameetrit, mis näitab logi üksikasju. hoiata - maksimaalne, crit - ainult kriitilised vead.

Need on kõik virtuaalse hosti põhiseaded, pärast mida see juba töötab. Kuid seal on ka asukoha jaotis, mis võimaldab teil konfigureerida serveri käitumist teatud kataloogide ja failide jaoks. Asukoha süntaks on:

asukoha aadress ()

Aadressina saab kasutada nii otsepäringut serveri juure kohta kui ka regulaaravaldisi. Regulaaravaldiste kasutamiseks eelneb sellele märk "~". Vaatame allolevaid näiteid, kuid praegu vaatame võimalikke direktiive:

• lubama- lubage juurdepääs asukohale kasutajatele, kõigile - kõigile, saate määrata ka IP või alamvõrgu.
• eitama- keelata juurdepääs asukohale, kõik - kõigile.
• proovifailid- proovib faile avada kindlas järjekorras, avab esimese leitud faili. Näiteks see konstruktsioon: $uri $uri/index.html $uri.html =404; esmalt proovib see avada $uri, seejärel index.html, kui $uri.html ei leita, ja siis, kui ühtegi eessõnafaili pole olemas, annab see vea 404.
• aegub- määrab antud elemendi brauseri vahemällu salvestamise aja, näiteks 1d - üks päev, 2h - kaks tundi, 30s - 30 sekundit.

Lisaks nendele peamistele direktiividele võib siin kasutada ka teisi. Lisateabe saamiseks vaadake ametlikku dokumentatsiooni. Vaatame paari näidet:

Ära logi faviconi sisse:

asukoht = /favicon.ico (
log_not_found off;
access_log off;
}

Keela juurdepääs punktiga algavatele failidele:

asukoht ~ /\. (
keelata kõik;
}

Tavaliste failide vahemällu 90 päevaks:

asukoht ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2 |doc|xls|exe|ppt|tar|midi|wav|bmp|rtf)$ (
access_log off; log_not_found off; aegub 90p;

Nginxi õige konfigureerimise teema on väga suur ja ma kardan, et see ei mahu ühe Habré artikli raamistikku. Selles tekstis püüdsin rääkida konfiguratsiooni üldisest ülesehitusest, huvitavamaid detaile ja üksikasju võib tulla hiljem. :)

Hea lähtepunkt nginxi seadistamiseks on distributsiooniga kaasas olev konfiguratsioon, kuid paljusid selle serveri võimalusi pole selles isegi mainitud. Palju üksikasjalikum näide on Igor Sysoevi veebisaidil: sysoev.ru/nginx/docs/example.html. Parem proovime siiski oma konfiguratsiooni ehitada nullist, bridži ja poetessidega. :)

Alustame üldiste seadistustega. Esiteks näitame kasutajat, kelle nimel nginx töötab (halb on rootina töötada, kõik teavad :))

Nüüd ütleme nginxile, mitu tööprotsessi tuleb luua. Tavaliselt on teie serveri protsessorituumade arvuga võrdne arv protsesse hea valik, kuid selle sättega tasub katsetada. Kui on oodata kõvaketta suurt koormust, saate iga füüsilise kõvaketta jaoks teha ühe protsessi, kuna kogu tööd piirab ikkagi selle jõudlus.

Töötaja_protsessid 2;

Teeme selgeks, kuhu vealogid kirjutada. Seejärel saab üksikute virtuaalserverite puhul selle parameetri alistada, nii et selles logis kuvatakse ainult “globaalsed” vead, mis on seotud näiteks serveri käivitamisega.

Error_log /spool/logs/nginx/nginx.error_log teade; # Teavitamise taset saab loomulikult muuta

Nüüd tuleb väga huvitavate sündmuste jaotis. Selles saate määrata maksimaalse ühenduste arvu, mida üks töötaja protsess samaaegselt töötleb, ja meetodi, mida kasutatakse OS-i sündmuste kohta asünkroonsete teatiste saamiseks. Loomulikult saate valida ainult need meetodid, mis on teie OS-is saadaval ja kompileerimise ajal kaasatud.

Need seaded võivad teie serveri jõudlust oluliselt mõjutada. Need tuleb valida ükshaaval, sõltuvalt OS-ist ja riistvarast. Võin anda vaid mõned üldised reeglid.

Sündmustega töötamise moodulid:
- valimine ja poll on tavaliselt aeglasemad ja koormavad protsessorit üsna tugevalt, kuid need on saadaval peaaegu kõikjal ja töötavad peaaegu alati;
- kqueue ja epoll - tõhusamad, kuid saadaval ainult FreeBSD ja Linux 2.6 jaoks;
- rtsig on üsna tõhus meetod ja seda toetavad isegi väga vanad Linuxid, kuid see võib põhjustada probleeme suure hulga ühendustega;
- /dev/poll - minu teada töötab see mõnevõrra eksootilisemates süsteemides, nagu Solaris, ja on seal üsna tõhus;

worker_connections parameeter:
- teenindatavate klientide maksimaalne koguarv on võrdne töötaja_protsessidega * töötaja_ühendustega;
- Mõnikord võivad isegi kõige äärmuslikumad väärtused töötada positiivselt, näiteks 128 protsessi, 128 ühendust protsessi kohta või 1 protsess, kuid parameetriga worker_connections=16384. Viimasel juhul peate aga suure tõenäosusega OS-i häälestama.

Sündmused (
töötaja_ühendused 2048;
kasutada kqueue; # Meil ​​on BSD :)
}

Järgmine jaotis on suurim ja sisaldab kõige huvitavamaid asju. See on virtuaalserverite ja nende kõigi jaoks ühiste parameetrite kirjeldus. Jätan välja standardseaded, mis on igas konfiguratsioonis, näiteks logide teed.

HTTP(
# Kogu allolev kood on selles jaotises %)
# ...
}

Selles jaotises võivad olla üsna huvitavad parameetrid.

Sendfile süsteemikutse on Linuxi jaoks suhteliselt uus. See võimaldab teil andmeid võrku saata, ilma et peaksite neid rakenduse aadressiruumi kopeerima. Paljudel juhtudel parandab see oluliselt serveri jõudlust, seega on kõige parem alati lubada suvand sendfile.

Keepalive_timeout parameeter vastutab ühenduse säilitamiseks maksimaalse aja eest, kui kasutaja selle kohta midagi ei taotle. Mõelge, kuidas teie sait päringuid saadab, ja kohandage seda seadet. AJAX-i aktiivselt kasutavate saitide puhul on parem ühendust hoida kauem; staatiliste lehtede puhul, mida kasutajad loevad pikka aega, on parem ühendus varakult katkestada. Pidage meeles, et kui säilitate passiivse ühenduse, loote ühenduse, mida saaks kasutada teisiti. :)

Keepalive_timeout 15;

Eraldi tasub esile tõsta nginxi puhverserveri sätted. Enamasti kasutatakse nginxi täpselt puhverserverina, seega on need üsna olulised. Eelkõige on mõistlik määrata puhverserveri taotluste puhvri suurus vähemalt taustaserveri eeldatava vastuse suurus. Aeglaste (või vastupidi väga kiirete) taustaprogrammide puhul on mõistlik muuta taustaprogrammi vastuse ootamise ajalõppe. Pidage meeles, et mida pikemad need ajalõpud on, seda kauem ootavad teie kasutajad vastust, kui taustaprogramm on aeglane.

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

Väike trikk. Kui nginx teenindab rohkem kui ühte virtuaalset hosti, on mõttekas luua vaikimisi virtuaalne host, mis töötleb päringuid juhtudel, kui server ei leia muud alternatiivi, kasutades kliendipäringu hosti päist.

# vaikimisi virtuaalne host
server(
kuula 80 vaikimisi;
serveri_nimi localhost;
keelata kõik;
}

Sellele võib järgneda üks (või mitu) "serveri" sektsiooni. Igaüks neist kirjeldab virtuaalset hosti (enamasti nimepõhist). Ühe hostimise paljude saitide omanike või hostijate jaoks võib olla midagi direktiivi sarnast

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

Ülejäänud kirjeldavad suure tõenäosusega oma virtuaalset hosti otse põhikonfiguratsioonis.

Server (
kuula 80;

# Pange tähele, et server_name direktiiv võib määrata mitu nime korraga.
serveri_nimi myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log ajastatud;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Määrame väljundi vaikekodeeringu.

Charset utf-8;

Ja oletame, et me ei taha vastu võtta klientide päringuid, mis on pikemad kui 1 megabaid.

Client_max_body_size 1m;

Lubame serveris SSI ja palume reserveerida SSI muutujate jaoks mitte rohkem kui 1 kilobait.

Si on;
ssi_väärtuse_pikkus 1024;

Ja lõpuks kirjeldame kahte asukohta, millest üks viib taustaprogrammi, Apache'i, mis töötab pordis 9999, ja teine ​​saadab staatilisi pilte kohalikust failisüsteemist. Kahe asukoha puhul on sellel vähe mõtet, kuid suurema hulga jaoks on mõttekas ka kohe defineerida muutuja, kuhu serveri juurkataloogi salvestatakse, ja seejärel kasutada seda asukohakirjeldustes.

Täna vaatleme virtuaalse hosti seadistamist, mis teenindab staatilise sisuga veebisaiti. See tähendab, et ei mingit CGI-d, Perli, PHP-d ega muud. Kõik artiklis mainitud näited viitavad ja on testitud Debian Linux 5.0 Lenny. Teiste süsteemide omanikke ei tohiks see mingil juhul segadusse ajada, kuna muutuda võivad ainult konfiguratsioonifailide teed, samas kui nende sisu on rakendatav kõigis süsteemides, milles Nginx töötab.

Konfiguratsioonifailide salvestamise meetod

Nagu võib-olla eelmisest artiklist mäletate, saate seda direktiivi kasutada Nginxi konfiguratsioonifailides sisaldama, mis võib sisaldada põhikonfiguratsioonifaili muude failide sisu. See lähenemisviis pakub administraatoritele täiendavat serverikonfiguratsiooni paindlikkust, mis säästab sageli aega ja vaeva.

Kui märkasite, siis põhikonfiguratsioonifailis /etc/nginx/nginx.conf pole sõnagi virtuaalserverite konfiguratsioonist. Üldse pole öeldud, kus asub serveri dokumendi juur, millisel pordil peaks server sissetulevaid ühendusi kuulama jne. Konfiguratsioonifaili eelviimane rida on aga järgmine:

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

Ehk siis kataloogist /etc/nginx/sites-enabled kõigi failide sisu loetakse ja rakendatakse praegusele serverikonfiguratsioonile. Vaadates mainitud kataloogi, näete seal ühte faili vaikimisi, mis on sümboolne link failile /etc/nginx/sites-available/default. See on ka väga mugav lähenemine: peate ootamatult mõne virtuaalse hosti keelama, lihtsalt kustutate sümboolse lingi ega viitsi faili edasi-tagasi liigutada.

Virtuaalse serveri loomine

"Katse puhtuse" huvides soovitan eemaldada distributsiooniga kaasas oleva sümboolse lingi /etc/nginx/sites-enabled/default ja alustada niiöelda puhtalt lehelt.

Looge fail /etc/nginx/sites-available/myvhost järgmise sisuga:

Server ( kuula 80; serveri_nimi myvhost; access_log /var/log/nginx/myvhost.log; asukoht / ( juur /var/www/myvhost/; index index.htm index.html; autoindex sees; ) )

See on Nginxi virtuaalserveri lihtsaim konfiguratsioon. Nüüd järjekorras kasutatavatest parameetritest.

Esimene variant server millele järgneb lokkis traks, alustab uut lõiku. See on sektsioonides server ja kirjeldab kõigi Nginxi virtuaalsete serverite konfiguratsioone.

Võimalus kuulakeütleme Nginxile pordi numbri, mille kaudu meie virtuaalserver peaks ühendusi kuulama. Selle valiku vaikeväärtus on 80 , ja antud näites on väärtus defineeritud ainult selguse huvides. Samuti saate selle valiku abil määrata mitte ainult pordi numbri, vaid ka võrguliidese aadressi, millele soovite selle serveri "ühendada". Näiteks järgmised kaks näidet riputavad serveri kõigis süsteemis saadaolevates TCP/IP-liidestes pordis 8080:

Kuulake 8080 kuulake *:8080

Järgmine näide seob virtuaalserveri konkreetse võrguliidesega IP-aadressiga 192.168.0.1, kuulates sissetulevaid ühendusi pordis 8080:

Kuulake 192.168.0.1:8080

Võimalus serveri_nimi määrab virtuaalserveri nime, mida kasutatakse siis, kui veebiserver analüüsib HTTP päist Host, pärit kliendilt. Just see valik rakendab nimepõhiste virtuaalsete hostide konfiguratsiooni. Näiteks selline näeb välja ühe serveri kahe virtuaalse hosti konfiguratsiooni fragment:

Server ( ... kuula 80; serveri_nimi näide-1.com ... ) server ( ... kuula 80; serveri_nimi näide-2.com ... )

Valikul serveri_nimi võib olla rohkem kui üks parameeter, nii et saate määrata oma serverile varjunimed, näiteks:

Serveri_nimi näide-1.com www.example-1.com www1.example-1.com

Võite kasutada ka tärni, et asendada mis tahes tähemärkide jada serveri nimes:

Serveri_nimi näide-1.com *.näide-1.com

Koos parameetriga juurdepääsu_log aastal kohtusime. Selle parameetri väärtus määrab serveri sisule juurdepääsu logifaili asukoha ja vormingu.

Võimalus asukoht väärib käsitlemist eraldi märkuses, seega käsitleme selles artiklis selle tähendust ja võimalusi vaid veidi, niivõrd, kuivõrd see on piisav staatilise veebiserveri konfigureerimiseks. Asukohasuvandi kasutamine võimaldab kohandada serveri käitumist sõltuvalt kliendilt saadud URI väärtusest. Nii et sektsioon server võib sisaldada mitut pesastatud asukoha jaotist, mis kirjeldavad konfiguratsiooni osal URI-st. Artikli alguses toodud näites on määratletud ainult üks asukoht, mis vastab igale kliendilt saadud URI-le, kuna iga URI sisaldab kaldkriipsu.

Näiteks kui peate tagama, et kui URI-st leitakse alamstring /images/, Nginx ei pääsenud ligi serveri juurkataloogile, vaid otsis kataloogist faile /mnt/server2/var/www/images/, saate määrata järgmised kaks asukohta:

Asukoht / (juur /var/www/myvhost/; ) asukoht /images/ (juur /mnt/server2/var/www/; )

Ülaltoodud asukohanäited kasutavad URI stringi alamstringi otsingut. See tähendab, alamstring /images/ leitakse nagu http://server/images/, ja http://server/my/images/. Kui vajate otsimiseks Nginxit täpne kirjavahetus, selleks võite kasutada sümbolit "=" , mis sunnib serverit otsima järgmiselt:

Asukoht = /images/ (juur /mnt/server2/var/www/; )

Samuti saate määrata alamstringi, millega peaksite Alusta URI. Sel eesmärgil kasutatakse kahe sümboli konstruktsiooni "^~" :

Asukoht ^~ /images/ ( ... )

Noh, regulaaravaldisi muidugi toetatakse ja need pakuvad asukoha kirjeldamisel suuremat paindlikkust. Järgmine asukoht ühtib kõigi URI-dega, mis sisaldavad lõpus graafilisi failinimesid (suur- ja suurtähtede tundlik):

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

Sama asi, kuid tõstutundlik:

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

Ja natuke Nginxi asukohavalikute töötlemise järjekorrast. Vastupidiselt sellele, mida paljud esmapilgul arvata võivad, ei ole üldse oluline (muidugi välja arvatud regulaaravaldised), mis järjekorras asukohad konfiguratsioonifailis määratletakse. Ükskõik, kuidas te neid vahetate, on tulemus sama. Vajaliku asukoha otsimisel järgib Nginx järgmist algoritmi:

1. Otsib reeglit, mis algab tähega "=" . Niipea kui selline reegel leitakse, peatatakse edasine otsing.
2. Otsitakse "tavalisi" reegleid, st mitteregulaarseid avaldisi. Kui nende hulgast leitakse reegel, mis algab tähega "^~" , edasine otsing peatatakse.
3. Regulaaravaldisi töödeldakse selles järjekorras, milles need konfiguratsioonifailis ilmuvad.
4. Kui leitakse sobivus punkti 3 järgi, siis kasutatakse seda asukohta, vastasel juhul kasutatakse punktis 2 leitud asukohta.

Võimalus juur selle väärtus määrab failisüsteemi virtuaalserveri dokumentide juure tee.

Kasutades valikut indeks saate määrata indeksi dokumendifailide nimed, mille Nginx klientidele "annab", kui taotletakse juurdepääsu kataloogile. Kui kataloogis sellist faili pole ja valik on selle asukoha jaoks keelatud autoindeks, siis saab klient vastuseks HTTP-koodi 403 , mis näitab, et juurdepääs on keelatud.

Võimalus autoindeks konfigureerib Nginxi käitumise, kui soovitud registrifaili kataloogist ei leita. Kui automaatse indekseerimise suvandi väärtus, nagu ülaltoodud näites, on "peal", siis tagastab server kataloogi sisu kliendile failide HTML-loendi kujul. Vaikimisi on automaatne indeks keelatud, nii et olge sellega ettevaatlik, et mitte postitada kogemata olulist teavet kõigile.

Serveri taaskäivitamine

Nüüd, kui konfiguratsioonifail on valmis, tuleb sellele kataloogist sümboolne link teha /etc/nginx/sites-enabled/ nii et kui Nginx taaskäivitatakse, lisab see selle sisu oma konfiguratsiooni:

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

# mkdir /var/www/myvhost

Jääb üle vaid server taaskäivitada:

# /etc/init.d/nginx taaskäivitage

Ja kui kõik seaded tehti vigadeta, saate veebibrauseri abil ühenduse luua oma esimese Nginxi virtuaalserveriga ja näha serveri juurkataloogis tühja failide registrit. Proovige paigutada kataloogi paar staatilist html-faili /var/www/myshost ja seejärel pääsete neile oma brauserist juurde.

Järgmises artiklis vaatleme SSL-serveri konfiguratsiooni Nginxis.

Nginx? Eesmärk, funktsioonid, seadete valikud – need on asjad, mida iga veebiarendaja peaks oma töö testimiseks teadma.

Räägime mõne sõna nginxi kohta

Sellel tööriistal on üks põhi- ja mitu tööprotsessi. Esimene käsitleb konfiguratsiooni lugemist ja kontrollimist. Tema kontrolli all on ka tööprotsesside juhtimine. Viimase ülesandeks on sissetulevate päringute töötlemine. Nginx kasutab sündmustepõhist mudelit. Operatsioonisüsteemispetsiifilisi mehhanisme kasutatakse ka taotluste tõhusaks jaotamiseks otse töötajate protsesside vahel. Nende number on alati märgitud konfiguratsioonifailis. Väärtuse saab määrata kas fikseeritud või automaatselt, sõltuvalt protsessori tuumade arvust, millega saate töötada. Nginxis konfigureeritakse süsteem ja moodulid konfiguratsioonifaili abil. Seega, kui teil on vaja midagi muuta, siis peate seda otsima. Tavaliselt asub see direktiivis /etc/nginx (kuid tee võib teiste süsteemide kasutamisel muutuda) ja sellel on .conf laiend.

Käivitamine, taaskäivitamine ja logid

Selleks peate käivitatava faili tööle panema. Nginxi serveri konfigureerimine on võimalik ainult siis, kui see töötab. Juhtimine toimub käivitatava faili kutsumisega parameetriga -s. Selleks kasutage järgmist tähistust:

nginx -s signaal

Sel juhul saate asendada järgmised käsud (peavad tulema tööriista käivitanud kasutajalt):

1. Peatus. Kasutatakse töö kiireks sulgemiseks.
2. Laadi uuesti. Käsk on vajalik konfiguratsioonifaili uuesti laadimiseks. Asi on selles, et faili töötamise ajal muudatusi ei rakendata. Ja nende jõustumiseks on vajalik taaskäivitamine. Niipea kui see signaal on vastu võetud, hakkab põhiprotsess kontrollima konfiguratsioonifaili süntaksi õigsust ja proovib seal olevaid juhiseid rakendada. Kui see ebaõnnestub, tühistab see muudatused ja töötab vanade sätetega. Kui kõik õnnestus, käivitatakse uued tööprotsessid ja vanadele saadetakse lõpetamise taotlus.
3. Lõpeta. Kasutatakse tööde sujuvaks sooritamiseks. Kasutatakse, kui peate ootama, kuni praegused taotlused on teenindamise lõpetanud.
4. Ava uuesti. Sulgege ja avage logifailid.

Utiliidide kasutamine

Protsesse saab konfigureerida ka Unixi tööriistade abil (näitena käsitletakse tapmisutiliiti). Tavaliselt kasutavad nad mehhanismi signaali saatmiseks protsessile otse andmetega. Need on seotud ID-ga. Need andmed salvestatakse faili nginx.pid. Ütleme nii, et meid huvitab protsess nr 134. Seejärel peame sujuvaks täitmiseks saatma järgmise teabe:

tapa -s LÕPETA 1628

Oletame, et tahame vaadata kõigi töötavate failide loendit. Kasutame selleks utiliiti ps. Käsk näeb välja selline:

ps -ax | grep nginx

See tähendab, et nagu näete, näidatakse lisatööriistade kasutamisel, et seda kasutatakse. Nüüd keskendume sellele, kuidas nginxi konfigureerimine toimub.

Konfiguratsioonifaili struktuur

Paigaldamine ja nginxi seadistus näeb ette moodulitega töötamise. Need konfigureeritakse konfiguratsioonifailis määratud direktiivide abil. Need on lihtsad ja blokeerivad. Esimest tüüpi direktiiv koosneb nimest ja parameetritest, mis on eraldatud tühikutega ja lõpetatakse semikooloniga (;). Plokil on sarnane struktuur. Kuid see käskkiri sisaldab lõpu asemel täiendavaid juhiseid, mis asetatakse lokkis traksidega ((juhised)). Kui need võivad sisaldada teiste protsesside nimesid ja parameetreid, siis selliseid konstruktsioone nimetatakse kontekstiks. Näiteks http, asukoht ja server.

Staatilise sisu serveerimine

See on üks olulisemaid nginxi konfiguratsiooni ees seisvaid ülesandeid. Statistilise sisu levitamise all peame silmas pilte ja HTML-lehti (mitte dünaamilisi). Oletame, et vajame ühekordset tööd nix nginxi klastri seadistamiseks. Kas seda on raske teha? Ei, ja vaatame näidet. Enne selle alustamist on vaja üksikasjalikult kirjeldada ülesande tingimusi. Seega pärinevad failid olenevalt taotlustest erinevatest kohalikest kataloogidest. Nii et /data/www on meil HTML-dokumendid. Ja /data/images kataloog sisaldab pilte. Nginxi optimaalne konfigureerimine nõuab sel juhul konfiguratsioonifaili redigeerimist, milles peate konfigureerima serveriploki http-s. Toetamiseks kasutatakse ka kahte asukohta.

Teostus: server

Niisiis, kõigepealt peame looma kataloogid ise ja paigutama neisse vajalike laiendustega failid (sa pead html-ile sisu lisama). Seejärel avage konfiguratsioonifail. Vaikimisi sisaldab see juba mitmeid serveriplokke, mida enamasti kommenteeritakse. Optimaalsete tulemuste saavutamiseks tuleb see protsess läbi viia kõigi vaikekomponentide puhul. Seejärel lisame järgmise koodi abil uue serveriploki:

Konfiguratsioonifail võib töötada mitme sellise plokiga. Kuid need peavad erinema oma nimede ja portide poolest, mille kaudu andmeid vastu võetakse.

Rakendamine: asukoht

Määratud serveris:

Märgi “/” olemasolu on vajalik, et võrrelda saadud andmeid ja näha, kas selline aadress töödeldud päringust on siin. Kui probleeme pole, siis määrake vajaliku faili tee /data/www, mis asub selles kohalikus süsteemis. Kui on vaste mitme plokiga, siis valitakse see, millel on pikim prefiks. Antud näites on selle pikkus võrdne ühega, see tähendab, et seda kasutatakse ainult siis, kui "konkurente" pole. Nüüd parandame seda:

asukoht /pildid/ (

Kuidas saate aru, kas me otsime pilte? Nüüd ühendame kõik varem tehtud arendused ja praegune konfiguratsioon näeb välja selline:

asukoht /pildid/ (

See on töötav valik, mis on standardne. Sellele serverile pääseb kohalikus arvutis probleemideta ligi, kui lähete aadressile: http://localhost/. Kuidas see kõik toimima hakkab?

Kuidas näide töötab

Seega, kui saabuvad päringud, mis algavad tähega /images, saadab server kasutajale failid vastavast kataloogist. Kui see puudub, edastatakse info, mis viitab veale 404. Kui nginx on konfigureeritud kohalikus arvutis, siis http://localhost/images/example.png pärimisel saame faili, mille asukoht on /data/images/ näide.png. Kui määrate ühe märgi "/", tehakse otsing kataloogis /data/www. Kuid muutsime ainult konfiguratsiooni. Et see tööle hakkaks, tuleb see taaskäivitada. Selleks kasutage käsku nginx -s reload. Kui tavapärane töö pole võimalik, saate tõrke põhjust otsida failist error.log ja access.log, mis asuvad /usr/local/nginx/logs direktiivis.

Lihtsa puhverserveri loomine

Nginxi kohta võib öelda - selle objekti seadistamine on üks levinumaid kasutusviise (ja muide, üsna lihtne). See kasutab serveri põhimõtet, mis võtab päringud vastu ja suunab need seejärel vajalikele saitidele. Pärast seda oodatakse neilt vastust, mis suunab nad ülesande andja juurde. Vaatame siis baaspunkti loomise näidet. See käsitleb kasutajate taotlusi ja pakub neile pilte kohalikust kataloogist. Seega lisame http-plokile teise serveri, millel on järgmine sisu:

Nüüd lubage mul see teie jaoks lahti mõtestada: luuakse lihtne server. See kuulab. Kui te ei määra kuulamist, töötab server 80-l. Kuvatakse kõik kohaliku failisüsteemi päringud, mis on suunatud kataloogi /data/up1 (muidugi tuleb see enne seda luua). Selle kontrollimiseks peate sinna paigutama faili index.html. Asetades juurdirektiivi serveri konteksti, saame asukohta kasutada mis tahes tingimustel (kuna see eemaldab juurdepääsupiirangud). Nüüd tegeleme puhverserveri loomisega. Selle toimimiseks vajame käskkirja proxy_pass, mille parameetritena määratakse protokoll, nimi ja objektiport (kohaliku ühenduse korral näeb see välja kujul http://localhost:8080). Saate järgmise tulemuse:

proxy_pass http://localhost:8080;

asukoht /pildid/ (

Kui vaatate koodi ja analüüsite seda, võite märgata, et teist asukohaplokki on muudetud. Seega võib see sel juhul töötada tüüpiliste pildilaienditega. Seda saab kuvada veidi erinevalt, näiteks järgmiselt:

asukoht ~ \.(gif|jpg|png)$ (

juur /andmed/pildid;

Puhverserveri lõplik konfiguratsioon näeb välja selline:

proxy_pass http://localhost:8080/;

asukoht ~ \.(gif|jpg|png)$ (

juur /andmed/pildid;

See filtreerib välja taotlused, mille lõpus on määratud laiendid, ja saadab need failid küsinud isikule. Ärge unustage, et kui soovite konfiguratsioonifaili kontrollida, peate selle uuesti laadima. Ja uskuge mind, see on kõige lihtsam nginxi seadistus. Kui avate VKontakte või mõne muu suurettevõtte serveri konfiguratsioonifaili, on neil selles artiklis rohkem koodi kui sõnu.