0

У меня есть сложное веб-приложение на example-app.com, полностью размещенное на AWS с использованием ELB и Route 53 для DNS. Это приложение Rails.Маршрут 53 - Специальный домен для одной страницы на существующем сервере

Я выполняю эксперимент, который я использую в приложении rails, на example-app.com/test. Я хочу настроить new-domain-app.com, указывая на example-app.com/test, и у вас будет URL-адрес cloacked, который всегда будет new-domain-app.com. Это сайт с одной страницей, поэтому он не требует никакой навигации.

У меня возникли проблемы с настройкой моего DNS на маршруте 53, чтобы выполнить это. Кто-нибудь имеет хорошие идеи о том, как должна выглядеть эта конфигурация Route 53?

ответ

1

AWS предлагает очень простой способ осуществить это - с CloudFront. Забудьте о том, что он продается как CDN. Это также обратный прокси-сервер, который может добавить фиксированное значение в путь и отправить другое имя хоста на серверный сервер, чем тот, который введен в браузер, который звучит так, как вам нужно.

  • Создать веб-распространение CloudFront.

  • Настройте новое доменное имя как альтернативное доменное имя для распространения.

  • Для исходного сервера введите существующее имя хоста.

  • Для origin path введите /test - или любую строку, которую вы хотите префикс на пути, отправленном браузером.

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

  • Укажите ваше новое доменное имя в CloudFront ... Но прежде чем вы это сделаете, обратите внимание, что ваш дистрибутив CloudFront имеет имя хоста dxxxexample.cloudfront.net. После завершения настройки дистрибутива (статус «Выполняется», как правило, через 5-20 минут) ваш сайт должен быть доступен на имя узла cloudfront.net.

Как это работает: При вводе http://example.com в браузер, CloudFront добавит путь происхождения на пути браузер посылает, так GET/HTTP/1.1 становится GET /test/ HTTP/1.1. Эта конфигурация просто префикс пути каждого запроса с строкой, указанной вами в качестве пути источника, и отправляет ее на сервер. Адресная строка браузера не изменяется, потому что это не перенаправление. Заголовок хоста, отправленный браузером, заменяется именем хоста исходного сервера, когда запрос отправляется в начало.

0

DNS знает о доменах, а не о URL-адресах. DNS просто преобразует имена в IP-адреса.

Вы не можете делать то, что вы просите, просто используя DNS и ELB, однако, вы можете сделать отдельный VHOST для new-domain-app.com, который указывает на ваш сайт example-app.com и выполняет то, что вы хотите, используя какое-то правило перенаправления, которое срабатывает только для new-domain-app.com.

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

Так вот некоторые детали:

  1. У вас уже есть example-app.com установки и работы
  2. Вы можете создать запись CNAME, указывающую на new-domain-app.com example-app.com или может сделать запись A, указывающую на тот же IP. Если у вас уже есть example-app.com, указывающий на другой IP-адрес, используйте для этого его субдомен (test.example-app.com).
  3. Настройте новый vhost на своем сервере, который в основном дублирует существующий vhost для new-domain-app.com. Единственное, что вам нужно изменить, это конфигурация имени сервера.

Почему это работает? Поскольку HTTP 1.1 включал заголовок HOST, который отправляют браузеры, а веб-серверы используют в vhosting, чтобы определить, какой виртуальный хост должен направлять входящий запрос. Когда он видит, что клиентский браузер хочет «example-app.com», он направляет запрос соответствующему vhost.

Вместо того, чтобы делать некоторые фантазии проксирования, которые, безусловно, могут быть использованы для получения аналогичного результата, вы можете просто добавить правило перенаправления, которое ищет запросы для хоста example-app.com и перенаправляет их на пример- app.com. В apache, который использует mod_rewrite, который люди часто используют, помещая правила в вездесущий файл .htacess, но также может быть выполнен в nginx и других общих веб-серверах. Специфические особенности немного разные для каждого.

+0

Интересно, и что бы сохранить домен, синхронизированный на new-domain-app.com? Я обсуждал это с SO и serverfault, но решил опубликовать здесь, так как тэг route-53 был популярен, и я думаю, что для окончательного ответа может потребоваться некоторая конфигурация рельсов. –

+0

Я не уверен, что вы подразумеваете под маскировкой. После ввода записи в DNS она видна всем. Нет секретного DNS, который не существует внутри частного сетевого пространства (VPN, немаршрутизируемые IP-адреса и т. П.). – gview

+1

@gview cloaking - это отвратительная тактика с использованием iframes или JavaScript или аналогичной skullduggery, так что в адресной строке браузера отображается адрес, который вы набрали, в то время как контент на самом деле поступает из другого места. Многие регистраторы, которые используют бесплатный хостинг DNS, также имеют настроенные веб-серверы для клиентов, поэтому они создают впечатление, что это часть DNS. Я думаю, что «маскирование домена» - это другое слово. Обходная ужасная идея, но возможна со статическим веб-сервером, чтобы вернуть html-страницу, которая реализует хак. –

1

То, что вы пытаетесь сделать, невозможно. Route53 - это DNS-система, и вы не можете настроить имя хоста (например, new-domain-app.com), чтобы указать URL-адрес (например, http://example-app.com/test) с использованием DNS.

Однако, вероятно, вы используете неправильный инструмент для работы. Если example-app.com/test действительно простой, статический сайт с одной страницей, вам не нужно размещать его внутри приложения Rails. Вместо этого вы можете разместить его в ведомом AWS S3, а затем вы можете указать new-domain-app.com на это ведро с помощью Route53.

Смотрите следующие подробности:

+0

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

+1

В этом случае это значительно сложнее. Вам нужно будет использовать прокси-сервер (например,Nginx), чтобы переписать и прокси URL-запросы с 'http: // new-domain-app.com' на' http: // example-app.com/test'. Я делал это в прошлом, и это всегда занимало больше времени, чем ожидалось. – quarterdome

Смежные вопросы