From skandyla на gmail.com  Thu Jan 12 13:37:40 2023
From: skandyla на gmail.com (Sergey K)
Date: Thu, 12 Jan 2023 16:37:40 +0300
Subject: nginx stream module, dynamic upstream
Message-ID: <CAD+UUjstkeufP_YkSArpitygr2+KoVvUYOg8gExOVeBMoH=ZDA@mail.gmail.com>

В документации сказано, что можно использовать upstream с переменными
(stream module).

----
proxy_pass $upstream;
В этом случае имя сервера ищется среди описанных групп серверов и если не
найдено, то определяется с помощью resolver’а.
----

Однако, в случае изменения айпи адреса для postgres.local  nginx не видит
изменений и продолжает обращаться к старому айпи адресу апстрима.

nginx/1.18.0

----
  upstream postgres {
    server postgres.local:5432;
  }

  map stream $upstream {
    default postgres;
  }

  server {
    listen 5432;

    access_log  /var/log/nginx/stream.access.log  proxy buffer=32k
flush=10s;

    proxy_pass $upstream;
    resolver 10.0.0.2 valid=30s;
  }
----

похоже на баг либо я делаю что-то не верно?
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20230112/3995185a/attachment.htm>

From chipitsine на gmail.com  Thu Jan 12 13:41:30 2023
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 12 Jan 2023 19:41:30 +0600
Subject: nginx stream module, dynamic upstream
In-Reply-To: <CAD+UUjstkeufP_YkSArpitygr2+KoVvUYOg8gExOVeBMoH=ZDA@mail.gmail.com>
References: <CAD+UUjstkeufP_YkSArpitygr2+KoVvUYOg8gExOVeBMoH=ZDA@mail.gmail.com>
Message-ID: <CAFHpkQFvNTu-P7bn_ycDOvxd+rHr8G6pdJCWKdhAYSOibZHCSQ@mail.gmail.com>

Это, видимо, неточность документации, надо днс имя + пустую переменную
непосредственно в proxy_pass, а upstream по крайней мере в опенсорс
варианте днс ресолвтт на момент релоада

On Thu, Jan 12, 2023, 7:37 PM Sergey K <skandyla на gmail.com> wrote:

> В документации сказано, что можно использовать upstream с переменными
> (stream module).
>
> ----
> proxy_pass $upstream;
> В этом случае имя сервера ищется среди описанных групп серверов и если не
> найдено, то определяется с помощью resolver’а.
> ----
>
> Однако, в случае изменения айпи адреса для postgres.local  nginx не видит
> изменений и продолжает обращаться к старому айпи адресу апстрима.
>
> nginx/1.18.0
>
> ----
>   upstream postgres {
>     server postgres.local:5432;
>   }
>
>   map stream $upstream {
>     default postgres;
>   }
>
>   server {
>     listen 5432;
>
>     access_log  /var/log/nginx/stream.access.log  proxy buffer=32k
> flush=10s;
>
>     proxy_pass $upstream;
>     resolver 10.0.0.2 valid=30s;
>   }
> ----
>
> похоже на баг либо я делаю что-то не верно?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20230112/c254cede/attachment.htm>

From mdounin на mdounin.ru  Thu Jan 12 17:32:40 2023
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 12 Jan 2023 20:32:40 +0300
Subject: nginx stream module, dynamic upstream
In-Reply-To: <CAD+UUjstkeufP_YkSArpitygr2+KoVvUYOg8gExOVeBMoH=ZDA@mail.gmail.com>
References: <CAD+UUjstkeufP_YkSArpitygr2+KoVvUYOg8gExOVeBMoH=ZDA@mail.gmail.com>
Message-ID: <Y8BEOAvyZ/q8oyny@mdounin.ru>

Hello!

On Thu, Jan 12, 2023 at 04:37:40PM +0300, Sergey K wrote:

> В документации сказано, что можно использовать upstream с переменными
> (stream module).
> 
> ----
> proxy_pass $upstream;
> В этом случае имя сервера ищется среди описанных групп серверов и если не
> найдено, то определяется с помощью resolver’а.
> ----
> 
> Однако, в случае изменения айпи адреса для postgres.local  nginx не видит
> изменений и продолжает обращаться к старому айпи адресу апстрима.
> 
> nginx/1.18.0
> 
> ----
>   upstream postgres {
>     server postgres.local:5432;
>   }
> 
>   map stream $upstream {
>     default postgres;
>   }
> 
>   server {
>     listen 5432;
> 
>     access_log  /var/log/nginx/stream.access.log  proxy buffer=32k
> flush=10s;
> 
>     proxy_pass $upstream;
>     resolver 10.0.0.2 valid=30s;
>   }
> ----
> 
> похоже на баг либо я делаю что-то не верно?

