Обновить

Я устал каждый раз гуглить одно и то же в nginx — и сделал инструмент, который объясняет конфиги на русском

Уровень сложностиСредний
Время на прочтение4 мин
Охват и читатели15K
Всего голосов 19: ↑19 и ↓0+22
Комментарии18

Комментарии 18

Круто, а зачем? Генератор от digital ocean есть давно, а в остальном - если делаешь типовые вещи, то автоматизируй. Я лет 5 назад сделал простейший, базовый nginx.conf, сдела пару каталогов, куда напихал типовые конфиги для логов, сжатия, проксирования и всего прочего, а так же простые шаблоны, со всеми proxy_pass.

И шаблон можно инклюдить в блок server одной командой, а уже в шаблоне у вас редиректы, реверс прокси, acme клиенты, auth_basic, да что угодно, опять же через простые include и переменные. Разве что логи и серты руками прописывать, ну и апстримы

Можно и вам было давно это сделать

Спасибо!

Как раз согласен, что если ты 5+ лет живёшь в nginx и у тебя уже есть свой базовый конфиг + набор include’ов, то этот инструмент тебе вряд ли нужен. Я делал NginxForge не вместо такого подхода, а для другой ситуации:

• ты настраиваешь nginx не каждый день, а раз в несколько месяцев;

• у тебя нет “семейного” базового конфига, который кочует из проекта в проект;

• каждый раз всё начинается с трёх вкладок: дока, старый конфиг и какой‑нибудь ответ про proxy_pass со слэшем или без.

То есть по сути NginxForge = “готовый базовый конфиг + шаблоны”, только:

• они уже собраны под разные сценарии (reverse proxy, microservices, Django, Node.js и т.д.);

• каждую директиву можно подсмотреть с аннотацией на русском;

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

Если у человека уже есть своя отлаженная библиотека шаблонов — это вообще лучший вариант. NginxForge скорее для тех, кто до такой библиотеки ещё не дошёл или не хочет в неё инвестировать время, но при этом не хочет каждый раз собирать конфиг с нуля и бояться, что где‑то упустил server_tokens или протоколы TLS.

Так это, я тут как специалист по автоматизации говорю, что не важно, как часто. Если пошли одни и теже настройки, то сделай шаблон и выкини куда. По сути все «базовые шаблоны» это либо реверс, либо статика (редкость в наше время). И все эти пресеты уже есть у Digital Ocean инструмента. Он даже отдельно лежит. Гонять nginx -t прикольно, а зачем? Это базовый валидатор, как и сказано. Он не покажет ни мусоры, ни работоспособность, только явные ошибки в синтаксисе.

Я о том, что это достаточно сделать единожды для большинства проектов и не ломать голову. Крайне вряд ли, что у вас будет скакать синтаксис.

Да и в целом, чаще выгоднее взять тот же traefik, так же его настроить и всё. Его задача первичная маршрутизация, хотя по хорошему он вообще должен работать только с сертами и компрессией, плюс логировать доступ, а остальным, включая заголовки, заниматься приложение.

Плюс я у вас вижу token off, ок которого мало проку (древнейшая рекомендация по сокрытию версий, хотя у многих торчит инфа о nginx 1.18 и им ничего), зато не вижу ничего о quic, о том же http3 on и прочем реально полезном в секциях main и http

Справедливо по нескольким пунктам — спасибо, что развернул.

По Traefik согласен: если проект с самого начала строится на docker-compose и оркестрации, Traefik или Caddy — более органичное решение. NginxForge заточен именно под сценарий «мне нужен nginx, и я хочу получить рабочий конфиг без боли», а не под замену оркестратора.

По server_tokens off : Директива стоит в шаблоне как базовый гигиенический минимум по CIS Benchmark, наряду с отключением лишних методов и скрытием заголовка X-Powered-By на уровне upstream.

По HTTP/3 и QUIC — согласен. Это реальный пробел: http3 on, quic, add_header Alt-Svc, listen 443 quic reuseport — всё это должно быть в секции http и в шаблонах реверс-прокси. Сейчас этого нет, и ты прав, что это уже не экзотика, а мейнстрим начиная с nginx 1.25. Возьмем в доработку, спасибо за фидбэк.

Ответ нейросетей

забавно что раньше на малых проектах докидывал к nginx скрипт с certbot через cron, а сейчас использую angie/traefik/caddy.

В какой-то момент стало понятно: я повторяю один и тот же процесс раз за разом, каждый раз заново выясняя то, что уже знал полгода назад.

У меня просто на гитхабе репо с шаблонами, базовыми операциями и описанием или прям в гист делиться с сообществом еще можно, так сказать шпаргалка.

Это отличный вариант, если у тебя уже есть свой отлаженный набор кусочков и понятно, как их собирать.


Я делал для другой ситуации — когда хочется не лезть в репо/заметки, а выбрать сценарий, задать пару параметров и сразу получить готовый конфиг с аннотациями и проверкой через реальный nginx -t.

Спасибо мне пригодится!

Рад, что пригодится 🙂


Если в процессе чего‑то не будет хватать или что‑то сломается — напишите, буду только рад фидбэку.

А чем это принципиально удобнее от "Ctrl+c ->Ctrl+v в чат ИИ"?

Несколько вещей:

1) структурированная форма не даст забыть про SSL, gzip, worker_processes — ИИ в чате легко упустит детали если не попросить явно;

2) конфиг сразу проверяется реальным nginx -t — ИИ может написать синтаксически неверный конфиг и не узнает об этом;

3) каждая директива с русским объяснением прямо в тексте — не надо гуглить что значит proxy_pass_header или keepalive_timeout;

4) share-ссылка — можно скинуть коллеге готовый конфиг.

Ну хз хз по факту такую проблему по большей части решает готовый конфиг на одном из серверов.

Из того что бы добавил, потому что для некоторых это реально проблема Есть фронтендеры которые отдают свою статику через nginx и Бэкенд вешают на отдельный порт, потому что не умеют в location

Собственно если делать генератор, то вот как раз для таких бы функционал добавить, потыкал и такого не нашел. Вот это бы решило проблему, давал бы ресурс с фразой “разбирайся”

А то в коде фронтенда пишут localhost и шлют запросы так, а потом удивляются почему на сервере не работает…

Спасибо, это реально полезный кейс — добавим в отдельный шаблон. «Фронт (SPA) + API на отдельном порту» — классическая ситуация, когда человек застревает именно на location /api/ и proxy_pass. Будет отдельным сценарием в следующем обновлении.

Не успеваю перевести курсор на ссылку, окно слишком быстро пропадет.

Спасибо за инфо!
Не заметил сразу, проблема связана с используемым Tooltip в PrimeVue v4, техническая особенность... Заменил на Popover - теперь поведение адекватное, можно кликнуть

https://github.com/yandex/gixy

А как же gixy от Яндекса как статический локальный анализатор? Забыли за 10 лет?

Спасибо!

В шаблоне SPA + API не верно отрабатывает переключатель server_tokens off
В шаблоне SPA + API не верно отрабатывает переключатель server_tokens off
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации