Англійська для налаштування Nginx

Вимова: /ˈɛndʒɪn ɛks/ («двигун-x») — поширена причина для занепокоєння для тих, хто читає його як «N-jinks» вперше. Окрім назви, лексика налаштування — блоки серверів, початкові потоки, розташування — є тим, що робить обговорення налаштування зворотного проксі- сервера точним, а не складним.

Ключовий словник

** Серверний блок ** — розділ налаштування Nginx ( server { ... } ), який визначає, як обробляти запити на певну назву вузла і порт, приблизно аналогічно віртуальному вузлу. “Ми маємо окремі серверні блоки для піддоменів API і маркетингового сайту, навіть якщо вони обслуговуються з одного екземпляра Nginx.”

** Блок розташування ** — розділ у блоку сервера, який відповідає певному шаблону шляху URL і визначає, як обробляти запити на цей шлях, наприклад, за допомогою проксі, обслуговування статичних файлів або переспрямування. “Блок розташування /api/ є проксі-сервером для backend, в той час як блок розташування / обслуговує статичну збірку frontend безпосередньо.”

Upstream — названа група серверів, через які Nginx може завантажувати балансові запити, визначена один раз і вказана за назвою в директивах proxy_pass. “Ми визначили початковий поток з трьома екземплярами сервера, тому Nginx обробляє запити через всі три, замість того, щоб працювати на одному сервері.”

Reverse proxy — Nginx перенаправляє запит клієнта на сервер backend і повертає відповідь backend клієнту, на відміну від обслуговування самого вмісту, дозволяючи Nginx сидіти перед серверами програм для закінчення TLS, кешування і балансування навантаження. “Nginx тут діє як зворотній проксі — він завершує TLS, а потім пересилає простий запит HTTP на сервер програми, запущений на localhost.”

Directive — єдина інструкція налаштування ( proxy_pass, listen, root ), яка встановлює одну певну поведінку у блоку, основний блок збирання файла налаштувань Nginx. “Директива proxy_read_timeout все ще була встановлена на типове значення шістдесят секунд, що відрізало наші довші запиту.”

Звичайні фрази

• Який серверний блок насправді обробляє це ім’я вузла?
• «Це запит проходить через зворотний проксі, або обслуговується як статичний файл безпосередньо?»
• Чи можемо ми додати другий сервер до верхнього рівня для балансування навантаження?
• «Що робить блок розташування для цього шляху відповідає — це збіг префіксів або точний збіг?»
• Яка директива контролює запит timeout тут?

Приклади висловлювань

Пояснення налаштування маршрутизації співробітнику команди: “Nginx налаштовується як зворотній проксі перед трьома екземплярами програм, визначених у блоку початкового рівня — блок розташування для /api/ проксі там, в той час як все інше переходить на статичний файловий сервер.”

Зневадження помилки 504: “Базен займав більше часу, ніж типовий proxy_read_timeout, тому Nginx переривав з’єднання на шістдесят секунд і повертав 504 — ми збільшили цю директиву до 120 секунд для цього конкретного блоку розташування.”

Опис налаштування для декількох сайтів: “Ми запускаємо чотири різні сайти з одного екземпляра Nginx, використовуючи окремі серверні блоки, кожен з яких слухає на тому ж порту, але відповідає директиві server_name.”

Професійні поради

• Скажімо, ** серверний блок **, а не “конфігурація”, коли є декілька сайтів на одному екземплярі Nginx — це точний блок, який визначає, які правила застосовуються до якої назви вузла.
• Розрізняти блок ** розташування ** від блоку ** сервера ** явно під час обговорення маршрутизації — правила, засновані на шляху, мешкають у блоках розташування, правила, засновані на назві вузла, мешкають у блоках сервера.
• Посилайтеся на ** upstream ** за назвою, коли обговорюєте балансування навантаження або стан сервера — « сервер » є неоднозначним, якщо за ним стоїть більше одного сервера.
• Назва конкретної ** директиви ** при помилці під час зневадження тайм- аута або проблеми маршрутизації — « конфігурація неправильна » є набагато менш дієвою, ніж « директива proxy_read_timeout занижена »

Практичні вправи

1. Напишіть речення, у якому пояснюється різниця між блоком сервера і блоком розташування.
2. Поясніть, для чого використовується потік.
3. Опишете вашими словами, що означає « Nginx, що діє як зворотній проксі ».

На практиці: Навігація та співпраця

Будьмо чесними - ефективно спілкуватися про технічні конфігурації, особливо коли ви не є рідною мовою англійською, може відчувати себе неймовірно пригнічуючим. Одне — це зрозуміти технічне значення «серверного блоку» або «вихідного коду», але зовсім інше — чітко і впевнено сформулювати ці поняття у коментарі до перегляду коду, у дискусії на Slack або в описі запитів на витяг. Метою є не просто стверджувати, що ви зробили; це запропонувати співпрацю, запросити зворотній зв’язок і переконатися, що всі розуміють обґрунтування вашого вибору.

Поширеним сценарієм є отримання зворотнього зв’ язку щодо налаштування Nginx. Уявіть таке повідомлення Slack: «Привіт @developer_name, чи можете ви трохи розібратися, чому ви налаштували декілька upstream серверів для цієї програми? Це виглядає трохи складно; чи є якісь особливі обставини, які впливають на швидкість роботи цього проекту?» Безпосередній переклад з вашої рідної мови може здатися вам незграбним і, можливо, нечітким. Замість цього, націлюйтеся на фрази типу: «Я використовував декілька верхніх потоків для поліпшення стійкості і розподілу трафіку між різними серверними екземплярами, зменшуючи потенційні вузли під час пікових навантажень. Це дозволяє нам масштабувати більш ефективно і підтримувати послідовний досвід користувача.” демонструє розуміння * чому * за конфігурацією і проактивно вирішує потенційні проблеми. Аналогічно, при написанні опису PR, ви хочете вийти за рамки простого переліку параметрів: «Ця PR вводить серверний блок Nginx для піддомену api, використовуючи групу «example-upstream» з трьома серверами для балансування навантаження. Це налаштування забезпечує надлишковість і дозволяє майбутнє масштабування запитів API. ”

Важливо пам’ятати, що технічна англійська часто стосується точності і обґрунтованості. Не просто стверджуйте факт; поясніть * чому * це важливо. Використовуйте активний голос, коли це можливо — « Я налаштував…» замість « Його налаштував…». І будьте відкриті до пропозицій! Добре структуроване пояснення, навіть якщо воно спочатку буде неоднозначним вашою рідною мовою, зможе збудувати довіру і сприяти більш продуктивному середовищу співпраці. Спробуйте переконати інших у тому, що ви розглядаєте потенційні проблеми, і запропонуйте іншим долучитися до розробки.

Ось приклад використання nginx -t для перевірки ваших налаштувань:

sudo nginx -t

За допомогою цієї команди можна перевірити синтаксис ваших файлів налаштувань Nginx і повідомити про всі помилки. Зрозуміти вивід - “файл налаштувань /etc/nginx/conf.d/default.conf тест успішно” - це критично, і чітке повідомлення про те, що ви запустили цей крок перевірки під час перегляду показує старанність. Цей параметр також надає змогу іншим користувачам швидко перевірити ваші зміни, не перевіряючи всі параметри вручну.