Nginx базове налаштування. Nginx: налаштування та встановлення. Способи застосування Nginx

Привіт, Шановний користувачХабрахабра. Моя розповідь буде про те, як підготувати ґрунт для локальної веб-розробки проектів в операційній системі Ubuntu 16.04.1 LTS.

У цій статті хочеться розвіяти та роз'яснити можливі труднощіпов'язані з установкою та налаштуванням ПЗ, яке потрібно для сучасної веб-розробки, З якими можливо стикаються розробники-початківці і не тільки.

Технології, які будуть використані в статті: nginx, php-fpm.

Перед початком розповіді, хочу зазначити, що я робив усі ці дії на «голій» системі.
Я працюватиму з пакетним менеджером aptitude. Також рекомендую оновити індекс пакетів і самі пакети перед встановленням ПЗ. У статті ми зробимо ці дії разом.

Поїхали!

Встановлення пакетного менеджера aptitude, оновлення індексу та пакетів

Встановлюємо:

Sudo apt install aptitude
Оновлюємо індекс.

Sudo aptitude update
Оновлюємо пакети (команда оновить усі пакети, для яких є нові версії, якщо потрібно видалити пакети, то воно буде виконано).

Sudo aptitude full-upgrade

Встановлення та налаштування nginx(версія> = 1.10.0)

Встановлюємо.

Sudo aptitude install nginx
Запускаємо.

Sudo service nginx start
Перевіряємо версію, щоб переконатися, що не встановили стару, тобто нижче 1.10.0.

Установку та запуск зробили, тепер підемо в каталог туди, куди встановлений наш nginx і подивимося на його структуру. Каталог nginx знаходиться таким шляхом:

Cd /etc/nginx/
Подивитися вміст директорії можна командою ls, з прапорами -la зручніше переглядатиме вміст каталогу (насправді цю команду з конкретними прапорами можна описати детальніше та вірніше, але у нас сьогодні інша тема).

Ls-la
Наc цікавлять у Наразідва каталоги, які ви бачите на скріншоті. Це каталоги sites-available та sites-enabled.

Давайте перейдемо в каталог sites-available та почнемо конфігурувати наш віртуальний хост (сайт).

Cd /etc/nginx/sites-available
Перед початком створення конфігураційного файлу, перевіримо, що лежить у нас в даному каталозі. У моєму випадку каталог не порожній, у ньому вже є конфігураційні файли, я їх затер, щоб не вводити вас в оману.

Важливий відступ

В разі установки nginx"з нуля", саме "з нуля", так як при видаленні nginx командою
sudo apt-get remove nginx або sudo apt remove nginx конфігураційні файли залишаються і якщо ви раптом будете не розуміти, чому nginx не працює і захочете його перевстановити (зазвичай до такого вдаються початківці користувачі Linux), то і після переустановки він не буде коректно працювати, тому що в старих конфігураційних файлах (вони не видаляються після видалення командою remove) прописані неправильні налаштування, їх доведеться видалити, або налаштувати правильно, тільки тоді nginx запрацює.

Рекомендую видаляти командою sudo apt-get purge nginx або sudo apt purge nginx. Якщо ви використовуєте пакетний менеджер aptitude, то команда sudo aptitude purge nginx видаляє пакет повністю з усіма залежностями та конфігураційними файлами.


У цьому каталозі буде за промовчанням один файл під назвою default. У ньому буде конфігураційний файл з прикладом, з коментарями, його ви можете вивчити на дозвіллі, а можете взагалі видалити (завжди можна звернутися до офіційної документації).

Ls-la

Створимо свій конфігураційний файл, який відповідатиме назві домену нашого локального сайту (або реального, якщо вже знаєте його назву). Це зручно, в майбутньому, коли буде багато конфігураційних файлів, це позбавить вас від плутанини в них. У мене цей файл називатиметься project.local.

Sudo touch project.local
Подивимося, що вийшло.

Тепер відкриємо його у редакторі, я відкрию його у nano.

Sudo nano project.local
Бачимо, що він у нас порожній. Тепер перейдемо до формування нашого файлу. Потрібно привести конфігурацію до такого виду, як написано нижче. Я опишу тільки життєво важливі директиви цього файлу, описувати інше не буду, так як це не є на даний момент важливим, все ж таки у нас тема базового налаштування. Цих налаштувань із «гіркою» вистачить для розробки проектів локально, не лише дрібних, а й досить великих. У наступних статтях опишу окремо кожні використані директиви (саме так називаються рядки, наприклад server_name) цього файлу.

Дивіться коментарі прямо в конфігураційному файлі.

