Comments 19
Отлично! Я уже честно устал пересобирать свежие выпуски nginx с нужными мне модулями, теперь можно единожды (в общем случае) собрать модули, а пакетирование самого nginx оставить на совести мейнтейнеров дистрибутива.
Ну и возможно понизит порог вхождения для новичков.
Хотя именно с фразы в мануале «для этого вам придется пересобрать nginx с требуемым вам модулем» и началось мое увлекательное путешествие в кроличью нору *nix
Хотя именно с фразы в мануале «для этого вам придется пересобрать nginx с требуемым вам модулем» и началось мое увлекательное путешествие в кроличью нору *nix
Пересобирать всё равно придётся, во всяком случае в ближайшем будущем.
> We've been looking at whether this would let us offer a precompiled
> ngx_pagespeed module, though, and it looks to me like this might be
> pretty tricky? In order to load a module, it looks like it has to
> have been compiled for that specific point release of nginx and with a
> matching signature? So we would need to make binaries for 1.9.11,
> 1.9.12, 1.9.13 etc and for each of those we would need to make ones
> for each of the common signatures [1]. That's a lot of binaries to
> prepare!
Yes. We don't maintain a stable ABI between versions, and not
even API between mainline versions. So preparing different
binaries for different nginx versions is unavoidable for now.
As of now general idea is that it should be possible to compile
module that can be loaded into an nginx binary built on a
particular OS with particular configure arguments. That is, you
can prepare binaries targeting particular nginx distributions.
In the future we are likely to review and reduce number of various
options that change nginx internal structures and hence are
included in the signature. This should improve compatibility
between different builds.
http://mailman.nginx.org/pipermail/nginx-devel/2016-February/007879.html
> We've been looking at whether this would let us offer a precompiled
> ngx_pagespeed module, though, and it looks to me like this might be
> pretty tricky? In order to load a module, it looks like it has to
> have been compiled for that specific point release of nginx and with a
> matching signature? So we would need to make binaries for 1.9.11,
> 1.9.12, 1.9.13 etc and for each of those we would need to make ones
> for each of the common signatures [1]. That's a lot of binaries to
> prepare!
Yes. We don't maintain a stable ABI between versions, and not
even API between mainline versions. So preparing different
binaries for different nginx versions is unavoidable for now.
As of now general idea is that it should be possible to compile
module that can be loaded into an nginx binary built on a
particular OS with particular configure arguments. That is, you
can prepare binaries targeting particular nginx distributions.
In the future we are likely to review and reduce number of various
options that change nginx internal structures and hence are
included in the signature. This should improve compatibility
between different builds.
http://mailman.nginx.org/pipermail/nginx-devel/2016-February/007879.html
Поэтому я и упомянул «в общем случае» :) В принципе, задача сборки нужных модулей тоже можно возложить на мейнтейнеров, тогда просто нужно будет поставить nginx + необходимые модули, а не все скопом из пакета или собственноручно собираемые при каждом обновлении.
Но есть надежда, что спустя какое-то время этот функционал станет доступен по-умолчанию. Ну или, хотя бы, пока что один раз собрать с динамическими модулями, а потом их просто добавлять «на лету».
Интересный ход. Но я не уверен, что понимаю подоплеку. Ведь сейчас каждый за два вечера сможет собрать Nginx Plus на базе модулей!
Люди умные, люди сишные, сделайте пожалуйста, расширение для получения уникального идентификатора запроса, который можно пробросить в upstreams? Или хотя бы получение хеш-суммы из произвольно конкатенированных переменных?
Детали проблемы
:)
Детали проблемы
:)
А в сторону lua не смотрели? Nginx же её умеет.
UFO just landed and posted this here
Там можно и перл вызывать. Но мне нужно только одно небольшое улучшение, не хочется тянуть слишком много для этого.
В общем случае, с lua ничего тянуть не придется, и все должно выглядеть проще, по крайней мере на debian/ubuntu, достаточно доставить nginx-extras:
И lua в Nginx должен взлететь.
Центось я не уверен, не помню, но вроде там тоже можно просто сделать yum install nginx-extras.
Ну и я lua предложил только потому, что мы активно пользуем его в nginx, на довольно нагруженных участках, и оно хорошо себя ведет. А так, свет клином не сошелся, конечно.
aptitude install nginx-extras
И lua в Nginx должен взлететь.
Центось я не уверен, не помню, но вроде там тоже можно просто сделать yum install nginx-extras.
Ну и я lua предложил только потому, что мы активно пользуем его в nginx, на довольно нагруженных участках, и оно хорошо себя ведет. А так, свет клином не сошелся, конечно.
Например github.com/streadway/ngx_txid не поможет?
https://github.com/hhru/nginx_requestid
Аналогично вышесказанному, это не динамический модуль и именно этим он и плох. Нужно компилировать, что в продакшн-среде очень некомфортно. Ради одной маленькой фичи не хочется это делать. Пока что меня больше устраивают длинные request-id, зато можно ставить в любой среде nginx из пакетов и решение продолжает стабильно работать.
Его легко сделать динамическим путем исправления config к такому виду:
ngx_addon_name=ngx_http_requestid_filter_module
if [ $ngx_module_link = DYNAMIC ]; then
ngx_module_name=«ngx_http_requestid_filter_module»
ngx_module_srcs="$ngx_addon_dir/ngx_http_requestid_module.c"
. auto/module
elif [ $ngx_module_link = YES ]; then
ngx_module_type=HTTP
ngx_module_name=ngx_http_requestid_filter_module
ngx_module_incs=
ngx_module_deps=
ngx_module_srcs="$ngx_addon_dir/ngx_http_requestid_module.c"
. auto/module
fi
ngx_addon_name=ngx_http_requestid_filter_module
if [ $ngx_module_link = DYNAMIC ]; then
ngx_module_name=«ngx_http_requestid_filter_module»
ngx_module_srcs="$ngx_addon_dir/ngx_http_requestid_module.c"
. auto/module
elif [ $ngx_module_link = YES ]; then
ngx_module_type=HTTP
ngx_module_name=ngx_http_requestid_filter_module
ngx_module_incs=
ngx_module_deps=
ngx_module_srcs="$ngx_addon_dir/ngx_http_requestid_module.c"
. auto/module
fi
Эх, как же жалко, что перестали собирать под Debian и armhf :(
Динамические модули, как же долго я этого ждал.
Сколько матерных сов было высказано при необходимости каждый раз перекомпилировать )
Сколько матерных сов было высказано при необходимости каждый раз перекомпилировать )
Sign up to leave a comment.
Вышел Nginx 1.9.11 с поддержкой динамических модулей