Nginx Vocabulary: 25 Terms for DevOps and Backend Developers (англійською)
Блоки сервера Nginx, розташування, proxy_ pass, початок потоку, закінчення SSL і словник налаштувань веб- сервера.
Якщо ви працюєте у галузі розробки серверів або DevOps, ви неминуче зіткнетеся з Nginx — одним з найбільш широко використовуваних веб- серверів і зворотних проксі- серверів у галузі. Незалежно від того, приєднуєтеся ви до нової команди, переглядаєте запити на звантаження або берете участь у обговоренні архітектури, розуміння мови навколо налаштування Nginx є обов’ язковим.
Ця стаття охоплює 20 основних термінів Nginx, пояснює, що кожен з них означає простою англійською, і показує вам, як справжні розробники використовують їх у повсякденній розмові. До кінця курсу ви зможете спостерігати за технічними обговореннями щодо налаштування веб- сервера і робити свій внесок у їх обговорення.
Основні терміни конфігурації
nginx.conf — головний файл налаштувань Nginx, зазвичай розташований у /etc/nginx/nginx.conf. У ньому визначено загальні параметри, такі як робочі процеси, шляхи журналювання, а також інші файли налаштувань, які слід завантажити.
Перед перезапуском служби, двічі перевірте nginx.conf — хтось може залишити синтаксичну помилку в ньому
«Ми зберігаємо nginx.conf мінімальним і завантажуємо все інше через директиви include.»
** серверний блок ** — блок налаштування всередині nginx.conf (або включений файл), який визначає, як Nginx обробляє запити для певного домену або IP-адреси. Це приблизно еквівалентно Apache VirtualHost.
«Кожна з наших мікросервісів має свій власний серверний блок, тому ми можемо керувати маршрутизацією незалежно.»
«Я додав серверний блок для доменного імені і вказував на порт 3001»
** location block ** — директива всередині серверного блоку, яка відповідає шляхам URL і визначає, як Nginx має обробляти запити на ці шляхи.
«Ми маємо блок розташування, який маршрутизує все під
/api/до бекенду і обслуговує все інше як статичні файли»
Блок розташування для
/uploads/має окрему політику кешування, тому що ці активи рідко змінюються
include directive — інструкція, яка наказує Nginx завантажити інший файл або набір файлів до поточного налаштування. Це допомагає зберігати великі налаштування впорядкованими і зручними для підтримки.
«Ми використовуємо директиву include, щоб затягнути всі конфігурації сайту з
/etc/nginx/sites-enabled/.»
«Замість того, щоб дублювати налаштування SSL скрізь, я витягнув їх у спільний файл і використовував include, щоб посилатися на нього»
worker process — окремий процес операційної системи, створений Nginx для обробки вхідних з’ єднань. Кількість робочих процесів зазвичай встановлюється так, щоб вона відповідала кількості ядер процесора на сервері.
«Ми маємо чотири ядра на цьому блоку, тому я встановлюю worker_processes на чотири — кожен робочий процес обробляє свій власний набір з’єднань»
Якщо ви бачите високий процесор на одному ядрі, це може бути тому, що кількість ваших робочих процесів не налаштована для машини
** worker connections ** — параметр у блоку events, який визначає максимальну кількість одночасних з’ єднань, які може обробляти кожен робочий процес.
«Ми збільшили worker_connections до 2048 після того, як тест навантаження показав, що ми досягли типового обмеження.»
«Работні з’єднання помножені на робочі процеси дають вам теоретичний максимум одночасних з’єднань»
Прокси і балансування навантаження
** зворотний проксі ** — сервер, який знаходиться перед однією або декількома службами сервера і пересилає запити клієнтів до цих служб. З точки зору клієнта, вони розмовляють зі зворотним проксі, а не з сервером безпосередньо. Nginx зазвичай використовується як зворотний проксі перед Node.js, Python або Java-застосунками.
«Nginx діє як зворотний проксі тут — клієнти вдаряють по порту 443 і ми перенаправляємо до програми на порт 3000 внутрішньо.»
Однією з переваг зворотного проксі є те, що ви можете обмінюватися або масштабувати бекенди без торкання DNS
** proxy_ pass ** — директива Nginx, яка вказує, куди пересувати запит, коли виконується роль зворотного проксі. За його значення приймається адреса URL або назва джерела.
Додати
proxy_pass http://localhost:8080;всередині блоку розташування і Nginx перенаправить трафік до вашого додатку
«Ми використовуємо proxy_pass з ім’ям початкового потоку, а не з твердим IP, щоб ми могли додати більше вузлів пізніше.»
** upstream ** — названа група серверів, які використовуються для балансування навантаження. Ви визначаєте блок початкового рівня зі списком серверів, і Nginx розподіляє вхідні запити між ними.
«Визначте блок upstream з обома серверами додатків, а потім вказуйте proxy_pass на ім’я upstream — це все, що вам потрібно для базового балансування навантаження»
«Блок upstream підтримує різні стратегії балансування: round-robin є типовим, але ви можете переключитися на least_conn, якщо ваші запити змінюються у часі обробки.»
** keepalive ** — параметр з’ єднань з початковими серверами, який надає змогу Nginx повторно використовувати існуючі з’ єднання з серверами, замість того, щоб відкривати нове TCP- з’ єднання для кожного запиту. Це зменшує затримку і використання ресурсів.
Ми додали
keepalive 64;до блоку на верхньому рівні і побачили помітний спад у часі відповіді під навантаженням
«Без keepalive, Nginx відкривав нове з’єднання з сервером додатків при кожному запиті — не ідеально»
SSL, HTTP, і продуктивність
** Завершення SSL/TLS ** — процес розшифровки HTTPS-трафику на рівні Nginx, щоб серверні служби отримували простий HTTP. Шифроване з’ єднання закінчується (закінчується) на Nginx, саме тому цей процес називається завершенням.
«Ми обробляємо SSL/TLS закінчення на балансувальнику навантаження, тому бекенд програми тільки коли-небудь бачать простий HTTP у внутрішній мережі.»
«Централізація SSL-закінчення в Nginx означає, що нам потрібно тільки керувати сертифікатами в одному місці»
** HTTP/ 2 ** — друга основна версія протоколу HTTP, яка покращує продуктивність за допомогою таких можливостей, як мультиплексування запитів (направлення декількох запитів за допомогою одного з’ єднання) і стиснення заголовків. Nginx підтримує HTTP/2 на HTTPS з’єднаннях.
«Ми ввімкнули HTTP/2 в серверному блоку і це зробило вимірну різницю на сторінках з великою кількістю невеликих активів»
HTTP/2 вимагає HTTPS, тому вам потрібно спочатку встановити SSL-завершення
** gzip compression ** — параметр, який наказує Nginx стискати відповіді перед їх надсиланням до клієнта. Це зменшує кількість даних, що передаються за допомогою мережі, що прискорює завантаження сторінок.
«Включити gzip стиснення для текстових відповідей — HTML, CSS, JS, і JSON всі стискаються добре.»
«Ми ввімкнули gzip, але забувають додати
application/jsonдо списку типів MIME, тому відповіді API не стискалися»
** заголовки кешу ** — заголовки відповідей HTTP (наприклад, Cache-Control і Expires ), які повідомляють переглядачам і проксі- серверам про термін зберігання кешованої копії ресурсу. Nginx може додавати або змінювати ці заголовки.
Статичні активи отримують кеш-заголовки з один рік макс-вік, оскільки ми використовуємо content-hashed файлових імен
«Упевніться, що заголовки кешу на відповідях API встановлені на
no-store— ми не хочемо, щоб вони кешувались ніде»
** обмеження швидкості ** ( limit_req ) — можливість, яка обмежує кількість запитів, які клієнт може надати за певний проміжок часу. Він використовується для захисту служб від зловживання, атак з використанням грубої сили і піків трафіку.
«Ми додали
limit_reqна кінцевій точці входу, щоб запобігти спробам грубого насильства — десять запитів на хвилину на IP»
« Обмеження швидкості налаштовується у дві частини: ви визначаєте зону у блоку http, а потім вказуєте на неї за допомогою limit_ req всередині блоку адреси. »
Маршрутизація, перезаписування і журналювання
** try_ files ** — директива, яка наказує Nginx перевіряти файли або каталоги у вказаному порядку і обслуговувати перший з існуючих, повертаючись до останнього параметра (зазвичай, це файл PHP або назване місце), якщо їх не знайдено. Він широко використовується для односторінкових застосунків і PHP-фреймворків.
Для React-застосунку ми використовуємо
try_files $uri $uri/ /index.html;, щоб глибинне посилання працювало правильно
Якщо try_files не може знайти статичний файл, він переходить до резервного index.php — саме так працює маршрутизація WordPress в Nginx
** правило перезапису ** — директива, яка змінює адресу URL вхідного запиту, або перенаправляючи клієнта на нову адресу URL, або змінюючи шлях внутрішньо, перш ніж Nginx обробить його далі.
«Ми додали правило перезапису для перенаправлення всього HTTP-трафіку на HTTPS за допомогою постійного перенаправлення 301»
«Будьте обережні з правилами переписування — вони можуть створювати петлі перенаправлення, якщо ви не точні з умовами»
** error_ page ** — директива, яка вказує нетипову відповідь або перенаправлення для певних кодів помилок HTTP, наприклад, 404, 500 або 503.
«Налаштувати error_page для 502, щоб користувачі бачили приємне повідомлення про підтримку замість порожнього екрана, коли backend не працює.»
«Ми маємо спільний файл error_page include, який обробляє помилки 404, 403 і 5xx послідовно на всіх наших сайтах»
** журнал доступу / журнал помилок ** — два типи файлів журналу, які Nginx записує типово. Журнал доступу записує кожен запит (IP- адресу клієнта, код стану, час відповіді тощо). У журналі помилок записуються проблеми, такі як невдалі з’ єднання з попередніми користувачами або помилки налаштування.
«Перевірте журнал помилок спочатку — він точно скаже вам, чому Nginx повертає 502.»
«Ми відправляємо журнал доступу до нашого аналітичного конвеєра, щоб ми могли відстежувати реальний трафік користувача без клієнтських скриптів»
** map module ** — модуль Nginx, який надає вам змогу створювати змінні, значення яких залежать від інших змінних, ефективно створюючи таблиці пошуку у вашому налаштуванні. Це корисно для умовної логіки без складних if-заяви.
«Ми використовуємо модуль карти для перекладу рядків user-agent в категорії пристроїв, а потім маршрутизуємо мобільний трафік до іншого бекенду»
Модуль мапування набагато ефективніший, ніж ланцюг блоків if — Nginx оцінює мапування ліниво
Як використовувати їх у розмові
Знать условия - это только половина победы. Ось як ви можете почути їх у поєднанні у справжніх обговореннях команди:
** Під час перегляду коду: **
Проксі-прохід в цьому блоку розташування вказує безпосередньо на IP — чи можемо ми пересунути це в блок попереднього потоку, щоб у нас було місце для додавання більшої кількості вузлів пізніше?
** Під час інциденту: **
“Журнал помилок показує, що час очікування на верхньому рівні закінчився - схоже, що обмеження на підключення до робочого процесу було досягнуто під час піку трафіку. Давайте збільшимо його і також додамо обмеження швидкості на публічних кінцевих точках»
** Під час обговорення архітектури: **
«Ми будемо обробляти SSL/TLS-завершення на рівні Nginx, вмикати HTTP/2, і використовувати gzip-стискання на всіх текстових відповідях. Модуль карти може обробляти логіку маршрутизації A / B, тому нам не потрібні прапорці функцій на рівні програми для цього»
** Під час запуску: **
«Наша конфігурація Nginx розділена на файли для кожного сайту в
sites-enabled/— кожен з них затягується директивою include з nginx.conf. Визначення, що надходять з початкового коду, зберігаються у окремому файлі. Try_files обробляє маршрутизацію SPA на інтерфейсних програмах»
Таблиця швидких посилань
| Term | What it does |
|---|---|
| server block | Defines how Nginx handles a domain or IP |
| location block | Matches URL paths and sets per-path behaviour |
| proxy_pass | Forwards requests to a backend server or upstream |
| upstream | Named group of backends for load balancing |
| SSL/TLS termination | Decrypts HTTPS at Nginx; backends receive plain HTTP |
| try_files | Checks for files in order; fallback for SPAs and PHP |
| limit_req | Rate limiting — caps requests per IP per time window |
| gzip compression | Compresses responses to reduce transfer size |
| access log / error log | Records requests and problems respectively |
| map module | Lookup-table variables for conditional routing logic |
Завдяки оволодінню словником Nginx ви станете ефективнішим комунікатором у будь- якій команді, що працює над веб- інфраструктурою. Ці терміни постійно з’ являються в оглядах коду, пост- смертних інциденти, і обговорення архітектури — тому чим швидше ви будете впевнені з ними, тим швидше ви зможете робити внесок і бути зрозумілими.