Много пользовательских доменов для экземпляра AppEngine
Для нашей работы услуги электронной коммерции AppEngine мы хотели бы предложить опцию для клиентов выполнить хранилища на их пользовательских доменах (например: www.mystore.com вместо www.enstore.com/mystore).
С пользовательской точки зрения я хотел бы, чтобы они ввели доменное имя, которое они хотят использовать в их предпочтении, экранируют и говорят им, как настроить их DNS.
Я знаю, как Вы обычно добавляете домены к экземпляру AppEngine (через Google Apps), но я не уверен, что можно автоматизировать это. И даже если бы это возможно, они были бы всем (сотни), перечисленные на нашей странице приложений Google.
Кто-либо знает, возможно ли это/если существует хороший способ сделать это?
2 ответа
Я не думаю, что есть способ добавить домены "программно" к экземпляру AppEngine. Очевидно, что домены можно добавлять только с помощью описанного вами метода Google Apps. Это подтверждается в этом посте SO: Как я могу получить foo.somedomain.com для работы с myapp.appspot.com/foo в appengine
Единственные опции, которые приходят на ум, это следующие:
HTTP перенаправление
Многие DNS-провайдеры поддерживают HTTP перенаправление. В этом случае ваши клиенты смогут настроить
mystore.comиwww.mystore.comдля перенаправления наwww.enstore.com/mystore. Есть некоторые очевидные недостатки этого метода, которые могут быть неприемлемы. Прежде всего, при наличии 301 и 302 перенаправлений, пользователи все равно будут перенаправлены на зарегистрированный URL AppEngine:www.enstore.com/mystore, и он отобразится в их браузере. Кроме того, выбор между 301 и 302 перенаправлениями может сделать SEO хитрым, так как вам нужно будет разобраться в том, как ведут себя поисковые системы с этими перенаправлениями. Например, большинство поисковых систем не будут использовать оригинальный URL в качестве источника для ключевых слов, когда вы используете 301 редирект.В дополнение к 301 и 302 перенаправлениям, некоторые провайдеры DNS (например, DNS Made Easy ) также предоставляют то, что они называют "скрытым перенаправлением по маске". Страница будет отображаться внутри скрытого ифрейма, поэтому URL не меняется в браузерах пользователя. Однако это делает SEO еще более хитрым, и это не позволит пользователям закладывать внутренние страницы в закладки или легко на них ссылаться.
Как видите, этот вариант менее чем идеален, но в некоторых ситуациях он является одним из вариантов, который следует учитывать. Также обратите внимание, что на данный момент, переадресация HTTP с помощью 301 переадресации - это предлагаемое обходное решение для Naked Domain Issue 777 на трекере проблем AppEngine.
Reverse Proxy
Другой вариант может быть настройка небольшого сервера где-нибудь в другом месте, например, небольшого Amazon EC2 Instance, а также настройка простого reverse proxy. Вы сможете очень легко это настроить, просто используя Apache и mod_proxy (или различные другие альтернативы). Это позволит вам попросить ваших клиентов настроить обычную запись A Record, указывающую на этот экземпляр, в то время как HTTP-сервер Apache будет действовать как прокси-сервер вашего AppEngine.
Фундаментальной конфигурационной директивой для установки обратного прокси в mod_proxy является ProxyPass. Обычно вы устанавливаете ее одной строкой для каждого
VirtualHost(для каждого клиентского домена):ProxyPass / http://www.enmystore.com/mystore/Конфигурация удаленного прокси может быть легко обработана вашим внутренним программным обеспечением.
Это более аккуратное решение, которое дает вам большой контроль - но очевидно, что есть некоторые затраты на эти преимущества. Прежде всего, есть расходы на хостинг реверсного прокси. Вы также добавите еще одну точку отказа, так что вам придется добавить это к вашему плану высокой доступности. Кроме того, если вы обслуживаете некоторые страницы через SSL, это может стать довольно сложным.
Другой вариант - каждый клиент должен подписаться на приложения Google, а затем добавить свое приложение appengine к своему приложению. Так они смогут управлять урной. Для этого им нужно будет использовать имя cname, поэтому urls будет ограничен чем-то вроде 'store.customer.com'. Вам нужно будет поддерживать многократное арендование вне заголовка хоста, но это не сложно сделать, учитывая, что у вас уже есть способ поддерживать многократное арендование. Возможно, вы захотите сделать настройку для первой пары клиентов самостоятельно, чтобы вы могли задокументировать самый простой способ настройки.
Приложение для просмотра кода заклепок делает это, так как вы можете добавить его в свой домен приложений Google. Смотрите http://code.google.com/p/rietveld/wiki/CodeReviewHelp#Using_Code_Reviews_with_Google_Apps для получения более подробной информации.
Предпочтительным вариантом, вероятно, является предложение вашего решения через Google Solutions Marketplace: http://www.google.com/enterprise/enterprise_marketplace/about.html