
У меня есть онлайн-сервис, который предоставляет публичный профиль для пользователей. Пользователи могут зарегистрироваться и просматривать свои профили на www.example.com/users-name
.
Я хочу предоставить премиум-сервис, где пользователь может получить доступ к этому профилю через свое доменное имя (при этом сам сайт все еще будет размещен у меня). Так что, если они зарегистрируются users-custom-domain.com
, они смогут посетить этот сайт и увидят тот же профиль, что и выше, плюс некоторые премиум-функции
Какая инфраструктура должна быть для поддержки этого? Предположительно, пользователю придется направить свой DNS на мои серверы? Если я размещаю свой продукт на облачном хосте, таком как Heroku, можно ли этого добиться? Будет ли каждый пользователь, использующий пользовательский домен, получать доступ к изолированному веб-приложению? Например, если используется облачная инфраструктура, должен ли каждый «экземпляр» выделять новое приложение или это можно как-то сделать общим?
Я знаю, что есть много способов добиться этого, я просто ищу идеи и лучшие практики, так как не знаю, с чего начать (например, как about.me или tumblr могут этого добиться).
решение1
Тебе нужно:
- DNS для перевода доменного имени пользователя в имя или адрес, которые вы контролируете. Вы можете разместить эту службу и жестко закодировать необходимые записи, или пользователь может управлять своим собственным DNS и самостоятельно устанавливать записи. Я рекомендую вам иметь имя на вашем домене, к которому пользователи CNAME-имят свои записи; как обнаружил Github, когда им пришлось перенумеровывать, если вы позволяете людям жестко закодировать IP-адреса, все становится беспорядочным.
- Ваша инфраструктура веб-сервиса должна знать, как отвечать на запросы домена пользователя и какой контент для него обслуживать. Обычно это подразумевает, что пользователь делает что-то в своем профиле, чтобы сказать: «Я укажу вам такой-то домен», а затем у вас есть автоматизированная сантехника за кулисами, которая настраивает уровень веб-сервера для выполнения правильной работы.
Все в вашем приложении может быть общим; нет абсолютно никаких причин запускать что-то отдельное для обслуживания каждого пользователя. Реализацию на уровне поставщика вам нужно будет выяснить самостоятельно; существует слишком много возможностей и комбинаций, чтобы дать вам всеобъемлющий обзор.