Хей! Днес ще говорим за това правилната концепция, как виртуални хостове(Виртуални хостове)в уеб сървъра nginx. Ще използваме операционната система Ubuntu като пример. За други Linux системи настройката ще изглежда много подобна. Тази статия с инструкции ще бъде от интерес предимно за начинаещи уеб администратори и администратори, т.к те най-често имат този въпрос.

Виртуален хост е...

Първо, нека дефинираме виртуален хост. Така, виртуален хост еразделяне на адресното пространство на уеб сървър, например, по име на сайт, позволявайки на множество уеб сайтове/приложения да работят на един физически сървър. В терминологията на документацията на nginx виртуалният хост също се нарича "Сървърен блок", но за по-голяма прилика с Apache ще го нарека еднакво, тъй като целта им е същата. И още една конвенция - нека наречем това, което ще конфигурираме сайт за простота.

Създаване на виртуален хост

Много от командите в това ръководство изискват вашият потребител да има sudoer разрешения за VPS. Следователно, ако ги нямате, за съжаление, едва ли ще можете да конфигурирате виртуални хостове.

Предварително зададени

Сега ще кажа нещо, което всеки трябва да знае! За да конфигурирате виртуален хост в nginx, ви е необходим уеб сървърът nginx, инсталиран на вашата машина. Капитан Очевидно е с нас! Ако вече имате инсталиран nginx, можете спокойно да пропуснете тази стъпка и да следвате инструкциите. Ако по някаква причина все още го нямате на вашата машина, въведете командата в конзолата:

Sudo apt-get install -y nginx

Вариант "-Y"добавяме към командата apt-get, за да не отговаряме с да-да-да на досадните въпроси на инсталатора, защото сме сигурни, че искаме да инсталираме този пакет и се съгласяваме с използването на дисковото пространство, което заема. Ако все още не сте сигурни дали сте съгласни с всичко, тогава не добавяйте тази опция.

Създаване на директория на сайта

И така, преди да създадем виртуален хост, нека създадем папка на сайта, където ще поставим всички файлове, с които ще работи нашият уеб сървър.

Пътят до тази папка в конфигурацията на хоста, който се създава, ще бъде Корен на документа, един вид контекст, изолационна точка, над която е невъзможно да се издигне отвън без предварителни конфигурационни настройки и спрямо която се изграждат пътища към исканите файлове. С опция "-P"за командата mkdir, не е нужно да се притесняваме за създаване на родителски директории, те ще бъдат създадени автоматично:

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

Тук използваме истински проверен DNS домейн с правилни записи, сочещи към нашата машина. За да създадете виртуален хост с нерегистриран домейн, например за локална разработка, трябва да направите съответен запис във файла / etc / hosts. Повече за това в края на статията.

Права за достъп

Сега само root потребителят има права върху създадената от нас папка. Трябва да предоставим разрешения на директорията за желания потребител, за да не работи с нея постоянно в режим супер потребител. Можете да замените потребителя "www-data", използван по-долу, с друг, но по подразбиране nginx работи като този конкретен потребител.

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

Сега нека направим така, че всички потребители да могат да четат нашите нови файлове:

Sudo chmod 755 / var / www

Имаме предвид, че работим с VPS, на който всички потребители не са замислили нищо лошо или на който сте само вие. Следователно можем да дадем 755 права на папката / var / www. Ако във вашия случай е невъзможно да дадете на всички потребители на системата право да четат тази директория, проучете проблема с диференцирането на правата и го конфигурирайте сами.

Сега имате всичко с правата готово!

Създайте страница

Сега трябва да поставим в нашата папка някои статични файлове (HTML страници, картинки, скриптове, стилове и т.н.), които нашият сървър ще разпространява. Нека създадем HTML страница index.htm, която ще бъде главната страница на нашия сайт:

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

И нека добавим малко маркиране към него, което ще бъде показано на потребителя:

Ура! Успяхте да конфигурирате виртуален хост в nginx!

Запази и излез.

Създаване на конфигурация на виртуален хост

Стигнахме до създаването на конфигурационен файл за нашия нов виртуален хост, който ще съдържа цялата информация за сайта, необходима за уеб сървъра.

В nginx, в директорията / etc / nginx / sites-available има шаблон за генерираните конфигурации. Нека го копираме за нашия сайт:

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

Конфигурация на виртуален хост

Отворете нов конфигурационен файл и ще видите цялата необходима информация, която трябва да попълните.

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

Трябва да направим промени в текущата конфигурация... В резултат на нашия прост случай трябва да получите нещо като следното:

Сървър (слушайте 80; root /var/www/mysite.ru/public_html; index index.html index.htm; server_name mysite.ru www.mysite.ru;)

Тук се изисква да посочите правилно пътя до папката със статиката на сайта и името на сървъра, чрез който ще влизате в сайта си. Ако посочите пътя неправилно или изобщо не го посочите, тогава няма да можете да конфигурирате виртуалния хост. V като сървър _name, можете също да посочите IP адрес или няколко имена, разделени с интервал, чрез който хостът ще бъде достъпен, както направихме ние.

Това е всичко, приключихме с този файл. Запазете го и го затворете.

Активиране на виртуален хост

Nginx има папки за достъпни и активирани сайтове. Първият съхранява конфигурациите на ВСИЧКИ виртуални хостове, които могат да бъдат включени този сървър, а в директорията с активирани сайтове има символични връзки към активни. Никой не забранява в сайтове с активиран да поставите оригиналния конфигурационен файл, но не и връзката, но ще бъде по-малко удобно, т.к. ако е необходимо да го деактивирате, ще трябва или да изтриете файла (тогава ще бъде проблематично да го включите обратно), или да го преместите в друга директория (тогава трябва да запомним къде сме се преместили). Много по-лесно е да ударите символична връзка!

Ето защо, сега, за да активираме нашия виртуален хост, трябва да създадем символна връзка между директорията на наличните сайтове, където се намира нашия конфигурационен файл, и сайтовете, активирани. Apache има специален екип a2ensite. В nginx няма такава команда, така че нека изпълним следното:

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

За да избегнете „грешка в името на конфликта на сървъра“ и се уверете, че вашият сайт обслужва необходимата информация, можете да премахнете по подразбиране от броя на активните хостове:

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