У вас имя сервера, указанного в proxy_pass, ищется среди описанных 
групп серверов, и оно найдено - в конфигурации есть upstream с 
именем "postgres".  Соответственно resolver не используется.

Что до имени сервера, указанного в группе серверов "postgres", а 
именно "postgres.local", то это имя по общим правилам 
преобразуется в IP-адреса при загрузке конфигурации.

Если хочется, чтобы nginx разнимался преобразованием имени в 
IP-адреса при каждом обращении, то не надо описывать upstream, а 
следует просто указать имя сервера с использованием переменных, 
как-то так:

   map stream $upstream { default "postgres.local:5432"; }

   server {
       ...
       proxy_pass $upstream;
       resolver 10.0.0.2 valid=30s;
   }

-- 
Maxim Dounin
http://mdounin.ru/

From i.am.glint на gmail.com  Tue Jan 24 12:41:40 2023
From: i.am.glint на gmail.com (Alex Kubyshkin)
Date: Tue, 24 Jan 2023 14:41:40 +0200
Subject: =?utf-8?B?cGtnLW9zcyAtINC60LDQutC+0LIg0YHRgtCw0YLRg9GBINGN0YI=?=
 =?utf-8?B?0L7Qs9C+INC/0YDQvtC10LrRgtCwPw==?=
Message-ID: <F52BBE11-D02F-41E1-9DEE-ED65B4818859@gmail.com>

Добрый день всем!

Хотелось бы уточнить, насколько активно развивается pkg-oss для билда модулей?
Вопрос возник в связи с тем, что при попытке использовать его для многих docker images, которые по идее должны поддерживаться, возникают различные ошибки при работе скрипта build_module.sh.

Пробовал images:
almalinux:8
almalinux:9
centos:8
registry.access.redhat.com/ubi8/ubi:8.7
rockylinux:8
rockylinux:9

Воспроизвести можно так:
docker run --rm rockylinux:9 bash -c 'yum install -y wget && wget https://hg.nginx.org/pkg-oss/raw-file/default/build_module.sh && bash build_module.sh -y -r 20 https://github.com/arut/nginx-rtmp-module.git'

Даже забил баг в трекер:
https://trac.nginx.org/nginx/ticket/2441

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


From thresh на nginx.com  Tue Jan 24 19:00:54 2023
From: thresh на nginx.com (Konstantin Pavlov)
Date: Tue, 24 Jan 2023 11:00:54 -0800
Subject: =?UTF-8?B?UmU6IHBrZy1vc3MgLSDQutCw0LrQvtCyINGB0YLQsNGC0YPRgSDRjdGC?=
 =?UTF-8?B?0L7Qs9C+INC/0YDQvtC10LrRgtCwPw==?=
In-Reply-To: <F52BBE11-D02F-41E1-9DEE-ED65B4818859@gmail.com>
References: <F52BBE11-D02F-41E1-9DEE-ED65B4818859@gmail.com>
Message-ID: <dc04730f-5f2a-5c4c-e998-c8f103221963@nginx.com>

Здравствуйте, Alex,

On 24/01/2023 4:41 AM, Alex Kubyshkin wrote:
> Добрый день всем!
>
> Хотелось бы уточнить, насколько активно развивается pkg-oss для билда модулей?

Вполне активно.  С некоторых пор на основе pkg-oss (с небольшими 
изменениями, нерелевантными для самой сборки) мы собираем пакеты модулей 
для коммерческой версии, предварительно проверяя сборку на опенсорсном 
релизе.

> Вопрос возник в связи с тем, что при попытке использовать его для многих docker images, которые по идее должны поддерживаться, возникают различные ошибки при работе скрипта build_module.sh.
>
> Пробовал images:
> almalinux:8
> almalinux:9
> centos:8
> registry.access.redhat.com/ubi8/ubi:8.7
> rockylinux:8
> rockylinux:9
>
> Воспроизвести можно так:
> docker run --rm rockylinux:9 bash -c 'yum install -y wget && wget https://hg.nginx.org/pkg-oss/raw-file/default/build_module.sh && bash build_module.sh -y -r 20 https://github.com/arut/nginx-rtmp-module.git'

Работоспособность build_module.sh из tip проверяем на современных 
релизах, для NGINX Plus R20 система сборки была немного иная. Рекомендую 
чекаутить версию из бранча target-plus-r20 для настолько старого релиза 
- ну или обновиться на современный, для R27-R28 build_module.sh из tip 
default'а работать будет.

docker run --rm rockylinux:8 bash -c 'yum install -y wget sudo && wget 
https://hg.nginx.org/pkg-oss/raw-file/target-plus-r20/build_module.sh && 
bash build_module.sh -y -r 20 https://github.com/arut/nginx-rtmp-module.git'

Ну и с девятой версией rockylinux, вероятно, команда должна быть 
несколько иная, без репозитория EPEL (и, возможно, CRB для некоторых 
случаев) не обойтись.  Но это видимо, не так важно, ибо NGINX Plus для 
RHEL 9 и деривативов мы собираем начиная с R26.

> Так же есть вопросы к быстродействию всего процесса, который весьма нестабилен и некоторые его компоненты избыточны и можно оптимизировать его, сократив время сборки на радость всем девопсам.

Патчи приветствуются.

В целом правильный путь - не использовать build_module.sh, а написать 
Makefile для нужного модуля и использовать его для своих сборок. Это 
позволит кастомизировать свои сборки, например добавлять свои патчи 
поверх исходников модуля.  См. например 
https://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/Makefile.module-rtmp, но 
работать это будет только для современных релизов.

From i.am.glint на gmail.com  Tue Jan 24 20:31:59 2023
From: i.am.glint на gmail.com (Alex Kubyshkin)
Date: Tue, 24 Jan 2023 22:31:59 +0200
Subject: =?utf-8?B?UmU6IHBrZy1vc3MgLSDQutCw0LrQvtCyINGB0YLQsNGC0YPRgSA=?=
 =?utf-8?B?0Y3RgtC+0LPQviDQv9GA0L7QtdC60YLQsD8=?=
In-Reply-To: <dc04730f-5f2a-5c4c-e998-c8f103221963@nginx.com>
References: <F52BBE11-D02F-41E1-9DEE-ED65B4818859@gmail.com>
 <dc04730f-5f2a-5c4c-e998-c8f103221963@nginx.com>
Message-ID: <5F96320B-0C6D-479E-890E-4818CE99E904@gmail.com>

Добрый день, Константин!

Спасибо за оперативный ответ!

>> Вопрос возник в связи с тем, что при попытке использовать его для многих docker images, которые по идее должны поддерживаться, возникают различные ошибки при работе скрипта build_module.sh.
>> 
>> Пробовал images:
>> almalinux:8
>> almalinux:9
>> centos:8
>> registry.access.redhat.com/ubi8/ubi:8.7
>> rockylinux:8
>> rockylinux:9
>> 
>> Воспроизвести можно так:
>> docker run --rm rockylinux:9 bash -c 'yum install -y wget && wget https://hg.nginx.org/pkg-oss/raw-file/default/build_module.sh && bash build_module.sh -y -r 20 https://github.com/arut/nginx-rtmp-module.git'
> 
> Работоспособность build_module.sh из tip проверяем на современных релизах, для NGINX Plus R20 система сборки была немного иная. Рекомендую чекаутить версию из бранча target-plus-r20 для настолько старого релиза - ну или обновиться на современный, для R27-R28 build_module.sh из tip default'а работать будет.

Да, действительно, на r23 модуль собирается. Но r22 вышел 2.5 года назад всего, что по меркам сурового энтерпрайза фактически "вчера". Хотелось бы конечно, обратной совместимости, тем более в данном случае там совсем немного - путь в rpmbuild передается неверный.

> Патчи приветствуются.

А патчи как отсылать? Может у вас github/gitlab/bitbucket какой есть для простоты процесса?

> В целом правильный путь - не использовать build_module.sh, а написать Makefile для нужного модуля и использовать его для своих сборок. Это позволит кастомизировать свои сборки, например добавлять свои патчи поверх исходников модуля.  См. например https://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/Makefile.module-rtmp, но работать это будет только для современных релизов.

А поподробней где можно почитать про "Makefile для нужного модуля"? Я собираю кастомный модуль для узкого потребления суровым энтерпрайзом, который как раз на Nginx Plus сидит. Если есть какой-то не велосипедный путь, рад буду его использовать.


From thresh на nginx.com  Tue Jan 24 22:06:20 2023
From: thresh на nginx.com (Konstantin Pavlov)
Date: Tue, 24 Jan 2023 14:06:20 -0800
Subject: =?UTF-8?B?UmU6IHBrZy1vc3MgLSDQutCw0LrQvtCyINGB0YLQsNGC0YPRgSDRjdGC?=
 =?UTF-8?B?0L7Qs9C+INC/0YDQvtC10LrRgtCwPw==?=
In-Reply-To: <5F96320B-0C6D-479E-890E-4818CE99E904@gmail.com>
References: <F52BBE11-D02F-41E1-9DEE-ED65B4818859@gmail.com>
 <dc04730f-5f2a-5c4c-e998-c8f103221963@nginx.com>
 <5F96320B-0C6D-479E-890E-4818CE99E904@gmail.com>
Message-ID: <bcc2bc94-432d-08a0-2520-517870ce70cb@nginx.com>

Здравствуйте, Alex,

On 24/01/2023 12:31 PM, Alex Kubyshkin wrote:
> Добрый день, Константин!
>
> Спасибо за оперативный ответ!
>
>>> Вопрос возник в связи с тем, что при попытке использовать его для многих docker images, которые по идее должны поддерживаться, возникают различные ошибки при работе скрипта build_module.sh.
>>>
>>> Пробовал images:
>>> almalinux:8
>>> almalinux:9
>>> centos:8
>>> registry.access.redhat.com/ubi8/ubi:8.7
>>> rockylinux:8
>>> rockylinux:9
>>>
>>> Воспроизвести можно так:
>>> docker run --rm rockylinux:9 bash -c 'yum install -y wget && wget https://hg.nginx.org/pkg-oss/raw-file/default/build_module.sh && bash build_module.sh -y -r 20 https://github.com/arut/nginx-rtmp-module.git'
>> Работоспособность build_module.sh из tip проверяем на современных релизах, для NGINX Plus R20 система сборки была немного иная. Рекомендую чекаутить версию из бранча target-plus-r20 для настолько старого релиза - ну или обновиться на современный, для R27-R28 build_module.sh из tip default'а работать будет.
> Да, действительно, на r23 модуль собирается. Но r22 вышел 2.5 года назад всего, что по меркам сурового энтерпрайза фактически "вчера". Хотелось бы конечно, обратной совместимости, тем более в данном случае там совсем немного - путь в rpmbuild передается неверный.

Вероятно, чуть больше - там как минимум changelog'и еще не создаются на 
первый взгляд.

>> Патчи приветствуются.
> А патчи как отсылать? Может у вас github/gitlab/bitbucket какой есть для простоты процесса?

Можно аттачами в nginx-packaging на f5.com - это адрес рассылки со мной и 
моими коллегами, которые занимаются пакетированием продуктов NGINX/NGINX 
Plus в F5.

К сожалению, репозитория в git-формате для pkg-oss нет (как и другого 
web ui вместо hgweb), и не хотелось бы делать зеркало без лишней надобности.

>> В целом правильный путь - не использовать build_module.sh, а написать Makefile для нужного модуля и использовать его для своих сборок. Это позволит кастомизировать свои сборки, например добавлять свои патчи поверх исходников модуля.  См. например https://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/Makefile.module-rtmp, но работать это будет только для современных релизов.
> А поподробней где можно почитать про "Makefile для нужного модуля"? Я собираю кастомный модуль для узкого потребления суровым энтерпрайзом, который как раз на Nginx Plus сидит. Если есть какой-то не велосипедный путь, рад буду его использовать.

Документации в виде текстового описания, увы, нет.

В целом схема примерно такая: в pkg-oss/rpm/SPECS есть Makefile, который 
умеет запускать сборку поддерживаемых пакетов - nginx или модулей.  В 
случае модулей используются темплейт spec-файла 
(nginx-plus-module.spec.in) и наполнение его контентом через нехитрый 
sed.  В этом же Makefile через include добавляются Makefile'ы для 
модулей (Makefile.module-rtmp например), в которых заданы основные 
параметры вроде тарболла с исходниками, configure arguments, патчей, 
тестов и т.п. сборочной информации.

Для сборки под NGINX Plus достаточно в pkg-oss/rpm/SPECS в бранче для 
желаемого релиза (target-plus-rXX, где XX номер релиза) можно сказать 
что-то вида:

$ BASE_TARGET=plus MODULE_TARGET=plus make module-rtmp

При этом версия модуля, чексумма, url откуда его качать и т.п. вещи 
задаются в pkg-oss/contrib/src/$name/.

В вашем случае, полагаю, будет достаточно держать патчсет с добавлением 
rpm/SPECS/Makefile.module-$foo, 
contrib/src/$foo/{Makefile,version,SHA512SUMS} и время от времени его 
rebase'ить на новые бранчи релизов target-plus-rXX.  Если требуется еще 
и писать осмысленные changelog'и для пакетов, то стоит добавить и 
docs/nginx-module-$foo.xml по аналогии с уже существующими - на его 
основне при сборке будет генерироваться changelog, нативный для пакета 
(rpm и debian) и добавляться в пакет.

Хорошего дня,