Tema e konfigurimit të saktë të nginx është shumë e gjatë dhe, kam frikë, nuk futet në kuadrin e një artikulli në Habré. Në këtë tekst, u përpoqa t'ju tregoj për strukturën e përgjithshme të konfigurimit, gjëra të vogla dhe detaje më interesante, ndoshta, do të jenë më vonë. :)
Një pikënisje e mirë për konfigurimin e nginx është konfigurimi që vjen me kompletin e shpërndarjes, por shumë nga veçoritë e këtij serveri as që përmenden në të. Një shembull shumë më i detajuar është në faqen e internetit të Igor Sysoev: sysoev.ru/nginx/docs/example.html. Megjithatë, le të përpiqemi më mirë të ndërtojmë konfigurimin tonë nga e para, me urë dhe poetesha. :)
Le të fillojmë me cilësimet e përgjithshme. Së pari, ne do të tregojmë përdoruesin në emër të të cilit do të funksionojë nginx (do të funksionojë keq nga rrënjët, të gjithë e dinë :))
Tani le t'i tregojmë nginx-it se sa procese punëtore duhet të krijohen. Zakonisht, një numër procesesh i barabartë me numrin e bërthamave të procesorit në serverin tuaj është një zgjedhje e mirë, por ka kuptim të eksperimentoni me këtë cilësim. Nëse pritet një ngarkesë e lartë në hard disk, mund të bëni një proces për çdo hard disk fizik, pasi e gjithë puna do të jetë ende e kufizuar nga performanca e tij.
Punëtori_proceset 2;
Le të sqarojmë se ku të shkruajmë regjistrat e gabimeve. Më pas, për serverët virtualë individualë, ky parametër mund të anashkalohet, në mënyrë që vetëm gabimet "globale" të shtohen në këtë regjistër, për shembull, ato që lidhen me fillimin e serverit.
Error_log /spool/logs/nginx/nginx.error_log njoftim; # Niveli i "njoftimit" sigurisht që mund të ndryshohet
Tani vjen rubrika shumë interesante "ngjarjet". Në të, mund të vendosni numrin maksimal të lidhjeve që do të përpunojë njëkohësisht një punonjës dhe metodën që do të përdoret për të marrë njoftime asinkrone për ngjarjet në OS. Sigurisht, ju mund të zgjidhni vetëm ato metoda që janë të disponueshme në OS tuaj dhe janë përfshirë në përpilim.
Këto parametra mund të kenë një ndikim të rëndësishëm në performancën e serverit tuaj. Ato duhet të zgjidhen individualisht, në varësi të sistemit operativ dhe harduerit. Mund t'ju jap vetëm disa rregulla të përgjithshme.
Modulet për të punuar me ngjarje:
- zgjidhni dhe sondazh zakonisht janë më të ngadalta dhe ngarkojnë shumë procesorin, por ato janë të disponueshme pothuajse kudo dhe funksionojnë pothuajse gjithmonë;
- kqueue dhe epoll - më efikase, por të disponueshme vetëm në FreeBSD dhe Linux 2.6, respektivisht;
- rtsig është një metodë mjaft efikase dhe mbështetet edhe nga Linux shumë të vjetër, por mund të shkaktojë probleme me një numër të madh lidhjesh;
- / dev / sondazh - me sa di unë, funksionon në sisteme disi më ekzotike, si Solaris, dhe është mjaft efikas në të;
Parametri Worker_connections:
- Numri total maksimal i klientëve të shërbyer do të jetë i barabartë me proceset_punëtor * lidhjet_punëtor;
- Ndonjëherë edhe vlerat më ekstreme mund të funksionojnë në një drejtim pozitiv, si 128 procese, 128 lidhje për proces, ose 1 proces, por me parametrin worker_connections = 16384. Në rastin e fundit, megjithatë, ka shumë të ngjarë që do t'ju duhet të akordoni OS.
Ngjarjet (
punëtor_lidhjet 2048;
përdorni kqueue; # Ne kemi BSD :)
}
Seksioni tjetër është më i madhi dhe përmban më interesantët. Ky është një përshkrim i serverëve virtualë dhe disa parametrave të përbashkët për të gjithë ata. Unë do të heq cilësimet standarde që janë në çdo konfigurim, të tilla si shtigjet drejt regjistrave.
Http (
# I gjithë kodi më poshtë do të jetë brenda këtij seksioni%)
# ...
}
Mund të ketë disa parametra mjaft interesantë brenda këtij seksioni.
Thirrja e sistemit sendfile është relativisht e re për Linux. Ju lejon të dërgoni të dhëna në rrjet, duke anashkaluar fazën e kopjimit të tyre në hapësirën e adresave të aplikacionit. Në shumë raste, kjo do të përmirësojë ndjeshëm performancën e serverit, kështu që është mirë që gjithmonë të përfshihet parametri sendfile.
Parametri keepalive_timeout është përgjegjës për kohën maksimale për të mbajtur një lidhje keepalive nëse përdoruesi nuk kërkon asgjë për të. Konsideroni saktësisht se si dërgohen kërkesat në faqen tuaj dhe rregulloni këtë parametër. Për faqet që përdorin në mënyrë aktive AJAX, është më mirë të mbani lidhjen më gjatë, për faqet statike që përdoruesit do t'i lexojnë për një kohë të gjatë, është më mirë të shkëputni lidhjen herët. Vini re se duke mbajtur një lidhje joaktive mbajtëse, ju jeni duke zënë një lidhje që mund të ishte përdorur ndryshe. :)
Keepalive_timeout 15;
Më vete, ia vlen të theksohen cilësimet e proxying nginx. Më shpesh, nginx përdoret pikërisht si një server proxy, kështu që ato janë mjaft të rëndësishme. Në veçanti, ka kuptim të vendosni madhësinë e tamponit për kërkesat e proksiuara jo më pak se madhësia e pritshme e përgjigjes nga serveri mbështetës. Me backend të ngadalta (ose, anasjelltas, shumë të shpejta), ka kuptim të ndryshohen afatet e pritjes për një përgjigje nga backend. Mos harroni, sa më gjatë të jenë këto afate, aq më gjatë do të presin përdoruesit tuaj për një përgjigje kur prapavija të ngadalësohet.
Proxy_buffers 8 64k;
proxy_intercept_errors on;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;
Një truk i vogël. Nëse nginx shërben më shumë se një host virtual, ka kuptim të krijohet një "host virtual i paracaktuar" që do të përpunojë kërkesat në rastet kur serveri nuk mund të gjejë një alternativë tjetër nga kreu i Host në kërkesën e klientit.
# host virtual i paracaktuar
server (
dëgjo 80 parazgjedhje;
server_emri lokal host;
mohoj të gjitha;
}
Kjo mund të pasohet nga një (ose disa) seksione "server". Secili prej tyre përshkruan një host virtual (më shpesh, i bazuar në emër). Për pronarët e shumë sajteve në të njëjtin host, ose për hostet, mund të ketë diçka këtu, si p.sh. një direktivë
Përfshi /spool/users/nginx/*.conf;
Pjesa tjetër ka shumë të ngjarë të përshkruajë hostin e tyre virtual direkt në konfigurimin kryesor.
Serveri (
dëgjo 80;
# Vini re se mund të specifikoni shumë emra në të njëjtën kohë në direktivën e emrit të serverit.
emri i serverit myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log me kohë;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...
Le të vendosim kodimin e paracaktuar për shërbimin.
Charset utf-8;
Dhe le të themi se nuk duam të pranojmë kërkesa nga klientët që janë më shumë se 1 megabajt.
Klient_maks_madhësia_trupi 1m;
Le të aktivizojmë SSI për serverin dhe të kërkojmë të rezervojmë jo më shumë se 1 kilobajt për variablat SSI.
Ssi on;
ssi_value_length 1024;
Dhe së fundi, ne do të përshkruajmë dy vendndodhje, njëra prej të cilave do të çojë në backend, në Apache që funksionon në portin 9999, dhe e dyta do të shërbejë imazhe statike nga sistemi lokal i skedarëve. Për dy vendndodhje, kjo ka pak kuptim, por për një numër të madh të tyre, gjithashtu ka kuptim që menjëherë të përcaktohet një variabël në të cilin do të ruhet direktoria rrënjësore e serverit dhe më pas ta përdorni atë në përshkrimet e vendndodhjeve.
Një server i dedikuar në internet i bazuar në nginx është një mënyrë e shkëlqyer për të përmirësuar performancën e faqeve tuaja të internetit. Në shpejtësinë e përpunimit të përmbajtjes statike, ajo thjesht nuk ka të barabartë: përballon lehtësisht disa mijëra lidhje të njëkohshme dhe mund të optimizohet dhe rregullohet lehtësisht për çdo konfigurim. Por? Si një front-end për Apache, nginx rezulton të jetë pika më e cenueshme e të gjithë infrastrukturës së Uebit, prandaj, vëmendje e veçantë duhet t'i kushtohet sigurisë së nginx.
Ky artikull është një lloj programi arsimor, ose, nëse dëshironi, një përmbledhje e të gjitha teknikave për rritjen e sigurisë së nginx. Nuk do të ketë asnjë teori, asnjë përshkrim të bazave të konfigurimit të një serveri në internet, apo ndonjë gjë tjetër. Në vend të kësaj, do të merrni një material gjithëpërfshirës, praktik që përshkruan të gjithë hapat bazë që duhet të ndërmerrni për të marrë një server të vërtetë të sigurt në internet.
Instalimi
Paketa nginx është e disponueshme e parapërpiluar për çdo shpërndarje. Megjithatë, duke e ndërtuar vetë serverin, mund ta bëni atë më kompakt dhe më të besueshëm, dhe gjithashtu mund të ndryshoni linjën e përshëndetjes së serverit të Uebit për të dekurajuar kiddies jo inteligjente të skriptit.
Ndryshoni linjën e mirëseardhjes së serverit në internet
Shkarkoni burimet nginx, hapni skedarin src / http / ngx_http_header_filter_module.c dhe gjeni dy rreshtat e mëposhtëm:
static char ngx_http_server_string = "Serveri: nginx" CRLF;
static char ngx_http_server_full_string = "Serveri:" NGINX_VER CRLF;
Zëvendësojini ato me diçka si kjo:
static char ngx_http_server_string = "Server:] [Web Server" CRLF;
static char ngx_http_server_full_string = "Server:] [Web Server" CRLF;
Hiqni të gjitha modulet nginx që nuk po përdorni
Disa module nginx lidhen me serverin e uebit pikërisht në kohën e përpilimit, dhe secili prej tyre është potencialisht i rrezikshëm. Ndoshta, në të ardhmen, një dobësi do të gjendet në njërën prej tyre dhe serveri juaj do të jetë në rrezik. Duke çaktivizuar modulet e panevojshme, mund të reduktoni ndjeshëm rrezikun e një situate të tillë.
Ndërtoni me komandat e mëposhtme:
# ./konfiguro --without-http_autoindex_module --without-http_ssi_module
#bëj
# bëj instalim
Kjo do t'ju japë nginx me modulet SSI (Server Side Includes) dhe Autoindex të çaktivizuar (dhe në shumicën e rasteve të padobishme). Për të zbuluar se cilat module mund të hidhen në mënyrë të sigurtë nga serveri i uebit, ekzekutoni skriptin e konfigurimit me flamurin "-help".
Zbërthimi i nginx.konf
Pas instalimit, nginx duhet të konfigurohet. Në faqet e revistës kishte tashmë material që përshkruan këtë proces, por ne do t'i përmbahemi temës së artikullit dhe do të flasim për mënyrat për të përmirësuar sigurinë e serverit.
Çaktivizo shfaqjen e versionit të serverit në të gjitha faqet e gabimeve
Shtoni rreshtin "server_tokens off" në skedarin nginx.conf. Kjo do të bëjë që nginx të fshehë llojin dhe versionin e serverit në internet në faqet e krijuara në përgjigje të një kërkese të gabuar të klientit.
Vendosni mbrojtjen kundër thyerjeve të pirgut
Shtoni linjat e mëposhtme në seksionin e serverit:
# vi /etc/nginx/nginx.conf
# Madhësia maksimale e tamponit për ruajtjen e trupit të kërkesës së klientit
klient_trup_buffer_madhësia 1K;
# Madhësia maksimale e tamponit për ruajtjen e titujve të kërkesave të klientit
klienti_header_buffer_size 1k;
# Madhësia maksimale e trupit të kërkesës së klientit, siç specifikohet në fushën Content-Length të kokës. Nëse serveri duhet të mbështesë ngarkimet e skedarëve, kjo vlerë duhet të rritet
klient_max_madhësia_trupit 1k;
# Numri dhe madhësia e buferave për leximin e kokës së madhe të kërkesës së klientit
big_client_header_buffers 2 1k;
Kushtojini vëmendje direktivës large_client_header_buffers. Si parazgjedhje, nginx cakton katër bufera për të ruajtur vargun URI, secila prej të cilave është e barabartë me madhësinë e një faqe memorie (për x86, kjo është 4 KB). Buferët lëshohen sa herë që lidhja hyn në gjendjen e mbajtjes së gjallë pas përpunimit të kërkesës. Dy buferë 1 KB mund të ruajnë vetëm URI 2 KB, gjë që ju lejon të luftoni bots dhe sulmet DoS.
Shtoni linjat e mëposhtme për të përmirësuar performancën:
# vi /etc/nginx/nginx.conf
# Kohëzgjatja gjatë leximit të trupit të kërkesës së klientit
klienti_body_timeout 10;
# Kohëzgjatja gjatë leximit të kokës së kërkesës së klientit
klienti_header_timeout 10;
# Kohëzgjatja pas së cilës lidhja e mbajtur gjallë me klientin nuk do të mbyllet nga serveri
keepalive_timeout 5 5;
# Kohëzgjatja kur dërgoni një përgjigje te klienti
koha e dërgimit 10;
Kontrolloni numrin e lidhjeve të njëkohshme
Për të mbrojtur serverin e uebit nga mbingarkesa dhe përpjekjet DoS, shtoni linjat e mëposhtme në konfigurim:
# vi /etc/nginx/nginx.conf
# Përshkruani zonën (kufizuese) ku do të ruhen gjendjet e sesionit. Një zonë 1 MB mund të ruajë rreth 32000 gjendje, ne e vendosëm atë në 5 MB
kufijtë e zonës së kufirit $ binary_remote_addr 5m;
# Vendosni numrin maksimal të lidhjeve të njëkohshme për një seancë. Në fakt, ky numër përcakton numrin maksimal të lidhjeve nga një IP
limit_conn limitet 5;
Direktiva e parë duhet të jetë në seksionin HTTP, e dyta në seksionin e vendndodhjes. Kur numri i lidhjeve tejkalon kufijtë, klienti do të marrë një mesazh "Shërbimi nuk është i disponueshëm" me një kod 503.
Lejo lidhjet vetëm me domenin tuaj
Hakerët mund të përdorin bot për të skanuar nënrrjetat dhe për të gjetur serverë të cenueshëm në internet. Në mënyrë tipike, robotët thjesht kalojnë nëpër intervalet e IP-së duke kërkuar për 80 porte të hapura dhe dërgojnë një kërkesë HEAD për të marrë informacion në lidhje me serverin në internet (ose faqen kryesore). Mund ta parandaloni lehtësisht një skanim të tillë duke mos lejuar hyrjen në server me adresë IP (shtoni në nënseksionin e vendndodhjes):
# vi /etc/nginx/nginx.conf
nëse ($ host! ~ ^ (host.com | www.host.com) $) (
kthimi 444;
}
Kufizoni numrin e metodave të disponueshme për të hyrë në serverin e uebit
Disa robotë përdorin metoda të ndryshme për të kontaktuar serverin në përpjekje për të përcaktuar llojin dhe/ose depërtimin e tij, por RFC 2616 e bën të qartë se serveri në internet nuk duhet t'i zbatojë të gjitha ato dhe metodat e pambështetura thjesht mund të mos përpunohen. Sot, vetëm metodat GET (kërkesa për dokument), HEAD (kërkesa për kokën e serverit) dhe POST (kërkesë për publikim dokumenti) mbeten në përdorim, kështu që të gjitha të tjerat mund të çaktivizohen pa dhimbje duke vendosur rreshtat e mëposhtëm në seksionin e serverit të skedarit të konfigurimit:
# vi /etc/nginx/nginx.conf
nëse ($ kërkesa_metoda! ~ ^ (MERRNI | KREU | POST) $) (
kthimi 444;
}
Chuck bots
Një mënyrë tjetër për të bllokuar robotët, skanerët dhe shpirtrat e tjerë të këqij bazohet në përcaktimin e llojit të klientit (agjent-përdorues). Nuk është shumë efektiv, sepse shumica e robotëve imitojnë shfletues plotësisht të ligjshëm, por në disa raste mbetet i dobishëm:
# vi /etc/nginx/nginx.conf
# Blloko menaxherët e shkarkimit
nëse ($ http_user_agent ~ * LWP :: E thjeshtë | BBBike | wget) (
kthimi 403;
}
# Blloko disa lloje robotësh
nëse ($ http_user_agent ~ * msnbot | scrapbot) (
kthimi 403;
}
Blloko mesazhet e padëshiruara të referuesit
Nëse faqja juaj publikon regjistrat e uebit në domenin publik, ju mund të bëheni lehtësisht viktimë e postës së padëshiruar të referuesit (kur bot-et e padëshiruara kontaktojnë serverin tuaj, duke specifikuar adresën e faqes së reklamuar në kokën e referuesit). Ky lloj i spamit mund të prishë lehtësisht renditjen e SEO të një faqe në internet, kështu që është e domosdoshme ta bllokoni atë. Një mënyrë për ta bërë këtë është të vendosni në listën e zezë fjalët më të zakonshme që gjenden në URL-të e faqeve të reklamuara.
# vi /etc/nginx/nginx.conf
# Seksioni i serverit
nëse ($ http_referer ~ * (foshnja | shitje në shitje | vajzë | bizhuteri | dashuri | nudit | organike | poker | pornografi | seks | adoleshente))
{
kthimi 403;
}
Blloko lidhjen e drejtpërdrejtë
Hotlink është përfshirja e një imazhi (ose përmbajtje tjetër) nga një faqe tjetër në një faqe. Në fakt, kjo është vjedhje, sepse imazhi në të cilin keni shpenzuar më shumë se një orë nga koha juaj e lirë, jo vetëm që përdoret lirisht nga të tjerët, por gjithashtu krijon një ngarkesë në serverin tuaj të internetit pa sjellë vizitorë në të. Për të luftuar lidhjet e nxehtësisë, mjafton të siguroheni që imazhet t'i jepen klientit vetëm nëse ai i ka kërkuar ato ndërsa është tashmë në sit (me fjalë të tjera, titulli i kërkesës së referuesit duhet të përmbajë emrin e faqes suaj). Shtoni linjat e mëposhtme në seksionin e serverit të skedarit të konfigurimit nginx.conf (host.com është adresa e faqes suaj):
# vi /etc/nginx/nginx.conf
vendndodhja / imazhet / (
valid_referers asnjë i bllokuar www.host.com host.com;
nëse ($ invalid_referer) (
kthimi 403;
}
}
Përndryshe, mund të konfiguroni serverin që të shërbejë një mesazh të veçantë vjedhjeje në vend të imazhit të kërkuar. Për ta bërë këtë, zëvendësoni rreshtin "kthimi 403" me rreshtin:
rishkruaj ^ / imazhet / ngarkimet. * \. (gif | jpg | jpeg | png) $ http://www.host.com/banned.jpg fundit
Mbroni drejtoritë e rëndësishme nga të huajt
Ashtu si çdo server tjetër në internet, nginx ju lejon të rregulloni aksesin në drejtori bazuar në adresat IP dhe fjalëkalimet. Kjo veçori mund të përdoret për të mbyllur disa pjesë të faqes nga sytë kureshtarë. Për shembull, për të hequr një URI nga bota e jashtme:
# vi /etc/nginx/nginx.conf
vendndodhja / ngarkimet / (
# Lejo qasjen vetëm te makinat në rrjetin lokal
lejoj 192.168.1.0/24;
# Qep të gjithë të tjerët
mohoj të gjitha;
}
Tani vetëm përdoruesit e rrjetit lokal do të kenë akses në dokumentet e drejtorisë së ngarkimeve. Për të vendosur një fjalëkalim, do t'ju duhet të bëni hapa më komplekse. Së pari, duhet të krijoni një skedar privat fjalëkalimi për nginx dhe të shtoni përdoruesit e nevojshëm në të (si shembull, le të shtojmë përdoruesin e administratorit):
# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin
# vi /etc/nginx/nginx.conf
vendndodhja / administratori / (
auth_basic "I kufizuar";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}
Përdoruesit e rinj mund të shtohen duke përdorur komandën e mëposhtme:
# htpasswd -s /etc/nginx/.htpasswd/passwd përdorues
Përdorni SSL
Nëse faqja juaj funksionon me të dhëna private të përdoruesit, si numrat e kartave të kreditit, fjalëkalimet nga shërbime të tjera ose ofron akses në informacione të tjera të rëndësishme që mund të bëhen një gjë e mirë për palët e treta, kujdesuni për enkriptimin. Nginx funksionon mirë me SSL dhe nuk duhet neglizhuar.
Për të konfiguruar enkriptimin SSL duke përdorur nginx, ju vetëm duhet të ndiqni disa hapa të thjeshtë. Së pari, duhet të krijoni një certifikatë duke përdorur sekuencën e mëposhtme të komandave:
# cd / etj / nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -ditë 365 -në server.csr -signkey server.key -out server.crt
Pastaj përshkruani certifikatën në skedarin e konfigurimit nginx:
# vi /etc/nginx/nginx.conf
server (
emri i serverit host.com;
dëgjo 443;
ssl në;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}
Pas kësaj, mund të rinisni serverin në internet:
# /etc/init.d/nginx rifresko
Natyrisht, pa mbështetjen e vetë faqes në internet, nuk ka kuptim ta bësh këtë.
metoda të tjera
Vendosni vlerat e sakta për variablat e sistemit
Hapni skedarin /etc/sysctl.conf dhe vendosni linjat e mëposhtme në të:
# vi /etc/sysctl.conf
# Mbrojtje kundër sulmeve smurf
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Mbrojtje kundër mesazheve të pasakta ICMP
net.ipv4.icmp_ignore_bogus_error_responses = 1
# SYN mbrojtje nga përmbytjet
net.ipv4.tcp_syncookies = 1
# Çaktivizo drejtimin e burimit
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Mbrojtje kundër mashtrimit
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Ne nuk jemi një ruter
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Aktivizoni ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Zgjeroni gamën e porteve të disponueshme
net.ipv4.ip_local_port_range = 2000 65000
# Rritni madhësinë maksimale të buferave TCP
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1
Vendosni direktorinë rrënjë të serverit në internet në një ndarje të dedikuar
Duke vendosur direktoriumin rrënjë të serverit të Uebit në një ndarje të dedikuar dhe duke mos lejuar çdo skedar të ekzekutueshëm ose pajisjeje në të, ju mund të mbroni pjesën tjetër të sistemit nga kushdo që mund të hyjë në rrënjën e serverit të uebit. Në këtë rast, hyrja në skedarin / etc / fstab duhet të duket diçka si kjo:
/ dev / sda5 / nginx ext4 parazgjedhjet, nosuid, noexec, nodev 1 2
Vendos nginx në mjedisin chroot / jail
Çdo sistem modern * nix ju lejon të kyçni një aplikacion në një mjedis ekzekutimi të izoluar. Në Linux, për këtë mund të përdorni teknologjitë KVM, Xen, OpenVZ dhe VServer, në FreeBSD - Jail, në Solaris - Zones. Nëse asnjë nga këto teknologji nuk është e disponueshme, mund të vendosni nginx në një chroot klasik, i cili, megjithëse shumë më i brishtë, mund të ndalet nga shumica e krisurave.
Vendosni rregullat SELinux për të mbrojtur nginx
Sistemet lokale të zbulimit dhe parandalimit të ndërhyrjeve, si SELinux ose AppArmor janë alternativa të mira ndaj kohëzgjatjes me sandbox. Kur konfigurohen siç duhet, ato mund të parandalojnë përpjekjet për të komprometuar serverin e uebit. Si parazgjedhje, asnjë prej tyre nuk është i konfiguruar të funksionojë në lidhje me nginx, por brenda projektit SELinuxNginx(http://sf.net/projects/selinuxnginx/) janë krijuar rregulla për SELinux që çdokush mund t'i përdorë. Gjithçka që mbetet është të shkarkoni dhe instaloni:
# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10 / nginx
#bëj
# / usr / sbin / semodule -i nginx.pp
Konfiguro një mur zjarri
Në mënyrë tipike, nginx instalohet në makina të dedikuara që janë gati për ngarkesa të rënda pune, kështu që shpesh mbetet shërbimi i vetëm i rrjetit që funksionon në server. Për të siguruar serverin, mjafton të krijoni një grup shumë të vogël rregullash që do të hapin portet 80, 110 dhe 143 (nëse, sigurisht, nginx duhet të funksionojë gjithashtu si një përfaqësues IMAP / POP3) dhe të mbyllë gjithçka tjetër nga bota e jashtme .
Kufizoni numrin e lidhjeve me një mur zjarri
Për një faqe interneti të lehtë, është një ide e mirë të kufizoni numrin e përpjekjeve për lidhje nga një adresë IP në minutë. Kjo mund t'ju shpëtojë nga disa lloje të sulmeve DoS dhe sulmeve me forcë brutale. Në Linux, kjo mund të bëhet duke përdorur modulin standard të gjendjes iptables / netfilter:
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m gjendje --state E RE -m e fundit --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m gjendje --state E RE -m e fundit --përditësim \
-- sekonda 60 -- numri i goditjeve 15 -j DROP
Rregullat e shkurtojnë kufirin e numrit të lidhjeve nga një IP në minutë në 15. E njëjta gjë mund të bëhet duke përdorur pf:
# vi /etc/pf.conf
webserver_ip = "1.1.1.1"
tabela
bllokohu shpejt nga
kaloni në $ ext_if proto tcp në $ webserver_ip \
port www flamujt S / SA mbaj gjendjen \
(max-src-conn 100, max-src-conn-rate 15/60, \
mbingarkesë
Përveç kufirit në numrin e lidhjeve të njëpasnjëshme (15 në minutë), ky rregull vendos një kufi shtesë në numrin e lidhjeve të njëkohshme të barabartë me 100.
Konfigurimi i PHP
Nëse po përdorni nginx në lidhje me PHP, mos harroni ta konfiguroni gjithashtu. Kështu duhet të duket skedari i konfigurimit të sigurt të serverit /etc/php/php.ini:
# vi /etc/php/php.ini
# Çaktivizoni funksionet e rrezikshme
disable_functions = phpinfo, system, mail, exec
# Koha maksimale e ekzekutimit të skriptit
koha_maksimumi i_ekzekutimit = 30
# Koha maksimale që mund të shpenzojë një skrip për përpunimin e të dhënave të kërkesës
koha_max_input = 60
# Sasia maksimale e memories së caktuar për secilin skript
Kufiri_memorie = 8M
# Madhësia maksimale e të dhënave të dërguara në skript duke përdorur metodën POST
madhësia_max_post = 8M
# Madhësia maksimale e skedarëve të ngarkuar
upload_max_filesize = 2M
# Mos u shfaqni përdoruesve gabimet e skriptit PHP
shfaqja_gabimet = Joaktiv
# Aktivizo modalitetin e sigurt
safe_mode = Aktiv
# Aktivizo modalitetin e sigurt SQL
sql.safe_mode = Aktiv
# Lejoni të ekzekutohen komanda të jashtme vetëm në këtë direktori
safe_mode_exec_dir = / shteg / në / e mbrojtur / drejtoria
# Mbrojtje kundër rrjedhjeve të informacionit PHP
expose_php = Off
# Mbajtja e regjistrave
log_errors = Aktiv
# Ndaloni hapjen e skedarëve në distancë
allow_url_fopen = Joaktiv
konkluzionet
Duke zbatuar udhëzimet e përshkruara në këtë artikull, ju do të keni një server shumë më të sigurt në internet. Por mbani në mend se jo të gjitha teknikat do të përshtaten me konfigurimin tuaj. Për shembull, mbrojtja e forcës brutale bazuar në zvogëlimin e madhësisë së buferave të alokuara nga nginx për përpunimin e kërkesave të klientëve mund të çojë në një degradim të performancës dhe, në disa raste, në dështime në përpunimin e kërkesave. Kufizimi i numrit të lidhjeve do të ketë një ndikim të madh në performancën edhe të një faqe interneti të ngarkuar mesatarisht, por do të jetë e dobishme nëse faqja ka një fluks të ulët vizitorësh. Gjithmonë kontrolloni se si ndryshimet që keni bërë kanë ndikuar në performancën dhe shëndetin e përgjithshëm të faqes tuaj të internetit.
Për heroin e ditës
Nginx është një nga serverët më të fuqishëm dhe më të njohur në internet në botë. Sipas Netcraft, ai përdoret për të fuqizuar më shumë se 12 milionë faqe interneti në mbarë botën, duke përfshirë ato si Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusek dhe Taba.ru. Një arkitekturë kompetente e bazuar në lidhjet e shumëfishta duke përdorur thirrjet e sistemit select, epoll (Linux), kqueue (FreeBSD) dhe një mekanizëm të menaxhimit të memories bazuar në grupe (buferë të vegjël nga 1 në 16 KB), lejon nginx të mos ulet edhe nën ngarkesa shumë të larta. , duke përballuar mbi 10,000 lidhje të njëkohshme (i ashtuquajturi problem C10K). Shkruar fillimisht nga Igor Sysoev për Rambler dhe u hap në 2004 nën një licencë të ngjashme me BSD.
Në kontakt me
Të tjera). Versioni aktual, 0.6.x, konsiderohet i qëndrueshëm për besueshmërinë, ndërsa lëshimet nga dega 0.7 konsiderohen të paqëndrueshme. Është e rëndësishme të theksohet se funksionaliteti i disa moduleve do të ndryshojë, si rezultat i të cilave mund të ndryshojnë edhe direktivat, kështu që përputhshmëria e prapambetur në nginx deri në versionin 1.0.0 nuk është e garantuar.
Pse është nginx kaq i mirë dhe pse administratorët e projekteve me ngarkesë të lartë e duan atë kaq shumë? Pse të mos përdorni vetëm Apache?
Pse Apache është i keq?
Së pari, duhet të shpjegoni se si funksionojnë në përgjithësi serverët e rrjetit. Ata që janë të njohur me programimin e rrjetit e dinë se ekzistojnë në thelb tre modele të funksionimit të serverit:
- Konsistente. Serveri hap një prizë dëgjimi dhe pret që të shfaqet një lidhje (është në një gjendje të bllokuar gjatë pritjes). Kur arrin një lidhje, serveri e përpunon atë në të njëjtin kontekst, mbyll lidhjen dhe pret përsëri lidhjen. Natyrisht, kjo është larg nga mënyra më e mirë, veçanërisht kur klienti ka punuar për një kohë të gjatë dhe ka shumë lidhje. Për më tepër, modeli sekuencial ka shumë më tepër disavantazhe (për shembull, pamundësia për të përdorur shumë procesorë), dhe në kushte reale praktikisht nuk përdoret.
- Shumëprocesore (me shumë fije). Serveri hap një prizë dëgjimi. Kur arrin një lidhje, ajo e pranon atë dhe më pas krijon (ose merr nga grupi i atyre të krijuara më parë) një proces ose fill i ri që mund të funksionojë me lidhjen për aq kohë sa është e nevojshme, dhe pas përfundimit të punës, del ose kthehet. në pishinë. Ndërkaq, filli kryesor është gati të pranojë një lidhje të re. Ky është modeli më i popullarizuar sepse është relativisht i lehtë për t'u zbatuar, lejon llogaritje komplekse dhe që kërkojnë kohë për çdo klient dhe përdor të gjithë procesorët e disponueshëm. Një shembull i përdorimit të tij është serveri në internet Apache. Sidoqoftë, kjo qasje ka gjithashtu disavantazhe: me një numër të madh lidhjesh të njëkohshme, krijohen shumë fije (ose, edhe më keq, procese) dhe sistemi operativ harxhon shumë burime në ndërprerësit e kontekstit. Është veçanërisht e keqe kur klientët janë shumë të ngadalshëm në pranimin e përmbajtjes. Rezulton qindra fije ose procese, të zënë vetëm me dërgimin e të dhënave për klientët e ngadaltë, gjë që krijon një ngarkesë shtesë në planifikuesin e OS, rrit numrin e ndërprerjeve dhe konsumon shumë memorie.
- Prizat pa bllokim / Makina e gjendjes. Serveri funksionon brenda një thread të vetëm, por përdor bazat jo-bllokuese dhe një mekanizëm votimi. ato. serveri në çdo përsëritje të një cikli të pafund zgjedh nga të gjitha prizat atë që është gati të marrë/dërgojë të dhëna duke përdorur thirrjen selekto (). Pasi të zgjidhet një prizë, serveri i dërgon të dhëna ose i lexon ato, por nuk pret për konfirmim, por hyn në gjendjen fillestare dhe pret një ngjarje në një prizë tjetër, ose përpunon atë tjetër, në të cilën ngjarja ka ndodhur gjatë përpunimi i të mëparshmit. Ky model përdor me shumë efikasitet procesorin dhe memorien, por është mjaft i vështirë për t'u zbatuar. Për më tepër, në kuadrin e këtij modeli, përpunimi i një ngjarjeje në një prizë duhet të jetë shumë i shpejtë - përndryshe, shumë ngjarje do të grumbullohen në radhë dhe përfundimisht do të vërshojnë. Kështu funksionon nginx. Përveç kësaj, ju lejon të filloni procese të shumta të punëtorëve (të quajtur punëtorë), d.m.th. mund të përdorë shumë procesorë.
Pra, imagjinoni situatën e mëposhtme: 200 klientë me një kanal 256 Kbps janë të lidhur me një server HTTP me një kanal 1 Gbps:
Çfarë ndodh në rastin e Apache? Janë krijuar 200 thread/procese që gjenerojnë përmbajtje relativisht shpejt (mund të jenë faqe dinamike dhe skedarë statikë të lexuar nga disku), por ngadalë ua japin klientëve. Sistemi operativ duhet të merret me një mori fijesh dhe bllokimesh I/O.
Në një situatë të tillë, Nginx shpenzon një rend të madhësisë më pak OS dhe burime memorie për secilën lidhje. Sidoqoftë, kjo zbulon një kufizim të modelit të rrjetit nginx: ai nuk mund të gjenerojë përmbajtje dinamike brenda vetes, pasi kjo do të çojë në bllokimin brenda nginx. Natyrisht, ekziston një zgjidhje: nginx mund të proksojë kërkesa të tilla (për gjenerimin e përmbajtjes) në çdo server tjetër në internet (për shembull, i njëjti Apache) ose në një server FastCGI.
Le të shqyrtojmë mekanizmin e funksionimit të paketës nginx si serverin "kryesor" dhe Apache si serverin për gjenerimin e përmbajtjes dinamike:
Nginx pranon lidhjen nga klienti dhe lexon të gjithë kërkesën prej tij. Këtu duhet theksuar se derisa nginx të ketë lexuar të gjithë kërkesën, nuk e dërgon atë për “përpunim”. Për shkak të kësaj, pothuajse të gjithë treguesit e progresit të ngarkimeve të skedarëve zakonisht "prihen" - megjithatë, është e mundur t'i rregulloni ato duke përdorur modulin upload_progress të palëve të treta (kjo do të kërkojë modifikim të aplikacionit).
Pasi nginx të ketë lexuar të gjithë përgjigjen, hap një lidhje me Apache. Ky i fundit bën punën e tij (gjeneron përmbajtje dinamike), pas së cilës i dërgon përgjigjen e tij nginx, i cili e ruan atë në memorie ose një skedar të përkohshëm. Ndërkohë, Apache çliron burimet. Më tej, nginx ngadalë dërgon përmbajtje te klienti, ndërsa shpenzon urdhra të madhësisë më pak burime se Apache.
Kjo skemë quhet frontend + backend dhe përdoret shumë shpesh.
Instalimi
Sepse nginx sapo ka filluar të fitojë popullaritet, ka disa probleme me paketat binare, kështu që përgatituni ta përpiloni vetë. Ky zakonisht nuk është problem, thjesht duhet të lexoni me kujdes daljen e komandës. / Konfiguro --help dhe zgjidhni opsionet e përpilimit që ju nevojiten, për shembull:
./konfiguro \
--Prefiksi = / opt / nginx-0.6.x \ # prefiksi i instalimit
--Conf-path = / etc / nginx / nginx.conf \ # vendndodhjen e skedarit të konfigurimit
-Pid-path = / var / run / nginx.pid \ # ... dhe skedari pid
-Përdoruesi = nginx \ # emri i përdoruesit nën të cilin do të funksionojë nginx
—Me-http_ssl_module —with-http_gzip_static_module —with-http_stub_status_module \ # lista e të kërkuarave
—Pa-http_ssi_module —pa-http_userid_module —pa-http_autoindex_module —pa-http_geo_module —pa-http_referer_module —pa-http_memcached_module —pa-http_module_jo të kërkuara ...e
Pas konfigurimit, duhet të ekzekutoni standardin make && make install, pas së cilës mund të përdorni nginx.
Përndryshe, në Gentoo mund të përdorni ebuild nga pema standarde e porteve; në RHEL / CentOS depoja epel (ku ndodhet nginx 0.6.x) ose srpm për versionin 0.7, i cili mund të shkarkohet nga këtu: http://blogs.mail.ru/community/nginx; në Debian, mund të përdorni paketën nginx nga dega e paqëndrueshme.
Skedari i konfigurimit
Skedari i konfigurimit nginx është shumë i përshtatshëm dhe intuitiv. Zakonisht quhet nginx.conf dhe ndodhet në prefiksin $ / conf / nëse vendndodhja nuk është ripërcaktuar gjatë përpilimit. Më pëlqen ta vendos në / etc / nginx /, dhe kështu bëjnë zhvilluesit e të gjitha paketave të përmendura më sipër.
Struktura e skedarit të konfigurimit është si më poshtë:
përdoruesi nginx; # emër përdoruesi nën të cilin do të funksionojë nginx
punëtori_proceset 1; # numër i proceseve të punonjësve
ngjarjet (
<…># ky bllok specifikon mekanizmin e votimit që do të përdoret (shih më poshtë) dhe numrin maksimal të lidhjeve të mundshme
}Http (
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;# përshkrim i serverëve (kjo është ajo që apache e quan VirtualHost)
server (
# adresa dhe emri i serverit
dëgjo *: 80;
emri i serverit aaa.bbb;<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;
# dhe kështu mund të përcaktoni vendndodhjen, për të cilën gjithashtu mund të anashkaloni pothuajse të gjitha direktivat e specifikuara në nivele më globale
vendndodhja / abcd / (
<директивы>;
}
# Përveç kësaj, ju mund të bëni vendndodhjen me shprehje të rregullt, si kjo:
vendndodhja ~ \ .php $ (
<директивы>;
}
}# server tjetër
server (
dëgjo *: 80;
emri i serverit ccc.bbb;<директивы>
}
}
Ju lutemi vini re se çdo direktivë duhet të përfundojë me një pikëpresje.
Reverse proxying dhe FastCGI
Pra, më lart shqyrtuam avantazhet e skemës frontend + backend, kuptuam instalimin, strukturën dhe sintaksën e skedarit të konfigurimit, merrni parasysh tani se si të zbatoni proksimin e kundërt në nginx.
Është shumë e thjeshtë! Për shembull si kjo:
vendndodhja / (
proxy_pass http://1.2.3.4:8080;
}
Në këtë shembull, të gjitha kërkesat për vendndodhjen / do të proksiohen në serverin 1.2.3.4, portin 8080. Ky mund të jetë ose apache ose ndonjë server tjetër http.
Sidoqoftë, ka disa hollësi që lidhen me faktin që aplikacioni do të supozojë se, së pari, të gjitha kërkesat vijnë tek ai nga një adresë IP (e cila mund të interpretohet, për shembull, si një përpjekje për një sulm DDoS ose sulm me forcë brutale) , dhe së dyti, konsideroni se po funksionon në host 1.2.3.4 dhe port 8080 (përkatësisht gjeneroni ridrejtime të pasakta dhe lidhje absolute). Për të shmangur këto probleme pa pasur nevojë të rishkruani aplikacionin, konfigurimi i mëposhtëm më duket i përshtatshëm:
Nginx dëgjon në ndërfaqen e jashtme në portin 80.
Nëse backend (për shembull, Apache) ndodhet në të njëjtin host si nginx, atëherë ai "dëgjon" portin 80 në 127.0.0.1 ose një adresë tjetër IP të brendshme.
Në këtë rast, konfigurimi nginx duket si ky:
server (
dëgjo 4.3.2.1:80;
# vendosni kokën e Host-it dhe X-Real-IP: për çdo kërkesë të dërguar në backend
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header Host $ host: $ proxy_port;
# ose "proxy_set_header Host $ host;" nëse aplikacioni do të shtojë: 80 në të gjitha lidhjet
}
Në mënyrë që aplikacioni të dallojë adresat IP të vizitorëve, ju duhet ose të instaloni modulin mod_extract_forwarded (nëse është ekzekutuar nga serveri Apache), ose të modifikoni aplikacionin në mënyrë që të marrë informacione për adresën IP të përdoruesit nga X- Titulli real-IP HTTP.
Një tjetër opsion mbështetës është përdorimi i FastCGI. Në këtë rast, konfigurimi nginx do të duket diçka si kjo:
server (
<…># vendndodhje ku do të dërgohen kërkesat për skriptet php
vendndodhja ~ .php $ (
fastcgi_pass 127.0.0.1: 8888; # përcaktoni adresën dhe portin e serverit fastcgi,
fastcgi_index index.php; # ... skedari i indeksit# dhe disa parametra që duhet t'i kalojnë serverit fastcgi në mënyrë që të kuptojë se cilin skript dhe me cilët parametra duhet të ekzekutohet:
fastcgi_param SCRIPT_FILENAME / usr / www / html $ fastcgi_script_name; # emër skripti
fastcgi_param QUERY_STRING $ query_string; # varg pyetjesh
# dhe parametrat e kërkesës:
fastcgi_param REQUEST_METHOD $ request_method;
fastcgi_param CONTENT_TYPE $ content_type;
fastcgi_param CONTENT_LENGTH $ content_length;
}
# për shkak të faktit se vendndodhjet me shprehje të rregullta kanë një "prioritet" të lartë, të gjitha kërkesat jo-php do të shkojnë këtu.
vendndodhja / (
rrënjë / var / www / html /
}
Statika
Për të zvogëluar ngarkesën në backend, është më mirë të shërbeni skedarët statikë vetëm përmes nginx - ai e përballon këtë detyrë më mirë, pasi ai shpenzon dukshëm më pak burime për çdo kërkesë (nuk ka nevojë të hapet një proces i ri, dhe procesi nginx si rregull konsumon më pak memorie dhe mund të shërbejë shumë lidhje).
Në skedarin e konfigurimit, duket kështu:
server (
dëgjo *: 80;
emri i serverit myserver.com;Vendndodhja / (
proxy_pass
"> Http://127.0.0.1:80;
}# supozoni se të gjithë skedarët statikë janë në / skedarë
vendndodhja / skedarët / (
rrënjë / var / www / html /; # specifikoni shtegun për në fs
skadon 14 ditë; # shtoni titullin Skadon:
error_page 404 = @back; # dhe nëse skedari nuk gjendet, dërgojeni në vendndodhjen e emërtuar @back
}# kërkesa nga / skedarë, për të cilët nuk u gjet asnjë skedar, dërgohen në prapavijë dhe mund të gjenerojë skedarin e dëshiruar ose të shfaqë një mesazh të bukur gabimi
vendndodhja @mbrapa (
proxy_pass
"Titulli =" http://127.0.0.1:80;
"> Http://127.0.0.1:80;
}
Nëse të gjitha statikat nuk vendosen në një drejtori specifike, atëherë përdorni një shprehje të rregullt:
vendndodhja ~ * ^. + \. (jpg | jpeg | gif | png | ico | css | zip | tgz | gz | rar | bz2 | doc | xls | exe | pdf | ppt | txt | tar | wav | bmp | rtf | js) $ (
# e ngjashme me sa më sipër, vetëm të gjitha kërkesat që përfundojnë me një nga prapashtesat e specifikuara do të dërgohen në këtë vendndodhje
rrënjë / var / www / html /;
error_page 404 = @back;
}
Fatkeqësisht, nginx nuk mbështet trajtimin asinkron të skedarëve. Me fjalë të tjera, punëtori nginx është i bllokuar në operacionet I/O. Pra, nëse keni shumë skedarë statikë dhe, veçanërisht, nëse ato lexohen nga disqe të ndryshëm, është më mirë të rrisni numrin e proceseve të punës (deri në një numër që është 2-3 herë më shumë se numri i përgjithshëm i kokave në disku). Kjo, natyrisht, çon në një rritje të ngarkesës në OS, por performanca e përgjithshme rritet. Për të punuar me një sasi tipike statike (jo shumë të madhe skedarësh relativisht të vegjël: CSS, JavaScript, imazhe), mjaftojnë një ose dy flukse pune.
Vazhdon
Lidhjet
Më shumë informacion rreth nginx mund të gjeni këtu:
Nginx është një server në internet dhe server proxy postar që është i disponueshëm publikisht që nga viti 2004. Zhvillimi i projektit filloi në 2002, në rusisht emri tingëllon si "engin-ex". Krijimi i duarve të programuesit të famshëm Igor Sysoev, Nginx fillimisht ishte menduar për Rambler. Është projektuar për sistemet operative që i përkasin grupit të ngjashëm me Unix. Asambleja u testua me sukses në OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. Në platformën Microsoft Windows, Nginx filloi të punojë me paraqitjen e versionit 0.7.52 të asamblesë binare.
Statistikat për Mars 2011 tregojnë se numri i faqeve të shërbyera nga Nginx tashmë ka kaluar shifrën 22 milionë. Sot Nginx përdoret nga projekte të tilla të njohura si Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru dhe të tjerë. Së bashku me lighttpd, Nginx përdoret për të shërbyer përmbajtje statike të krijuar nga një aplikacion uebi "i papërshtatshëm" që funksionon nën një server tjetër në internet.
Por, përpara se të futemi në xhunglën e veçorive funksionale të Nginx - është e dobishme të mbani mend se çfarë është një server në internet në përgjithësi dhe një server proxy në veçanti.
Web server dhe proxy server
Web serverështë një server që pranon kërkesat HTTP nga shfletuesit e internetit dhe klientë të tjerë dhe lëshon përgjigje HTTP ndaj tyre. Këto të fundit zakonisht përfaqësohen nga një faqe HTML, një transmetim mediatik, imazh, skedar dhe të dhëna të tjera. Një server në internet kuptohet si softuer që kryen funksionet e serverit në internet dhe hardueri. Shkëmbimi i të dhënave dhe informacionit të kërkuar kryhet nëpërmjet protokollit HTTP.
Lista e funksioneve shtesë të serverëve të uebit përfshin: autorizimin dhe vërtetimin e përdoruesve, regjistrimin e thirrjeve të tyre drejt burimeve, mbështetje HTTPS për ndërrim të sigurt me klientët dhe të tjera. Ueb serveri më i përdorur në sistemet operative të ngjashme me Unix është Apache. Rreshti i tretë në listën e preferencave të klientit aktualisht është i zënë nga Nginx.
Proxy server i lejon klientët të kërkojnë shërbime online në mënyrë indirekte. Kjo do të thotë, është një server që është i specializuar në përcjelljen e kërkesave të klientëve në serverë të tjerë. Duke u lidhur me një server proxy dhe duke kërkuar një burim të vendosur në një server tjetër, klienti mund të ruajë anonimitetin dhe të mbrojë kompjuterin nga sulmet e rrjetit. Proxy server i lëshon të dhënat e kërkuara klientit ose nga cache e tij (nëse ka) ose i merr ato nga serveri i specifikuar. Në disa raste (për të arritur qëllimet e mësipërme), përgjigja e serverit, si kërkesa e klientit, mund të ndryshohet nga serveri proxy.
Proxy serveri më i thjeshtë konsiderohet të jetë Përkthyesi i Adresave të Rrjetit ose NAT. Në vitin 2000, proxy NAT u ndërtua në shpërndarjen e Windows. Proxy serverët, si çdo fenomen, kanë dy anët e medaljes, domethënë mund të përdoren si për të mirë ashtu edhe për të keq. Për shembull, me ndihmën e tyre ata që kanë frikë nga sanksionet për veprimet e tyre të pahijshme në rrjet fshehin adresat e tyre IP ...
Gama funksionale e Nginx:
- servisimi i serverit të skedarëve të indeksit, pyetjet statike, gjenerimi i përshkruesve për cache të hapur, lista e skedarëve;
- proxying i përshpejtuar, shpërndarja elementare e ngarkesës, toleranca ndaj gabimeve;
- mbështetje për caching gjatë proxying të përshpejtuar dhe FastCGI;
- mbështetje për serverët FastCGI (të përshpejtuar) dhe memcached;
- modulariteti, filtrat, duke përfshirë "rifillimin" (varg-byte) dhe kompresimin (gzip);
- Autentifikimi HTTP, përgjigjet e copëtuara, filtri SSI;
- ekzekutimi paralel i disa nënkërkesave në faqen e përpunuar përmes FastCGI ose proxy në filtrin SSI;
- Mbështetje StartTLS dhe SSL;
- aftësia për të mbështetur Perl të integruar;
- vërtetim i thjeshtë (USER / PASS, LOGIN);
- ridrejtimi i serverit (proxy IMAP / POP3) i përdoruesit në prapavijën IMAP / POP3 duke përdorur një server të jashtëm vërtetimi (HTTP).
Për ata që nuk janë të njohur me këtë terminologji, përshkrimi i funksionalitetit të Nginx mund të duket mjaft i paqartë. Por kur bëhet fjalë për mënyrat e përdorimit konkret të këtij web serveri - ai do të fillojë të zbehet pak nga pak.
Arkitektura dhe konfigurimi
Proceset e punëtorit Nginx shërbejnë për lidhje të shumta njëkohësisht, duke u siguruar atyre thirrjet OS (sistemi operativ) epoll (Linux), zgjidhni dhe kqueue (FreeBSD). Të dhënat e marra nga klienti analizohen nga një makinë shtetërore. Kërkesa e analizuar trajtohet nga zinxhiri i modulit të specifikuar nga konfigurimi. Formimi i një përgjigjeje ndaj klientit ndodh në buferë, të cilët mund të tregojnë një seksion të një skedari ose të ruajnë të dhëna në memorie. Sekuenca e transmetimit të të dhënave te klienti përcaktohet nga zinxhirët në të cilët grupohen buferët.
Strukturisht, serveri Nginx HTTP është i ndarë në serverë virtualë, të cilët nga ana tjetër ndahen në vendndodhje. Një serveri virtual ose direktivë mund t'i caktohen porte dhe adresa për të marrë lidhje. Vendndodhja mund të specifikohet me një URI të saktë, pjesë të një URI ose një shprehje të rregullt. Për menaxhimin e kujtesës në lëvizje, grupet janë një sekuencë e blloqeve të memories së zgjedhur paraprakisht. Një bllok i caktuar fillimisht për pishinën ka një gjatësi prej 1 deri në 16 kilobajt. Ai është i ndarë në zona - të pushtuara dhe të pabanuara. Ndërsa kjo e fundit plotësohet, zgjedhja e një objekti të ri sigurohet nga formimi i një blloku të ri.
Klasifikimi gjeografik i klientëve sipas adresës së tyre IP kryhet në Nginx duke përdorur një modul të veçantë. Sistemi i pemës Radix ju lejon të punoni shpejt me adresat IP, duke marrë një minimum memorie.
Përfitimet e Nginx
Nginx konsiderohet një server shumë i shpejtë HTTP. Në vend të ose në lidhje me Apache, Nginx përdoret për të shpejtuar përpunimin e kërkesave dhe për të zvogëluar ngarkesën në server. Fakti është se aftësitë e mëdha të ofruara nga arkitektura modulare Apache nuk kërkohen nga shumica e përdoruesve. Pagesa për këtë funksionalitet të padeklaruar është një humbje e konsiderueshme e burimeve të sistemit. Për faqet e zakonshme, si rregull, ekziston një dominim i qartë i skedarëve statikë (imazhe, skedarë stili, JavaScript) dhe jo skriptet. Asnjë funksionalitet i veçantë nuk kërkohet për t'i transferuar këto skedarë te vizitori i burimit, pasi detyra është shumë e thjeshtë. Kjo do të thotë që serveri në internet për përpunimin e kërkesave të tilla duhet të jetë i thjeshtë dhe i lehtë, si Nginx.
Mënyrat për të përdorur Nginx
Në një port / IP të veçantë. Nëse burimi është plot me imazhe ose skedarë për shkarkim, Nginx mund të konfigurohet në një port ose IP të veçantë dhe të shërbejë përmbajtje statike përmes tij. Për ta bërë këtë, megjithatë, duhet të shqetësoheni pak me ndryshimin e lidhjeve në sit. Me një numër të madh kërkesash për skedarë statikë, ka kuptim të krijoni një server të veçantë dhe të instaloni Nginx në të.
Përfaqësimi i përshpejtuar... Me këtë opsion, të gjitha kërkesat e vizitorëve shkojnë së pari në Nginx. Nginx trajton kërkesat për skedarë statikë (të tillë si një imazh, skedar i thjeshtë HTML, JavaScript ose CSS) më vete. Nëse përdoruesi kontakton një skript të caktuar, ai ia përcjell kërkesën departamentit Apache. Ju nuk keni nevojë të bëni ndonjë transformim me kodin e faqes.
Nëse kanali nga serveri te vizitori dhe anasjelltas është i ngadalshëm, ky përdorim i Nginx mund të japë një efekt shtesë. Kërkesa e marrë nga vizitori i kalon Nginx për përpunim nga Apache. Pas përpunimit të kërkesës, Apache drejton faqen Nginx dhe përfundon lidhjen me një ndjenjë të arritjes. Nginx tani mund t'i dërgojë një faqe një përdoruesi për aq kohë sa është e nevojshme, praktikisht pa konsumuar burime të sistemit. Apache që funksiononte në vend të tij do të shoqërohej nga një ngarkesë e paarsyeshme e lartë e memories kur ishte pothuajse boshe. Nga rruga, ky rast përdorimi për Nginx ka një emër tjetër: "Frontend to Apache".
Nginx plus FastCGI. Apache mund të mos jetë fare i nevojshëm nëse përkthyesi i gjuhës në të cilën janë shkruar skriptet e faqes mbështet teknologjinë FastCGI. Gjuhë të tilla përfshijnë, për shembull, PHP, Perl dhe një numër të tjerash. Megjithatë, në këtë rast, mund t'ju duhet të modifikoni kodet e skriptit.
Ka shumë materiale të detajuara se si të instaloni dhe konfiguroni Nginx në rrjet. Mund të mësoni më shumë rreth Nginx në faqen e internetit të zhvilluesit të saj Igor Sysoev.
Përshëndetje, i dashur përdorues i Habrahabr. Historia ime do të jetë rreth asaj se si të vendosim skenën për projektet lokale të zhvillimit të uebit në sistemin operativ Ubuntu 16.04.1 LTS.
Në këtë artikull, unë do të doja të shpërndaj dhe sqaroj vështirësitë e mundshme që lidhen me instalimin dhe konfigurimin e softuerit që kërkohet për zhvillimin modern të uebit, me të cilin mund të përballen zhvilluesit fillestarë dhe jo vetëm.
Teknologjitë që do të përdoren në artikull: nginx, php-fpm.
Para fillimit të tregimit, dua të vërej se të gjitha këto veprime i kam bërë në një sistem "të zhveshur".
Unë do të punoj me aftësinë e menaxherit të paketave. Unë rekomandoj gjithashtu përditësimin e indeksit të paketave dhe vetë paketave përpara se të instaloni softuerin. Në këtë artikull, ne do t'i bëjmë këto hapa së bashku.
Shkoni!
Instalimi i menaxherit të paketave zotësia, duke përditësuar indeksin dhe paketat
Instaloni:Aftësia e instalimit të Sudo apt
Ne përditësojmë indeksin.
Përditësimi i aftësisë sudo
Ne përditësojmë paketat (komanda do të përditësojë të gjitha paketat për të cilat ka versione të reja, nëse është e nevojshme të hiqen paketat, do të bëhet).
Përmirësim i plotë i aftësisë sudo
Instalimi dhe konfigurimi nginx(versioni> = 1.10.0)
Instaloni.Instaloni nginx aftësinë sudo
Ne nisim.
Fillimi i shërbimit Sudo nginx
Ne kontrollojmë versionin për t'u siguruar që nuk e kemi instaluar të vjetrën, domethënë nën 1.10.0.
Ne e instaluam dhe e nisëm atë, tani le të shkojmë te drejtoria ku është instaluar nginx-i ynë dhe të shikojmë strukturën e tij. Drejtoria nginx ndodhet përgjatë kësaj rruge:
Cd / etc / nginx /
Ju mund të shikoni përmbajtjen e drejtorisë me komandën ls, me flamujt -la do të jetë më i përshtatshëm për të parë përmbajtjen e drejtorisë (në fakt, kjo komandë me flamuj specifikë mund të përshkruhet më në detaje dhe më saktë, por sot kemi një temë tjetër).
Ls -la
Aktualisht jemi të interesuar për dy drejtoritë që shihni në pamjen e ekranit. Këto janë drejtoritë e disponueshme dhe të aktivizuara për faqet.
Le të shkojmë te drejtoria e disponueshme e faqeve dhe të fillojmë të konfigurojmë hostin (faqen) tonë virtual.
Cd / etc / nginx / faqet e disponueshme
Para se të fillojmë të krijojmë një skedar konfigurimi, le të kontrollojmë se çfarë kemi në këtë direktori. Në rastin tim, drejtoria nuk është bosh, ajo tashmë përmban skedarë konfigurimi, i kam mbishkruar ato për të mos ju mashtruar.
Digresion i rëndësishëm
Në rastin e instalimit të nginx "nga e para", përkatësisht "nga e para", që kur hiqet nginx me komandën
sudo apt-get hiqni skedarët e konfigurimit nginx ose sudo apt hiqni nginx, dhe nëse papritur nuk e kuptoni pse nginx nuk funksionon dhe dëshironi ta riinstaloni atë (zakonisht përdoruesit fillestarë të Linux i drejtohen kësaj), atëherë pasi ta instaloni atë nuk do të funksionojë siç duhet , për faktin se në skedarët e vjetër të konfigurimit (ato nuk hiqen pas fshirjes me komandën e heqjes) janë shkruar cilësime të pasakta, ato do të duhet të hiqen ose konfigurohen saktë, vetëm atëherë nginx do të funksionojë.
Unë rekomandoj çinstalimin me sudo apt-get purge nginx ose sudo apt purge nginx. Nëse jeni duke përdorur menaxherin e paketave aptitude, komanda sudo aptitude purge nginx heq të gjithë paketën, duke përfshirë të gjitha varësitë dhe skedarët e konfigurimit.
Ky direktori do të ketë një skedar si parazgjedhje, të quajtur default. Ai do të përmbajë një skedar konfigurimi me një shembull, me komente, ju mund ta studioni atë në kohën e lirë, ose mund ta fshini fare (mund t'i referoheni gjithmonë dokumentacionit zyrtar).
Ls -la 
Le të krijojmë skedarin tonë të konfigurimit që do të korrespondojë me emrin e domenit të faqes sonë lokale (ose të vërtetë, nëse tashmë e dini emrin e tij). Kjo është e përshtatshme, në të ardhmen, kur do të ketë shumë skedarë konfigurimi, do t'ju shpëtojë nga konfuzioni në to. Për mua ky skedar do të quhet project.local.
Projekt sudo prekje.lokale
Le të shohim se çfarë ndodhi.
Tani le ta hapim në redaktues, unë do ta hap në nano.
Sudo nano projekt.lokal
E shohim që e kemi bosh. Tani le të kalojmë në formimin e skedarit tonë. Është e nevojshme të sillni konfigurimin në formën e përshkruar më poshtë. Unë do të përshkruaj vetëm direktivat jetike të këtij skedari, nuk do të përshkruaj pjesën tjetër, pasi kjo nuk është e rëndësishme për momentin, në fund të fundit, ne kemi një temë për konfigurimin bazë. Këto cilësime me një "rrëshqitje" do të jenë të mjaftueshme për zhvillimin e projekteve në nivel lokal, jo vetëm të vegjël, por edhe mjaft të mëdhenj. Në artikujt e mëposhtëm do të përshkruaj veçmas çdo direktivë të përdorur (kështu quhen rreshtat, për shembull emri_server) i këtij skedari.
Shikoni komentet drejtpërdrejt në skedarin e konfigurimit.
Serveri (dëgjo 80; # porta që dëgjon në nginx server_name project.local; # emri i domenit që lidhet me rrënjën aktuale të hostit virtual /home/stavanger/code/project.local; # drejtoria ku ndodhet projekti, shtegu për në indeksin e pikës hyrëse indeksi php; # add_header Access-Control-Allow-Origin *; # shërbimi i skedarëve statikë direkt vendndodhjen ~ * \. (jpg | jpeg | gif | css | png | js | ico | html) $ (qasja_log off; skadon maksimale; log_not_found off ;) vendndodhja / (# add_header Access-Control-Allow-Origin *; try_files $ uri $ uri / /index.php?$query_string;) vendndodhja ~ * \ .php $ (provo skedarët $ uri = 404; fastcgi_split_path_info ^ ( + \ .php) (/.+) $; fastcgi_pass unix: /var/run/php/php7.0-fpm.sock; # aktivizoni folenë php-fpm fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_script_params ) vendndodhja ~ /\.ht (moho të gjitha;))
Ne e ruajmë skedarin. Tani duhet të kontrollojmë nëse ka ndonjë gabim në të. Ne mund ta bëjmë këtë si një ekip.
Sudo nginx -t
Nëse shohim një informacion të tillë si në pamjen e ekranit, atëherë gjithçka është e saktë për ne, mund të vazhdojmë të konfigurojmë. Nëse keni ndonjë gabim, ia vlen të kontrolloni përsëri skedarin e konfigurimit.
Tani duhet të aktivizojmë skedarin e konfigurimit, në drejtorinë / etc / nginx / sites-enabled /, duhet të krijojmë një lidhje simbolike (lidhje simbolike). Nëse keni nginx të instaluar "nga e para", atëherë në këtë direktori ka një lidhje simbolike me skedarin e paracaktuar, i cili u përshkrua më lart, mund ta fshini nëse nuk ju nevojitet. Shkoni te drejtoria e dëshiruar.
Cd / etc / nginx / faqet e aktivizuara /
Tani jemi në drejtorinë e duhur. Le të krijojmë lidhjen tonë simbolike. Për ta krijuar atë, përdorni komandën ln me flamurin -s, më pas do të tregojmë rrugën drejt konfigurimit tonë project.local.
Sudo ln -s /etc/nginx/sites-available/project.local
Le të hedhim një vështrim në lidhjen tonë të krijuar.
Për t'u siguruar që po bëjmë gjithçka siç duhet, ekzekutoni përsëri komandën.
Skedari pret
Ky skedar ndodhet në shtegun / etc / hosts. Prania e hyrjeve në të ju lejon të ekzekutoni nginx duke përdorur localhost si domen. Në këtë skedar, ju mund të caktoni pseudonime alternative, për shembull, për projektin tonë project.local, ne do të caktojmë domenin project.local.Hapni skedarin në redaktuesin nano.
Sudo nano / etj / pret
Do të keni informacione të tjera në këtë skedar, thjesht shpërfillini ato. Thjesht duhet të shtoni një rresht si në pamjen time të ekranit.
Instalimi php-fpm (>=7.0)
sudo aptitude instaloni php-fpmNe kontrollojmë versionin e instaluar, për çdo rast, megjithëse në Ubuntu 16.04.1 versioni 7.0 është në depo.
Php-fpm7.0 -v
Ne sigurohemi që gjithçka të jetë në rregull. Ne fillojmë php-fpm.
Fillimi i shërbimit Sudo php7.0-fpm
Nëse redaktoni konfigurimet, atëherë mos harroni të rinisni demonin. Kështu bën. Por ne nuk kemi nevojë për këtë.
Rinisja e shërbimit Sudo php7.0-fpm
Kjo përfundon instalimin dhe konfigurimin e php-fpm. E vërtetë, kjo është e gjitha. Kjo nuk është magji, shtegu për në folenë php-fpm është shkruar tashmë në skedarin e konfigurimit. Sigurisht, mund t'ju nevojiten disa shtesa php për të zhvilluar projektet tuaja personale, por mund t'i instaloni sipas nevojës.
Tani le të shkojmë te drejtoria me projektin tonë, unë e kam atë përgjatë kësaj rruge.
Cd /home/stavanger/code/project.lokal
Le të ngjitemi në drejtori dhe të bëjmë të drejtat 777 (d.m.th., ne do të bëjmë të drejtat e plota të drejtorisë me projektin tonë.local). Në të ardhmen, kjo do të na shpëtojë nga problemet e panevojshme.
Cd .. sudo chmod -R 777 projekt.lokal
Kjo përfundon konfigurimin e softuerit, le të krijojmë një skedar testimi në drejtorinë tonë të punës project.local dhe të sigurohemi që gjithçka funksionon. Unë do të krijoj një skedar index.php me përmbajtje si kjo.
Shkojmë te shfletuesi dhe shohim që gjithçka funksionon shkëlqyeshëm për ne! Përkthyesi Php duke përfshirë.
Përshëndetje për lexuesit, Stavanger.
