Nginx-də virtual hostları necə yaratmaq olar. Nginx nədir

Nginx populyar və güclü veb serverdir və əks proxy-dir.

Nginx bir çox üstünlüklərə malikdir, lakin onun parametrləri olduqca mürəkkəbdir və yeni başlayanlar üçün həmişə aydın deyil. Bu təlimat Nginx-in əsas parametrlərini, sintaksisini və konfiqurasiya fayllarını başa düşməyə kömək edəcək.

Qeyd: Bu dərslik Ubuntu 12.04-də hazırlanmışdır.

Nginx Directory İerarxiyası

Nginx konfiqurasiya fayllarını /etc/nginx qovluğunda saxlayır.

Bu kataloqda daha bir neçə kataloq və modul konfiqurasiya faylları var.

cd /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

Apache istifadəçiləri artıq mövcud saytlar və saytlar tərəfindən aktivləşdirilən qovluqlarla tanışdırlar. Bu qovluqlar sayt konfiqurasiyalarını müəyyən edir. Fayllar adətən saytlarda yaradılır və saxlanılır-mövcuddur; saytlar aktivləşdirilmiş saytların yalnız konfiqurasiyalarını saxlayır. Bunu etmək üçün, mövcud olan saytlardan aktivləşdirilən saytlara simvolik bir keçid yaratmalısınız.

conf.d kataloqu konfiqurasiyaları saxlamaq üçün də istifadə edilə bilər. Nginx başlayanda .conf uzantılı hər bir fayl oxunacaq. Belə faylların sintaksisində səhvlər olmamalıdır.

Qalan faylların demək olar ki, hamısı xüsusi proseslər və ya əlavə komponentlər üçün konfiqurasiya məlumatlarını ehtiva edən /etc/nginx-də saxlanılır.

Əsas Nginx konfiqurasiya faylı nginx.conf-dir.

nginx.conf faylı

Nginx.conf faylı müvafiq konfiqurasiya fayllarını oxuyur və onları birləşdirir tək fayl serveri işə salarkən konfiqurasiyalar.

Faylı açın:

sudo nano /etc/nginx/nginx.conf