Рестартирайте

Вече преминахме през много стъпки и почти всичко е настроено. Нека сега презаредим нашия уеб сървър, за да кандидатстваме нова конфигурация, но преди да направите това, е добра практика да проверите дали всичко с конфигурацията е правилно и nginx го разбира правилно. За да направите това, стартирайте диагностиката на nginx със следната команда:

Sudo nginx -t

Такава проверка е изключително необходима при конфигуриране на производствени сървъри, за да не се случи да извикаме командата за рестартиране nginx, но тя не може да стартира поради неправилна конфигурация и всичките ни виртуални хостове не отговарят.

Ако получите нещо подобно в отговор:

Nginx: конфигурационният файл /etc/nginx/nginx.conf синтаксисът е наред nginx: конфигурационният файл /etc/nginx/nginx.conf тестът е успешен

Тогава всичко е наред с вас и можете спокойно да рестартирате сървъра с командата:

Рестартиране на услугата Sudo nginx

V в противен случайтрябва да погледнете конфигурационния файл на хоста. Нещо, което не сте посочили там.

Конфигуриране на локални хостове

Ако сте посочили IP адрес като име на сървъра, можете да пропуснете тази стъпка, т.к нямате нужда от локална конфигурация на хоста, вашият виртуален хост ще работи без него. Но ако искате да работите с вашия виртуален хост без истинско име на домейн, можете да настроите локални хостове на вашата машина. Както казах по-горе, това е много удобно, например, при разработване. Мога да създам mysite.dev и локалната нестабилна версия на сайта ще работи на него. За системи macOS и Linux изпълнете следната команда:

Sudo nano / etc / хостове

Ако работите под Windows, тогава файлът от локалните хостове трябва да лежи приблизително по този път C: \ Windows \ System32 \ drivers \ etc \ hosts.

Добавете запис за новия локален хост към файла. В нашия случай трябва да добавим два записа, тъй като ние посочихме два домейна в server_name.

12.34.56.789 mysite.ru 12.34.56.789 www.mysite.ru

Сега, докато този запис не бъде изтрит, заявките към mysite.ru ще получават информация за този хост от този файл и ще ви пренасочат към вашия отдалечен сървър. Ако сървърът е разположен локално, трябва да напишете "127.0.0.1" вместо "12.34.56.789".

Добра практика е да изтриете хост записи, след като са изпълнили задачата си, за да се избегнат бъдещи проблеми.

резултати

Сега можем да видим резултатите от нашия труд! Въведете адреса http://mysite.ru или http://www.mysite.ru в браузъра и се полюбувайте на главната страница, която създадохме от index.htm. И двата адреса трябва да показват нашия начална страница... Това е всичко! Нашият виртуален хост работи чудесно.

Nginx е популярен и работещ уеб сървър и обратен прокси сървър.

Nginx има много предимства, но настройките му са доста сложни и не винаги са ясни за начинаещите. Това ръководствоще ви преведе през основните параметри, синтаксис и конфигурационни файлове на Nginx.

Забележка: Урок, направен на Ubuntu 12.04.

Йерархия на директории Nginx

Nginx съхранява конфигурационни файлове в директорията / etc / nginx.

Тази директория съдържа още няколко директории и модулни конфигурационни файлове.

cd / etc / nginx
ls -F

conf.d / koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf сайтове-достъпни / win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled /

Потребителите на Apache вече са запознати с директориите за достъпни и активирани сайтове. Тези директории определят конфигурациите на сайта. Файловете обикновено се създават и съхраняват на достъпни сайтове; sites-enabled съхранява само конфигурации на активирани сайтове. За да направите това, трябва да създадете символична връзка от сайтове-достъпни към сайтове-активирани.

Директорията conf.d може да се използва и за съхраняване на конфигурации. Всеки .conf файл ще бъде прочетен при стартиране на Nginx. Синтаксисът на такива файлове не трябва да съдържа грешки.

Почти всички останали файлове се съхраняват в / etc / nginx, който съдържа информация за конфигурацията за конкретни процеси или допълнителни компоненти.

Основният конфигурационен файл на Nginx е nginx.conf.

Nginx.conf файл

Файлът nginx.conf чете съответните конфигурационни файлове и ги слива в един конфигурационен файл, когато сървърът стартира.

Отворете файла:

sudo nano /etc/nginx/nginx.conf

