Мы запускаем два контейнера причала на разных хостах (Host-P, Host-Q). Один из контейнеров развернут с несколькими приложениями (App-A, App-B, App-C). Еще один контейнер, в котором также есть несколько приложений (App-X, App-Y, App-Z).
Host-P => App-A,App-B,App-C
Host-Q => App-X,App-Y,App-Z
myapp.test.com является основным хостом, доступным для веб-клиента. Мой веб-клиент знает о приложении, которое нужно вызвать. Я передаю этот тип приложения в параметре URL. URL будет похож на
http://myapp.test.com/?=appType=App-A
http://myapp.test.com/?=appType=App-B
http://myapp.test.com/?=appType=App-Y
http://myapp.test.com/?=appType=App-X
Где мне нужно настроить логику маршрутизации на основе параметра URL. Могу ли я запустить tomcat / nginx в myapp.test.com хост, который будет делать только маршрутизацию? Какой файл конфигурации мне нужно найти?
Если параметр запроса относится к контейнеру, к которому вы можете обращаться напрямую, вы можете просто передать его в proxy_pass
напрямую, например:
proxy_pass http://$arg_appType;
Но это использование ненадежного ввода, а также огромная дыра в безопасности. Рассматривать ?appType=www.google.com
. Я показываю это на примере того, что не делать.
Вместо этого используйте map
для сопоставления параметров запроса местам назначения:
map $arg_appType $destination {
App-A http://container1:8443;
App-B http://container2:5000;
App-X http://container24:9001;
App-Y https://some.remote.host;
}
Теперь вы можете proxy_pass
прямо к нему.
proxy_pass $destination;
Но вы также должны перехватить ситуацию, в которой неизвестно или нет appType
был дан.
if ($destination = "") {
return 403; # or do something else appropriate
}
Если у вас есть конкретный контейнер для обработки этого сценария, вы можете использовать default
в map
послать ему вместо этого.
map $arg_appType $destination {
....
default http://error-handler-container:8000;
}