from:"Valery Kholodkov"

Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?

2020-04-28 Пенетрантность Valery Kholodkov


On 27-04-2020 22:29, gz wrote:

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf

Не совсем понимаю какие выводы делают авторы.


Мне, кроме того, и непонятно где автор взял исходные данные.

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

Re: backend для Nginx + websockets

2020-04-03 Пенетрантность Valery Kholodkov


Алиса, прекрати флудить на форумах из-под анонимного аккаунта!

On 03-04-20 19:13, greenwar wrote:

Valery Kholodkov Wrote:
---

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


там сейчас вообще нет fastcgi, от слова совсем
ни одной директивы с этим словом


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

Re: backend для Nginx + websockets

2020-04-03 Пенетрантность Valery Kholodkov


Во-первых, в сравнении не FastCGI, а с libfcgi.

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


Так вот в сравнении с libfcgi придется ещё большую кучу писать и 
обрабатывать, потому что то что Вы показали -- это поток байт. Таким 
способом можно сделать сервер-затычку, но чтобы сделать 
полнофункциональный сервер, нужно релизовать ещё список вещей, чтобы 
корректно транспортировать запросы и ответы, в то время как libfcgi из 
коробки уже будет это делать.


On 02-04-20 16:19, greenwar wrote:

господа, а расскажите пожалуйста про начинку для этого конфига, где Nginx
проксирует вебсокеты?
я вот взял обычный демон, который просто отдаёт:
"HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type:
text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n"

Подключил конфиг для вебсокета и вуаля - оно работает прям с первого
раза...
Что особенно понравилось - БЕЗ бубнов и магии - ПРОСТО работает!
Так вот вопрос, в сравнении с FastCGI, где надо было кучу всего писать и
обрабатывать, чтобы тот же самый эффект получить, здесь как будет? Ну ведь
всё равно же куки надо обрабатывать? Сессии надо обрабатывать? GET/POST надо
обрабатывать? И т.д.?
В общем, можете расписать принцип работы этой схемы? (а то я первый раз в
вебсокеты залез)
Них*я не понял, но очень интересно! (с)
https://www.youtube.com/watch?v=qSkUuFySwqE



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

Re: Nginx + WebSockets на C/C++

2020-04-01 Пенетрантность Valery Kholodkov


On 01-04-20 15:59, Илья Шипицин wrote:

Нет, я хочу денег за Ваше непонимание в какую техничкую проблему Вы
ввязались. По-моему, это справедливо.



да пусть человек развлекается.
вреда от этого скорее всего никакого. > может польза будет.


Точно! Я подумал, возможно он вообще повар или физиотерапевт? Карантин, 
работчий день закончился, а поговорить не с кем. А тут списки рассылки.


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

Re: Nginx + WebSockets на C/C++

2020-04-01 Пенетрантность Valery Kholodkov


On 01-04-20 15:35, Evgeniy Berdnikov wrote:

Далее, зачем в 2020 году писать многопоточное приложение с кучей блокирующих
библиотек, если можно писать приложение с кучей неблокирующих библиотек?


  Ваша самоцель демонстрировать свою крутизну как программера и получать
  побольше зарплату, или же писать код с минимальным расходом ресурсов?


Не понял, что тут с чем и как связано?


Давайте решим этот спор следующим образом: если Вам требуется некоторое
приложение на FastCGI и C++, я готов Вам его разработать и поддерживать,
если Вы готовы за это заплатить.


  Понятно, Вы не способны аргументировать свои утверждения, всё сводится
  к тому, что за какую-то техническую чушь хотите денег. Вопрос закрыт.


Нет, я хочу денег за Ваше непонимание в какую техничкую проблему Вы 
ввязались. По-моему, это справедливо.


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

Re: Nginx + WebSockets на C/C++

2020-04-01 Пенетрантность Valery Kholodkov

On 01-04-20 13:58, Evgeniy Berdnikov wrote:

On Wed, Apr 01, 2020 at 01:06:27PM +0200, Valery Kholodkov wrote:

FastCGI использовался в прошлом для ускорения комуникации между веб-сервером
и апп-сервером.

Разве? Запросы, упакованные в FastCGI, бегут по сети между серверами
быстрее, чем те же запросы в виде HTTP?

См. https://en.wikipedia.org/wiki/FastCGI -> Implementation details

Сейчас, когда можно с легкостью написать событийно-ориентированное
приложение отвечающее по HTTP, преимущество использования FastCGI
представляется сомнительным.

Возможность писать простые однопоточные приложения как раз является
преимуществом. К тому же запрос в FastCGI доступен приложению в
уже разложенном по хедерам виде.

А как насчет кук, параметров, разбора тела, поддержки сессий? libfcgi-то
отдает только голый запрос.

Далее, зачем в 2020 году писать многопоточное приложение с кучей
блокирующих библиотек, если можно писать приложение с кучей
неблокирующих библиотек?

Если есть задача сделать приложение на C++ и подключить к nginx с помощью
libfcgi, то это несложно. А вот выжать из него максимум производительности,
реализовать поддерджку всех фич HTTP и поддерживать его в течении
длительного времени -- это гораздо сложнее, чем на то же самом node.js.

1. О каких фичах http речь?
2. Где можно выжать максимум производительности, за счёт чего?
3. Приведите примеры, pls, где что-то выжимается большим трудом на FastCGI
и легко и просто на Node.js.

Давайте решим этот спор следующим образом: если Вам требуется некоторое
приложение на FastCGI и C++, я готов Вам его разработать и поддерживать,
если Вы готовы за это заплатить.

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

Re: Nginx + WebSockets на C/C++

2020-04-01 Пенетрантность Valery Kholodkov

FastCGI использовался в прошлом для ускорения комуникации между 
веб-сервером и апп-сервером.


Сейчас, когда можно с легкостью написать событийно-ориентированное 
приложение отвечающее по HTTP, преимущество использования FastCGI 
представляется сомнительным.


Более того, nginx не поддерживает мультиплексирования запросов через 
одно соединение FastCGI, то есть преимущество использования FastCGI 
сводится всего лишь к компресии заголовков и возможности не принимать 
тело запроса.


Если есть задача сделать  приложение на C++ и подключить к nginx с 
помощью libfcgi, то это несложно. А вот выжать из него максимум 
производительности, реализовать поддерджку всех фич HTTP и поддерживать 
его в течении длительного времени -- это гораздо сложнее, чем на то же 
самом node.js.


On 01-04-20 10:05, greenwar wrote:

Valery Kholodkov Wrote:
---

Вот и я спрашиваю: зачем тебе FastCGI если есть HTTP?


кстати, что конкретно имеется ввиду под HTTP? О каком именно
программировании тут речь идёт?



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

Re: Nginx + WebSockets на C/C++

2020-03-30 Пенетрантность Valery Kholodkov

Вот и я спрашиваю: зачем тебе FastCGI если есть HTTP? FastCGI -- древний
протокол, документации толком в онлайне уже похоже нет.

Нужна высокая производительность? Сделай сервер на node.js или Golang,
запроксируй его и будет счастие.

On 28-03-20 11:02, greenwar wrote:

наткнулся тут на интересный тред, где предлагается реализовать что-то вроде
модуля под Nginx через вебсокеты:
https://www.linux.org.ru/forum/development/12702791

В курсе. Поэтому и удивляюсь, зачем нужен FastCGI, когда есть HTTP и

WebSockets и соответствующие либы.

Вот и возник вопрос, нужен ли FastCGI на самом деле мне...
У меня изначально была мысль реализовать через модуль Nginx, но как-то
отговорили...
Таки что конкретно предлагается в том треде, можете пояснить, как это будет
внутри Nginx выглядеть?
Сейчас чтобы Nginx передал HTTP-инфу демону нужно это делать через параметр
"fastcgi_pass ..."
А там что предлагается?
Я запутался... чтобы вебсокет создать надо HTML-код передать с JS, который
этот вебсокет создаст! хм...
как это всё должно работать?

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