потребителски www-данни;
работни_процеси 4;
pid /var/run/nginx.pid;
събития (
worker_connections 768;
# multi_accept включен;
}
http (
. . .

Първите редове са поставени Главна информацияза Nginx. Низът за потребителски www-данни указва потребителя, с когото се стартира сървърът.

Директивата pid указва къде ще се съхраняват PID на процеси за вътрешна употреба. Редът worker_processes дефинира броя на процесите, които Nginx може да поддържа едновременно.

Също така, в тази част на файла можете да посочите регистрационни файлове (например журналът за грешки се дефинира с помощта на директивата error_log).

Общата информация за сървъра е последвана от секцията за събития. Той се справя с обработката на Nginx връзки. Следва http блока. Преди да продължите с конфигурациите на вашия уеб сървър, трябва да разберете как е форматиран конфигурационният файл на Nginx.

Структура на конфигурационния файл на Nginx

Конфигурационният файл на Nginx е разделен на блокове.

Първият блок е събития, последван от http и започва основната йерархия на конфигурацията.

Конфигурационните детайли на http блока се наслояват с помощта на частни блокове, които наследяват свойства от блока, в който се намират. http блокът съхранява по-голямата част от общи конфигурации Nginx, които са разделени на сървърни блокове, които от своя страна са разделени на блокове за местоположение.

Когато конфигурирате Nginx, е важно да запомните следното правило: колкото по-високо е нивото на конфигурация, толкова повече блокове ще наследят тази конфигурация; колкото по-ниско е нивото на конфигурация, толкова по-„индивидуално“ е то. Тоест, ако параметърът X трябва да се използва във всеки сървърен блок, тогава такъв параметър трябва да бъде поставен в http блока.

Ако погледнете внимателно файла, ще забележите, че той съдържа много опции, които определят поведението на програмата като цяло.

Например, за да конфигурирате компресирането на файлове, трябва да зададете следните параметри:

gzip върху;
gzip_disable "msie6";

Това ще позволи поддръжката на gzip за компресиране на данни, изпратени до клиента, и ще деактивира gzip за Internet Explorer 6 (тъй като този браузър не поддържа компресиране на данни).

Ако параметърът трябва да има различна стойност в няколко сървърни блока, тогава такъв параметър може да бъде зададен на най-високо ниво и след това да бъде предефиниран в самите сървърни блокове. В резултат на това Nginx ще изпълни параметъра от най-ниско ниво.

Това подреждане на конфигурации избягва необходимостта от управление на множество идентични файлове. Освен това, ако сте забравили да дефинирате параметри от ниско ниво, Nginx просто ще изпълни параметрите по подразбиране.

http блокът във файла nginx.conf завършва така:

включва /etc/nginx/conf.d/*.conf;
включва / etc / nginx / sites-enabled / *;

Това означава, че сървърът и блоковете за местоположение, които определят настройките за конкретни сайтове и URL адреси, ще се съхраняват извън този файл.

Това позволява да се поддържа модулна конфигурационна архитектура, в която могат да се създават нови файлове за обслужване на нови сайтове. Освен това ви позволява да групирате подобни файлове заедно.

Затворете файла nginx.conf. Сега трябва да разгледате настройките за отделни сайтове.

Nginx виртуални блокове

Сървърните блокове в Nginx са аналогични на виртуалните хостове на Apache (но за удобство се наричат ​​още виртуални хостове). По същество сървърните блокове са техническите характеристики на отделните уебсайтове, хоствани на един сървър.

В директорията на наличните сайтове можете да намерите файла за блокиране на сървъра по подразбиране, който идва със сървъра. Този файл съдържа всички данни, необходими за поддържане на сайта.

CD сайтове-достъпни
sudo nano по подразбиране

root / usr / share / nginx / www;
индекс index.html index.htm;
име_сървър локален хост;
местоположение / (

}
местоположение / документ / (

псевдоним / usr / share / doc /;
автоиндексиране включен;
позволете 127.0.0.1;
отричай всичко;

Файлът е много добре коментиран по подразбиране, но в примера по-горе коментарите са пропуснати за простота и удобство.

Блокът на сървъра включва всички настройки, поставени между къдрави скоби:

сървър (
. . .
}

Този блок се намира във файла nginx.conf близо до края на http блока, използващ включват директиви.

Основната директива определя директорията, в която ще се съхранява съдържанието на сайта. В тази директория Nginx ще търси файлове, поискани от потребителя. По подразбиране тази директория е / usr / share / nginx / www.

Моля, имайте предвид, че всички редове завършват с точка и запетая. Ето как Nginx отделя една директива от друга. Ако няма точка и запетая, Nginx ще прочете двете директиви (или множество директиви) като една директива с допълнителни аргументи.

Директивата index дефинира файловете, които да се използват като индекс. Уеб сървърът ще провери файловете в реда, в който са изброени. Ако не е поискана страница, сървърният блок ще намери и върне файла index.html. Ако не може да намери този файл, ще се опита да анализира index.htm.

Директива сървър_име

Директивата server_name съдържа списък с имена на домейни, които ще се обслужват от този сървърен блок. Броят на домейните е неограничен; Отделете домейните в списъка с интервали.

Звездичка (*) в началото или края на домейн указва име с маска, където звездичката съвпада с част (или повече части) от името. Например, * .example.com ще съответства на forum.example.com и www.animals.example.com.

Ако исканият URL адрес съвпада с множество директиви server_name, той първо ще отговори с тази, която точно съвпада.

Ако адресът не намери съвпадение, той ще търси най-дългото маскирано име, което завършва със звездичка. Ако не намери такова име, ще върне първото съвпадение с регулярни изрази.

Имената на сървъри, които използват регулярни изрази, започват с тилда (~). За съжаление тази тема е извън обхвата на тази статия.

Блокове за местоположение

Местоположението/редът указва, че директивите в скоби ще се прилагат към всички заявени ресурси, които не съвпадат с други блокове за местоположение.

Такива блокове могат да съдържат uri пътека (напр. / doc /). За да се установи пълно съответствие между местоположението и uri, се използва символът =. Символът ~ съвпада с регулярни изрази.

Тилдата позволява режим, чувствителен към малки и малки букви, а тилдата със звездичка включва режим, чувствителен към малки и големи букви.

Ако заявката съвпада напълно с локационния блок, тогава сървърът спира търсенето и използва такъв блок. Ако сървърът не намери напълно съвпадащ блок за местоположение, той сравнява URI с параметрите на директивите за местоположение. Nginx ще избере блок, който използва комбинацията от знаци ^ ~ и съответства на URI.

Ако опцията ^ ~ не се използва, Nginx ще избере най-близкото съвпадение и ще извърши търсене с регулярен израз, за ​​да се опита да съвпадне с един от наличните шаблони. Ако намери такъв израз, значи го използва. Ако няма такъв израз, тогава сървърът използва намереното по-рано URI съвпадение.

Като заключение трябва да се отбележи, че Nginx предпочита точните съвпадения. Ако няма такова съвпадение, той търси регулярен израз и след това търси URI. За да промените приоритета на търсенето на URI, използвайте комбинацията от знаци ^ ~.

Директива Try_files

Директивата try_files е много полезен инструменткойто проверява наличието на файлове в дадения ред и използва първия намерен файл за обработка на заявката.

Това ви позволява да използвате допълнителни параметри, за да дефинирате как Nginx ще обслужва заявките.

В конфигурационния файл по подразбиране има ред:

try_files $ uri $ uri / /index.html;

Това означава, че когато пристигне заявка, обслужена от блок за местоположение, Nginx първо ще се опита да обслужи uri като файл (това поведение се задава от променливата $ uri).

Ако сървърът не намери съвпадение за променливата $ uri, той ще се опита да използва uri като директория.

Сървърът използва наклонена черта в края, за да провери съществуването на директорията, например $ uri /.

Ако не бъде намерен файл или директория, Nginx стартира файла по подразбиране (в този случай index.html в основната директория на сървърния блок). Всяка директива try_files използва последния параметър като резервен, така че този файл трябва да съществува в системата.

В случай, че уеб сървърът не намери съвпадения в предишните параметри, той може да върне страница за грешка. За това се използват знак за равенство и код за грешка.

Например, ако местоположението/блокът не може да намери искания ресурс, той може да върне грешка 404 вместо файла index.html:

try_files $ uri $ uri / = 404;

За да направите това, трябва да поставите знак за равенство и да зададете кода за грешка като последен параметър (= 404).

Допълнителни опции

Директивата за псевдонима позволява на Nginx да обслужва страници в локационния блок извън определената директория (например извън root).

Например файловете, поискани от /doc /, ще бъдат обслужвани от /usr / share / doc /.

Директивата autoindex on позволява изброяване на Nginx директории за дадената директива за местоположение.

Редовете за разрешаване и отказ контролират достъпа до директории.

Заключение

Уеб сървърът на Nginx е богат на функции и много производителен, но неговата терминология и параметри могат да бъдат объркващи.

Като разбирате и работите с конфигурации на Nginx, можете да се възползвате напълно от този мощен и лек инструмент.

Един от най-популярните уеб сървъри

Nginx е много популярен сред потребителите на уеб и прокси сървъри поради своята производителност. Сървърът има много предимства, но може да бъде трудно за начинаещ да го настрои. Искаме да ви помогнем да разберете конфигурационните файлове, синтаксиса и основните настройки на Nginx.

Йерархия на директории

Всички конфигурационни файлове на сървъра се намират в директорията / etc / nginx. Освен това в директорията има още няколко папки, както и модулни конфигурационни файлове.

cd / etc / nginx
ls -F
conf.d / koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf сайтове-достъпни / win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled /

Ако сте използвали Apache, трябва да сте запознати с директориите с активирани и достъпни сайтове. Те определят конфигурацията на сайтовете. Генерираните файлове се съхраняват в последната директория. Папката с активирани сайтове е необходима за съхраняване на конфигурации само на активирани страници. За да ги свържете, ви е необходима символна връзка между папките. Конфигурациите могат да се съхраняват и в директорията conf.d. В същото време по време на стартиране на Nginx всеки файл с разширение .conf ще бъде прочетен отново. Когато пишете конфигурационни файлове, въведете кода правилно и следвайте синтаксиса. Всички останали файлове се намират в / etc / nginx. Конфигураторът съдържа информация за конкретни процеси, както и допълнителни компоненти.

Основният конфигурационен файл на Nginx е nginx.conf.

Той чете всички конфигурационни файлове, като ги обединява в един, който се изисква при стартиране на сървъра. Отворете файла с:

sudo nano /etc/nginx/nginx.conf

На екрана ще се появят следните редове:

потребителски www-данни;
работни_процеси 4;
pid /var/run/nginx.pid;
събития (
worker_connections 768;
# multi_accept включен;
}
http (
. . .

Първият е преглед на Nginx. Фразата потребителски www-data се отнася до потребителя, който стартира сървъра. Директивата pid указва къде се намират вътрешните PID процеси. Редът worker_processes показва колко процеса Nginx може да изпълнява едновременно. Освен това тук можете да посочите регистрационни файлове (например дневникът за грешки се дефинира с помощта на директивата error_log). По-долу е разделът за събития. Той е необходим за работа със сървърни връзки. След него е http блокът.

Структура на конфигурационния файл на Nginx

Разбирането на структурата за форматиране на файловете ще ви помогне да разберете по-добре конфигурацията на вашия уеб сървър. Разделя се на градивни блокове. Подробностите за конфигурацията на http блока са наслоени с помощта на частни блокове. Те наследяват имоти от своя родител, т.е. този, в който се намират. Този блоксъхранява повечето конфигурации на сървъра. Те са разделени на сървърни блокове, вътре в които се намира местоположението.

Когато конфигурирате вашия Nginx сървър, не забравяйте, че колкото по-нисък е конфигурационният блок, толкова по-малко елементи ще наследят свойства и обратно. Файлът съдържа голям брой опции, които променят работата на сървъра. Можете да зададете компресирането на файлове, изпратени на клиента, например. За да направите това, напишете параметрите:

gzip върху;
gzip_disable "msie6";

Имайте предвид, че един и същ параметър може да приема различни стойности в различни блокове. Първо го задайте в горната част, след което заменете параметъра на необходимото ниво. Ако последно действиене се изпълняват, програмата ще зададе стойностите в автоматичен режим.

Последните редове на файла nginx.conf са:

включва /etc/nginx/conf.d/*.conf;
включва / etc / nginx / sites-enabled / *;

Те показват, че местоположението и сървърните блокове се съхраняват извън този файл. Те определят настройките за URL адреси и конкретни файлове. Тази структура е необходима за поддържане на модулна конфигурационна структура. Вътре в него ще можете да създавате нови директории, файлове за различни сайтове. Освен това можете да групирате подобни файлове. След преглед можете да затворите файла nginx.conf.

Виртуални блокове

Те са аналогични на виртуалните хостове в Apache. Блоковете на секцията на сървъра включват характеристиките на отделните сайтове, които се намират на сървъра. В папката Sites-available ще намерите файла за блокиране на сървъра по подразбиране. Вътре в него можете да намерите извън необходимите данни, които може да са необходими при поддръжка на сайтове.

CD сайтове-достъпни
sudo nano по подразбиране
сървър (
root / usr / share / nginx / www;
индекс index.html index.htm;
име_сървър локален хост;
местоположение / (
try_files $ uri $ uri / /index.html;
}
местоположение / документ / (
псевдоним / usr / share / doc /;
автоиндексиране включен;
позволете 127.0.0.1;
отричай всичко;
}
}

В горния пример коментарът беше премахнат умишлено. Това беше направено за четливост. Вътре в сървърните блокове са настройките, затворени в къдрави скоби:

Този блок се поставя с помощта на директивата за включване в края на http, посочен във файла nginx.conf. Основната директива определя директорията, където ще се намира съдържанието на сайта. В него програмата ще търси файлове, които потребителят ще поиска. Пътят по подразбиране е / usr / share / nginx / www. Nginx разделя редове или директиви един от друг с точка и запетая. Ако не поставите препинателен знак, няколко реда ще се четат като един. За да напишете правилата, които ще се използват като индекс, използвайте директивата index. Сървърът ще ги провери в реда, в който са изброени. Ако никоя от наличните страници не е поискана от потребителя, ще бъде върнат index.html. Ако го няма, сървърът ще търси index.htm.

Правило за име_сървър

Той включва списък с имена на домейни, които трябва да бъдат обработени от сървърния блок. Можете да напишете произволен брой от тях, като ги разделите с интервали. Ако поставите * в края или началото на домейн, ще можете да посочите име с маска. Звездичката съвпада с част от името. Ако регистрирате * .com.ua, тогава всички адреси на посочените домейн зона... Ако адресът съвпада с описанието на няколко директиви, тогава той ще отговори с тази, която отговаря напълно. Ако няма съвпадение, отговорът ще бъде най-дългото име, което има маска. В противен случай регулярните изрази ще бъдат съпоставени. Имената на сървъри, които използват регулярни изрази, започват с тилда (~).

Блокове за местоположение

Следващият по ред ще имаме блок за местоположение. Използва се, за да се определи как се обработват определени заявки. Ако ресурсите не съответстват на други блокове за местоположение, тогава директивите, посочени в скоби, ще бъдат приложени към тях. Тези блокове могат да включват път като /doc /. За да се установи пълно съответствие между uri и местоположението, се използва знакът =. Прилагането на тилдата ще съответства на регулярните изрази. Можете също да зададете чувствителността на главния и главния букви, като поставите ~. Ако добавите звездичка, регистрът няма значение.

Имайте предвид: когато заявката съвпада с блока за местоположение, той ще бъде използван и търсенето ще спре. Когато съвпадението е непълно, URI ще се сравнява с параметрите на директивите за местоположение. Блок с комбинацията ^ ~ се използва, за да съответства на URI за избора на блок. Ако тази опцияне използвайте, сървърът избира най-доброто съвпадение и също така търси с помощта на регулярни изрази. Това е необходимо, за да изберете един от подходящите шаблони. Ако бъде намерен съвпадащ израз, той ще бъде използван. В противен случай ще бъде приложено предишното URI съответствие. Имайте предвид обаче, че Nginx харесва повече пълни съвпадения. Ако те не са там, той ще започне да търси регулярни изрази и след това по URI. Паритетът за търсене се определя от комбинацията от знаци ^ ~.

Правилото Try_files

Това е много полезен инструмент, който може да проверява за файлове в определен ред. Той прилага първите критерии за съвпадение за обработка на заявката. можеш да използваш Допълнителни опцииза да определите как сървърът ще обслужва заявки. Конфигураторът има ред по подразбиране като този:

try_files $ uri $ uri / /index.html;

Какво означава? Ако постъпи заявка, която се обслужва от блок за местоположение, сървърът първо ще се опита да обработи uri като файл. Това се осигурява от променливата $uri. Когато няма съвпадение, uri ще се третира като директория. Можете да проверите съществуването му, като добавите наклонена черта в края: $ uri /. Има ситуации, когато нито файлът, нито директорията няма да бъдат намерени. В този случай файлът по подразбиране index.html ще бъде зареден. Правилото try_files прилага последния параметър като резервен. Ето защо този файлтрябва да е в системата. Ако обаче не бъдат намерени съвпадения, Nginx ще върне страница за грешка. За да го зададете, напишете = и кода за грешка:

Допълнителни опции

Ако приложите правилото за псевдоним, ще можете да обслужвате страници в блока за местоположение извън основната директория, например. Когато са необходими файлове от doc, те ще бъдат поискани от /usr / share / doc /. В допълнение, правилото за автоматично индексиране започва да изброява директориите на сървъра за посочената директива за местоположение. Ако напишете редовете deny и allow, ще можете да промените достъпа до директории.

Като заключение трябва да се каже, че Nginx е много мощен многофункционален инструмент. Но получаването на добро разбиране за това как работи ще отнеме време и усилия. Ако разбирате как работят конфигурациите, можете напълно да се насладите на всички функции на програмата.

Друго). Сегашна версия, 0.6.x се счита за стабилен по отношение на надеждността, а изданията от клона 0.7 се считат за нестабилни. Важно е да се отбележи, че функционалността на някои модули ще се промени, в резултат на което може да се променят и директивите, така че обратната съвместимост в nginx до версия 1.0.0 не е гарантирана.

Защо nginx е толкова добър и защо администраторите на проекти с високо натоварване го обичат толкова много? Защо просто не използвате Apache?

Защо Apache е лош?

Първо трябва да обясните как те обикновено работят. мрежови сървъри... Запознатите с мрежово програмиранезнайте, че по същество има три модела на работа на сървъра:

1. Последователно. Сървърът отваря сокет за слушане и чака да се появи връзка (той е в блокирано състояние, докато чака). Когато пристигне връзка, сървърът я обработва в същия контекст, затваря връзката и изчаква връзката отново. Очевидно това далеч не е най-много По най-добрия начин, особено когато работата с клиента се извършва дълго време и има много връзки. В допълнение, последователният модел има много повече недостатъци (например невъзможността за използване на множество процесори) и в реални условия практически не се използва.
2. Многопроцес (многонишков). Сървърът отваря сокет за слушане. Когато пристигне връзка, тя я приема, след което създава (или взема от групата от предварително създадени) нов процес или нишка, която може да работи с връзката толкова дълго, колкото е необходимо, а след приключване на работата излиза или се връща до басейна. Междувременно основната нишка е готова да приеме нова връзка. Това е най-много популярен модел, тъй като е относително лесен за изпълнение, позволява сложни и отнемащи време изчисления за всеки клиент и използване на всички налични процесори... Пример за използването му е уеб сървърът Apache. Този подход обаче има и недостатъци: кога Голям бройЕдновременните връзки създават много нишки (или по-лошо, процеси) и операционната система губи много ресурси за превключване на контекста. Особено лошо е, когато клиентите много бавно приемат съдържание. Оказва се, че стотици нишки или процеси, заети само с изпращане на данни към бавни клиенти, което създава допълнително натоварване на планировчика на ОС, увеличава броя на прекъсванията и консумира много памет.
3. Неблокиращи гнезда / State Machine. Сървърът работи в рамките на една нишка, но използва неблокиращи гнезда и механизъм за запитване. Тези. сървърът при всяка итерация на безкраен цикъл избира от всички гнезда този, който е готов да приеме/изпрати данни с помощта на повикването select (). След избор на сокет сървърът изпраща данни към него или ги чете, но не чака потвърждение, а преминава в първоначално състояние и изчаква събитие на друг сокет или обработва следващото, в което събитието се е случило по време на обработката на предишния. Този моделизползва много ефективно процесор и памет, но е доста труден за изпълнение. Освен това, в рамките на този модел, обработката на събитие в сокет трябва да бъде много бърза - в противен случай много събития ще се натрупат в опашката и в крайна сметка тя ще препълни. Ето как работи nginx. Освен това ви позволява да стартирате множество работни процеси (наречени работници), т.е. може да използва множество процесори.

И така, представете си следната ситуация: 200 клиента с 256 Kbps канал са свързани към HTTP сървър с 1 Gbps канал:

Какво се случва в случая с Apache? Създават се 200 нишки/процеси, които генерират съдържание относително бързо (то може да бъдат както динамични страници, така и статични файлове, прочетени от диск), но бавно го дават на клиентите. Операционната система трябва да се справи с куп нишки и I/O ключалки.

В такава ситуация Nginx изразходва порядък по-малко ресурси на ОС и памет за всяка връзка. Тук обаче ограничението се разкрива мрежов модел nginx: не може да генерира динамично съдържание в себе си, т.к това ще доведе до блокиране вътре в nginx. Естествено, има решение: nginx може да прокси такива заявки (за генериране на съдържание) към всеки друг уеб сървър (например същия Apache) или към FastCGI сървър.

Нека разгледаме механизма на работа на пакета nginx като "главен" сървър и Apache като сървър за генериране на динамично съдържание:

Nginx приема връзката от клиента и чете цялата заявка от него. Тук трябва да се отбележи, че докато nginx не прочете цялата заявка, той не я изпраща за "обработка". Поради това почти всички индикатори за напредъка на качванията на файлове обикновено се "счупват" - възможно е обаче да ги коригирате с помощта на модула upload_progress на трета страна (това ще изисква модификация на приложението).

След като nginx прочете целия отговор, той отваря връзка с Apache. Последният върши своята работа (генерира динамично съдържание), след което изпраща своя отговор на nginx, който го буферира в паметта или временен файл. Междувременно Apache освобождава ресурси. Освен това, nginx бавно изпраща съдържание на клиента, като същевременно харчи порядък по-малко ресурси от Apache.

Тази схема се нарича frontend + backend и се използва много често.

Инсталация

Защото nginx тепърва започва да набира популярност, има някои проблеми с двоичните пакети, така че бъдете готови да го компилирате сами. Това обикновено не е проблем, просто трябва внимателно да прочетете изхода на командата. / Конфигурирайте --help и изберете опциите за компилация, от които се нуждаете, например:

./конфигуриране \
--Префикс = / opt / nginx-0.6.x \ # инсталационен префикс
--Conf-path = / etc / nginx / nginx.conf \ # местоположение на конфигурационния файл
-Pid-path = / var / run / nginx.pid \ # ... и pid файл
-Потребител = nginx \ # потребителско име, под което ще работи nginx
—С-http_ssl_module —with-http_gzip_static_module —с-http_stub_status_module \ # списък с необходимите
—Без-http_ssi_module —без-http_userid_module —без-http_autoindex_module —без-http_geo_module —без-http_referer_module —без-http_memcached_module —без-http_limit_zone ... и не се изисква_module

След конфигурирането трябва да стартирате стандартната make && make install, след което можете да използвате nginx.

Като алтернатива, в Gentoo можете да използвате ebuild от дървото на стандартните портове; в RHEL / CentOS epel хранилището (където се намира nginx 0.6.x) или srpm за версия 0.7, което може да бъде изтеглено от тук: http://blogs.mail.ru/community/nginx; в Debian можете да използвате пакета nginx от нестабилния клон.

Конфигурационен файл

Конфигурационният файл на nginx е много удобен и интуитивен. Обикновено се нарича nginx.conf и се намира в $ префикс /conf /, ако местоположението не е било предефинирано по време на компилацията. Обичам да го поставям в / etc / nginx /, както и разработчиците на всички споменати по-горе пакети.

Структурата на конфигурационния файл е както следва:

потребител nginx; # потребителско име, под което ще работи nginx
работни_процеси 1; # брой работни процеси
събития (
<…># този блок указва механизма за допитване, който ще се използва (вижте по-долу) и максимална сумавъзможни връзки
}

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

# описание на сървърите (това apache нарича VirtualHost)
сървър (
# адрес и име на сървъра
слушай *: 80;
име на сървъра aaa.bbb;

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

# и ето как можете да дефинирате местоположение, за което можете също да замените почти всички директиви, посочени на по-глобални нива
местоположение / abcd / (
<директивы>;
}
# Освен това можете да направите местоположение чрез регулярен израз, като този:
местоположение ~ \ .php $ (
<директивы>;
}
}

# друг сървър
сървър (
слушай *: 80;
име на сървъра ccc.bbb;

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

Моля, имайте предвид, че всяка директива трябва да завършва с точка и запетая.
Обратно прокси и FastCGI

И така, по-горе разгледахме предимствата на интерфейса + бекенд схемата, разбрахме инсталацията, структурата и синтаксиса на конфигурационния файл, помислете сега как да приложите обратно прокси в nginx.

Много е просто! Например така:

местоположение / (
proxy_pass http://1.2.3.4:8080;
}

В този пример всички заявки за местоположение / ще бъдат прокси сървъри 1.2.3.4, порт 8080. Това може да бъде или apache, или всеки друг http сървър.

Въпреки това, има няколко тънкости, свързани с факта, че приложението ще приеме, че първо, всички заявки идват към него от един IP адрес (което може да се тълкува например като опит за DDoS атака или атака с груба сила) , и второ, имайте предвид, че той работи на хост 1.2.3.4 и порт 8080 (съответно генерира неправилни пренасочвания и абсолютни връзки). За да избегнете тези проблеми, без да се налага да пренаписвате приложението, следната конфигурация ми се струва удобна:
Nginx слуша преден крайна порт 80.

Ако бекендът (например Apache) се намира на същия хост като nginx, тогава той "слуша" порт 80 на 127.0.0.1 или друг вътрешен IP адрес.

В този случай конфигурацията на nginx изглежда така:

сървър (
слушайте 4.3.2.1:80;
# задайте заглавката на Host и X-Real-IP: за всяка заявка, изпратена до бекенда
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header Хост $ хост: $ proxy_port;
# или "proxy_set_header Host $ host;", ако приложението ще добави: 80 към всички връзки
}

За да може приложението да прави разлика между IP адресите на посетителите, трябва или да инсталирате модула mod_extract_forwarded (ако се изпълнява Apache сървър), или модифицирайте приложението, така че да взема информация за IP адреса на потребителя от HTTP заглавката на X-Real-IP.

Друга бекенд опция е използването на FastCGI. В такъв случай nginx конфигурацияще изглежда така:

сървър (
<…>

# място, където ще се изпращат заявки за php-скриптове
местоположение ~ .php $ (
fastcgi_pass 127.0.0.1:8888; # дефинирайте адреса и порта на fastcgi сървъра,
fastcgi_index index.php; # ... индекс файл

# и някои параметри, които трябва да бъдат предадени на fastcgi сървъра, за да разбере кой скрипт и с кои параметри да се изпълни:
fastcgi_param SCRIPT_FILENAME / usr / www / html $ fastcgi_script_name; # име на скрипт
fastcgi_param QUERY_STRING $ query_string; # низ на заявка
# и параметри на заявката:
fastcgi_param REQUEST_METHOD $ request_method;
fastcgi_param CONTENT_TYPE $ content_type;
fastcgi_param CONTENT_LENGTH $ content_length;
}

# поради факта, че местоположенията с регулярни изрази имат висок "приоритет", всички не-php заявки ще отидат тук.

местоположение / (
root / var / www / html /
}

Статика

За да намалите натоварването на бекенда, по-добре е да обслужвате статичните файлове само чрез nginx - той се справя по-добре с тази задача, т.к. за всяка заявка той изразходва значително по-малко ресурси (няма нужда да създава нов процес и процесът nginx обикновено консумира по-малко памети може да обслужва много връзки).

В конфигурационния файл това изглежда така:

сървър (
слушай *: 80;
server_name myserver.com;

Местоположение / (
proxy_pass


"> Http://127.0.0.1:80;

}

# приемем, че всички статични файлове са в / файлове
местоположение / файлове / (
root / var / www / html /; # посочете пътя към fs
изтича 14г; # добавете заглавката Expires:
error_page 404 = @back; # и ако файлът не бъде намерен, изпратете го на посоченото място @back
}

# заявки от / файлове, за които не е намерен файл, се изпращат до бекенда и той може или да генерира желания файл, или да покаже хубаво съобщениеотносно грешката
местоположение @назад (
proxy_pass
„Заглавие =" http://127.0.0.1:80;

"> Http://127.0.0.1:80;

}

Ако всички статики не са поставени в конкретна директория, тогава използвайте регулярен израз:

местоположение ~ * ^. + \. (jpg | jpeg | gif | png | ico | css | zip | tgz | gz | rar | bz2 | doc | xls | exe | pdf | ppt | txt | tar | wav | bmp | rtf | js) $ (
# подобно на горното, само всички заявки, завършващи на един от посочените суфикси, ще бъдат изпратени до това местоположение
root / var / www / html /;
error_page 404 = @back;
}

За съжаление, nginx не е внедрен асинхронна работас файлове. С други думи, nginx работникът е блокиран при I/O операции. Така че, ако имате много статични файлове и, особено, ако те се четат от различни дискове, по-добре е да увеличите броя на работните процеси (до число, което е 2-3 пъти повече от общия брой глави на дискът). Това, разбира се, води до увеличаване на натоварването на ОС, но цялостната производителност се увеличава. За да работите с типично количество статика (не много голям брой относително малки файлове: CSS, JavaScript, изображения), един или два работни процеса са достатъчни.

Следва продължение

Връзки

Повече информация за nginx можете да намерите тук:

Nginx е уеб сървър и пощенски прокси сървър, който е публично достъпен от 2004 г. Разработването на проекта започва през 2002 г., на руски името звучи като engin-ex. Създаването на ръцете на известния програмист Игор Сисоев, Nginx първоначално е предназначено за Rambler. Той е предназначен за операционни системи, принадлежащи към Unix-подобната група. Сглобката беше успешно тествана на OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. На платформа на Microsoft Windows Nginx започна да работи с пускането на двоичната версия 0.7.52.

Статистиката за март 2011 г. показва, че броят на сайтовете, обслужвани от Nginx, вече е надхвърлил границата от 22 милиона. Днес Nginx се използва от такива добре познати проекти като Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru и други. Заедно с lighttpd, Nginx се използва за обслужване на статично съдържание, генерирано от "неудобно" уеб приложение, работещо под друг уеб сървър.
Но преди да навлезем по-дълбоко в дивата природа функционални характеристики Nginx - ще бъде полезно да запомните какво представлява уеб сървърът като цяло и прокси сървърът в частност.

Уеб сървър и прокси сървър

уеб сървъре сървър, който приема HTTP заявки от уеб браузъри и други клиенти и издава HTTP отговори към тях. Последните обикновено се представят HTML страница, медиен поток, изображение, файл, други данни. Под уеб сървър се разбира както софтуер, който изпълнява функции на уеб сървър, така и хардуер. Обменът на данни и искана информация се извършва чрез HTTP протокол.

Списъкът допълнителни функцииуеб сървърите включват: авторизация и удостоверяване на потребители, регистриране на техните заявки към ресурси, HTTPS поддръжка за сигурно превключване с клиенти и други. Най-често използваният уеб сървър в Unix-подобни операционни системи е Apache. Третият ред в списъка с предпочитания на клиента в момента се заема от Nginx.

Прокси сървърпозволява на клиентите да се справят заявки за търсенеДа се мрежови услугив непряка форма. Тоест, това е сървър, който е специализиран в пренасочването на клиентски заявки към други сървъри. Чрез свързване към прокси сървър и заявка за ресурс, намиращ се на друг сървър, клиентът може да запази анонимност и да защити компютъра от мрежови атаки. Прокси сървърът издава исканите данни на клиента или от собствения си кеш (ако има такъв), или ги получава от посочения сървър. В някои случаи (за постигане на горните цели) отговорът на сървъра, подобно на заявката на клиента, може да бъде променен от прокси сървъра.

Най-простият прокси сървър се счита за преводач на мрежови адреси или NAT. През 2000 г. прокси NAT беше вграден в дистрибуцията на Windows. Прокси сървърите, като всяко явление, имат две страни на монетата, тоест могат да се използват както за добро, така и за зло. Например, с тяхна помощ тези, които се страхуват от санкции за своите непристойни действия в мрежата, крият своите IP адреси ...

Функционална гама на Nginx:

• сървърно обслужване на индексни файлове, статични заявки, генериране на дескриптори за отворен кеш, списък с файлове;
• ускорено проксиране, елементарно разпределение на натоварването, отказоустойчивост;
• поддръжка за кеширане по време на ускорено прокси и FastCGI;
• поддръжка за FastCGI (ускорени) и memcached сървъри;
• модулност, филтри, включително "resume" (byte-ranges) и компресия (gzip);
• HTTP удостоверяване, разделени отговори, SSI филтър;
• паралелно изпълнение на няколко подзаявки на страницата, обработена чрез FastCGI или прокси в SSI филтъра;
• Поддръжка на StartTLS и SSL;
• възможността за поддръжка на вграден Perl;
• проста автентификация (ПОЛЗВАТЕЛ/ПРОХОД, ВХОД);
• сървър пренасочва (IMAP / POP3 прокси) потребител към IMAP / POP3 бекенд, използвайки външен сървърудостоверяване (HTTP).

За тези, които не са запознати с тази терминология, описанието на функционалността на Nginx може да изглежда доста неясно. Но когато става дума за начини за конкретно използване на този уеб сървър - той ще започне да избледнява малко по малко.

Архитектура и конфигурация

Работни процеси в Nginx едновременно обслужват много връзки, предоставяйки им извиквания на ОС ( операционна система) epoll (Linux), select и kqueue (FreeBSD). Получените от клиента данни се анализират с помощта на държавна машина. Анализираната заявка се обработва от посочената от конфигурацията модулна верига. Формирането на отговор към клиента става в буфери, които могат да сочат към секция от файл или да съхраняват данни в паметта. Последователността на предаване на данни към клиента се определя от веригите, в които са групирани буферите.

Структурно Nginx HTTP сървърът е разделен на виртуални сървъри, които от своя страна са разделени на местоположения. Виртуален сървърили директивата може да се използва за определяне на портове и адреси за приемане на връзки. Местоположението може да бъде определено с точен URI, част от URI или регулярен израз. За управление на паметта в движение, пуловете са последователност от предварително избрани блокове памет. Един блок, първоначално разпределен за пула, има дължина от 1 до 16 килобайта. Разделя се на райони – заети и незаети. При запълване на последния изборът на нов обект се осигурява чрез образуването на нов блок.

Географската класификация на клиентите по техния IP адрес се извършва в Nginx с помощта на специален модул. Дървовата система Radix ви позволява бързо да работите с IP адреси, като заемате минимум памет.

Предимства на Nginx

Nginx се счита за много бърз HTTP сървър. Вместо или във връзка с Apache, Nginx се използва за ускоряване на обработката на заявки и намаляване на натоварването на сървъра. Факт е, че огромните възможности, предоставени от модулната архитектура на Apache, не се изискват от повечето потребители. Плащането за тази непотърсена функционалност е значителен разход. системни ресурси... За обикновените сайтове, като правило, има ясно доминиране на статичните файлове (изображения, стилови файлове, JavaScript), а не на скриптове. Не се изисква специална функционалност за прехвърляне на тези файлове към посетителя на ресурса, тъй като задачата е много проста. Това означава, че уеб сървърът за обработка на такива заявки трябва да бъде прост и лек, като Nginx.

Начини за използване на Nginx

На отделен порт / IP.Ако ресурсът е пълен с изображения или файлове за изтегляне, Nginx може да бъде конфигуриран на отделен порт или IP и да обслужва статично съдържание през него. За да направите това обаче, трябва да се поправите малко със смяната на връзките в сайта. С голям брой заявки към статични файлове има смисъл да създадете отделен сървър и да инсталирате Nginx на него.

Ускорено проксиране... С тази опция всички заявки на посетители отиват първо в Nginx. Nginx обработва заявки за статични файлове (като изображение, обикновен HTML, JavaScript или CSS файл) самостоятелно. Ако потребителят се свърже с конкретен скрипт, той препраща заявката към отдела на Apache. Не е необходимо да правите никакви трансформации с кода на сайта.

Ако каналът от сървъра към посетителя и обратно е бавен, това използване на Nginx може да даде допълнителен ефект. Заявката, получена от посетителя, се предава на Nginx за обработка от Apache. След обработка на заявката, Apache насочва страницата на Nginx и прекратява връзката с чувство за постижение. Nginx вече може да изпраща страница на потребител толкова дълго, колкото е необходимо, практически без да изразходва системни ресурси. Apache работана негово място би било придружено от неоправдано голямо натоварване на паметта при работа почти на празен ход. Между другото, този случай на използване на Nginx има друго име: "Frontend to Apache".

Nginx плюс FastCGI. Apache може изобщо да не е необходим, ако интерпретаторът на езика, на който са написани скриптовете на сайта, поддържа технологията FastCGI. Такива езици включват например PHP, Perl и редица други. В този случай обаче може да се наложи да промените скриптовите кодове.

Има много подробни материали за това как да инсталирате и конфигурирате Nginx в мрежата. Можете да научите повече за Nginx на уебсайта на неговия разработчик Игор Сисоев.