Server ( listen 80; # порт, що прослуховує nginx server_name project.local; # доменне ім'я, що відносяться до поточного віртуальному хосту root /home/stavanger/code/project.local; # каталог, у якому лежить проект, шлях до точки входу index index.php; # add_header Access-Control-Allow-Origin*; # serve static files directly location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ ( access_log off; expires max; log_not_found off; ) location / ( # add_header Access-Control-Allow- Origin *; try_files $uri $uri/ /index.php?$query_string; ) location ~* \.php$ ( try_files $uri = 404; :/var/run/php/php7.0-fpm.sock;# підключаємо сокет php-fpm fastcgi_index index.php;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;include () ;
Зберігаємо файл. Тепер нам треба перевірити, чи в ньому немає помилок. Зробити ми можемо командою.

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

Тепер нам треба активувати конфігураційний файл, у каталозі /etc/nginx/sites-enabled/ необхідно створити симлінк ( символічне посилання). Якщо у вас nginx був встановлений з нуля, то в цьому каталозі є симлінк на файл default, про який розповідалося вище, його можна видалити, якщо він вам не потрібно. Переходимо до потрібного каталогу.

Cd /etc/nginx/sites-enabled/
Тепер ми в потрібному каталозі. Давайте створимо наш симлінк. Для створення використовується команда ln із прапором -s, далі ми вкажемо шлях до нашого конфігу project.local.

Sudo ln -s /etc/nginx/sites-available/project.local
Подивимося на наш створений симлінк.

Щоб переконатися, що ми робимо ще все вірно, знову запустимо команду.

Файл hosts

Цей файл знаходиться на шляху /etc/hosts. Наявність в ньому записів дозволяє запускати nginx з використанням в якості домену localhost. У цьому файлі можна надавати альтернативні псевдоніминаприклад, для нашого проекту project.local, ми надамо домен project.local.

Відкриваємо файл у редакторі nano.

Sudo nano /etc/hosts
У вас у цьому файлі буде інша інформація, просто ігноруйте її. Вам лише потрібно додати рядок як на моєму скріншоті.

Встановлення php-fpm (>=7.0)

sudo aptitude install php-fpm
Перевіряємо встановлену версію, про всяк випадок, хоча в Ubuntu 16.04.1 у репозиторіях лежить саме 7.0 версія.

Php-fpm7.0-v

Переконуємось, що все ок. Стартуємо php-fpm.

Sudo service php7.0-fpm start
Якщо правитимете конфіги, то не забувайте рестартувати демон. Це так. Але нам це не буде потрібно.

Sudo service php7.0-fpm restart
На цьому встановлення та налаштування php-fpmзакінчено. Щоправда, це все. Це не магія, шлях до сокету php-fpm у нас вже був прописаний у файлі конфігурації. Звичайно, вам можуть знадобитися будь-які розширення phpдля розробки особистих проектів, але їх ви можете поставити в міру того, як вони будуть потрібні.

Тепер підемо до каталогу з нашим проектом, у мене він лежить таким шляхом.

Cd /home/stavanger/code/project.local
Піднімемося на каталог вище та зробимо права 777 (тобто ми будемо робити повні правакаталогу з нашим проектом (project.local). У майбутньому це позбавимо нас зайвих проблем.

Cd .. sudo chmod -R 777 project.local
На цьому налаштування ПЗ завершено, давайте створимо тестовий файл у нашому робочому каталозі project.local і переконаємось, що все працює. Я створю файл index.php з таким змістом.

Йдемо в браузер і бачимо, що у нас все чудово працює! Інтерпретатор php у тому числі.

З повагою до читачів, Ставангер.

На даний момент найбільшу популярність набрали два веб-сервери. Це Apache та Ngnix. У кожного з них є свої плюси та мінуси. Apache був розроблений ще в 1995 році і при його розробці враховувалися не всі можливі потреби користувачів, він споживає багато пам'яті та ресурсів системи, зате він простий у налаштуванні. Nginx був розроблений трохи пізніше в 2002 році, враховуючи помилки Apache і орієнтуючись на максимальну продуктивність.

Ми не будемо докладно вникати у плюси та мінуси цих обох веб-серверів. У кожного з них своя сфера застосування. У цій інструкції буде розглянуто встановлення Nginx Ubuntu 16.04. Хоча я говоритиму про Ubuntu 16.04, всі дії підійдуть і для інших дистрибутивів. Налаштування Nginx скрізь однакове, тільки команда установки відрізняється.

Насамперед потрібно встановити сам веб-сервер у систему. Програма є в офіційних репозиторіях, але її версія вже трохи застаріла, тому якщо хочете нову версію, потрібно додати PPA:

sudo apt-add-repository ppa:nginx/stable

Зараз в офіційних репозиторіях доступна версія 1.10.0, а стабільної PPA вже доступна 1.10.1. Якщо вам версія не потрібна можна обійтися і без PPA. Далі оновіть списки пакетів із репозиторіїв:

І встановлюємо ngnix:

sudo apt install nginx

Після того, як установка сервера Nginx буде завершена додамо програму в автозавантаження, щоб вона запускалася автоматично:

sudo systemctl enable nginx

Якщо ви вже зараз відкриєте браузер, то побачите nginx, що працює, але нам належить його ще налаштувати.

Налаштування Nginx Ubuntu

Налаштування Nginx Ubuntu набагато складніше, ніж Apache. Тут ми не будемо розглядати всі опції та можливості програми, а поговоримо лише про основне. Є різні конфігурації, в яких Nginx використовується як проксі сервер, а основний сервер Apache, але нас це цікавити не буде. Нам потрібна установка Nginx як самостійного веб-сервера.

Налаштування Nginx сильно відрізняються тут є тільки один основний конфігураційний файл і файли для віртуальних хостів. Налаштування з кожної директорії, як Apache не підтримується.

  • /etc/nginx/nginx.conf- Головний файл конфігурації
  • /etc/nginx/sites-available/*- Файли конфігурації для віртуальних хостів, простіше кажучи для кожного сайту.
  • /etc/nginx/sites-enabled/*- Файли конфігурації активованих сайтів.

Насправді файли конфігурації для віртуальних хостів читаються лише з директорії sites-enabled, але тут містяться посилання на sites-available. Така система була придумана, щоб дати можливість відключати на якийсь час ті чи інші сайти, не стираючи їх конфігурацію. Всі інші файли містять лише оголошення змінних та стандартні налаштування, які не потрібно змінювати. Що ж стосується nginx.conf, то в нього включаються всі файли з sites-enables, а тому вони можуть містити все точно такі ж інструкції. А тепер розглянемо головний файл конфігурації:

sudo vi /etc/nginx/nginx.conf

Як бачите, файл розділений на секції. Загальна структура така:

глобальні опції
events ()
http(
server (
location()
}
server()
}
mail ()

  • глобальні опціївідповідають за роботу всієї програми.
  • events- Ця секція містить налаштування для роботи з мережею.
  • http- містить налаштування веб-сервера. Повинна містити секцію servier для тонкого налаштування кожного сайту.
  • server- У цій секції міститься налаштування кожного розміщеного на веб-сервері сайту.
  • location- секція location може перебувати лише всередині секції server і містить налаштування лише певного запиту.
  • mail- містить налаштування поштового проксі.

Перед тим як перейти до опцій, потрібно сказати ще кілька слів про синтаксис рядка конфігураційного файлу. Він виглядає ось так:

параметр значення додаткове значення;

Рядок повинен обов'язково закінчуватися ";", а всі відкриті дужки (мають бути закриті.

Тепер, коли ви вивчили глобальну структуру, можна переходити до розгляду самих параметрів. Глобальних опцій не так багато:

  • user- Користувач, від імені якого працюватиме програма.
  • worker_processes- Встановлює скільки процесів потрібно запускати для паралелізації роботи програми, потрібно запускати не більше процесів, ніж у вас є ядер. Можна встановити параметр autoі тоді програма визначить це число сама.
  • pid= файл pid програми.
  • worker_rlimit_nofile- Вказує максимальну кількість файлів, які може відкрити програма. Розраховується як worker_processes *worker_connections* 2.

З глобальними опціями закінчили, їх було не так багато і вони не такі цікавіші. Куди цікавіше щодо оптимізації опції з секції events:

  • worker_connections- кількість з'єднань, які програма може обробляти одночасно одному процесі. Якщо помножити worker_process на цей параметр, ми отримаємо максимальну кількість користувачів, які можуть підключитися до сервера одночасно. Рекомендується встановити значення від 1024 до 4048.
  • multi_accept- дозволити приймати багато з'єднань одночасно, встановіть параметр on або off.
  • use- Спосіб роботи з мережевим стеком. За замовчуванням використовується poll, але для Linux ефективніше використовувати epoll.
  • sendfile- Використовувати метод відправлення даних sendfile. Значення on.
  • tcp_nodelay, tcp_nopush- надсилати заголовки та початок файлу одним пакетом. Значення on.
  • keepalive_timeout- таймування очікування, перед тим як keepalive з'єднання буде розірвано, за замовчуванням 65, але можна зменшити до 10 секунд.
  • keepalive_requests- максимальна кількість keepalive з'єднань від одного клієнта, рекомендовано 100.
  • reset_timedout_connection- Розривати з'єднання після таймууту. Значення on.
  • open_file_cache- кешувати інформацію про відкриті файли. Рядок налаштування виглядає так: open_file_cache max=200000 inactive=20s; max – максимальна кількість файлів у кеші, час кешування.
  • open_file_cache_valid- Вказує після закінчення якого часу потрібно видалити інформацію з кешу. Наприклад: open_file_cache_valid 30s;
  • open_file_cache_min_uses- кешувати інформацію про файли, які були відкриті щонайменше вказану кількість разів.
  • open_file_cache_errors- кешувати інформацію про відсутні файли, значення on.

Основні параметри розглянули. Ці налаштування допоможуть вам отримати більшу продуктивність від nginx. Секцію server та location ми розглянемо у налаштуванні віртуальних хостів.

Налаштування стиснення Gzip

Стиснення контенту необхідно, щоб зменшити розмір даних, що завантажуються браузером. Це прискорює завантаження сайту, але додає додаткового навантаження на процесор сервера. Щоб увімкнути стиснення в секції http, потрібно додати параметр:

Цю директиву можна використовувати також у секції server, тоді вона працюватиме лише для вказівного віртуального домену. Далі налаштовуємо параметри стиснення налаштовуються за допомогою наступних опцій:

  • gzip_min_length- Мінімальна довжина сторінки в байтах, при якій потрібно використовувати стиснення, наприклад, 1000 (1 кб)
  • gzip_proxied- чи потрібно стискати проксовані запити, каже, що потрібно стискати все.
  • gzip_types- типи файлів, які необхідно стискати, наприклад: text/plain application/xml application/x-javascript text/javascript text/css text/json;
  • gzip_disable "msie6"- у IE 6 стиск не підтримується, тому відключаємо.
  • gzip_comp_level- рівень стиснення, доступні варіанти від 1 до 10. 1 - мінімальний, 10 - максимальний стиск.

Налаштування віртуальних хостів

Як ви знаєте, на сервері може розміщуватись декілька сайтів. Всі запити надходять на ip сервера, а nginx вже визначає на основі домену який контент потрібно видати. Для того щоб nginx знав, що до якого домену належить потрібно налаштувати віртуальні хости. Кожен хост прийнято розміщувати в окремому файлі. Налаштування хоста знаходиться в секції server, але оскільки всі файли із sites-enabled імпортуються в секцію http, то логіка структури конфігураційного файлу не порушується.

Розглянемо приклад налаштування:

vi /etc/nginx/sites-enabled/сайт.conf

  • listen 80- вказує, що потрібно очікувати на підключення на порту 80, може також містити опцію default-server, яка означає, що цей домен буде відкриватися, якщо домен не був заданий у запиті.
  • root /var/www/html- директорія, де знаходяться файли сайту.
  • index index.html- сторінка, яка відкриватиметься за замовчуванням.
  • server_name- доменне ім'я сайту.
  • access_log- Файл для запису лога запитів до сервера, може використовуватися як глобально в секції http, так і для певного типу файлів у location.
  • error_log- Лог помилок веб-сервера, може приймати додатковий параметр, що вказує на подробиці лога. warn - максимум, crit - лише критичні помилки.

Це все основні налаштування віртуального хоста, після них він уже працюватиме. Але тут є ще секція location, яка дозволяє настроїти поведінку сервера для певних директорій та файлів. Синтаксис location такий:

location адреса ()

Як адреса може використовуватися як прямий запит щодо кореня сервера, і регулярні висловлювання. Для використання регулярних виразів перед ним встановлюється символ "~". Приклади розглянемо нижче, а поки що розглянемо можливі директиви:

  • allow- дозволити доступ до розташування для користувачів, all - всіх, також можна вказати ip або підсіти.
  • deny- заборонити доступ до розташування, all – для всіх.
  • try-files- намагається відкрити файли у порядку, відкриває перший виявлений файл. Наприклад, така конструкція: $uri $uri/index.html $uri.html =404; спочатку намагається відкрити $uri, потім index.html, якщо не знайдено $uri.html, і аж потім, якщо жодного із прийменникових файлів не існує, видає помилку 404.
  • expires- задає час кешування браузером відданого елемента, наприклад, 1d – один день, 2h – дві години, 30s – 30 секунд.

Крім цих головних директив тут можуть використовуватися й інші. Щоб отримати більше подробиць, дивіться офіційну документацію. Розглянемо кілька прикладів:

Не виконувати логування для favicon:

location = /favicon.ico (
log_not_found off;
access_log off;
}

Заборонити доступ до файлів, що починаються з точки:

location ~ /\. (
deny all;
}

Кешувати звичайні файли на 90 днів:

location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf | |doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ (
access_log off; log_not_found off; expires 90d;

Тема правильного налаштування nginx дуже велика, і, боюсь, в рамках однієї статті на хабрі ніяк не міститься. У цьому тексті я постарався розповісти про загальну структуру конфігу, цікавіші дрібниці і зокрема, можливо, будуть пізніше. :)

Непоганою початковою точкою для налаштування nginx є конфіг, який йде в комплекті з дистрибутивом, але багато можливостей цього сервера в ньому навіть не згадуються. Значно докладніший приклад є на сайті Ігоря Сисоєва: sysoev.ru/nginx/docs/example.html. Однак, давайте краще спробуємо зібрати з нуля свій конфіг, з бриджем та поетесами. :)

Почнемо із загальних налаштувань. Спочатку вкажемо користувача, від імені якого працюватиме nginx (від рута працювати погано, всі знають:))

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

Worker_processes 2;

Уточнимо, куди писати логи помилок. Потім для окремих віртуальних серверів цей параметр можна перевизначити, так що в цей лог будуть сипатися лише «глобальні» помилки, наприклад, пов'язані зі стартом сервера.

Error_log /spool/logs/nginx/nginx.error_log notice; # рівень повідомлень "notice", звичайно, можна міняти

Тепер йде дуже цікава секція Events. У ній можна задати максимальну кількість з'єднань, які одночасно оброблятиме один процес-воркер, і метод, який використовуватиметься для отримання асинхронних повідомлень про події в ОС. Звичайно, можна вибрати тільки ті методи, які доступні на вашій ОС і були включені при компіляції.

Ці параметри можуть вплинути на продуктивність вашого сервера. Їх треба підбирати індивідуально, залежно від ОС та заліза. Я можу навести лише кілька загальних правил.

Модулі роботи з подіями:
- select і poll зазвичай повільніше і досить сильно навантажують процесор, проте доступні практично скрізь, і працюють практично завжди;
- kqueue та epoll - більш ефективні, але доступні тільки у FreeBSD та Linux 2.6, відповідно;
- rtsig - досить ефективний метод і підтримується навіть дуже старими лінуксами, але може викликати проблеми при великій кількості підключень;
- /dev/poll - наскільки мені відомо, працює в дещо екзотичніших системах, типу солярісу, і в ньому досить ефективний;

Параметр worker_connections:
- Загальна максимальна кількість клієнтів, що обслуговуються, дорівнюватиме worker_processes * worker_connections;
- Іноді можуть спрацювати в позитивну сторону навіть найекстремальніші значення, на кшталт 128 процесів, по 128 коннектів на процес, або 1 процесу, але з параметром worker_connections=16384. В останньому випадку, втім, швидше за все знадобиться тюнити ОС.

Events (
worker_connections 2048;
use kqueue; # У нас BSD:)
}

Наступна секція – найбільша, і містить найцікавіше. Це опис віртуальних серверів та деяких параметрів, спільних для них усіх. Я опущу стандартні налаштування, які є у кожному конфізі, типу шляхів до логів.

Http (
# Весь код нижче буде всередині цієї секції %)
# ...
}

Усередині цієї секції можуть бути кілька досить цікавих параметрів.

Системний виклик sendfile з'явився на Linux відносно недавно. Він дозволяє відправити дані до мережі, минаючи етап їх копіювання в адресний простір програми. У багатьох випадках це істотно підвищує продуктивність сервера, тому параметр sendfile краще завжди включати.

Параметр keepalive_timeout відповідає за максимальний час підтримки keepalive-з'єднання, якщо користувач по ньому нічого не запитує. Обміркуйте, як саме на вашому сайті надсилаються запити, та виправте цей параметр. Для сайтів, що активно використовують AJAX, з'єднання краще тримати довше, для статичних сторінок, які користувачі будуть довго читати, з'єднання краще розривати раніше. Врахуйте, що підтримуючи неактивне keepalive-з'єднання, ви займаєте коннекшн, який міг би використовуватися по-іншому. :)

Keepalive_timeout 15;

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

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

Невеликий трюк. У випадку, якщо nginx обслуговує більш ніж один віртуальний хост, має сенс створити «віртуальний хост за замовчуванням», який оброблятиме запити в тих випадках, коли сервер не зможе знайти іншої альтернативи за заголовком Host у запиті клієнта.

# default virtual host
server (
listen 80 default;
server_name localhost;
deny all;
}

Далі може йти одна (або кілька) секцій «server». У кожному їх описується віртуальний хост (найчастіше, name-based). Для власників безлічі сайтів на одному хостингу, або для хостерів тут може бути щось на кшталт директиви

Include /spool/users/nginx/*.conf;

Інші, швидше за все, опишуть свій віртуальний хост прямо в основному конфізі.

Server (
listen 80;

# Зверніть увагу, що в директиві server_name можна вказати кілька імен одночасно.
server_name myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log timed;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Встановимо кодування для віддачі за замовчуванням.

Charset UTF-8;

І скажемо, що ми не хочемо приймати від клієнтів запити довжиною більш ніж 1 мегабайт.

Client_max_body_size 1m;

Включимо для сервера SSI та попросимо для SSI-змінних резервувати не більше 1 кілобайта.

Ssi on;
ssi_value_length 1024;

І, нарешті, опишемо два локейшні, один з яких вестиме на бекенд, до апачу, запущеному на порту 9999, а другий віддавати статичні картинки з локальної файлової системи. Для двох локейшнів це малоосмислено, але для більшого їх числа має сенс також відразу визначити змінну, в якій зберігатиметься кореневий каталог сервера, і потім використовуватиме її в описах локацій.

Сьогодні розглянемо налаштування віртуального хоста, який обслуговує сайт із статичним контентом. Тобто ніяких CGI, Perl, PHP і що з ними. Усі приклади, згадані у статті, відносяться та перевірялися на Debian Linux 5.0 Lenny. Власників інших систем це ніяк не повинно бентежити, оскільки змінюватися можуть тільки шляхи до файлів конфігурації, в той час як їх вміст можна застосувати до будь-якої системи, на якій працює Nginx.

Спосіб зберігання файлів конфігурації

Як можна пам'ятати з попередньої статті, у файлах конфігурації Nginx можна використовувати директиву includeяка вміє включати в основний файл конфігурації вміст інших файлів. Такий підхід забезпечує адміністраторів додатковою гнучкістю конфігурування сервера, що найчастіше заощаджує час та сили.

Якщо ви звернули увагу, в основному конфігураційний файл /etc/nginx/nginx.confнемає жодного слова про конфігурацію віртуальних серверів. Зовсім нічого не сказано про те, де знаходиться корінь документів сервера, на якому порту сервер повинен очікувати вхідних з'єднань та інше. Однак передостаннім рядком у файлі конфігурації записано таке:

Include /etc/nginx/sites-enabled/*;

Тобто з каталогу /etc/nginx/sites-enabledзчитується вміст всіх файлів і застосовується до конфігурації сервера. Заглянувши до згаданого каталогу, ви побачите там один файл default, що є символічним посиланням на файл /etc/nginx/sites-available/default. Також дуже зручний підхід: вам раптом знадобилося відключити якийсь віртуальний хост, ви просто видаляєте символічне посилання, а на морочитеся з переміщенням файлу туди-сюди.

Створення віртуального сервера

Для «чистоти експерименту» пропоную видалити символічне посилання, що поставляється з дистрибутивом /etc/nginx/sites-enabled/defaultі почати, так би мовити, із чистого аркуша.

Створіть файл /etc/nginx/sites-available/myvhostз наступним вмістом:

Server ( listen 80; server_name myvhost; access_log /var/log/nginx/myvhost.log; location / ( root /var/www/myvhost/;

Це і є найпростіша конфігурація віртуального сервера в Nginx. Тепер про параметри, що використовуються по порядку.

Перша опція server, За якою слідує фігурна дужка, починає нову секцію. Саме у секціях serverі описуються конфігурації всіх віртуальних серверів Nginx.

Опцією listenми повідомляємо Nginx номер порту, на якому наш віртуальний сервер повинен очікувати на з'єднання. За замовчуванням значення цієї опції дорівнює 80 , й у наведеному прикладі значення визначено лише наочності. Також за допомогою цієї опції можна вказати не тільки номер порту, але й адресу інтерфейсу, до якого потрібно «причепити» даний сервер. Наприклад, наступні два приклади «вішають» сервер на всі доступні в системі TCP/IP-інтерфейси, на порт 8080:

Listen 8080 listen *:8080

Наступний приклад пов'язує віртуальний сервер з певним мережевим інтерфейсом з IP-адресою 192.168.0.1, очікуючи на вхідні з'єднання на порту 8080:

Listen 192.168.0.1:8080

Опція server_nameвизначає ім'я віртуального сервера, яке використовується при аналізі веб-сервером HTTP-заголовка Host, що надходить від клієнта. Саме ця опція і реалізує налаштування віртуальних хостів, що базуються на імені. Наприклад, ось так виглядатиме фрагмент конфігурації двох віртуальних хостів на одному сервері:

Server ( ... listen 80; server_name example-1.com ... ) server ( ... listen 80; server_name example-2.com ... )

Параметрів у опції server_name може бути більше одного, таким чином можна визначити псевдоніми вашого сервера, наприклад:

Server_name example-1.com www.example-1.com www1.example-1.com

Також можна використовувати символ зірочки, який замінює будь-яку послідовність символів у імені сервера:

Server_name example-1.com *.example-1.com

З параметром access_logми знайомилися у . Значення цього параметра визначає місце розташування та формат лог-файлу доступу до контенту сервера.

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

Наприклад, якщо вам необхідно, щоб при виявленні в URI підрядки /images/, Nginx не звертався до кореневого каталогу сервера, а шукав файли в каталозі /mnt/server2/var/www/images/, можна визначити наступні два location:

Location / ( root /var/www/myvhost/; ) location /images/ ( root /mnt/server2/var/www/; )

У наведених вище прикладах використання location використовується пошук підрядка у рядку URI. Тобто підрядок /images/буде знайдена як у http://server/images/, так і http://server/my/images/. Якщо вам необхідно, щоб Nginx виконував пошук точноговідповідності, для цього можна скористатися символом "=" , який і змушує сервер вести пошук таким чином:

Location = /images/ ( root /mnt/server2/var/www/; )

Також ви можете визначити підрядок, з якого повинен починатися URI. Для цього використовується конструкція із двох символів "^~" :

Location ^~ /images/ ( ... )

Та й регулярні висловлювання підтримуються і дають більшу гнучкість при описі location. Наступний location буде відповідати всім URI, які містять наприкінці імена графічних файлів (без урахування регістру):

Location ~* \.(gif|jpg|jpeg)$ ( ... )

Те саме, але з урахуванням регістру:

Location ~ \.(gif|jpg|jpeg)$ ( ... )

І трохи про порядок черги обробки опцій location в Nginx. Всупереч тому, що багатьом здається на перший погляд, зовсім не має значення (крім регулярних виразів, в якому порядку визначено місце в конфігураційному файлі). Як не міняйте їх місцями, результат буде той самий. При пошуку потрібного локейшену, Nginx слідує наступному алгоритму:

  1. Виконується пошук правила, що починається з "=" . Як тільки таке правило буде знайдено, подальший пошук буде припинено.
  2. Виконується пошук «звичайних» правил, тобто не регулярних виразів. Якщо серед них буде знайдено правило, що починається з "^~" , подальший пошук буде припинено.
  3. Обробляються регулярні висловлювання у порядку, у якому зустрічаються у файлі конфігурації.
  4. Якщо буде знайдено відповідність за п. 3, то використовуватиметься саме цей location, інакше буде використовуватися location, знайдений у п. 2.

Опція rootсвоїм значенням визначає шлях до кореня документів віртуального сервера на файловій системі.

За допомогою опції indexви можете визначити імена файлів індексних документів, які «віддаватиме» клієнтам Nginx, якщо був запрошений доступ до каталогу. Якщо в каталозі такого файлу не виявиться і для цього location вимкнено опцію autoindex, то клієнт у відповідь отримає HTTP-код 403 , що говорить про те, що доступ заборонено.

Опція autoindexналаштовує поведінку Nginx у випадку, якщо в каталозі не знайдений індексний файл, що запитується. Якщо значення опції autoindex, як приклад вище, є "on", то сервер поверне клієнту вміст каталогу як HTML-списку файлів. За замовчуванням autoindex вимкнено, і будьте обережні з нею, щоб ненароком не вивісити на загальний огляд критично важливу інформацію.

Перезапуск сервера

Тепер, коли файл конфігурації готовий, необхідно зробити на нього символічне посилання з каталогу /etc/nginx/sites-enabled/, щоб під час перезапуску Nginx підключив його вміст у свою конфігурацію:

# ln -s /etc/nginx/sites-available/myvhost /etc/nginx/sites-enabled/myvhost

# mkdir /var/www/myvhost

Залишилося перезапустити сервер:

# /etc/init.d/nginx restart

І, якщо всі налаштування були виконані без помилок, ви зможете підключитися до першого віртуального сервера Nginx за допомогою веб-браузера і побачити порожній індекс файлів кореневого каталогу сервера. Спробуйте розмістити пару статичних html-файлів у каталозі /var/www/myshostа потім отримати доступ до них з вашого браузера.

У наступній статті ми розглянемо конфігурацію SSL-сервера Nginx.

Nginx? Призначення, особливості, варіанти налаштувань - це речі, з якими має бути ознайомлений кожен веб-розробник, щоби тестувати свої напрацювання.

Про nginx замовимо слово

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

Запуск, перезавантаження та логи

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

nginx -s сигнал

У цьому випадку підставляти можна такі команди (мають надходити від користувача, що запустив інструмент):

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

Використання утиліт

Налаштування процесів може здійснюватися також за допомогою засобів Unix (як приклад буде розглянуто утиліту kill). Зазвичай вони використовують механізм надсилання процесу сигналу безпосередньо з даними. Вони пов'язуються за допомогою ID. Ці дані зберігаються у файлі nginx.pid. Припустимо, що нас цікавить процес №134. Тоді для плавного завершення нам необхідно надіслати таку інформацію:

kill-s QUIT 1628

Припустимо, ми хочемо переглянути список всіх запущених файлів. Використовуємо для цього утиліту s. Команда ж виглядатиме так:

ps-ax | grep nginx

Тобто, як бачите, при використанні додаткового інструментарію вказується, що саме його застосування. А тепер давайте сконцентруємося на тому, як відбувається nginx-налаштування.

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

Встановлення та налаштування nginxпередбачає роботу із модулями. Вони налаштовуються за допомогою директив, які вказуються у конфігураційному файлі. Вони бувають простими та блоковими. Перший тип директив складається з імені та параметрів, які розділяються за допомогою пробілів, а їх кінець вказується крапкою з комою - (;). Блокова має схожу будову. Але в цій директиві замість закінчення розміщується набір додаткових інструкцій, які розміщують у фігурних скобах ((вказівки)). Якщо в них можна розмістити імена та параметри інших процесів, то називаються такі конструкції вже контекстом. Як приклад можна навести http, location та server.

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

Це одна з найважливіших завдань, яка стоїть перед конфігурацією nginx. Під роздачею статистичного вмісту маються на увазі зображення та HTML-сторінки (не динамічні). Припустимо, що нам потрібна разова робота з налаштування nix nginx кластера. Чи важко це зробити? Ні, і розглянемо приклад. Перш ніж братися до нього, необхідно деталізувати умови завдання. Так, залежно від запитів файли будуть йти з різних локальних каталогів. Так, у /data/www ми маємо HTML-документи. На каталозі /data/images містяться зображення. Оптимальне налаштування nginx у цьому випадку потребує редагування конфігураційного файлу, в якому необхідно налаштувати блок сервер усередині http. Для підтримки буде використовуватися також два місця.

Реалізація: server

Отже, для початку нам необхідно створити самі каталоги та розмістити у них файли з необхідними розширеннями (у html необхідно додати вміст). Потім відкриваємо файл конфігурації. У ньому за замовчуванням вже є кілька блоків server, які у своїй закоментовані. Щоб досягти оптимального результату, цей процес необхідно зробити по відношенню до всіх складових за умовчанням. Потім додаємо новий блок server за допомогою такого коду:

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

Реалізація: location

Визначається всередині server:

Наявність знака «/» необхідно, щоб порівнювати отримані дані та дивитися, чи є така адреса з опрацьованого запиту тут. Якщо проблем немає, то вказуємо шлях /data/www до необхідного файлу, що у цій локальній системі. Якщо збіг є з кількома блоками, то вибирається той, у якого найдовший префікс. У наведеному прикладі його довжина дорівнює одиниці, тобто використання буде виключно в тому випадку, якщо немає конкурентів. Тепер давайте його вдосконалимо:

location /images/ (

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

location /images/ (

Це робочий варіант, який трапляється стандартний. Цей сервер без проблем може бути доступний на локальному комп'ютері, якщо пройти за адресою: 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 з таким вмістом:

А тепер давайте вам розшифрую: створюється простий сервер. Він буде прослуховувати Не вказати listen, то сервер працюватиме на 80-му. Відобразяться всі запити в рамках локальної файлової системи, які спрямовані на каталог /data/up1 (звичайно, його перед цим необхідно буде створити). Для можливості перевірки там необхідно розмістити файл index.html. Завдяки розміщенню директиви root у контексті server ми зможемо скористатися location за будь-яких умов (оскільки таким чином знімаються обмеження доступу). Тепер працюємо над створенням проксі-сервера. Для його роботи нам знадобиться директива proxy_pass, для якої буде вказано протокол, ім'я, а також порт об'єкта як параметри (при локальному підключенні це буде виглядати як http://localhost:8080). Вийде такий результат:

proxy_pass http://localhost:8080;

location /images/ (

Якщо ви розглядаєте код та аналізуєте його, то можете помітити, що другий блок location був змінений. Так, у разі він може працювати з типовими розширеннями зображень. Трохи інакше його можна було б відобразити таким чином:

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

root /data/images;

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

proxy_pass http://localhost:8080/;

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

root /data/images;

Він відфільтровуватиме запити, в кінці яких є вказані розширення, і надсилатиме їх тому, хто попросив файли. Не забувайте, що при бажанні перевірити конфігураційний файл його необхідно буде перезавантажити. І повірте, це найпростіше nginx-налаштування. Якщо відкрити файл конфігурації сервера «Вконтакте» або іншої великої компанії, у них буде коду більше, ніж слів у цій статті.



ПОХОДЖЕННЯ СТАТТІ