Comments 31
Про sendfile это ведь он оговорился. Речь была о sendmail :). А доклад хороший, годный, стараюсь жить по его заветам уже не первый год, и такой подход себя оправдывает.
+4
>> Речь была о sendmail :)
Это юмор такой, да? :)
Это юмор такой, да? :)
0
Я имел ввиду вот это место:
Еще из этой же серии:
А «вишенкой на торте» являются RewriteRules, которые позволяют сделать конфигурацию похожей на sendfile. Немногие оценили юмор, т.к., к счастью, большинство уже не знают, что это такое.
Еще из этой же серии:
Evil — тоже не рекомендуемая конструкция в nginx, потому что, как работает внутри Evil, знает человек 10 в мире, и вы вряд ли входите в их число.
0
Да, Игорь оговорился. В первом случае речь шла о sendmail
, во втором об if
.
+1
Да, про Evil тоже заметил, когда читал. Но про sendfile/sendmail все равно не пойму, о чем речь. О том, что в случае с sendmail не нужно никакой конфигурации, равно как в случае с RewriteRules можно все несколькими строками зарулить на некий index.php и дальше не париться с конфигурацией?
0
Речь о том, что кофиг апача становится затейливым и плохочитаемым, и в этом плане автор его сравнивает с конфигом сендмайла — одним из лидеров в сфере затейливости конфигов. В общем он был прав, насчет того, что не многие поймут юмор).
+1
Вы просто никогда не настраивали sendmail. =)
Посмотрите хотя бы сколько страниц в книге по sendmail:
http://shop.oreilly.com/product/9780596510299.do
+1
Не очень согласен с его призывом использовать copy paste и отказаться от принципов DRY.
Есть есть 200 локейшенов с одинаковой конфигурацией, то мне удобно инклюдить конфигурацию в каждом из них.
Если потом понадобится один локейшен выключить из этой общей обработки, то что мне мешает взять все настройки из общего файла, прописать их в этот один конкретный локейшен и изменить то, что нужно?
Есть есть 200 локейшенов с одинаковой конфигурацией, то мне удобно инклюдить конфигурацию в каждом из них.
Если потом понадобится один локейшен выключить из этой общей обработки, то что мне мешает взять все настройки из общего файла, прописать их в этот один конкретный локейшен и изменить то, что нужно?
+2
Стоит наверное упомянуть, что не всё наследуется и не все директивы можно применять внутри «контейнеров». Например, директива resolver работает внутри location только в nginx+. В бесплатной версии ее необходимо вытащить на уровень server. И мне до сих пор не очень понятно, каким образом можно проверить ее работоспособность на этом уровне, без привязки к конкретному upstream… Может кто сталкивался?
0
Например, директива resolver работает внутри location только в nginx+. В бесплатной версии ее необходимо вытащить на уровень server.
Это не так. В обоих версиях директива может быть задана на уровне location.
+2
Я видимо не до конца разобрался… Сейчас перечитал документацию и понял, что есть директива resolve и директива resolver. Получается что именно resolve (без 'r' на конце) недоступна в бесплатной версии?
0
Насколько я понял из документации, resolve это один из возможных параметров директивы server используемой в секции upstream. Этот параметр заставляет nginx отслеживать изменения ip у этого сервера (резолвит при каждом запросе, или как? наверняка Vbart лучше знает). И там же написано что этот параметр доступен только в Nginx Plus.
http://nginx.org/ru/docs/http/ngx_http_upstream_module.html
http://nginx.org/ru/docs/http/ngx_http_upstream_module.html
0
супер, спасибо
0
Ребятам из 1С-Битрикс и связанным с ними — обязательно посмотрите доклад, здесь речь явно о ваших настройках NGINX.
Многие разработчики 1С-Битрикс просят для них скачивать образ ВМ с официального сайта продукта 1С-Битрикс. В импорте готовой виртуальной машины нет сложности, но когда возникает задача что-либо поменять в конфигах NGINX, вот тут начинается АД!
Вот вам пример листинга конфигурационных файлов для одного сайта на 1С-Битрикс:
Еще не страшно? Переходим к самому интересному.
А вот список строк с include во всех конфигах для одного сайта
Не знаю какими принципами руководствовались админы (а может быть собирали конфиги NGINX разработчики) при создании шаблона ВМ, упростить работу либо прибавить работы админам. Ведь его в пример ставят люди которые делают сайты на 1С-Битрикс.
Многие разработчики 1С-Битрикс просят для них скачивать образ ВМ с официального сайта продукта 1С-Битрикс. В импорте готовой виртуальной машины нет сложности, но когда возникает задача что-либо поменять в конфигах NGINX, вот тут начинается АД!
Вот вам пример листинга конфигурационных файлов для одного сайта на 1С-Битрикс:
Листинг конфигов NGINX
/etc/nginx/
├── bx
│ ├── cache_general.conf.bx
│ ├── conf
│ │ ├── bitrix_block.conf
│ │ ├── bitrix.conf
│ │ ├── bitrix_general.conf
│ │ ├── blank.conf
│ │ ├── blank.conf.bx
│ │ ├── errors.conf
│ │ ├── errors.conf.bx
│ │ ├── im_settings.conf
│ │ ├── im_settings.conf.bx
│ │ ├── im_subscrider.conf
│ │ ├── server_monitor.conf
│ │ ├── ssl.conf
│ ├── maps
│ │ ├── common_variables.conf
│ │ ├── composite_settings.conf
│ ├── pool_passwords
│ ├── server_monitor.conf -> /etc/nginx/bx/conf/server_monitor.conf
│ ├── site_avaliable
│ │ ├── nginx_server_status.conf
│ │ ├── pool_manager.conf
│ │ ├── push.conf
│ │ ├── push.conf.bx
│ │ ├── s1.conf
│ │ ├── s1.conf.bx
│ │ ├── ssl.s1.conf
│ │ └── ssl.s1.conf.bx
│ ├── site_enabled
│ │ ├── nginx_server_status.conf -> /etc/nginx/bx/site_avaliable/nginx_server_status.conf
│ │ ├── pool_manager.conf -> /etc/nginx/bx/site_avaliable/pool_manager.conf
│ │ ├── push.conf -> /etc/nginx/bx/site_avaliable/push.conf
│ │ ├── s1.conf -> /etc/nginx/bx/site_avaliable/s1.conf
│ │ └── ssl.s1.conf -> /etc/nginx/bx/site_avaliable/ssl.s1.conf
│ └── site_ext_enabled
├── conf.d
├── default.conf
└── example_ssl.conf
Еще не страшно? Переходим к самому интересному.
А вот список строк с include во всех конфигах для одного сайта
инклуды
[random@bitrix bx]# grep -R include /etc/nginx/ | grep -v ori
/etc/nginx/bx/site_enabled/ssl.s1.conf: include bx/conf/ssl.conf;
/etc/nginx/bx/site_enabled/ssl.s1.conf: include bx/conf/bitrix.conf;
/etc/nginx/bx/site_enabled/ssl.s1.conf: include bx/server_monitor.conf;
/etc/nginx/bx/site_enabled/push.conf: include bx/conf/errors.conf;
/etc/nginx/bx/site_enabled/push.conf: include bx/conf/im_subscrider.conf;
/etc/nginx/bx/site_enabled/push.conf: include bx/conf/ssl.conf;
/etc/nginx/bx/site_enabled/push.conf: include bx/conf/errors.conf;
/etc/nginx/bx/site_enabled/push.conf: include bx/conf/im_subscrider.conf;
/etc/nginx/bx/site_enabled/push.conf: include bx/conf/errors.conf;
/etc/nginx/bx/site_enabled/s1.conf: include bx/conf/bitrix.conf;
/etc/nginx/bx/site_enabled/s1.conf: include bx/server_monitor.conf;
/etc/nginx/bx/conf/bitrix.conf:include bx/conf/bitrix_general.conf;
/etc/nginx/bx/conf/bitrix_general.conf:include bx/conf/errors.conf;
/etc/nginx/bx/conf/bitrix_general.conf:include bx/conf/im_subscrider.conf;
/etc/nginx/bx/conf/bitrix_general.conf:include bx/conf/bitrix_block.conf;
/etc/nginx/bx/site_avaliable/ssl.s1.conf.bx: include bx/conf/ssl.conf;
/etc/nginx/bx/site_avaliable/ssl.s1.conf.bx: include bx/conf/bitrix.conf;
/etc/nginx/bx/site_avaliable/ssl.s1.conf.bx: include bx/server_monitor.conf;
/etc/nginx/bx/site_avaliable/ssl.s1.conf: include bx/conf/ssl.conf;
/etc/nginx/bx/site_avaliable/ssl.s1.conf: include bx/conf/bitrix.conf;
/etc/nginx/bx/site_avaliable/ssl.s1.conf: include bx/server_monitor.conf;
/etc/nginx/bx/site_avaliable/push.conf.bx: include bx/conf/errors.conf;
/etc/nginx/bx/site_avaliable/push.conf.bx: include bx/conf/im_subscrider.conf;
/etc/nginx/bx/site_avaliable/push.conf.bx: include bx/conf/ssl.conf;
/etc/nginx/bx/site_avaliable/push.conf.bx: include bx/conf/errors.conf;
/etc/nginx/bx/site_avaliable/push.conf.bx: include bx/conf/im_subscrider.conf;
/etc/nginx/bx/site_avaliable/push.conf.bx: include bx/conf/errors.conf;
/etc/nginx/bx/site_avaliable/push.conf: include bx/conf/errors.conf;
/etc/nginx/bx/site_avaliable/push.conf: include bx/conf/im_subscrider.conf;
/etc/nginx/bx/site_avaliable/push.conf: include bx/conf/ssl.conf;
/etc/nginx/bx/site_avaliable/push.conf: include bx/conf/errors.conf;
/etc/nginx/bx/site_avaliable/push.conf: include bx/conf/im_subscrider.conf;
/etc/nginx/bx/site_avaliable/push.conf: include bx/conf/errors.conf;
/etc/nginx/bx/site_avaliable/s1.conf: include bx/conf/bitrix.conf;
/etc/nginx/bx/site_avaliable/s1.conf: include bx/server_monitor.conf;
/etc/nginx/bx/site_avaliable/s1.conf.bx: include bx/conf/bitrix.conf;
/etc/nginx/bx/site_avaliable/s1.conf.bx: include bx/server_monitor.conf;
/etc/nginx/nginx.conf: include /etc/nginx/mime.types;
/etc/nginx/nginx.conf: include bx/maps/*.conf;
/etc/nginx/nginx.conf: include bx/conf/im_settings.conf;
/etc/nginx/nginx.conf: include bx/site_enabled/*.conf;
/etc/nginx/nginx.conf: include bx/site_ext_enabled/*.conf;
/etc/nginx/openssl.cnf:# PKIX recommendations harmless if included in all certificates.
/etc/nginx/openssl.cnf:# PKIX recommendations harmless if included in all certificates.
/etc/nginx/openssl.cnf.bx:# PKIX recommendations harmless if included in all certificates.
/etc/nginx/openssl.cnf.bx:# PKIX recommendations harmless if included in all certificates.
/etc/nginx/conf.d/default.conf: # include fastcgi_params;
Не знаю какими принципами руководствовались админы (а может быть собирали конфиги NGINX разработчики) при создании шаблона ВМ, упростить работу либо прибавить работы админам. Ведь его в пример ставят люди которые делают сайты на 1С-Битрикс.
+1
Что-то как-то негативно, особенно странно это воспринимать от создателя nginx: "вот есть в nginx то и это, но не используйте, и это тоже не используйте".
Лучше бы осветил больше интересных возможностей текущей версии или будущих(поделился бы планами), которые мало кто знает, но реально полезны были бы многим.
-1
Разработчик рассказывает о недостатках и «подводных камнях» своего же продукта, что может быть полезнее и интереснее для пользователя? ИМХО, это гораздо лучше, чем когда просто хвалят и хотят продать. А недостатки есть у всех.
У меня назрел вопрос к разработчикам, будет ли когда-нибудь «красивый» способ вернуть именованный location? Чтобы не вот так:
У меня назрел вопрос к разработчикам, будет ли когда-нибудь «красивый» способ вернуть именованный location? Чтобы не вот так:
location / {
error_page 418 = @backend;
return 418;
}
0
Как я понимаю это запись 2014-ого года. Если бы на видео планы и были, то сейчас бы это было не актуально. Разве только как для истории.
0
Планами делились на nginx.conf. Можно посмотреть на нашем youtube-канале.
Также на прошлом HL++ был доклад и в этом году будет.
+2
Sign up to leave a comment.
Масштабируемая конфигурация nginx