Nginx: налада і ўстаноўка

Што такое apache, nginx? Прызначэнне, асаблівасці, варыянты налад - гэта рэчы, з якімі павінен быць азнаёмлены кожны вэб-распрацоўшчык, каб тэставаць свае напрацоўкі.

Аб nginx замовіць слова

Дадзены інструмент валодае адным галоўным і некалькімі працоўнымі працэсамі. Першы займаецца чытаннем і праверкай канфігурацыі. Таксама пад яго кантролем знаходзіцца кіраванне працоўнымі працэсамі. Задача апошніх - апрацоўваць паступаюць запыты. У nginx ўжываецца мадэль, што грунтуецца на падзеях. Таксама выкарыстоўваюцца механізмы, залежныя ад аперацыйнай сістэмы, каб дамагчыся эфектыўнага размеркавання запытаў непасрэдна паміж працоўнымі працэсамі. Іх колькасць заўсёды пазначана ў канфігурацыйным файле. Значэнне можа быць як фіксаваным, так і ўсталёўвацца аўтаматычна, арыентуючыся па ліку працэсарных ядраў, з якімі можна працаваць. У nginx налада сістэмы і модуляў праводзіцца з дапамогай канфігурацыйнага файла. Таму, калі трэба нешта змяніць, то шукаць неабходна менавіта яго. Звычайна ён знаходзіцца ў дырэктыве / etc / nginx (але шлях можа мяняцца пры выкарыстанні іншых сістэм) і мае пашырэнне .conf.

Запуск, перазагрузка і логі

Для гэтага неабходна прымусіць працаваць выкананы файл. Настройка nginx-сервера магчымая, толькі калі ён запушчаны. Кіраванне ажыццяўляецца дзякуючы выкліку выкананага файла з параметрам -s. Для гэтага выкарыстоўвайце такі запіс:

nginx -s сігнал

У дадзеным выпадку падстаўляць можна такія каманды (павінны паступаць ад карыстальніка, што запусціў інструмент):

1. Stop. Выкарыстоўваецца для хуткага завяршэння працы.
2. Reload. Каманда неабходная, каб перазагрузіць канфігурацыйны файл. Справа ў тым, што любыя змены не будуць ужытыя, пакуль файл працуе. І каб яны ўступілі ў сілу, неабходная перазагрузка. Як толькі будзе атрыманы гэты сігнал, галоўны працэс пачне правяраць правільнасць сінтаксічнай складнікам канфігурацыйнага файла і паспрабуе ўжыць наяўныя там ўказанні. У выпадку няўдачы ён адкаціць змены і будзе працаваць са старымі параметрамі. Калі ўсё адбылося паспяхова, то будуць запушчаныя новыя працоўныя працэсы, а старым будзе адпраўлена патрабаванне завяршыцца.
3. Quit. Ўжываецца для плыўнага завяршэння працы. Прымяняецца, калі неабходна пачакаць, пакуль скончаць абслугоўвацца бягучыя запыты.
4. Reopen. Зачыніць і адкрыць лог-файлы.

выкарыстанне утыліт

Настройка працэсаў можа ажыццяўляцца таксама з дапамогай сродкаў Unix (у якасці прыкладу будзе разгледжана ўтыліта kill). Звычайна яны выкарыстоўваюць механізм адпраўкі працэсу сігналу напрамую з дадзенымі. Ўвязваюцца яны з дапамогай ID. Гэтыя дадзеныя захоўваюцца ў файле nginx.pid. Дапусцім, што нас цікавіць працэс №134. Тады для плыўнага завяршэння нам неабходна адправіць наступную інфармацыю:

kill -s QUIT 1628

Дапусцім, што мы хочам паглядзець сьпіс усіх запушчаных файлаў. Выкарыстоўваем для гэтага ўтыліту ps. Каманда жа будзе выглядаць наступным чынам:

ps -ax | grep nginx

Гэта значыць, як бачыце, пры выкарыстанні дадатковага інструментара паказваецца, што ідзе менавіта яго прымяненне. А цяпер давайце сканцэнтруемся на тым, як здзяйсняецца nginx-налада.

Структура канфігурацыйнага файла

Ўстаноўка і настройка nginx прадугледжвае працу з модулямі. Яны наладжваюцца з дапамогай дырэктыў, якія паказваюцца ў канфігурацыйным файле. Яны бываюць простымі і блокавымі. Першы тып дырэктыў складаецца з імя і параметраў, якія падзяляюцца з дапамогай прабелаў, а іх канец паказваецца кропкай з коскі - (;). Блочная мае падобнае будынак. Але ў дадзенай дырэктыве замест заканчэння размяшчаецца набор дадатковых інструкцый, якія размяшчаюць у фігурных клямках ({ўказанні}). Калі ў іх можна размясціць імёны і параметры іншых працэсаў, то называюцца такія канструкцыі ўжо кантэкстам. У якасці прыкладу можна прывесці http, location і server.

Раздача статычнага змесціва

Гэта адна з самых важных задач, якая стаіць перад канфігурацыяй nginx. Пад раздачай статыстычнага змесціва маюць на ўвазе выявы і HTML-старонкі (не дынамічныя). Дапусцім, што нам патрэбна разавая праца па наладзе nix nginx кластара. Ці складана гэта зрабіць? Няма, і давайце разгледзім прыклад. Перш чым прыступаць да яго, неабходна дэталізаваць ўмовы задачы. Так, у залежнасці ад запытаў, файлы будуць ісці з розных лакальных каталогаў. Так, у / data / www мы маем HTML-дакументы. А ў каталогу / data / images падаюцца здымкі. Аптымальная налада nginx у дадзеным выпадку патрабуе рэдагавання канфігурацыйнага файла, у якім неабходна наладзіць блок server ўнутры http. Для падтрымкі будзе выкарыстоўвацца таксама два location.

Рэалізацыя: server

Такім чынам, для пачатку нам неабходна стварыць самі каталогі і размясціць у іх файлы з неабходнымі пашырэннямі (у html неабходна дадаць змесціва). Затым адкрываем канфігурацыйны файл. У ім па змаўчанні ўжо ёсць некалькі блокаў server, якія ў масе сваёй закаментаваны. Каб дамагчыся аптымальнага выніку, гэты працэс неабходна прарабіць у адносінах да ўсіх складнікам па змаўчанні. Затым дадаем новы блок server з дапамогай такога кода:

http {

server {

}

}

Канфігурацыйны файл можа працаваць з некалькімі такімі блокамі. Але яны павінны адрознівацца сваімі імёнамі і партамі, з дапамогай якіх адбываецца атрыманне дадзеных.

Рэалізацыя: location

Вызначаецца ўнутры server:

location / {

root / data / www;

}

Наяўнасць знака «/» неабходна, каб параўноўваць атрымоўваныя дадзеныя і глядзець, ці ёсць такі адрас з апрацаванага запыту тут. Калі ніякіх праблем няма, то паказваем шлях / data / www да неабходнага файлу, што знаходзіцца ў дадзенай лакальнай сістэме. Калі супадзенне ёсць з некалькімі блокамі, то выбіраецца той, у якога самы доўгі прэфікс. У прыкладзе прыкладзе яго даўжыня складае адзінкі, гэта значыць выкарыстанне будзе толькі ў тым выпадку, калі няма «канкурэнтаў». Зараз давайце яго ўдасканалім:

location / images / {

root / data;

}

Як можаце вызначыць, шукаем мы малюнка. А цяпер давайце сумяшчальны ўсе напрацоўкі, якія былі раней, і канфігурацыя на дадзены момант выглядае наступным чынам:

server {

location / {

root / data / www;

}

location / images / {

root / data;

}

}

Гэта рабочы варыянт, які злучвае стандартны порт №80. Гэты сервер без праблем можа быць даступны на лакальным кампутары, калі прайсці па адрасе: http: // localhost /. Як жа гэта ўсё будзе працаваць?

Прынцып функцыянавання прыкладу

Такім чынам, калі прыйдуць запыты, што пачынаюцца з с / images, то серверам файлы з адпаведнага каталога будуць адпраўляцца карыстальніку. Пры яго адсутнасці будзе перададзена інфармацыя, якая ўказвае на памылку 404. Калі праводзіцца настройка nginx на лакальным кампутары, то пры запыце http: //localhost/images/example.png намі будзе атрыманы файл, месцазнаходжанне якога /data/images/example.png. Пры ўказанні аднаго знака «/» пошук будзе праводзіцца ў дырэкторыі / data / www. Але мы толькі змянілі канфігурацыю. Каб яна пачала працаваць, яе неабходна перазагрузіць. Для гэтага выкарыстоўвайце каманду nginx -s reload. У выпадку калі нармальная праца не з'яўляецца магчымай, то ў файлах error.log і access.log, размешчаных у дырэктыве / usr / local / nginx / logs, вы зможаце пашукаць прычыну няспраўнасцяў.

Стварэнне простага проксі-сервера

Можна сказаць адносна nginx - налада дадзенага аб'екта з'яўляецца адным з частых ужыванняў (і даволі лёгкім, між іншым). Тут выкарыстоўваецца прынцып сервера, які прымае запыт, а потым ажыццяўляе перанакіраванне іх да неабходных сайтаў. Пасля гэтага чакаецца адказ ад іх, які накіроўвае іх да таго, хто паставіў задачу. Таму давайце разгледзім прыклад стварэння базавай кропкі. Яна будзе займацца абслугоўваннем запытаў карыстальнікаў і прадастаўляць ім выявы з лакальнага каталога. Такім чынам, да блоку http дадаем яшчэ адзін server з такім змесцівам:

server {

listen 8080;

root / data / up1;

location / {

}

}

А цяпер давайце для вас расшыфрую: ствараецца просты сервер. Ён будзе праслухоўваць порт 8080. Ці не пазначыць listen, то сервер будзе працаваць на 80-м. Адлюстроўвацца будуць усе запыты ў рамках лакальнай файлавай сістэмы, якія накіраваны на каталог / data / up1 (вядома, яго перад гэтым неабходна будзе стварыць). Для магчымасці праверкі там неабходна змясціць файл index.html. Дзякуючы размяшчэнні дырэктывы root ў кантэксце server мы зможам скарыстацца location пры любых умовах (паколькі, такім чынам, здымаюцца абмежаванні доступу). Цяпер працуем над стварэннем проксі-сервера. Для яго працы нам спатрэбіцца дырэктыва proxy_pass, для якой будуць пазначаны пратакол, імя, а таксама порт аб'екта як параметры (пры лакальным падключэнні гэта будзе выглядаць як http: // localhost: 8080). Атрымаецца такі вынік:

server {

location / {

proxy_pass http: // localhost: 8080;

}

location / images / {

root / data;

}

}

Калі вы разглядаеце код і аналізуеце яго, то можаце заўважыць, што другі блок location быў зменены. Так, у дадзеным выпадку ён можа працаваць з тыповымі пашырэннямі малюнкаў. Крыху па-іншаму яго можна было б адлюстраваць такім чынам:

location ~ \. (gif | jpg | png) $ {

root / data / images;

}

Выніковая канфігурацыя проксі-сервера выглядае наступным чынам:

server {

location / {

proxy_pass http: // localhost: 8080 /;

}

location ~ \. (gif | jpg | png) $ {

root / data / images;

}

}

Ён будзе адфільтроўваць запыты, у канцы якіх маюцца названыя пашырэння, і адпраўляць іх таму, хто папрасіў файлы. Не забывайце, што пры жаданні праверыць файл канфігурацыі яго неабходна будзе перазагрузіць. І паверце, гэта найпростая nginx-налада. Калі адкрыць канфігурацыйны файл сервера «Вконтакте» або іншай буйной кампаніі, у іх будзе кода больш, чым слоў у гэтым артыкуле.