nginx и проксирование
В Docker-контейнере крутится nginx, который при обращении по
определённому пути перенаправляет запрос к сервису во внутренней сети.
Например, так:
location /youtube-dl/ {
#auth_request /auth-proxy;
proxy_pass http://youtube-dl-webui:5000/;
}
Т.е., фактически, работает, как обратный прокси. Но сервисы
предоставляют Web интерфейс и хотят отдавать статику.
Я обращаюсь к youtube-dl-webui:
https://NAS/youtube-dl/
youtube-dl-webgui загружает CSS, начиная от корня: "GET
/static/css/global.css HTTP/1.1" 404
Ну и, естественно, получает 404.
Как сделать проксирование так, чтобы сервисы обращались по нужному адресу?
Re: nginx и проксирование
On Fri, 5 Oct 2018 01:50:55 +0300
artiom wrote:
> В Docker-контейнере крутится nginx, который при обращении по
> определённому пути перенаправляет запрос к сервису во внутренней сети.
>
> Например, так:
>
> location /youtube-dl/ {
> #auth_request /auth-proxy;
> proxy_pass http://youtube-dl-webui:5000/;
> }
>
> Т.е., фактически, работает, как обратный прокси. Но сервисы
> предоставляют Web интерфейс и хотят отдавать статику.
>
> Я обращаюсь к youtube-dl-webui:
>
> https://NAS/youtube-dl/
>
> youtube-dl-webgui загружает CSS, начиная от корня: "GET
> /static/css/global.css HTTP/1.1" 404
>
> Ну и, естественно, получает 404.
> Как сделать проксирование так, чтобы сервисы обращались по нужному
> адресу?
Я бы сказал, что nginx тут не виноват. Существует слишком много
способово запросить URL-ку, чтобы их можно было все перехватить и
поправить при отдаче страницы наружу.
Поэтому если сервис хочет корня, ему надо дать корень.
Завести name-based virtual host на нем отдавать куда надо всё.
Re: nginx и проксирование
Да, nginx ни в чём, ни в чём не виноват.
Это на странице прописано включение css от корня и браузер,
соответственно, делает GET запрос.
Вопрос, как сделать, не заводя корень, и возможно ли это?
У меня уже этих доменов штук 7, а здесь не Transmission, а сразу три
сервиса висит за LDAP авторизацией через nginx.
05.10.2018 18:17, Victor Wagner пишет:
> On Fri, 5 Oct 2018 01:50:55 +0300
> artiom wrote:
>
>> В Docker-контейнере крутится nginx, который при обращении по
>> определённому пути перенаправляет запрос к сервису во внутренней сети.
>>
>> Например, так:
>>
>> location /youtube-dl/ {
>> #auth_request /auth-proxy;
>> proxy_pass http://youtube-dl-webui:5000/;
>> }
>>
>> Т.е., фактически, работает, как обратный прокси. Но сервисы
>> предоставляют Web интерфейс и хотят отдавать статику.
>>
>> Я обращаюсь к youtube-dl-webui:
>>
>> https://NAS/youtube-dl/
>>
>> youtube-dl-webgui загружает CSS, начиная от корня: "GET
>> /static/css/global.css HTTP/1.1" 404
>>
>> Ну и, естественно, получает 404.
>> Как сделать проксирование так, чтобы сервисы обращались по нужному
>> адресу?
>
> Я бы сказал, что nginx тут не виноват. Существует слишком много
> способово запросить URL-ку, чтобы их можно было все перехватить и
> поправить при отдаче страницы наружу.
>
> Поэтому если сервис хочет корня, ему надо дать корень.
>
> Завести name-based virtual host на нем отдавать куда надо всё.
>
>
Re: nginx и проксирование
В Fri, 5 Oct 2018 22:32:47 +0300 artiom пишет: > Да, nginx ни в чём, ни в чём не виноват. > Это на странице прописано включение css от корня и браузер, > соответственно, делает GET запрос. > Вопрос, как сделать, не заводя корень, и возможно ли это? А подумать? Вот у нас есть поток данных, идущих от сервера к браузеру через proxy. Вот где-то внутри этого потока данных js-код, формирующий URL запроса. По-моему, очевидно, что прошерстить весь этот код и выловить URL, чтобы их переписать - задача в общем виде не разрешимая. Если же у нас код дошел до браузера неизменным, то браузер отправит на прокси ту URL, которую ему отдал сервер. И определить от какого из проксированных сервисов эта URL тоже будет ох как непросто. Раз задача в общем виде неразрешимая, то решать ее придется в частных случаях, для каждого из сервисов по отдельности, конфигурируя каждый сервис (если он это позволяет) на работу под уникальным префиксом, причем совпадающим с тем, что был указан нв фронтэнде. > У меня уже этих доменов штук 7, а здесь не Transmission, а сразу три Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный. Расходуются только строчки в файле зоны локального DNS. > сервиса висит за LDAP авторизацией через nginx Вот как раз transmission прекрасно работает с указанием префикса. Там единственное, что нужно сделать кроме проксирования /transmission/ это перманентный редирект /transmisson на /transmission/web. -- Victor Wagner
Re: nginx и проксирование
05.10.2018 22:54, Victor Wagner пишет: > В Fri, 5 Oct 2018 22:32:47 +0300 > artiom пишет: > >> Да, nginx ни в чём, ни в чём не виноват. >> Это на странице прописано включение css от корня и браузер, >> соответственно, делает GET запрос. >> Вопрос, как сделать, не заводя корень, и возможно ли это? > > А подумать? Вот у нас есть поток данных, идущих от сервера к браузеру > через proxy. > Вот через подумать и выходит, что технически это возможно. > Вот где-то внутри этого потока данных js-код, формирующий URL запроса. > По-моему, очевидно, что прошерстить весь этот код и выловить URL, > чтобы их переписать - задача в общем виде не разрешимая. >Так и не требуется. Достаточно подменить PUT/POST/GET/etc., обращающиеся к /bla/bla/... на BASE_URL/bla/bla/... > Если же у нас код дошел до браузера неизменным, то браузер отправит на > прокси ту URL, которую ему отдал сервер. И определить от какого из > проксированных сервисов эта URL тоже будет ох как непросто. > > Раз задача в общем виде неразрешимая, то решать ее придется в частных > случаях, для каждого из сервисов по отдельности, конфигурируя каждый > сервис (если он это позволяет) на работу под уникальным префиксом, > причем совпадающим с тем, что был указан нв фронтэнде. > Ага, это при том, что я пытаюсь общую авторизацию LDAP припилить к сервисам, в которых её нет. > >> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу три > > Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный. > Расходуются только строчки в файле зоны локального DNS. > Не особенно удобно. А в случае с сервисами, авторизуемыми по LDAP через nginx это не вариант. Мне же их надо внутри держать, а запрос проксировать лишь тогда, когда авторизация прошла. >> сервиса висит за LDAP авторизацией через nginx > > Вот как раз transmission прекрасно работает с указанием префикса. > > Там единственное, что нужно сделать кроме проксирования > /transmission/ это перманентный редирект /transmisson > на /transmission/web. Ok, посмотрю, как с ним разобраться. jDownloader работает тоже. Остаётся GUI к youtube-dl.
Re: nginx и проксирование
On Sat, 6 Oct 2018 12:56:42 +0300 artiom wrote: > 05.10.2018 22:54, Victor Wagner пишет: > > В Fri, 5 Oct 2018 22:32:47 +0300 > > artiom пишет: > > > >> Да, nginx ни в чём, ни в чём не виноват. > >> Это на странице прописано включение css от корня и браузер, > >> соответственно, делает GET запрос. > >> Вопрос, как сделать, не заводя корень, и возможно ли это? > > > > А подумать? Вот у нас есть поток данных, идущих от сервера к > > браузеру через proxy. > > > Вот через подумать и выходит, что технически это возможно. > > > Вот где-то внутри этого потока данных js-код, формирующий URL > > запроса. По-моему, очевидно, что прошерстить весь этот код и > > выловить URL, чтобы их переписать - задача в общем виде не > > разрешимая. > >Так и не требуется. Достаточно подменить PUT/POST/GET/etc., > >обращающиеся Где подменить? На клиенте? На proxy-то не получится. Вот у вас есть два сервиса, каждый из которых считает что он в корне сайта, и формирует URL на свои кнопки как /images/something.gif. Вот приходит к вам на прокси запрос GET /images/something.gif. Как вы определите, его надо переписывать на /service1/images/something.gif или на /service2/images/something.gif? > к /bla/bla/... на BASE_URL/bla/bla/... > > > Если же у нас код дошел до браузера неизменным, то браузер отправит > > на прокси ту URL, которую ему отдал сервер. И определить от какого > > из проксированных сервисов эта URL тоже будет ох как непросто. > > > > Раз задача в общем виде неразрешимая, то решать ее придется в > > частных случаях, для каждого из сервисов по отдельности, > > конфигурируя каждый сервис (если он это позволяет) на работу под > > уникальным префиксом, причем совпадающим с тем, что был указан нв > > фронтэнде. > Ага, это при том, что я пытаюсь общую авторизацию LDAP припилить к > сервисам, в которых её нет. > > > > >> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу > >> три > > > > Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный. > > Расходуются только строчки в файле зоны локального DNS. > > > Не особенно удобно. А в случае с сервисами, авторизуемыми по LDAP > через nginx это не вариант. Мне же их надо внутри держать, а запрос > проксировать лишь тогда, когда авторизация прошла. Почему не вариант? Вариант. Вы заводите В nginx name-based virtualhost, и его проксируете весь. Так что запрос https://externalname/static/image.gif проксируется в http://internalcontainerip:port/static/image.gif. Т.е. меняется при проксировании адрес nginx на адрес контейнера (или на localhost, если сервис крутится на той же машине, что и nginx. А та часть URl,которая следует за именем хоста - не меняется. Можно еще извернуться так, чтобы контейнер с сервисом считал что то имя, под которым вся сеть видит виртуальный хост на nginx - это его имя Из того, что каждый сервис будет иметь свой собственный внешний (видимый клиентам) хостнейм, никак не следует что пользователей будут по этому хостнейму пускать на сервис напрямую, минуя общий для всех сервисов фронтенд-прокси. --
Re: nginx и проксирование
06.10.2018 13:46, Victor Wagner пишет: > On Sat, 6 Oct 2018 12:56:42 +0300 > artiom wrote: > >> 05.10.2018 22:54, Victor Wagner пишет: >>> В Fri, 5 Oct 2018 22:32:47 +0300 >>> artiom пишет: >>> Да, nginx ни в чём, ни в чём не виноват. Это на странице прописано включение css от корня и браузер, соответственно, делает GET запрос. Вопрос, как сделать, не заводя корень, и возможно ли это? >>> >>> А подумать? Вот у нас есть поток данных, идущих от сервера к >>> браузеру через proxy. >>> >> Вот через подумать и выходит, что технически это возможно. >> >>> Вот где-то внутри этого потока данных js-код, формирующий URL >>> запроса. По-моему, очевидно, что прошерстить весь этот код и >>> выловить URL, чтобы их переписать - задача в общем виде не >>> разрешимая. >>> Так и не требуется. Достаточно подменить PUT/POST/GET/etc., >>> обращающиеся > > Где подменить? На клиенте? На proxy-то не получится. > Вот именно тут и есть проблема. На прокси получится. Только для этого ему нужно понимать, на какой из сервисов перекидывать запрос. > Вот у вас есть два сервиса, каждый из > которых считает что он в корне сайта, и формирует URL на свои кнопки > как /images/something.gif. > > Вот приходит к вам на прокси запрос GET /images/something.gif. > > Как вы определите, его надо переписывать > на /service1/images/something.gif > или на /service2/images/something.gif? > Да, про это я в курсе. Вообще, сделать это может и возможно. Я даже смутно представляю, как с костылями в виде общего cookies для всех сервисов, но это извращение. >> к /bla/bla/... на BASE_URL/bla/bla/... >> >>> Если же у нас код дошел до браузера неизменным, то браузер отправит >>> на прокси ту URL, которую ему отдал сервер. И определить от какого >>> из проксированных сервисов эта URL тоже будет ох как непросто. >>> >>> Раз задача в общем виде неразрешимая, то решать ее придется в >>> частных случаях, для каждого из сервисов по отдельности, >>> конфигурируя каждый сервис (если он это позволяет) на работу под >>> уникальным префиксом, причем совпадающим с тем, что был указан нв >>> фронтэнде. >> Ага, это при том, что я пытаюсь общую авторизацию LDAP припилить к >> сервисам, в которых её нет. >> >>> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу три >>> >>> Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный. >>> Расходуются только строчки в файле зоны локального DNS. >>> >> Не особенно удобно. А в случае с сервисами, авторизуемыми по LDAP >> через nginx это не вариант. Мне же их надо внутри держать, а запрос >> проксировать лишь тогда, когда авторизация прошла. > > Почему не вариант? Вариант. Вы заводите В nginx name-based > virtualhost, и его проксируете весь. Так что запрос > https://externalname/static/image.gif проксируется в > http://internalcontainerip:port/static/image.gif. Т.е. меняется при > проксировании адрес nginx на адрес контейнера (или на localhost, если > сервис крутится на той же машине, что и nginx. А та часть URl,которая > следует за именем хоста - не меняется. > В смысле, он виден только изнутри и недоступен из внешней сети? > Можно еще извернуться так, чтобы контейнер с сервисом считал что то > имя, под которым вся сеть видит виртуальный хост на nginx - это его имя > Примерно так у меня и есть, в целом: https://habr.com/post/359344/ > Из того, что каждый сервис будет иметь свой собственный внешний > (видимый клиентам) хостнейм, никак не следует что пользователей будут по > этому хостнейму пускать на сервис напрямую, минуя общий для всех > сервисов фронтенд-прокси. > Хм... Т.е., я завожу в своей зоне ещё три домена. При обращении к ним, меня перекидывает на ещё один обратный прокси, который делает проброс только если пользователь авторизован?
Re: nginx и проксирование
On Sat, 6 Oct 2018 17:56:30 +0300 artiom wrote: d > > Из того, что каждый сервис будет иметь свой собственный внешний > > (видимый клиентам) хостнейм, никак не следует что пользователей > > будут по этому хостнейму пускать на сервис напрямую, минуя общий > > для всех сервисов фронтенд-прокси. > > > > Хм... Т.е., я завожу в своей зоне ещё три домена. При обращении к ним, Не домена, а хоста. И все их A-записи указывают на один и тот же IP-адрес - тот, на котором nginx. В конфиге у nginx пишем, что если к нему пришли, указав в http запросе такой-то хостнейм, проксируем на такой-то сервис. Обратная прокси будет одна. И слушать будет на одном IP-адресе и одном порту. Просто в этот IP-адрес будет резолвится несколько имен, и на основании того имени, к которому обратился клиент (и честно указал это в HTTP запросе, как это позволяет HTTP/1.0 и безусловно требует HTTP/1.1) nginx будет решать куда именно проксировать прошедший авторизацию запрос. Просто вы тут разработали систему, когда признаком того, к какому сервису относится запрос, является префикс пути, а я предлагаю использовать для этого другую часть URL - имя хоста. > меня перекидывает на ещё один обратный прокси, который делает проброс > только если пользователь авторизован? >
