> include хороший вариант, но далеко не идеальный.
>
> причин несколько:
>
> 1. для того, чтобы видеть полный конфиг - надо будет постоянно
> переключаться между несколькими конфигурационными файлами,
> например, при просмотре через F3 в mc - это надо часто
> открывать/закрывать несколько файлов, чтобы понять
> логику работы nginx. или использовать screen
> с той же целью. таким образом директива include
> ухудшает читаемость конфига и легкость восприятия.
Ммм... У вас на сервере ограничение на число входов в шелл?
К тому же с инклуды (в данном контексте) выносятся базовые, общие для
всех директивы.
На понимание конфига это никак не влияет. Хотя испортить можно и Машу каслом.

> 2. если есть несколько сотен сайтов, то вполне логичным будет
> делать 1 сайт == 1 конфигурационный файл. использование include
> увеличивает количество конфигурационных файлов в несколько раз.
> что также затрудняет легкость понимания конфигурации nginx.
На один файл. Хотя наизвращаться можно.

> возможных способов решения этих проблем тоже два:
>
> 1. писать свой собственный генератор raw-конфига nginx,
> при этом можно использовать как угодно компактный DSL
> (domain-specific language) так что будет соблюдаться
> принцип "1 сайт == 1 конфиг" и не будет нарушаться
> принцип DRY (Don't Repeat Yourself).
>
> 2. расширить конфиг nginx встроенным средством
> для подстановки блоков, например:
Окей! Файл на сто хостов. С выкрутасами. Строк 500 будет? Запросто!
И где мы этот блок прописывать будем? С Вашей же логикой - чтим, видим блок,
пытаемся вспомнить что там, не получается, скроллим вверх-вниз-вбок, радостно
понимаем что тут все хорошо и... Судорожно ищем где же мы были до этого.
Либо те же самые screen/второй шелл/whatever...

Я не против блока, но данная аргументация слаба и совершенно не решает
озвученной проблемы. А с кучей инклудов все еще хуже. В каком файле искать?
Или блок виден только из этого же файла? А смысл тогда? Профит есть,
но маловат, ИМХО.

> location / {
>   ...
>   use rails_params;
>   ...
> }
>
> это будет примерно то же самое, что и директива include,
> только без необходимости выносить блок в отдельный файл.
> т.е. вместо "include filename;" будет "use blockname;".
>
> причем, понять что именно означает use blockname;
> можно будет гораздо проще, просто задав поиск по конфигу
> имени этого блока - так можно будет легко увидеть
> что именно из себя представляет этот блок
> и где именно он используется.

F9-C-F и вы так же сможете увидить где используется инклуд.
А проблема скролла в одном шелле добавит гораздо БОЛЬШЕ гемора,
нежели инклуд. Особенно в современных редакторах с запоминанием позиции.

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

> фрагменты конфига включаемые через include - это примено
> то же самое, что и глобальные переменные в программе,
> нельзя понять где именно используется этот файл
> не просмотрев полностью весь конфиг nginx.
А чем в этом блок отличается? То же самое - только просмотрев ВЕСЬ конфиг
мы можем знать где он используется. Ограничение видимости рубит профит
в использовании инициализатора того же fcgi - пишем в каждый хост одно и то же.
А еще найдется толпа сами знаете кого, которые будут вписывать инклуды в блоки.
Вам то пофиг, а Игоря тут закидают вопросами.

В общем много чего хорошо расписано, но решения Вами же озвученных проблем,
ИМХО, не описано. А некие удобства слишком малы что бы вводить новую сущность.
А то так и до указателей, виртуальных вункций и стека вызовов дойдем.
C-like во всю глотку. :)
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru