LINUX.ORG.RU

Ищется реверс прокси

 ,


0

1

Требований пока три:

Первое: лёгкий, не загромождающий память и не жрущий процессорное время тоннами.

Второе: возможность легко задавать соответствие между параметрами исходного запроса и бэкендом, который их будет выполнять. Например, в nginx я могу написать следующее:

map $http_host $rp_backend {
        hostnames;
        default some_host:80;

        .example.com some_host:80;
        .example.net other_host:80;
        .beta.example.net testing_host:8027;
}

И потом просто сказать

proxy_pass http://$rp_backend;
там где нужно перекинуть запрос бэкенду.

Третье: минимально вмешиваться в обмен данными между клиентом и бэкендом. В частности, уметь передавать тело запроса напрямую в бэкенд без предварительного кэширования у себя. Такое умеет Pound, но он не умеет маппинг, так что приходится для каждого хостнейма писать конструкцию из 7 строк вида:

Service
        HeadRequire "Host:\s+example\.com"
        BackEnd
                Address 1.2.3.4
                Port    80
        End
End

Меня задолбало поддерживать разрастающийся и становящийся унылым и запутанным конфиг паунда и я хочу перейти на что-то более умное. Но nginx слишком умный и кэширует предварительно запросы. Из-за этого ломается, в частности, upload_progress_module, установленный на другом nginx'е где-то во внутренней сети за проксёй. Тело запроса ему прилетает целиком и получить инфу о том, сколько таки уже загружено, из браузера не получается.

Если же поставить upload_progress_module на саму проксю, то это может сломать другие приложения, пути в которых могут совпасть с тем, который я укажу для прогресса. Да и сама по себе загрузка файла в ещё один лишний кэш — это дополнительная нагрузка на диски, которой можно было бы избежать.

Есть варианты?

★★★★★
Ответ на: комментарий от Atlant

Отключение кэширования/буферизации в nginx возможно только для ответов, но не для запросов:

синтаксис: proxy_buffering on | off; умолчание:

proxy_buffering on;

контекст: http, server, location

Разрешает или запрещает использовать буферизацию ответов проксируемого сервера.

INFOMAN ★★★★★ ()
Ответ на: комментарий от INFOMAN

я конечно не настолько влезал в потроха, но зачем ему кешировать входящие запросы, если ответы на них всё равно не кешируются.

Atlant ★★★★★ ()
Ответ на: комментарий от Atlant

Чото походу там такая же шняга что и в Pound — замапить одной строкой хедер в адрес бэкенда нельзя, + всё усугубляется более тяжёлой архитектурой и, соответственно, огромнейшим количеством опций.

INFOMAN ★★★★★ ()
Ответ на: комментарий от Atlant

Хрен знает зачем, ни если я, допустим, заливаю 2 гига, то эти 2 гига сначала лягут в буфер на nginx-фронтенде, потом лягут в другой буфер на nginx, к которому прикручен passenger, и только после всех этих манипуляций попадут к rails-приложению. И если во втором случае такая буферизация оправдана — файло от медленного клиента принимает лёгкий воркер nginx, а не тяжеленное рельсовое приложение с кучей подключенных гемов и внешних библиотек, то в первом оно мне нафиг не надо, ибо задача той прокси всего-навсего выяснить, кому обрабатывать запрос. Так как ipv4-адрес имеется один, а виртуальных машин с разными настройками и разными версиями всякой шняги за ним несколько.

INFOMAN ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.