@Umkus7 июл 2013 в 21:33

Nginx boilerplate: Быстрая и изящная настройка nginx

1 мин

38K

Nginx *

+67

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

@MechanisM 7 июл 2013 в 22:37

Хороший проект, для тех кто сам не очень разбирается, но хочет чего-то более функционального из коробки, да или вообще сэкономить время.
У меня за годы использования nginx тоже есть свои наработки, которые образовали собой некий подобный фреймворк, да и у многих других я думаю тоже.
Будучи Django-разработчиком, я написал себе свой скелет django-проекта, который при создании проекта, генерит в том числе и конфиг nginx + конфиг uwsgi и другие. Которые можно симлинкнуть в /etc/nginx/sites-enabled или вообще сделать в конфиге nginx что-то типа:
include /apps/*/*.nginx.conf;
и из каждой папки с проектом будут подхвачены конфиги сгенерированные вместе с django проектом. Точно так-же подхватывает конфиги и uwsgi в режиме emperor.
Обязательно ознакомлюсь с вашим проектом и возможно что-то позаимствую и привнесу.
P.S. у меня не совсем так организовано, я просто это указал в качестве примера.

@akalend 8 июл 2013 в 07:03

мой РНР проект тоже генерит под себя конфиг nginx
что сказано про организацию, то да, автор подошел основательно и структурно — молодец,
спасибо, возможно некоторые настройки мне пригодятся

@antonydevanchi 7 июл 2013 в 23:25

Суховато как-то. Было бы немного лучше если бы некоторый текст из слайдов был бы непосредственно в теле поста :)

@Umkus 8 июл 2013 в 07:56

Я боялся, что это будет очередная вариация поста с заголовком «Настраиваем nginx» :) Но, карма вашего моментария говорит об обратном. Сегодня добавлю больше листингов и текста, спасибо.

@Tranced 8 июл 2013 в 03:49

В favicon.conf также рекомендую добавить файлы apple-touch-icon.png и apple-touch-icon-precomposed.png.
Для iOS устройств это своеобразный favicon.ico, к которому они обращаются при каждом заходе на сайт. Сами файлы также должны лежать в корне.

@Umkus 8 июл 2013 в 07:39

Точно. Спасибо, забыл про них.

@btd 8 июл 2013 в 04:05

А сравнивали с github.com/h5bp/server-configs?

@Umkus 8 июл 2013 в 07:44

Конечно. Некоторые моменты взяты из этого проекта.

@powerman 8 июл 2013 в 13:22

Было бы неплохо хоть в двух словах список отличий упомянуть, т.к. похоже что оба проекта решают одну задачу.

@dronnix 8 июл 2013 в 04:27

Игорь Сысоев рекомендует именно «Всё в одном файле» и «Дублирование настроек».

@powerman 8 июл 2013 в 13:30

Кстати, да. Я с конфигами от H5BP в этом плане помучался — учитывая особенности nginx приоритет некоторых настроек при использовании как-бэ «стандартных» подключаемых кусков конфига определить не так тривиально. В результате стратегия «просто подключить нужные стандартные блоки конфига а потом дописать настройки под нужды конкретного сайта» можно сказать не работает вообще — настройки особенностей конкретного сайта приходится дописывать не после подключённых стандартных блоков, а где-то между, тщательно учитывая приоритеты и порядок выполнения конфига.

@Umkus 8 июл 2013 в 15:24

Если у вас нет 50-ти location-ов в server-е, то всё должно быть относительно просто и логично.
А какие у вас были проблемы с конфигом из html5 boilerplate, если не секрет?

@powerman 10 июл 2013 в 02:59

Имел место бег по граблям когда решил полностью перевести сайты с апача и конвертировал пачки .htaccess-ов в конфиг nginx. В результате у меня в conf-файлах сайтов, сразу после include-ов H5BP появился вот такой коммент:

################
### WARNING! ###
################
# Some of included conf/* files use
#	location ~*
# As result, if you'll match same urls using
#	location =
#	location ^~
# you'll overwrite configuration in included files.
# Otherwise these urls will be handled by configuration in
# included files and default error_page 404.
# If you'll need to modify this behavior - inline content of these
# conf/* files instead of including them and modify it.

@Umkus 10 июл 2013 в 08:31

Ну да, " = " (точное совпадение) и " ^~ "(не пробовать другие регекспы после совпадения) более строгие локейшены, чем простые " * " (регистро зависимый регексп) и " ~* "(регистро независимый регексп).

@FireWind 8 июл 2013 в 04:46

Как то можно вывести на экран текущую действующую конфигурацию, которую nginx собрал из разных подключаемых файлов и применяет?

@SilenceAndy 8 июл 2013 в 07:10

Вот так. Нативная поддержка есть в tengine.

@Umkus 8 июл 2013 в 09:09

Tengine, кстати, интересный проект, панирую его потрогать, как время появится.

@eps 8 июл 2013 в 07:09

Когда я вижу то, что написано в 19 слайде…

server
{
server_name	~^(?!www\.);
return		301 $scheme://www.$host$request_uri;
}

…хочется долго и безутешно плакать. Зачем этот www.? И уж тем более, зачем доводить это до абсурда и приписывать www. к каждому адресу сайта? www. is deprecated, и это уже давно не смешно.

@DmitriyEntelis 8 июл 2013 в 07:19

Это какие то SEO заморочки.
Не имею отношения к SEO напрямую, но клиенты обслуживающиеся у достаточно крупных оптимизаторов типа Ашманова, регулярно приносят вот такие вот требования.

@eps 8 июл 2013 в 07:33

SEO требует, чтобы сайт был доступен по обоим адресам и не было дублирования содержимого на двух разных доменах — отлично, можно сделать перенаправление с кодом 301 с домена www. на домен без www.

Так предлагают на сайте в моём прошлом комментарии, так делает, например, Хабр:

Как делает наш любимый Хабр

--2013-07-08 13:27:14-- www.habrahabr.ru/
Resolving www.habrahabr.ru… 212.24.43.44
Connecting to www.habrahabr.ru|212.24.43.44|:80… connected.
HTTP request sent, awaiting response… 302 Moved Temporarily
Location: habrahabr.ru/ [following]
--2013-07-08 13:27:14-- habrahabr.ru/
Resolving habrahabr.ru… 212.24.43.44
Reusing existing connection to www.habrahabr.ru:80.
HTTP request sent, awaiting response… 200 OK

Правда, всё же тут уместнее код 301 Moved permanently

Но клиент, конечно, всегда прав, даже когда просит бяку.

@Umkus 8 июл 2013 в 07:50

У меня в ближайших планах универсальный редирект без .www в начале (кстати, уже появился реквест на гитхабе). Сам использую его для своих проектов (статичную версию).

@chetzof 8 июл 2013 в 07:53

Вот одно из преимуществ использования www
developer.yahoo.com/performance/rules.html#cookie%5Ffree

Так как в топике речь идет о скорости и оптимизации — данный совет уместен.

@achekalin 8 июл 2013 в 15:03

Зря Вы так. Важно не то, что «все с www» или «все без www», важно, чтобы ваш конкретный сайт откликался на одно и то же имя, а остальные «очевидные» имена либо (глупее) не отвечали, либо (умнее) делали 301 редирект на «правильный» вариант написания.

Вы бы знали, сколько раз я диктовал людям по телефону адреса вроде news.domain.ru, а в ответ слышал «я ввел, как ты сказал, www.news.domain.ru, а он не открывается». Мне лично близка идея иерархического развития именования хостов и доменов — в домене «ru» есть домен «domain», а в нем хост «www», который отвечает на http-запросы, Вам, очевидно, ближе мысли «www is depricated» (тоже вполне логично), но всех под одну гребенку стричь?

Тем более что есть адреса, где www прямо просится, а есть такие, где по звучанию хочется набрать без www. ))

@stanlee 8 июл 2013 в 08:57

Хм, тут просто инклуды готовых конфигов, а у меня панелька с веб интерфейсом под генерацию конфига nginx есть.

@k3NGuru 8 июл 2013 в 10:33

А поделиться с народом?

@Loremaster 8 июл 2013 в 19:36

Поделитесь, пожалуйста, с людьми! Это многим было бы полезно!

@stanlee 9 июл 2013 в 10:53

Это часть моей экосистемы, а не отдельный продукт, поэтому могу только рассказать на пальцах.
Интерфейс состоит из добавляемых полей, каждое из которых отвечает за location, и несколько отдельных параметров, например, вести логи или нет, включить fpm или нет и так далее.
Потом все уходит в журнальную таблицу в виде json массива.
На сервере крон смотрит если ли задачи по nginx и собирает конфиг.
Вот так все просто реализовано.

@Umkus 12 июл 2013 в 15:13

Может, хоть, со скриншота покажете? :)

@ashel 12 июл 2013 в 10:43

Вопрос к автору — а как это заточить под несколько доменов на одном VPS? Размножение конфигов в /sites/ не помогает.

@Umkus 12 июл 2013 в 14:59

Если речь о создании нескольких виртуальных хостов (server{}) и они не подхватываются, нужно смотреть error_log. Конфиги должны иметь расширение ".conf". Может проблема в настройках DNS/hosts. Уточните вопрос.

@ashel 29 июл 2013 в 06:35

Спасибо, разобрался. Дело и правда в моих кривых руках.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий