Керівництво для початківців

У цьому керівництві дається початкове введення в nginx і описуються деякі прості завдання, які можуть бути вирішені з його допомогою. Передбачається, що nginx вже встановлений на комп'ютері Новомосковсктеля. Якщо немає, див. Установка nginx. У цьому посібнику описано, як запустити і зупинити nginx і перезавантажити його конфігурацію, пояснюється, як влаштований конфігураційний файл, і описується, як налаштувати nginx для роздачі статичного вмісту, як налаштувати проксі-сервер на nginx, і як пов'язати nginx з додатком FastCGI.

У nginx є один головний і кілька робочих процесів. Основне завдання головного процесу - читання і перевірка конфігурації і управління робочими процесами. Робочі процеси виконують фактичне опрацювання запитів. nginx використовує модель, засновану на подіях, і залежать від операційної системи механізми для ефективного розподілу запитів між робочими процесами. Кількість робочих процесів задається в конфігураційному файлі і може бути фіксованим для даної конфігурації або автоматично встановлюватися дорівнює кількості доступних процесорних ядер (див. Worker_processes).

Як працюють nginx і його модулі, визначається в файлі конфігурації. За замовчуванням, конфігураційний файл називається nginx.conf і розташований в каталозі / usr / local / nginx / conf. / Etc / nginx або / usr / local / etc / nginx.

Запуск, зупинка, перезавантаження конфігурації

Щоб запустити nginx, потрібно виконати виконуваний файл. Коли nginx запущений, їм можна управляти, викликаючи виконуваний файл з параметром -s. Використовуйте наступний синтаксис:

Де сигнал може бути одним з нижченаведених:

stop - швидке завершення
quit - плавне завершення
reload - перезавантаження конфігураційного файлу
reopen - перевідкриття лог-файлів

Наприклад, щоб зупинити процеси nginx з очікуванням закінчення обслуговування поточних запитів робочими процесами, можна виконати наступну команду:

Команда повинна бути виконана під тим же користувачем, під яким був запущений nginx.

Зміни, зроблені в файлі конфігурації, які не будуть застосовані, поки команда перезавантажити змін не буде вручну відправлена nginx'у або він не буде перезапущений. Для перезавантаження конфігурації виконайте:

Отримавши сигнал, головний процес перевіряє правильність синтаксису нового конфігураційного файлу і намагається застосувати конфігурацію, що міститься в ньому. Якщо це йому вдається, головний процес запускає нові робочі процеси і відправляє повідомлення старим робочим процесам з вимогою завершитися. В іншому випадку, головний процес відкочується зміни і продовжує працювати зі старою конфігурацією. Старі робочі процеси, отримавши команду завершитися, припиняють приймати нові запити і продовжують обслуговувати поточні запити до тих пір, поки всі такі запитом не будуть обслужені. Після цього старі робочі процеси завершуються.

Посилати сигнали процесам nginx можна також засобами Unix, такими як утиліта kill. У цьому випадку сигнал відправляється безпосередньо процесу з даними ID. ID головного процесу nginx записується за замовчуванням в файл nginx.pid в каталозі / usr / local / nginx / logs або / var / run. Наприклад, якщо ID головного процесу дорівнює 1628, для відправки сигналу QUIT, який приведе до плавного завершення nginx, потрібно виконати:

Додаткову інформацію про відправку сигналів процесам nginx можна знайти в Управління nginx.

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

nginx складається з модулів, які налаштовуються директивами, зазначеними в файлі конфігурації. Директиви діляться на прості і блокові. Проста директива складається з імені та параметрів, розділених пробілами, і закінчується крапкою з комою (;). Блокова директива влаштована так само, як і проста директива, але замість крапки з комою після імені та параметрів слід набір додаткових інструкцій, поміщених усередині фігурних дужок ( <и> ). Якщо у блокової директиви всередині фігурних дужок можна задавати інші директиви, то вона називається контекстом (приклади: events. Http. Server і location).

Директиви, поміщені в файлі конфігурації поза будь-якого контексту, вважатися такими, що в контексті main. Директиви events і http розташовуються в контексті main. server - в http. а location - в server.

Роздача статичного вмісту

Одна з важливих завдань конфігурації nginx - роздача файлів, таких як зображення або статичні HTML-сторінки. Розглянемо приклад, в якому в залежності від запиту файли будуть лунати з різних локальних каталогів: / data / www. який містить HTML-файли, і / data / images. що містить файли з зображеннями. Для цього буде потрібно відредагувати конфігураційний файл і налаштувати блок server всередині блоку http з двома блоками location.

У загальному випадку конфігураційний файл може містити кілька блоків server. розрізняються по портам, на яких вони слухають. і по імені сервера. Визначивши, який server буде обробляти запит, nginx порівнює URI, зазначений в заголовку запиту, з параметрами директив location. певних всередині блоку server.

У блок server додайте блок location такого вигляду:

Цей блок location задає "/" в якості префікса, який порівнюється з URI із запиту. Для відповідних запитів додаванням URI до шляху, вказаному в директиві root. тобто, в даному випадку, до / data / www. виходить шлях до запитуваного файлу в локальній файловій системі. Якщо є збіг з декількома блоками location. nginx вибирає блок з найдовшим префіксом. У блоці location вище зазначений найкоротший префікс, довжини один, і тому цей блок буде використаний, тільки якщо не буде збігу з жодним з інших блоків location.

Далі, додайте другий блок location.

Він буде давати збіг із запитами, які починаються часткою з / images / (location / для них теж підходить, але зазначений там префікс коротше).

Підсумкова конфігурація блоку server повинна виглядати наступним чином:

Щоб застосувати нову конфігурацію, запустіть nginx, якщо він ще не запущений, або надішліть сигнал reload головному процесу nginx, виконавши:

У разі якщо щось працює не як очікувалося, можна спробувати з'ясувати причину за допомогою файлів access.log і error.log з каталогу / usr / local / nginx / logs або / var / log / nginx.

Налаштування простого проксі-сервера

Одним з частих застосувань nginx є використання його в якості проксі-сервера, тобто сервера, який приймає запити, спрямує його на проксіруемие сервера, отримує відповіді від них і на клієнтський.

Ми налаштуємо базовий проксі-сервер, який буде обслуговувати запити зображень з локального каталогу та відправляти всі інші запити на проксіруемий сервер. У цьому прикладі обидва сервера працюватимуть в рамках одного примірника nginx.

По-перше, створіть проксіруемий сервер, додавши ще один блок server в конфігураційний файл nginx з наступним змістом:

Це буде простий сервер, слухає на порту 8080 (раніше директива listen не вказувалася, тому що використовувався стандартний порт 80) і відображає всі запити на каталог / data / up1 в локальній файловій системі. Створіть цей каталог і покладіть в нього файл index.html. Зверніть увагу, що директива root поміщена в контекст server. Така директива root буде використана, коли директива location. обрана для виконання запиту, не містить власної директиви root.

Ми змінимо другий блок location. який на даний момент відображає запити з префіксом / images / на файли з каталогу / data / images так, щоб він підходив для запитів зображень з типовими розширеннями файлів. Змінений блок location виглядає наступним чином:

Параметром є регулярний вираз, що дає збіг з усіма URI, що закінчуються на .gif. jpg або .png. Регулярному виразу повинен передувати символ

Відповідні запити будуть відображені на каталог / data / images.

Коли nginx вибирає блок location. який буде обслуговувати запит, то спочатку він перевіряє директиви location. задають префікси, запам'ятовуючи location з найдовшим відповідним префіксом, а потім перевіряє регулярні вирази. Якщо є збіг з регулярним виразом, nginx вибирає відповідний location. в іншому випадку береться запомненний раніше location.

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

Цей сервер буде фільтрувати запити, що закінчуються на .gif. jpg або .png. і відображати їх на каталог / data / images (додаванням URI до параметру директиви root) і перенаправляти всі інші запити на проксіруемий сервер, конфігурований вище.

Щоб застосувати нову конфігурацію, відправте сигнал reload nginx'у, як описувалося в попередніх розділах.

Існує безліч інших директив для подальшої настройки проксі-з'єднання.

Налаштування проксінг FastCGI

nginx можна використовувати для перенаправлення запитів на FastCGI-сервери. На них можуть виконуватися додатки, створені з використанням різноманітних фреймворків і мов програмування, наприклад, PHP.