Pull to refresh

Comments 31

Хороший проект, для тех кто сам не очень разбирается, но хочет чего-то более функционального из коробки, да или вообще сэкономить время.
У меня за годы использования nginx тоже есть свои наработки, которые образовали собой некий подобный фреймворк, да и у многих других я думаю тоже.
Будучи Django-разработчиком, я написал себе свой скелет django-проекта, который при создании проекта, генерит в том числе и конфиг nginx + конфиг uwsgi и другие. Которые можно симлинкнуть в /etc/nginx/sites-enabled или вообще сделать в конфиге nginx что-то типа:
include /apps/*/*.nginx.conf;
и из каждой папки с проектом будут подхвачены конфиги сгенерированные вместе с django проектом. Точно так-же подхватывает конфиги и uwsgi в режиме emperor.
Обязательно ознакомлюсь с вашим проектом и возможно что-то позаимствую и привнесу.
P.S. у меня не совсем так организовано, я просто это указал в качестве примера.
мой РНР проект тоже генерит под себя конфиг nginx
что сказано про организацию, то да, автор подошел основательно и структурно — молодец,
спасибо, возможно некоторые настройки мне пригодятся
Суховато как-то. Было бы немного лучше если бы некоторый текст из слайдов был бы непосредственно в теле поста :)
Я боялся, что это будет очередная вариация поста с заголовком «Настраиваем nginx» :) Но, карма вашего моментария говорит об обратном. Сегодня добавлю больше листингов и текста, спасибо.
В favicon.conf также рекомендую добавить файлы apple-touch-icon.png и apple-touch-icon-precomposed.png.
Для iOS устройств это своеобразный favicon.ico, к которому они обращаются при каждом заходе на сайт. Сами файлы также должны лежать в корне.
Точно. Спасибо, забыл про них.
Конечно. Некоторые моменты взяты из этого проекта.
Было бы неплохо хоть в двух словах список отличий упомянуть, т.к. похоже что оба проекта решают одну задачу.
Кстати, да. Я с конфигами от H5BP в этом плане помучался — учитывая особенности nginx приоритет некоторых настроек при использовании как-бэ «стандартных» подключаемых кусков конфига определить не так тривиально. В результате стратегия «просто подключить нужные стандартные блоки конфига а потом дописать настройки под нужды конкретного сайта» можно сказать не работает вообще — настройки особенностей конкретного сайта приходится дописывать не после подключённых стандартных блоков, а где-то между, тщательно учитывая приоритеты и порядок выполнения конфига.
Если у вас нет 50-ти location-ов в server-е, то всё должно быть относительно просто и логично.
А какие у вас были проблемы с конфигом из html5 boilerplate, если не секрет?
Имел место бег по граблям когда решил полностью перевести сайты с апача и конвертировал пачки .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.
Ну да, " = " (точное совпадение) и " ^~ "(не пробовать другие регекспы после совпадения) более строгие локейшены, чем простые " * " (регистро зависимый регексп) и " ~* "(регистро независимый регексп).
Как то можно вывести на экран текущую действующую конфигурацию, которую nginx собрал из разных подключаемых файлов и применяет?
Tengine, кстати, интересный проект, панирую его потрогать, как время появится.
Когда я вижу то, что написано в 19 слайде…

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

…хочется долго и безутешно плакать. Зачем этот www.? И уж тем более, зачем доводить это до абсурда и приписывать www. к каждому адресу сайта? www. is deprecated, и это уже давно не смешно.
Это какие то SEO заморочки.
Не имею отношения к SEO напрямую, но клиенты обслуживающиеся у достаточно крупных оптимизаторов типа Ашманова, регулярно приносят вот такие вот требования.
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


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

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

Тем более что есть адреса, где www прямо просится, а есть такие, где по звучанию хочется набрать без www. ))
Хм, тут просто инклуды готовых конфигов, а у меня панелька с веб интерфейсом под генерацию конфига nginx есть.
А поделиться с народом?
Поделитесь, пожалуйста, с людьми! Это многим было бы полезно!
Это часть моей экосистемы, а не отдельный продукт, поэтому могу только рассказать на пальцах.
Интерфейс состоит из добавляемых полей, каждое из которых отвечает за location, и несколько отдельных параметров, например, вести логи или нет, включить fpm или нет и так далее.
Потом все уходит в журнальную таблицу в виде json массива.
На сервере крон смотрит если ли задачи по nginx и собирает конфиг.
Вот так все просто реализовано.
Может, хоть, со скриншота покажете? :)
Вопрос к автору — а как это заточить под несколько доменов на одном VPS? Размножение конфигов в /sites/ не помогает.
Если речь о создании нескольких виртуальных хостов (server{}) и они не подхватываются, нужно смотреть error_log. Конфиги должны иметь расширение ".conf". Может проблема в настройках DNS/hosts. Уточните вопрос.
Спасибо, разобрался. Дело и правда в моих кривых руках.
Sign up to leave a comment.

Articles