предложение по дальнейшему развитию/улучшению nginx.

Игорь, хотелось бы узнать Ваше мнение по этому вопросу.

On 06.07.2011 11:30, Роман Москвитин wrote:

> use "include", Luke!!!
> Как раз одно из предназначений - убивать дубли!

include хороший вариант, но далеко не идеальный.

причин несколько:

1. для того, чтобы видеть полный конфиг - надо будет постоянно
переключаться между несколькими конфигурационными файлами,
например, при просмотре через F3 в mc - это надо часто
открывать/закрывать несколько файлов, чтобы понять
логику работы nginx. или использовать screen
с той же целью. таким образом директива include
ухудшает читаемость конфига и легкость восприятия.

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

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

возможных способов решения этих проблем тоже два:

1. писать свой собственный генератор raw-конфига nginx,
при этом можно использовать как угодно компактный DSL
(domain-specific language) так что будет соблюдаться
принцип "1 сайт == 1 конфиг" и не будет нарушаться
принцип DRY (Don't Repeat Yourself).

2. расширить конфиг nginx встроенным средством
для подстановки блоков, например:

block rails_params {
...
}

и дальше в конфиге nginx:

location / {
...
use rails_params;
...
}

это будет примерно то же самое, что и директива include,
только без необходимости выносить блок в отдельный файл.
т.е. вместо "include filename;" будет "use blockname;".

причем, понять что именно означает use blockname;
можно будет гораздо проще, просто задав поиск по конфигу
имени этого блока - так можно будет легко увидеть
что именно из себя представляет этот блок
и где именно он используется.

кроме того, блок дает очень важное свойство - инкапсуляции
фрагментов конфига внутри одного конфигурационного файла.

фрагменты конфига включаемые через include - это примено
то же самое, что и глобальные переменные в программе,
нельзя понять где именно используется этот файл
не просмотрев полностью весь конфиг nginx.

следовательно - нельзя будет понять, изменения в этом файле
затронут только один/несколько сайтов, или изменения в этом
файле (например, fastcgi_params) затронут многие сайты.

block - по определению имеет локальную область действия,
только в пределах того файла, где он описан, таким образом
можно будет легко и спокойно менять содержимое этого блока,
точно зная, какие именно части конфига он затронет
и каким образом повлияет на поведение nginx.

P.S. вместо block и use можно использовать практически
любые ключевые слова, например, fragment вместо block.
лучших вариантов чем use я пока что придумать не могу.

еще один пример:

все необходимые варианты настройки fastcgi
можно будет описать в одном глобальном файле

fastcgi.conf:
-------------

block fastcgi_params {
...
}

block fastcgi_conf {
use fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
}

и тогда конфиг nginx для сайта example.com будет гораздо легче читать:

example.com.conf:
-----------------

include fastcgi.conf;

server {
server_name example.com;
location / {
fastcgi_pass unix:/tmp/fastcgi.socket;
use fastcgi_conf;
}
}

т.е. таким образом конфиг nginx будучи C-like
по своей сути станет еще больше C-like, значительно
увеличится читаемость конфига и легкость сопровождения,
потому что таким образом:

- можно будет избежать многократных дублей фрагментов
конфигурации через copy-paste и необходимости править
конфиг во многих местах для внесения одного изменения.

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

вместо непростого выбора между этими двумя альтернативами,
есть третий путь, который сочетает в себе преимущества обеих
вариантов:

- как и в первом варианте весь конфиг файла будет в одном
файле, а не в детсятке мелких файлов, что улучшает читаемость.

- как и во втором варианте - в конфиге не будет избыточности
и дублирования фрагментов через copy-paste и при этом будет гораздо
проще и легче править конфиг - потому что все будет в одном файле.

--
Best regards,
Gena


_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru