Какую конфигурацию следует указать, чтобы разные серверы находились в одном и том же пространстве URL-адресов в CloudBees PaaS

Я пытаюсь использовать CloudBees PaaS (RUN@CloudBees), чтобы консолидировать по существу три разных использования в одном и том же пространстве URL:

  • корень (/) основной лендинг, маркетинговая страница
  • app (/app) java-приложение, работающее в CloudBees
  • blog (/blog) другое Java-приложение, работающее в cloudbees или, возможно, за его пределами (example.wordpress.com)

Если бы я делал это сам в центре обработки данных или в AWS, я бы установил обратный прокси-сервер (возможно, как Varnish и настроил обратный прокси-сервер для сопоставления пространства URL-адресов следующим образом:

  • root (/): www.example.com/ --> CMS, работающая как приложение cloudbees example-cms.cloudbees.net
  • app (/app) Java-приложение, работающее в CloudBees www.example.com/app -> app.example.com
  • блог (/blog) аналогично www.example.com/blog -> example.wordpress.com или exampleblog.cloudbees.net

Как я могу добиться того же с помощью CloudBees. Можно ли это сделать? Не слишком ли многого можно ожидать от поставщика PaaS?


reverse-proxy paas cloudbees
person Pankaj Tyagi    schedule 13.09.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Интересная проблема и несколько решений:

  1. Используйте домены вместо путей (например, blog.example.com и т. д.), чтобы вы могли использовать DNS для управления вещами.
  2. Создайте приложение, которое, по сути, проксирует трафик для вас (оно может работать на cloudbees или где-либо еще) — есть много способов сделать это.
  3. Используйте какой-нибудь сервис маршрутизации/прокси (например, CloudFlare), который может позволить вам настроить правила маршрутизации (чтобы он мог проксировать трафик).

Я всегда предпочитаю номер 1 — DNS — отличный способ делать такие вещи. При таком подходе вы можете иметь похожие URL-адреса /blog в своем приложении paas и выполнять перенаправление 302 на реальный blog.example.com - это дает вам и то, и другое.

person Michael Neale    schedule 17.09.2012
comment
Спасибо. Номер 1 действительно самый простой. Воздействие на поисковую систему также неплохое, так как ваш основной URL-адрес получит кредит для статей в перенаправлении (302, как вы предполагаете, лучше, чем 301). Единственная проблема заключается в том, что после перенаправления пользователя он будет использовать URL-адрес blogs.example.com для обмена, а это не то, что хотелось бы. Тем не менее решение 1 кажется довольно простым в реализации. - person Pankaj Tyagi; 25.09.2012
comment
Кстати, если кто-то хочет добавить обратный прокси-сервер в свое приложение на основе рельсов, я нашел rack-reverse-proxy gem быть очень хорошим. Также см. ответ jplewicki на stackoverflow - person Pankaj Tyagi; 27.09.2012