Re: взаимодействие Nginx с fcgi БЕЗ пхп-файлов

2020-03-27 Пенетрантность Valery Kholodkov


fastcgi вообще-то бинарный протокол. Используй libfcgi. Вот пример:

https://github.com/vkholodkov/fcgi-cpp-appserver
https://github.com/vkholodkov/fcgi-cpp-appserver/blob/master/src/server/fcgi_server.cpp

On 27-03-20 12:11, greenwar wrote:

Всем привет )
тут запускаю fcgi-демона, который тупо ловит строку текста от Nginx, а в
ответ шлёт ему соответствующую HTML-строку...
и во всех конфигах, что я нашёл в гугле, фигурируют пхп-файлы, прям
везде...
Но у меня нет пхп-файла. У меня висит демон и через сокет ловит строку.
И эту строку я вывожу в линух-консоль (для тестов) и вижу такой текст:
(тут очевидно BB-кодов нет, так что сорри, как есть...):

[I] Accepted connection on descriptor 5(host=127.0.0.1, port=41892)
count = 872
data:;
   QUERY_STRINGREQUEST_METHODGET
CONTENT_TYPECONTENT_LENGTH
  SCRIPT_NAME/
 
REQUEST_URI/

DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1
 
  SERVER_SOFTWAREnginx/1.14.2
 
   
REMOTE_ADDR127.0.0.1
 
 
   REMOTE_PORT53664
 
 
   SERVER_ADDR127.0.0.1

 SERVER_PORT80
 SERVER_NAMEtest1.ruREDIRECT_STATUS200  HTTP_HOSTtest1.ru
HTTP_CONNECTIONkeep-alive
HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/80.0.3987.149 Safari/537.36
HTTP_ACCEPT_ENCODINGgzip,
deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
4096
count = -1
return false
count = 0
[I] Close 5
[I] Accepted connection on descriptor 5(host=127.0.0.1, port=41894)
count = 832
data:▒
   QUERY_STRINGREQUEST_METHODGET
CONTENT_TYPECONTENT_LENGTH

 
SCRIPT_NAME/favicon.ico


 
REQUEST_URI/favicon.ico


DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1
DOCUMENT_URI/favicon.ico
 
  SERVER_SOFTWAREnginx/1.14.2
 
   
REMOTE_ADDR127.0.0.1
 
 
   REMOTE_PORT53664
 
 
   SERVER_ADDR127.0.0.1

 SERVER_PORT80
 SERVER_NAMEtest1.ruREDIRECT_STATUS200  HTTP_HOSTtest1.ru
HTTP_CONNECTIONkeep-alive

HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0

(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/80.0.3987.149 Safari/537.36
 
 
   
'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8

HTTP_ACCEPT_ENCODINGgzip,
deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
4096
count = -1
return false
count = 0
[I] Close 5


ну вот к этой строке у меня и возникают вопросы...
1. как видно, тут ДВАЖДЫ практически одно и то же (port=41894 - порт разный
2 раза)
это 2 запроса делает браузер, или Nginx, или мой демон?

2. нет пробела между названием переменной и значением

3. а тут ещё и переноса строк нет:
HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENT

4. подразумевается эти параметры обрабатывать регекспом?

5. мне столько параметров не надо, как убрать половину?

6. ОТВЕТ, который я пытаюсь записать обратно в сокет не даёт результата... Я
шлю буквально следующее:
HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type:
text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n

Прошу знающих поделиться мудростью )



--
Val
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.n

Re: Keepalives considered harmful

2020-03-20 Пенетрантность Valery Kholodkov

Там возникает дисбаланс в загрузке воркеров из-за того что часть 
клиентов привязаны к своим воркерам через keep-alive. Отключая 
keep-alive они заставляют клиентов мигрировать на менее загруженные воркеры.


Описывается комуникация внутри их стэка, про что и статья. Полагаю, 
заголовок, нужно читать "[In some cases] keepalives considered harmful".


On 20-03-20 11:11, Илья Шипицин wrote:
Речь идёт про то, что не все воркеры одинаково хороши. Но не 
раскрывается, почему они могут быть нехороши. Блокирущие воркеры?


On Fri, Mar 20, 2020, 1:03 AM Gena Makhomed > wrote:


Здравствуйте, All!

Интересная статья в блоге Cloudflare:

https://blog.cloudflare.com/keepalives-considered-harmful/

Keepalives considered harmful

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

Re: зачем писать FastCGI сервер?

2019-11-07 Пенетрантность Valery Kholodkov


Пожалуйста:

http://www.grid.net.ru/nginx/nginx-modules.html

On 07-11-19 21:30, greenwar wrote:

а можно поподробнее - ЧТО именно проходит и НЕ проходит?

Valery Kholodkov Wrote:
---

В модулях nginx? Как раз наоборот, там неасинхрон не проходит.



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

Re: зачем писать FastCGI сервер?

2019-11-07 Пенетрантность Valery Kholodkov


В модулях nginx? Как раз наоборот, там неасинхрон не проходит.

On 07-11-19 21:14, greenwar wrote:

а где там асинхронный код нужен? Каждый запрос в своём потоке обрабатывается
же?

Valery Kholodkov Wrote:
---

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

On 05-11-19 14:11, greenwar wrote:

Добрый день.
а нельзя ли обойтись БЕЗ fcgi на пути к самому производительному

серверу,

м?
вот, например, "Hello World" в виде N-модуля прекрасно себя

чувствует:

https://tejgop.github.io/nginx-module-guide/#the-c-file
что мешает сходить в БД, собрать string "..." и также

вернуть

клиенту через NGINX?



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

Re: зачем писать FastCGI сервер?

2019-11-07 Пенетрантность Valery Kholodkov

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


On 05-11-19 14:11, greenwar wrote:

Добрый день.
а нельзя ли обойтись БЕЗ fcgi на пути к самому производительному серверу,
м?
вот, например, "Hello World" в виде N-модуля прекрасно себя чувствует:
https://tejgop.github.io/nginx-module-guide/#the-c-file
что мешает сходить в БД, собрать string "..." и также вернуть
клиенту через NGINX?



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

Re: SPAM Re: Релиз Unit 1.10.0

2019-08-26 Пенетрантность Valery Kholodkov

On 26-08-19 14:25, Валентин Бартенев wrote:

> Ему уже лет 10, но что-то про живых пользователей практически ничего
> не слышно.

Ну как же, Пьер писал об этом:
http://gwan.com/blog/20140901.html

> Если мы будем тратить время на публикацию подобных тестов и рисование
> красивых графиков, то вот с учетом сказанного выше - это как-то
> реально поможет?

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

А вот ты как раз ходишь по серой линии применяя ожидания от nginx к G-WAN.

G-WAN не предназначен для масс-маркета (или наоборот?). Масс-маркет не 
понимает его сильные стороны. Ровно так же как в nginx нет достаточного 
уровня расширяемости, поддержка HTTP/2.0 (а также 1.1) не полная и т.д.

Да, графики субъективны, но не нужно из-за этого записывать в андердоги.

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

Re: Релиз Unit 1.9.0

2019-08-13 Пенетрантность Valery Kholodkov


On 14-08-19 00:00, S.A.N wrote:

Нам мешают те же причины что у вас, бизнесу выгодно чтобы мы писали больше
бизнес логики и меньше писали инфрастуктурного кода.


Есть сервис Pusher, который позволяет раздавать потоки по WebSocket. 
Никакой инфраструктуры не нужно. Подозреваю там есть прямые и обратные 
каналы.


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

Re: Nginx и queue в upstream (Windows)

2017-10-30 Пенетрантность Valery Kholodkov


On 30-10-17 14:18, "Дима Кулик" wrote:

Если уж вы заикнулись про лицензии, то использование Win Server на
выделенном сервере обойдётся в $200-$300 за год, а Nginx Plus $2500 за
каждый поток на сервере. Подумайте, на что обычный разработчик найдёт
деньги, а на что не найдёт и у какого продукта адекватные цены...


Если нет денег, почему бы не сделать самому?

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

Re: Получить файл в папке

2017-05-28 Пенетрантность Valery Kholodkov


Подобрать смогут, если захотят.

Оценку вероятности можно получить исходя из энтропии Шеннона.

Пример расчета оставлю Вам на домашнее задание.

On 27-05-17 17:47, Schumi wrote:

А если исходим из соображения, что не передаёт.

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

Re: host not found in upstream: не появилась возможность игнорировать?

2017-03-16 Пенетрантность Valery Kholodkov

Добавлю, что контейнер в сети может иметь несколько разных алиасов. 
Поэтому необходимость иметь уникальные имена не противоречит с 
возможностью иметь неуникальный алиас.


On 16-03-17 20:19, obolobova wrote:

У нас так не получается, увы - мы используем оверлей с внешним хранилищем
(Консулом), а эта разновидность сети требует уникальных имен всех нод в
кластере.

Да и не хочется ставить старт NGINXа, который служит entrypoint'ом для всех
сервисов, в зависимость от одного или нескольких сервисов или событий.
Хотелось бы сделать его максимально независимым. Вы правильно сказали, что
оверлей-нетворк бывают нестабильны, а у нас это всё распределенное, крутится
в Амазоне, поэтому события в стиле "сетевой администратор ошибся цифрой -
два континента отвалились" тоже случаются.

Получается, NGINX out-of-box не очень приспособлен к работе в быстро
меняющемся окружении, где, в общем, нормой является, что где-то что-то
падает, исчезает, появляется, меняются имена и адреса и т. п.
По крайней мере, жалоб именно на эту проблему с апстримом в сети очень много
:)

Valery Kholodkov Wrote:
---

Для решения этой проблемы достаточно всем контейнерам одного сервиса в

оверлей-сети прописать один и тот же алиас. Тогда докер в своем
внутреннем DNS-е пропишет запись с множеством адресов и nginx сможет
резолвить набор адресов контейнеров соответствующих сервису.


Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272978,272991#msg-272991

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


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

Re: host not found in upstream: не появилась возможность игнорировать?

2017-03-16 Пенетрантность Valery Kholodkov

Для решения этой проблемы достаточно всем контейнерам одного сервиса в 
оверлей-сети прописать один и тот же алиас. Тогда докер в своем 
внутреннем DNS-е пропишет запись с множеством адресов и nginx сможет 
резолвить набор адресов контейнеров соответствующих сервису.


Пример на docker-compose:

version: '2'

services:
  myapp:

[ ... пропущено ... ]

networks:
  ovr0:
aliases:
  - myapp

networks:
  ovr0:
external:
  name: ovr0

Конфиг nginx:

server {
server_name myurl.com;
listen 80 ;
access_log /var/log/nginx/access.log vhost;
location / {
proxy_pass http://myapp;
}
}

Замечания:

1. nginx должен быть докеризирован. Я пока не нашел способов роутинга 
трафика с хоста в оверлей-сеть;

2. Контейнеры должны использовать внутренный DNS докера;
3. Оверлей-сеть не всегда стабильна, особенно в глобальном масштабе. 
Полагаю максимальная стабильность может  быть гарантирована, только если 
все хосты находятся в локальной сети.


On 16-03-17 14:56, obolobova wrote:

Здравствуйте.

У нас крутится nginx в докере, и проксирует запросы на большое количество
сервисов, тоже в контейнерах.
Все это хозяйство объединено в Docker overlay network, и адресация идет не
по реальным хостнеймам, а по именам/алиасам докер-контейнеров (DNS-резолвинг
обеспечивает сетевая инфраструктура докера).

Конфиг примерно такой:

upstream my_upstream1 {
server DOCKER_CONTAINER1:8080 max_fails=0;
server DOCKER_CONTAINER2:8080;
keepalive 32;
}

# еще куча апстримов
upstream my_upstream2...
upstream my_upstream3...

server {
server_name myurl.com;
listen 80 ;
access_log /var/log/nginx/access.log vhost;
location / {
proxy_pass http://my_upstream1;

#также пробовали вариант с переменной
set $my_var my_upstream1;
proxy_pass http://$my_var;
}
}

Проблема, наверное, уже понятна: если хоть один контейнер исчезает (упал,
удалили, машина провалилась под землю, whatever), то соответствующее имя не
резолвится и NGINX крэшится при старте.
Подчеркну, что проблема не в резолвере - он работает совершенно верно,
исчезнувший контейнер и не должен резолвиться - всё, его нет, и докер
убирает соответствующую запись из своего DNS.

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

Можно ли что-то сделать - на уровне штатного конфига - чтобы NGINX всё же
стартовал?
В гугле пишут, что либо ничего не сделать, либо использовать переменную в
proxy_pass - но нам не помогло. Если хоть одно имя хоть в одном upstream не
резолвится, NGINX не стартует.
Может быть, появился какой-то новый workaround?

Если нет, то, насколько я понимаю, остается вариант цеплять к NGINXу
дополнительный DNS, который все эти апстримы будет резолвить хоть бы на
127.0.0.1?

Большое спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,272978,272978#msg-272978

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


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

Re: resumable upload

2013-05-10 Пенетрантность Valery Kholodkov


On 05/10/2013 06:45 PM, Maxim Dounin wrote:

Так где API для этого? Какие функции нужно крутить, куда вставлять
свои хэндлеры?


Патч по ссылке выше как раз это API добавляет.  Интерфейс -
подобен body-фильтрам ответа: добавляешь обработчик в цепочку
фильтров (сохранив/поставив ngx_http_top_request_body_filter),
по мере прихода данных от клиента - его вызовут с цепочкой
прочитанных буферов.


Они интегрирован или нет?

--
Best regards,
Valery Kholodkov

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

Re: resumable upload

2013-05-10 Пенетрантность Valery Kholodkov

On 05/09/2013 01:54 PM, Maxim Dounin wrote:

Hello!

On Wed, May 08, 2013 at 10:13:05PM +0200, Valery Kholodkov wrote:

On 05/08/2013 07:03 PM, Maxim Dounin wrote:

Hello!

On Tue, May 07, 2013 at 09:37:38PM +0200, Valery Kholodkov wrote:

On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote:

On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote:

On 29.03.2013 17:02, Валентин Бартенев wrote:

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

Большинство вопрошающих вполне устраивал upload_module.

P.S. Пожалуй, это тупиковая ветвь дискуссии.

тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку
уже как полгода.

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

Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы
спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё
будет".

Однако, я считатю, что подобный ответ не соответствует моему уровню.
Предлагаемая бизнес-модель не работает, я проверил это на
собственном опыте. В то же время, поддерживать этот модуль на
собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос
из nginx (sic!).

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

Поэтому, как видите, ситуация не может сдвинутся с мертвой точки,
несмотря на то, что в nginx достаточно было бы поправить несколько
строк.

Валерий, если есть конкретные предложения, какие именно строки
поправить в самом nginx'е - пожалуйста, выскажи их.

Чтобы работало достаточно вернуть переменную to_write в
ngx_http_request_body_t.

Если я правильно понимаю, это - не чтобы работало, а чтобы
собиралось. В 1.3.9 появилась поддержка Transfer-Encoding
chunked, и если такой запрос попадёт в location с upload - всё
сломается.

Ты предлагал высказать мои предложения относительно того, что нужно
исправить, -- я высказал. У меня нет ни времени ни желания отслеживать
что и как вы там меняете и подстраиваться под эти изменения.

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