istifadəçi www-data;
işçi_prosesləri 4;
pid /var/run/nginx.pid;
hadisələr (
işçi_əlaqələri 768;
#multi_accept aktivdir;
}
http(
. . .

İlk sətirlər müəyyən edir ümumi məlumat Nginx haqqında. Sətir istifadəçisi www-data serverin işə salındığı istifadəçini təyin edir.

pid direktivi harada saxlanacağını müəyyənləşdirir PID-ləri emal edinüçün daxili istifadə. Worker_processes xətti Nginx-in eyni vaxtda dəstəkləyə biləcəyi proseslərin sayını müəyyən edir.

Siz həmçinin faylın bu hissəsində qeydləri təyin edə bilərsiniz (məsələn, xəta jurnalı error_log direktivindən istifadə etməklə müəyyən edilir).

Server haqqında ümumi məlumatdan sonra hadisələr bölməsidir. Nginx əlaqələrinin idarə edilməsini idarə edir. Ondan sonra http bloku gəlir. Veb server konfiqurasiyalarına davam etməzdən əvvəl Nginx konfiqurasiya faylının necə formatlandığını başa düşməliyik.

Nginx konfiqurasiya fayl strukturu

Nginx konfiqurasiya faylı bloklara bölünür.

Birinci blok hadisələrdir, ardınca http və konfiqurasiyaların əsas iyerarxiyası başlayır.

Http blokunun konfiqurasiya təfərrüatları, yerləşdikləri blokdan xassələri miras alan qapalı bloklardan istifadə edərək laylılaşdırılır. http bloku server bloklarına bölünən ümumi Nginx konfiqurasiyalarının əksəriyyətini saxlayır, onlar da öz növbəsində yer bloklarına bölünür.

Nginx qurarkən yadda saxlamaq vacibdir növbəti qayda: konfiqurasiya səviyyəsi nə qədər yüksəkdirsə, bir o qədər çox blok bu konfiqurasiyanı miras alır; konfiqurasiya səviyyəsi nə qədər aşağı olarsa, bir o qədər "fərdi" olur. Yəni hər bir server blokunda X parametrindən istifadə edilməlidirsə, onda belə parametr http blokunda yerləşdirilməlidir.

Fayla diqqətlə baxsanız, onda bütövlükdə proqramın davranışını təyin edən bir çox variantın olduğunu görəcəksiniz.

Məsələn, fayl sıxılmasını konfiqurasiya etmək üçün aşağıdakı parametrləri təyin etməlisiniz:

gzip açıq;
gzip_disable "msie6";

Bu, müştəriyə göndərilən məlumatların sıxılması üçün gzip dəstəyini aktivləşdirəcək və gzip-i deaktiv edəcək Internet Explorer 6 (çünki bu brauzer məlumatların sıxılmasını dəstəkləmir).

Bir parametr bir neçə server blokunda fərqli dəyərə malik olmalıdırsa, belə bir parametr təyin edilə bilər üst səviyyə və sonra server bloklarının içərisində onu ləğv edin. Nəticədə, Nginx ən aşağı səviyyəli parametri yerinə yetirəcək.

Konfiqurasiyaların bu təbəqələşməsi çoxlu eyni faylları idarə etmək ehtiyacının qarşısını alır. Həmçinin, parametrləri təyin etməyi unutmusunuzsa ən aşağı səviyyə, Nginx sadəcə olaraq standart seçimləri həyata keçirəcək.

Nginx.conf faylındakı http bloku belə bitir:

daxildir /etc/nginx/conf.d/*.conf;
/etc/nginx/sites-enabled/* daxil edin;

Bu o deməkdir ki, xüsusi saytlar və URL-lər üçün parametrləri müəyyən edən server və yer blokları bu fayldan kənarda saxlanılacaq.

Bu, yeni saytlara xidmət etmək üçün yeni faylların yaradıla biləcəyi modul konfiqurasiya arxitekturasına imkan verir. O, həmçinin qruplaşdırmağa imkan verir oxşar fayllar.

nginx.conf faylını bağlayın. İndi ayrı-ayrı saytların parametrlərini öyrənməlisiniz.

Nginx virtual blokları

Nginx-də server blokları virtual bloklara bənzəyir Apache hostları(lakin rahatlıq üçün onlara virtual hostlar da deyilir). Əslində, server blokları texniki spesifikasiyalar eyni serverdə yerləşdirilən ayrı-ayrı veb-saytlar.

Saytların mövcud kataloqunda siz serverlə birlikdə gələn standart server blok faylını tapa bilərsiniz. Bu fayl saytın saxlanması üçün bütün lazımi məlumatları ehtiva edir.

cd saytları mövcuddur
sudo nano default

root /usr/share/nginx/www;
indeks index.html index.htm;
server_name localhost;
yer/(

}
yer /sənəd/ (

ləqəb /usr/share/doc/;
autoindex aktivdir;
icazə 127.0.0.1;
hamısını inkar etmək;

Standart fayl çox yaxşı şərh edilmişdir, lakin yuxarıdakı nümunədə sadəlik və rahatlıq üçün şərhlər buraxılmışdır.

Server bloku əyri mötərizələr arasında yerləşdirilən bütün parametrləri ehtiva edir:

server (
. . .
}

Bu blok daxildir direktivindən istifadə edərək http blokunun sonuna yaxın nginx.conf faylına yerləşdirilir.

Kök direktivi saytın məzmununun saxlanacağı qovluğu təyin edir. Nginx istifadəçi tərəfindən tələb olunan faylları bu kataloqda axtaracaq. Varsayılan olaraq bu /usr/share/nginx/www.

Diqqət edin: bütün sətirlər nöqtəli vergüllə bitir. Nginx bir direktivi digərindən belə ayırır. Əgər nöqtəli vergül yoxdursa, Nginx iki direktivi (və ya bir neçə direktivi) əlavə arqumentlərlə bir direktiv kimi oxuyacaq.

İndeks direktivi indeks kimi istifadə olunacaq faylları təyin edir. Veb server faylları sadalanan ardıcıllıqla yoxlayacaq. Əgər heç bir səhifə tələb olunmayıbsa, server bloku index.html faylını tapıb qaytaracaq. Əgər həmin faylı tapa bilmirsə, o, index.htm faylını emal etməyə çalışacaq.

server_name direktivi

server_name direktivi bu server blokunun xidmət göstərəcəyi domen adlarının siyahısını ehtiva edir. Domenlərin sayı məhdudiyyətsizdir; siyahıdakı domenlər boşluqlarla ayrılmalıdır.

Domenin əvvəlində və ya sonunda ulduz işarəsi (*) maskalı adı müəyyən edir, burada ulduz işarəsi adın bir hissəsinə (və ya bir neçə hissəsinə) uyğun gəlir. Məsələn, *.example.com adı forum.example.com və www.animals.example.com adlarına uyğun gəlir.

Əgər tələb olunan url birdən çox server_name direktivinə uyğun gəlirsə, o, əvvəlcə tam olaraq uyğun gələn ilə cavab verəcək.

Ünvan heç bir uyğunluq tapmasa, ən çox axtaracaq uzun ad ulduzla bitən maska ilə. Əgər belə bir ad tapmazsa, ilk normal ifadə uyğunluğunu qaytaracaq.

Normal ifadələrdən istifadə edən server adları tilde (~) ilə başlayır. Təəssüf ki, bu mövzu bu məqalənin əhatə dairəsi xaricindədir.

Məkan blokları

Məkan/sətir mötərizədə olan direktivlərin hər hansı digər yer bloklarına uyğun gəlməyən bütün tələb olunan resurslara tətbiq ediləcəyini göstərir.

Belə bloklarda uri yolu ola bilər (məsələn, /doc/). Yer və uri arasında tam uyğunluq yaratmaq üçün = simvolundan istifadə olunur. ~ simvolu müntəzəm ifadələrə uyğun gəlir.

Tilda hərflərə həssas rejimi işə salır, ulduz işarəsi olan tilde isə hərflərə həssas olmayan rejimi işə salır.

Əgər sorğu məkan blokuna tam uyğun gəlirsə, o zaman server axtarışı dayandırır və belə blokdan istifadə edir. Əgər server tam uyğun yer bloku tapmasa, o, URI-ni yer direktivlərinin parametrləri ilə müqayisə edir. Nginx ^~ simvol kombinasiyasından istifadə edən və URI-yə uyğun gələn blok seçəcək.

^~ seçimi istifadə edilmədikdə, Nginx ən yaxın uyğunluğu seçəcək və birinə uyğun gəlməyə çalışmaq üçün müntəzəm ifadə axtarışı həyata keçirəcək. mövcud şablonlar. Əgər belə bir ifadə tapsa, ondan istifadə edir. Əgər belə bir ifadə yoxdursa, server əvvəllər tapılmış URI uyğunluğundan istifadə edir.

Son qeyd olaraq, Nginx dəqiq uyğunluqlara üstünlük verir. Əgər belə uyğunluqlar yoxdursa, o, müntəzəm ifadə axtarır və sonra URI-də axtarış aparır. URI-nin axtarış prioritetini dəyişdirmək üçün ^~ simvol birləşməsindən istifadə edin.

try_files direktivi

try_files direktivi çox böyükdür faydalı alət, verilmiş qaydada faylları yoxlayır və sorğunu emal etmək üçün tapılan ilk fayldan istifadə edir.

Bu, Nginx-in sorğulara necə xidmət göstərəcəyini müəyyən etmək üçün əlavə parametrlərdən istifadə etməyə imkan verir.

Standart konfiqurasiya faylında xətt var:

try_files $uri $uri/ /index.html;

Bu o deməkdir ki, bir yer bloku tərəfindən xidmət edilən sorğu qəbul edildikdə, Nginx əvvəlcə uri-yə fayl kimi xidmət etməyə çalışacaq (bu davranış $uri dəyişəni ilə müəyyən edilir).

Server $uri dəyişəni üçün uyğunluq tapmasa, o, uri-ni kataloq kimi istifadə etməyə çalışacaq.

Arxadakı kəsik işarəsindən istifadə edərək, server kataloqun mövcudluğunu yoxlayır, məsələn, $uri/.

Heç bir fayl və ya qovluq tapılmazsa, Nginx standart faylı (in bu halda bu server blokunun kök kataloqunda index.html). Hər try_files direktivi ehtiyat kimi sonuncu parametrdən istifadə edir, ona görə də fayl sistemdə mövcud olmalıdır.

Veb server əvvəlki parametrlərdə uyğunluq tapmadıqda, xəta səhifəsini qaytara bilər. Bunu etmək üçün bərabər işarədən və səhv kodundan istifadə edin.

Məsələn, əgər yer/blok tələb olunan resursu tapa bilmirsə, o, index.html faylı əvəzinə 404 xətası qaytara bilər:

try_files $uri $uri/ =404;

Bunun üçün bərabər işarə qoymalı və səhv kodunu sonuncu parametr kimi təyin etməlisiniz (=404).

Əlavə seçimlər

Təxəllüs direktivi Nginx-ə verilmiş kataloqdan kənarda (məsələn, kökdən kənarda) yer bloku səhifələrinə xidmət etməyə imkan verir.

Məsələn, /doc/ ünvanından tələb olunan fayllar /usr/share/doc/ ünvanından təqdim olunacaq.

Direktiv üzrə autoindex sizə verilmiş yer direktivi üçün Nginx qovluqlarının siyahısını aktivləşdirməyə imkan verir.

İcazə və rədd xətləri kataloqlara girişi idarə edir.

Nəticə

Veb Nginx server xüsusiyyətlərlə zəngin və çox məhsuldardır, lakin onun terminologiyası və variantları çaşdırıcı ola bilər.

Nginx konfiqurasiyalarını başa düşdükdən və onlarla işləməyi öyrəndikdən sonra bu güclü və yüngül alətin bütün üstünlüklərini əldə edəcəksiniz.

Etiketlər: ,

Mövzu düzdür nginx parametrləriÇox böyükdür və qorxuram ki, Habré haqqında bir məqalənin çərçivəsinə sığmır. Bu mətndə danışmağa çalışdım ümumi quruluş konfiqurasiya, daha maraqlı kiçik şeylər və detallar sonra gələ bilər. :)

Nginx qurmaq üçün yaxşı başlanğıc nöqtəsi paylama ilə birlikdə gələn konfiqurasiyadır, lakin bu serverin bir çox imkanları hətta orada qeyd olunmur. Daha çox ətraflı nümunəİqor Sysoevin saytında mövcuddur: sysoev.ru/nginx/docs/example.html. Bununla belə, gəlin konfiqurasiyamızı sıfırdan, körpü və şairələrlə qurmağa çalışaq. :)

ilə başlayaq ümumi parametrlər. Əvvəlcə nginx-in adından işləyəcəyi istifadəçini göstərəcəyik (root kimi işləmək pisdir, hamı bilir :))

İndi nginx-ə nə qədər işçi prosesinin kürü verməsini söyləyək. Adətən, yaxşı seçim sayına bərabər bir sıra proseslər var prosessor nüvələri serverinizdə, lakin bu parametrlə sınaqdan keçirməyə dəyər. Gözlənilirsə yüksək yük haqqında sabit disk, siz hər bir fiziki sabit disk üçün bir proses edə bilərsiniz, çünki bütün işlər hələ də onun performansı ilə məhdudlaşacaq.

İşçi_prosesləri 2;

Səhv qeydlərinin hara yazılacağını aydınlaşdıraq. Sonra fərdi virtual serverlər, bu parametr ləğv edilə bilər ki, bu jurnalda yalnız "qlobal" səhvlər, məsələn, serverin işə salınması ilə bağlı görünəcək.

Error_log /spool/logs/nginx/nginx.error_log bildirişi; # "Xəbərdarlıq" bildiriş səviyyəsi, əlbəttə ki, dəyişdirilə bilər

İndi çox maraqlı "hadisələr" bölməsi gəlir. Bunun içində siz təyin edə bilərsiniz maksimum miqdar bir işçi prosesinin eyni vaxtda işləyəcəyi bağlantılar və ƏS-də hadisələr haqqında asinxron bildirişlər almaq üçün istifadə olunacaq üsul. Əlbəttə ki, siz yalnız OS-də mövcud olan və tərtib zamanı daxil edilmiş metodları seçə bilərsiniz.

Bu parametrlər serverinizin performansına əhəmiyyətli təsir göstərə bilər. Onlar OS və aparatdan asılı olaraq fərdi olaraq seçilməlidir. Mən yalnız bir neçə ümumi qayda verə bilərəm.

Hadisələrlə işləmək üçün modullar:
- seç və sorğu adətən daha yavaş olur və prosessoru kifayət qədər yükləyir, lakin onlar demək olar ki, hər yerdə mövcuddur və demək olar ki, həmişə işləyir;
- kqueue və epoll - daha səmərəli, lakin müvafiq olaraq yalnız FreeBSD və Linux 2.6-da mövcuddur;
- rtsig - gözəl təsirli üsul, və hətta çox köhnə Linux-lar tərəfindən dəstəklənir, lakin zaman problem yarada bilər çox saydaəlaqələr;
- /dev/poll - bildiyim qədər, bir az daha çox işləyir ekzotik sistemlər, Solaris kimi və bunda olduqca effektivdir;

işçi_əlaqələri parametri:
- Xidmət edilən müştərilərin ümumi maksimum sayı işçi_proseslərinə * işçi_əlaqələrinə bərabər olacaq;
- Bəzən işləyə bilirlər müsbət tərəfi hətta ən ekstremal dəyərlər, məsələn, 128 proses, hər prosesə 128 əlaqə və ya 1 proses, lakin worker_connections=16384 parametri ilə. Lakin ikinci halda, çox güman ki, OS-ni tənzimləməli olacaqsınız.

Tədbirlər (
işçi_əlaqələri 2048;
kqueue istifadə edin; # BSD var :)
}

Növbəti bölmə ən böyükdür və ən maraqlı şeyləri ehtiva edir. Bu, virtual serverlərin təsviri və onların hamısı üçün ümumi olan bəzi parametrlərdir. Mən buraxacağam standart parametrlər jurnallara gedən yollar kimi hər konfiqurasiyada olan .

Http(
# Aşağıdakı bütün kodlar bu bölmənin içində olacaq %)
# ...
}

Bu bölmənin içərisində olduqca maraqlı parametrlər ola bilər.

Sendfile sistem çağırışı Linux üçün nisbətən yenidir. O, məlumatı proqramın ünvan sahəsinə köçürmədən şəbəkəyə göndərməyə imkan verir. Bir çox hallarda bu, server performansını əhəmiyyətli dərəcədə yaxşılaşdırır, ona görə də həmişə göndərmə faylı seçimini aktivləşdirmək ən yaxşısıdır.

keepalive_timeout parametri cavabdehdir maksimum vaxt istifadəçi onun vasitəsilə heç bir şey tələb etmədiyi təqdirdə davamlı əlaqənin saxlanması. Saytınızın sorğuları necə göndərdiyini nəzərdən keçirin və bu ayarı tənzimləyin. AJAX-dan aktiv istifadə edən saytlar üçün istifadəçilərin uzun müddət oxuyacağı statik səhifələr üçün əlaqəni daha uzun saxlamaq daha yaxşıdır, əlaqəni erkən kəsmək daha yaxşıdır; Nəzərə alın ki, qeyri-aktiv saxlama əlaqəsini saxlamaqla siz fərqli şəkildə istifadə oluna biləcək bir əlaqə əldə edirsiniz. :)

Keepalive_timeout 15;

Ayrıca, nginx proxy parametrlərini vurğulamağa dəyər. Çox vaxt nginx proksi server kimi dəqiq istifadə olunur, buna görə də onlar kifayət qədərdir böyük dəyər. Xüsusilə, proxy sorğular üçün bufer ölçüsünü backend serverindən gözlənilən cavab ölçüsündən az olmayaraq təyin etmək məna kəsb edir. Yavaş (və ya əksinə, çox sürətli) arxa uçlarla, arxa hissədən cavab gözləmək üçün fasilələri dəyişdirmək məna kəsb edir. Yadda saxlayın ki, bu fasilələr nə qədər uzun olarsa, backend yavaş olarsa, istifadəçiləriniz bir o qədər çox cavab gözləyəcək.

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

Bir az hiylə. Nginx birdən çox virtual hosta xidmət edərsə, server müştəri sorğusunda Host başlığından istifadə edərək başqa alternativ tapa bilmədiyi hallarda sorğuları emal edəcək “defolt virtual host” yaratmaq məqsədəuyğundur.

# default virtual host
server (
qulaq asmaq 80 default;
server_name localhost;
hamısını inkar etmək;
}

Bundan sonra bir (və ya bir neçə) “server” bölməsi ola bilər. Onların hər biri virtual hostu təsvir edir (əksər hallarda ad əsasında). Bir hostinqdə bir çox saytın sahibləri və ya hosterlər üçün direktiv kimi bir şey ola bilər

/spool/users/nginx/*.conf;

Qalanları çox güman ki, virtual hostlarını birbaşa əsas konfiqurasiyada təsvir edəcəklər.

server (
qulaq asmaq 80;

# Nəzərə alın ki, server_name direktivi eyni anda bir neçə ad təyin edə bilər.
server_name myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log vaxtı təyin olundu;
error_log /spool/logs/nginx/myserver.error_log xəbərdarlıq;
# ...

Gəlin çıxış üçün standart kodlaşdırmanı təyin edək.

Charset utf-8;

Və deyək ki, uzunluğu 1 meqabaytdan çox olan müştərilərin sorğularını qəbul etmək istəmirik.

Müştəri_maksimum_bədən_ölçüsü 1m;

Gəlin server üçün SSI-ni aktiv edək və SSI dəyişənləri üçün 1 kilobaytdan çox olmayan rezerv tələb edək.

Si on;
ssi_value_length 1024;

Və nəhayət, iki yeri təsvir edəcəyik, bunlardan biri arxa hissəyə, 9999 portunda işləyən Apache-yə, ikincisi isə yerli şəbəkədən statik şəkillər göndərəcək. fayl sistemi. İki yer üçün bunun mənası azdır, lakin onların daha çoxu üçün serverin kök kataloqunun saxlanacağı dəyişəni dərhal müəyyən etmək və sonra onu yer təsvirlərində istifadə etmək də məna kəsb edir.

14 avqust 2009-cu il, saat 19:29

Nginx qurulması

Nginx

Mövzu düzgün parametrlər nginx çox böyükdür və qorxuram ki, Habré-dəki bir məqalənin çərçivəsinə uyğun gəlmir. Bu mətndə konfiqurasiyanın ümumi quruluşu haqqında danışmağa çalışdım, daha maraqlı detallar və detallar sonra gələ bilər; :)

Nginx qurmaq üçün yaxşı başlanğıc nöqtəsi paylama ilə birlikdə gələn konfiqurasiyadır, lakin bu serverin bir çox imkanları hətta orada qeyd olunmur. Daha ətraflı nümunə İqor Sysoevin saytındadır: sysoev.ru/nginx/docs/example.html. Ancaq gəlin, konfiqurasiyamızı sıfırdan, körpü və şairələrlə qurmağa çalışaq. :)

Ümumi parametrlərdən başlayaq. Əvvəlcə nginx-in adından işləyəcəyi istifadəçini göstərəcəyik (root kimi işləmək pisdir, hamı bilir :))

İndi gəlin nginx-ə neçə işçi prosesinin kürü verməsini söyləyək. Tipik olaraq, serverinizdəki prosessor nüvələrinin sayına bərabər olan bir sıra proseslər yaxşı seçimdir, lakin bu parametrlə sınaqdan keçirməyə dəyər. Sabit diskdə yüksək yük gözlənilirsə, hər bir fiziki sabit disk üçün bir proses edə bilərsiniz, çünki bütün işlər hələ də onun performansı ilə məhdudlaşacaq.

İşçi_prosesləri 2;

Səhv qeydlərinin hara yazılacağını aydınlaşdıraq. Sonra fərdi virtual serverlər üçün bu parametr ləğv edilə bilər ki, bu jurnalda yalnız "qlobal" səhvlər, məsələn, serverin işə salınması ilə bağlı görünəcək.

Error_log /spool/logs/nginx/nginx.error_log bildirişi; # "Xəbərdarlıq" bildiriş səviyyəsi, əlbəttə ki, dəyişdirilə bilər

İndi çox maraqlı "hadisələr" bölməsi gəlir. Orada bir işçi prosesinin eyni vaxtda işləyəcəyi maksimum əlaqə sayını və OS-dəki hadisələr haqqında asinxron bildirişlər almaq üçün istifadə ediləcək metodu təyin edə bilərsiniz. Əlbəttə ki, siz yalnız OS-də mövcud olan və tərtib zamanı daxil edilmiş metodları seçə bilərsiniz.

Hadisələrlə işləmək üçün modullar:
- seç və sorğu adətən daha yavaş olur və prosessoru kifayət qədər yükləyir, lakin onlar demək olar ki, hər yerdə mövcuddur və demək olar ki, həmişə işləyir;
- kqueue və epoll - daha səmərəli, lakin müvafiq olaraq yalnız FreeBSD və Linux 2.6-da mövcuddur;
- rtsig kifayət qədər təsirli bir üsuldur və hətta çox köhnə Linux-lar tərəfindən dəstəklənir, lakin çox sayda əlaqə ilə problemlər yarada bilər;
- /dev/poll - bildiyim qədər, o, Solaris kimi bir qədər daha ekzotik sistemlərdə işləyir və orada kifayət qədər effektivdir;

işçi_əlaqələri parametri:
- Xidmət edilən müştərilərin ümumi maksimum sayı işçi_proseslərinə * işçi_əlaqələrinə bərabər olacaq;
- Bəzən hətta ən ekstremal dəyərlər də müsbət işləyə bilər, məsələn, 128 proses, hər bir proses üçün 128 əlaqə və ya 1 proses, lakin worker_connections=16384 parametri ilə. Lakin ikinci halda, çox güman ki, OS-ni tənzimləməli olacaqsınız.

Tədbirlər (
işçi_əlaqələri 2048;
kqueue istifadə edin; # BSD var :)
}

Növbəti bölmə ən böyükdür və ən maraqlı şeyləri ehtiva edir. Bu, virtual serverlərin təsviri və onların hamısı üçün ümumi olan bəzi parametrlərdir. Hər konfiqurasiyada olan standart parametrləri, məsələn, qeydlərə gedən yolları buraxacağam.

Http(
# Aşağıdakı bütün kodlar bu bölmənin içində olacaq %)
# ...
}

Bu bölmənin içərisində olduqca maraqlı parametrlər ola bilər.

Keepalive_timeout parametri istifadəçi heç bir şey tələb etmədiyi halda, saxlama bağlantısını saxlamaq üçün maksimum vaxt üçün cavabdehdir. Saytınızın sorğuları necə göndərdiyini nəzərdən keçirin və bu ayarı tənzimləyin. AJAX-dan aktiv istifadə edən saytlar üçün, istifadəçilərin uzun müddət oxuyacağı statik səhifələr üçün əlaqəni daha uzun saxlamaq daha yaxşıdır, əlaqəni erkən kəsmək daha yaxşıdır; Nəzərə alın ki, qeyri-aktiv saxlama əlaqəsini saxlamaqla siz fərqli şəkildə istifadə oluna biləcək bir əlaqə əldə edirsiniz. :)

Keepalive_timeout 15;

Ayrıca, nginx proxy parametrlərini vurğulamağa dəyər. Çox vaxt nginx bir proxy server kimi istifadə olunur, buna görə də onlar olduqca vacibdir. Xüsusilə, proxy sorğular üçün bufer ölçüsünü backend serverindən gözlənilən cavab ölçüsündən az olmayaraq təyin etmək məna kəsb edir. Yavaş (və ya əksinə, çox sürətli) arxa uçlarla, arxa hissədən cavab gözləmək üçün fasilələri dəyişdirmək məna kəsb edir. Yadda saxlayın ki, bu fasilələr nə qədər uzun olarsa, backend yavaş olarsa, istifadəçiləriniz bir o qədər çox cavab gözləyəcək.

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

# default virtual host
server (
qulaq asmaq 80 default;
server_name localhost;
hamısını inkar etmək;
}

/spool/users/nginx/*.conf;

Qalanları çox güman ki, virtual hostlarını birbaşa əsas konfiqurasiyada təsvir edəcəklər.

server (
qulaq asmaq 80;

Gəlin çıxış üçün standart kodlaşdırmanı təyin edək.

Charset utf-8;

Və deyək ki, uzunluğu 1 meqabaytdan çox olan müştərilərin sorğularını qəbul etmək istəmirik.

Müştəri_maksimum_bədən_ölçüsü 1m;

Gəlin server üçün SSI-ni aktiv edək və SSI dəyişənləri üçün 1 kilobaytdan çox olmayan rezerv tələb edək.

Si on;
ssi_value_length 1024;

Və nəhayət, iki yeri təsvir edəcəyik, onlardan biri 9999 portunda işləyən Apache-yə, ikincisi isə yerli fayl sistemindən statik şəkillər göndərəcək. İki yer üçün bunun mənası azdır, lakin onların daha çox hissəsi üçün serverin kök kataloqunun saxlanacağı dəyişəni dərhal müəyyən etmək və sonra onu yer təsvirlərində istifadə etmək də məna kəsb edir.

Ən populyar veb serverlərdən biridir

Nginx performansına görə veb və proxy server istifadəçiləri arasında çox populyardır. Serverin bir çox üstünlükləri var, lakin onu qurmaq yeni başlayanlar üçün çətin olacaq. Biz sizə konfiqurasiya fayllarını, sintaksisi və əsas Nginx parametrlərinin qurulmasını başa düşməyinizə kömək etmək istəyirik.

Kataloq iyerarxiyası

Bütün server konfiqurasiya faylları /etc/nginx kataloqunda yerləşir. Bundan əlavə, kataloq daxilində daha bir neçə qovluq, həmçinin modul konfiqurasiya faylları yerləşir.

cd /etc/nginx
ls -F
conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

Əgər siz Apache-dən istifadə etmisinizsə, saytların aktivləşdirdiyi və saytların mövcud kataloqları ilə tanış olmalısınız. Onlar saytların konfiqurasiyasını müəyyənləşdirirlər. Yaradılmış fayllar sonuncu kataloqda saxlanılır. Saytların aktivləşdirdiyi qovluq yalnız konfiqurasiyaları saxlamaq üçün lazımdır aktivləşdirilmiş səhifələr. Onları birləşdirmək üçün sizə lazımdır simvolik əlaqə qovluqlar arasında. Konfiqurasiyalar həmçinin conf.d kataloqunda saxlanıla bilər. Eyni zamanda, Nginx işə salınması zamanı .conf uzantılı hər bir fayl yenidən oxunacaq. Konfiqurasiya fayllarını yazarkən kodu səhvsiz yazın və sintaksisə əməl edin. Bütün digər fayllar /etc/nginx-də yerləşir. Konfiquratorda xüsusi proseslər, həmçinin əlavə komponentlər haqqında məlumatlar var.

Əsas Nginx konfiqurasiya faylı nginx.conf-dir.

O, bütün konfiqurasiya fayllarını oxuyur, onları server işə salındıqda tələb olunan birinə birləşdirir. Faylı aşağıdakılarla açın:

sudo nano /etc/nginx/nginx.conf

Ekranda aşağıdakı sətirlər görünəcək:

istifadəçi www-data;
işçi_prosesləri 4;
pid /var/run/nginx.pid;
hadisələr (
işçi_əlaqələri 768;
#multi_accept aktivdir;
}
http(
. . .

Birincisi, Nginx haqqında ümumi məlumatdır. İstifadəçi www-data ifadəsi serveri idarə edən istifadəçini göstərir. pid direktivi daxili istifadə üçün PID proseslərinin harada yerləşdiyini göstərir. Worker_processes sətri Nginx-in eyni vaxtda neçə prosesi işlədə biləcəyini göstərir. Bundan əlavə, burada qeydləri təyin edə bilərsiniz (məsələn, xəta jurnalı error_log direktivindən istifadə etməklə müəyyən edilir). Aşağıda hadisələr bölməsidir. Bu server bağlantılarını idarə etmək üçün lazımdır. Bundan sonra http bloku.

Nginx konfiqurasiya fayl strukturu

Fayl formatlama strukturunu anlamaq sizə veb server konfiqurasiyanızı daha yaxşı başa düşməyə kömək edəcək. Struktur bloklara bölünür. Http blokunun konfiqurasiya təfərrüatları şəxsi bloklardan istifadə edilərək laylılaşdırılır. Onlar əmlakı valideyndən miras alırlar, yəni. onların yerləşdiyi yer. Bu blok server konfiqurasiyalarının əksəriyyətini saxlayır. Onlar server bloklarına bölünür, içərisində hansı yerdir.

Nginx serverini konfiqurasiya edərkən yadda saxlayın ki, konfiqurasiya bloku nə qədər aşağı olarsa, bir o qədər az element xassələri miras alacaq və əksinə. Fayl ehtiva edir çox sayda serverin işini dəyişən seçimlər. Məsələn, müştəriyə göndərilən fayllar üçün sıxılma təyin edə bilərsiniz. Bunu etmək üçün parametrləri daxil edin:

gzip açıq;
gzip_disable "msie6";

Unutmayın ki, eyni parametr qəbul edilə bilər müxtəlif mənalar V müxtəlif bloklar. Əvvəlcə onu yuxarıya qoyun, sonra parametri istədiyiniz səviyyədə yenidən təyin edin. Əgər son hərəkət icra edilmədikdə, proqram avtomatik olaraq dəyərləri təyin edəcəkdir.

Nginx.conf faylının son sətirləri bunlardır:

daxildir /etc/nginx/conf.d/*.conf;
/etc/nginx/sites-enabled/* daxil edin;

Onlar yerin və server bloklarının bu fayldan kənarda saxlandığını göstərir. Onlar URL parametrlərini müəyyən edir və xüsusi fayllar. Bu struktur modul konfiqurasiya strukturunu saxlamaq üçün lazımdır. Onun daxilində müxtəlif saytlar üçün yeni kataloqlar və fayllar yarada bilərsiniz. Bundan əlavə, oxşar faylları qruplaşdıra bilərsiniz. Baxdıqdan sonra nginx.conf faylını bağlaya bilərsiniz.

Virtual bloklar

Onlar Apache-dəki virtual hostlara bənzəyirlər. Server bölmə bloklarına serverdə yerləşən ayrı-ayrı saytların xüsusiyyətləri daxildir. Saytların mövcud qovluğunda siz standart server blok faylını tapa bilərsiniz. Bunun içərisində saytları saxlayarkən tələb oluna biləcək lazımi məlumatları tapa bilərsiniz.

cd saytları mövcuddur
sudo nano default
server(
root /usr/share/nginx/www;
indeks index.html index.htm;
server_name localhost;
yer/(
try_files $uri $uri/ /index.html;
}
yer /sənəd/ (
ləqəb /usr/share/doc/;
autoindex aktivdir;
icazə 127.0.0.1;
hamısını inkar etmək;
}
}

Yuxarıdakı misalda şərhlər qəsdən silinmişdir. Bu, qavrayış asanlığı üçün edilib. Server bloklarının içərisində əyri mötərizələrə daxil edilmiş parametrlər var:

Bu blok nginx.conf faylında yazılmış http-nin sonundakı daxiletmə direktivindən istifadə etməklə yerləşdirilir. Kök direktivi sayt məzmununun yerləşəcəyi qovluğu müəyyənləşdirir. Orada proqram istifadəçinin tələb edəcəyi faylları axtaracaq. Standart yol: /usr/share/nginx/www. Nginx nöqtəli vergüllərdən istifadə edərək xətləri və ya direktivləri bir-birindən ayırır. Durğu işarəsi qoymasanız, bir neçə sətir bir kimi oxunacaq. İndeks kimi istifadə olunacaq qaydaları müəyyən etmək üçün indeks direktivindən istifadə edin. Server onları sadalanan ardıcıllıqla yoxlayacaq. Mövcud səhifələrdən heç biri istifadəçi tərəfindən tələb olunmayıbsa, index.html qaytarılacaq. Əgər orada deyilsə, server index.htm axtaracaq.

server_adı qaydası

O, server blokunun emal etməli olduğu domen adlarının siyahısını ehtiva edir. Siz onların istənilən sayını boşluqlarla ayıraraq daxil edə bilərsiniz. Domenin sonuna və ya əvvəlinə * qoysanız, maskalı bir ad təyin edə bilərsiniz. Ulduz işarəsi adın bir hissəsinə uyğun gəlir. *.com.ua daxil etsəniz, bu, göstərilən bütün ünvanları əhatə edəcəkdir domen zonası. Ünvan bir neçə direktivin təsvirinə uyğundursa, o, tam uyğun gələnə cavab verəcəkdir. Uyğunluq yoxdursa, cavab maskası olan ən uzun ad olacaq. Əks halda, müntəzəm ifadə uyğunluğu həyata keçiriləcək. Normal ifadələrdən istifadə edən server adları tilde (~) ilə başlayır.

Məkan blokları

Növbəti sırada yer blokumuz olacaq. Emal üsulunu müəyyən etmək lazımdır müəyyən tələblər. Resurslar hər hansı digər yer bloklarına uyğun gəlmirsə, mötərizədə göstərilən direktivlər onlara tətbiq olunacaq. Bu bloklara /doc/ kimi bir yol daxil ola bilər. Uri və yer arasında tam uyğunluq yaratmaq üçün = işarəsi istifadə olunur. Tild işarəsindən istifadə etməklə siz normal ifadələri uyğunlaşdıra bilərsiniz. Siz həmçinin ~ qoyaraq hərf həssaslığını təyin edə bilərsiniz. Ulduz işarəsi əlavə etsəniz, hərflərin əhəmiyyəti olmayacaq.

Nəzərə alın: sorğu yer blokuna tam uyğun gələndə ondan istifadə olunacaq və axtarış dayandırılacaq. Uyğunluq natamam olduqda, URI yer direktivlərinin parametrləri ilə müqayisə ediləcək. Bloku seçmək üçün URI-yə uyğun ^~ olan blokdan istifadə edin. Əgər bu seçim istifadə edilmirsə, server optimal uyğunluğu seçir və həmçinin istifadə edərək axtarış aparır müntəzəm ifadələr. Bu, uyğun şablonlardan birini seçmək üçün lazımdır. Əgər uyğun ifadə tapılarsa, ondan istifadə olunacaq. Əks halda, əvvəlki URI uyğunluğu tətbiq olunacaq. Ancaq unutmayın ki, Nginx tam uyğunluqlara üstünlük verir. Əgər onlar orada deyilsə, o, müntəzəm ifadələri, sonra isə URI ilə axtarmağa başlayacaq. Axtarış pariteti ^~ simvol birləşməsi ilə müəyyən edilir.

try_files qaydası

Bu, faylları yoxlaya bilən çox faydalı bir vasitədir müəyyən edilmiş qaydada. Sorğunu emal etmək üçün meyarlara uyğun gələn birincidən istifadə edir. istifadə edə bilərsiniz əlavə seçimlər serverin sorğulara necə xidmət edəcəyini müəyyən etmək üçün. Konfiquratorda bu standart xətt var:

try_files $uri $uri/ /index.html;

Bu nə deməkdir? Məkan bloku tərəfindən təqdim olunan sorğu daxil olarsa, server əvvəlcə uri-ni fayl kimi qəbul etməyə çalışacaq. Bu, $uri dəyişəni tərəfindən təmin edilir. Heç bir uyğunluq olmadıqda, uri kataloq kimi qəbul ediləcək. Ardınca slash işarəsi əlavə etməklə onun mövcudluğunu yoxlaya bilərsiniz: $uri/. Nə faylın, nə də kataloqun tapılmadığı vəziyyətlər var. Bu halda, standart fayl yüklənəcək - index.html. try_files qaydası son parametrdən ehtiyat kimi istifadə edir. Buna görə bu fayl sistemdə olmalıdır. Bununla belə, heç bir uyğunluq tapılmazsa, Nginx səhv səhifəsini qaytaracaq. Onu təyin etmək üçün = və xəta kodunu daxil edin:

Əlavə seçimlər

Əgər ləqəb qaydasını tətbiq etsəniz, məsələn, kök kataloqdan kənarda yer blokunun səhifələrinə xidmət göstərə biləcəksiniz. Sənəddən fayllar lazım olduqda, onlar /usr/share/doc/ ünvanından tələb olunacaq. Bundan əlavə, qayda üzrə autoindex müəyyən edilmiş yer direktivi üçün server qovluqlarını siyahıya salmağa başlayır. Əgər inkar və icazə sətirlərini yazsanız, kataloqlara girişi dəyişdirə biləcəksiniz.

Nəticə olaraq, Nginx-in çox güclü olduğunu söyləməyə dəyər çoxfunksiyalı alət. Ancaq onun iş prinsipini yaxşı başa düşmək üçün vaxt və səy tələb olunur. Konfiqurasiyaların necə işlədiyini başa düşsəniz, proqramın bütün xüsusiyyətlərindən tam istifadə edə bilərsiniz.