Я потратил некоторое время на создание такого механизма в рамках
работы над поддержкой chunked-запросов, но a) upload модуль
придётся заметно переписать, чтобы использовать этот механизм и
б) скорее всего нужно будет ещё что-то допиливать, чтобы с этим можно
было нормально работать из сторонних модулей.

Если вдруг есть желание заняться/посмотреть - то патч можно взять
тут:

http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003492.html

У меня самого где-то валяется подобный кусок кода. Проблема
заключается в HTTP pipelining. Я уже два года назад просил механизм
возвращения буферов в заголовок запроса. Без этого нельзя выйти из
ситуации, когда за телом запроса незамедлительно следует часть
заголовка следующего запроса.

Проблемы HTTP pipelining'а - это то, что должен решать (и решает)
сам nginx в рамках функций чтения тела запроса. Фильтрам тела
запроса достаются уже прочитанные от клиента данные.

Так где API для этого? Какие функции нужно крутить, куда вставлять свои
хэндлеры?

Из известных проблем - оно несовместимо со spdy, у которого, всилу
особенностей протокола, совсем своя логика чтения тела запроса.

--
Best regards,
Valery Kholodkov

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

Re: resumable upload

2013-05-08 Пенетрантность Valery Kholodkov

On 05/08/2013 07:03 PM, Maxim Dounin wrote:

Hello!

On Tue, May 07, 2013 at 09:37:38PM +0200, Valery Kholodkov wrote:

On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote:

On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote:

On 29.03.2013 17:02, Валентин Бартенев wrote:

Большинство вопрошающих вполне устраивал upload_module.

P.S. Пожалуй, это тупиковая ветвь дискуссии.

тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку
уже как полгода.

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

Чтобы работало достаточно вернуть переменную to_write в
ngx_http_request_body_t.

Если вдруг есть желание заняться/посмотреть - то патч можно взять
тут:

http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003492.html

У меня самого где-то валяется подобный кусок кода. Проблема заключается
в HTTP pipelining. Я уже два года назад просил механизм возвращения
буферов в заголовок запроса. Без этого нельзя выйти из ситуации, когда
за телом запроса незамедлительно следует часть заголовка следующего запроса.

--
Best regards,
Valery Kholodkov

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

Re: resumable upload

2013-05-07 Пенетрантность Valery Kholodkov

On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote:

On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote:

On 29.03.2013 17:02, Валентин Бартенев wrote:

Большинство вопрошающих вполне устраивал upload_module.

P.S. Пожалуй, это тупиковая ветвь дискуссии.

тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку
уже как полгода.

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

Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы спрос,
мы бы всё сделали". Иными словами, "дайте денег -- всё будет".

Однако, я считатю, что подобный ответ не соответствует моему уровню.
Предлагаемая бизнес-модель не работает, я проверил это на собственном
опыте. В то же время, поддерживать этот модуль на собсвтенном энтузиазме
мне тоже не имеет смысла, так как я уже вырос из nginx (sic!).

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

--
Best regards,
Valery Kholodkov

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

Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?

Re: backend для Nginx + websockets

Re: backend для Nginx + websockets

Re: Nginx + WebSockets на C/C++

Re: Nginx + WebSockets на C/C++

Re: Nginx + WebSockets на C/C++

Re: Nginx + WebSockets на C/C++

Re: Nginx + WebSockets на C/C++

Re: взаимодействие Nginx с fcgi БЕЗ пхп-файлов

Re: Keepalives considered harmful

Re: зачем писать FastCGI сервер?

Re: зачем писать FastCGI сервер?

Re: зачем писать FastCGI сервер?

Re: SPAM Re: Релиз Unit 1.10.0

Re: Релиз Unit 1.9.0

Re: Nginx и queue в upstream (Windows)

Re: Получить файл в папке

Re: host not found in upstream: не появилась возможность игнорировать?

Re: host not found in upstream: не появилась возможность игнорировать?

Re: resumable upload

Re: resumable upload

Re: resumable upload

Re: resumable upload

23 matches

Site Navigation

Mail list logo

Footer information