Сегодня я встречался с небольшой компанией, которая разработала SaaS-решение для управления задачами и проектами. Это очень классное приложение, и, как это принято в наши дни, использует субдомены для определения компании конечного пользователя по мере поступления запросов в браузер. Итак, если бы я подписался на приложение, мой домашний URL был бы http://adamhoffman.getdonedone.com, тогда как если бы вы зарегистрировались (и имели маловероятное имя Билла Иона), ваша домашняя страница была бы http: //billion.getdonedone.com. Это обрабатывается в коде приложения ASP.NET на их серверах Win2K8, размещенных в Rackspace. Вопрос быстро стал: «Эй, мы можем сделать что-то подобное в Azure, верно?»
Ответ — да, и нет, и да. Позволь мне объяснить.
Мое мгновенное предположение было «да», и, в конечном счете, это правда, что вы можете выполнить это поведение. Однако требуется, чтобы везде, где вы размещаете свой DNS, который указывает на ваше приложение, поддерживалось понятие « записи DNS с подстановочными знаками » и, более конкретно, поддерживалось « подстановочные знаки CNAME ». Оказывается, службы DNS Go Daddy не поддерживают это, поэтому нам придется искать другие возможности, чтобы получить эту функциональность.
Следующий вопрос, который вы, возможно, задаете себе сейчас: почему нас интересует подстановочный знак CNAME, а не просто подстановочный DNS? В частности, ответ заключается в том, как Azure обеспечивает высокую надежность. Как очень быстрый DNS-учебник, вы должны понимать разницу между записями A и CNAME . Перейдите по ссылке, если хотите узнать подробности, но краткий ответ: «Записи указывают на IP-адреса, записи CNAME — это псевдонимы других записей доменных имен. Хорошо, но почему это важно?
Как оказалось, когда вы хотите разместить свой модный бренд на своем веб-сайте на базе Azure, вы можете сделать это только с помощью записи CNAME. Причина, по которой вы не можете использовать запись A для указания своего сайта, заключается в том, что у вашего сайта нет IP-адреса. Да, это так, но это не то, к чему вы можете получить доступ, и даже если бы вы могли, это не является постоянным и, скорее всего, изменится. Чтобы избежать этой проблемы, на самом деле вы получаете доменное имя, которое является частью «cloudapp.net». Например, веб-сайт, который я собираюсь продемонстрировать для вас и поддерживающий поддомены с подстановочными знаками, доступен по адресу « wildcardsubdomain.cloudapp.net », но не по IP-адресу. Ну да ладно, умные штаны. Адресуется также и по IP. Например,в этот момент я также могу попасть на тот же сайт по адресу http://65.52.208.222, но я не должен на это полагаться. Кто знает — к тому времени, когда вы прочитаете это, это может вообще не сработать. Если вы хотите узнать, как я это выяснил, посмотрите nslookup .
Причина, по которой все это верно, заключается в том, что Azure полагается на CNAME, так что он может переключать ваш IP, но сохранять адресность вашего сайта. Почему он это делает? Это безумная работа с сетью, связанная с балансировщиком нагрузки и контроллером Azure Fabric, и это сделано для того, чтобы обеспечить максимальную стабильность и работоспособность вашего сайта.
Хорошо, вернемся к рассматриваемой проблеме — передача наших динамических поддоменов в код нашего приложения, чтобы позволить многопользовательским приложениям разделяться на домен третьего уровня. Как мы с этим справимся? Вот так.
- Во-первых, мы найдем службу DNS, которая поддерживает подстановочные знаки CNAME.
- Далее мы настроим эту службу DNS так, чтобы она указывала на наше приложение.
- Наконец, мы напишем код приложения, который понимает входящие запросы, чтобы мы могли соответствующим образом форкнуть наших клиентов.
- Наконец, мы посмотрим на функции маршрутизации URL-адресов в ASP.NET и посмотрим, сможем ли мы расширить наш пример, чтобы хорошо с ним интегрироваться.
На первый взгляд, это не так просто, как вы думаете. Например, я использовал GoDaddy для приобретения нескольких своих доменов (да, я знаю о SOPA и не буду здесь заниматься политикой). Как видно из приведенной здесь ссылки, подстановочные знаки CNAME недоступны на DNS-серверах GoDaddy, поэтому нам нужно искать в другом месте. Я не буду пытаться составить здесь исчерпывающий список, но одной службой DNS, которая поддерживает эту концепцию, является служба Amazon Route 53 DNS. Еще одной приятной особенностью этого является то, что у него есть API, который фактически открывает еще одну возможность, если мы того пожелаем. Наше решение здесь для направления всех поддоменов на один размещенный веб-сайт. Альтернативой нашему мультитенантному подходу с одним приложением может быть конкретное предоставление поддоменов и указание их на разных размещенных веб-сайтах. Так,вместо
* .adamhoffman.net CNAME wildcardsubdomain.cloudapp.net (в котором есть код приложения, который сортирует его)
мы могли бы вместо этого пойти с
customer1.adamhoffman.net CNAME customer1.cloudapp.net (для домена customer1) и
customer2.adamhoffman.net CNAME customer2.cloudapp.net (для домена customer2) и
скоро…
Да, мы могли бы сделать это, и с помощью API Route 53 мы могли бы даже предоставлять эти новые записи CNAME по мере необходимости. Но это не тот маршрут, который мы собираемся использовать. Мы хотели бы использовать первый вариант и иметь одну запись CNAME с подстановочными знаками, которая просто направляет все в наше супер-умное приложение.
Итак, затем мы получим учетную запись Amazon для настройки наших DNS-сервисов на 53-м маршруте. После регистрации создайте в терминологии Amazon размещенную зону для домена, в котором мы будем поддерживать групповые символы. Конечно, вам нужно владеть этим доменом.
Взгляните сейчас на «набор делегирования», который назначил вам Маршрут 53. Здесь перечислены 4 DNS-сервера, и это DNS-серверы, о которых вам нужно сообщить регистратору домена, чтобы он гарантировал, что запросы на ваш домен передаются на эти DNS-серверы Route 53. В моем случае моим регистратором для adamhoffman.net является Go Daddy, поэтому я буду использовать инструменты Go Daddy для указания этих DNS-серверов.
После всего этого есть только один последний шаг. Нам нужно сообщить DNS-серверам, которые обрабатывают adamhoffman.net, что каноническое имя (CNAME) для * .adamhoffman.net действительно является wildcardsubdomain.cloudapp.net. Посмотрите на запись CNAME для * .adamhoffman.net на следующем рисунке. Это секретный соус.
Теперь, как только вы это сделаете, весь трафик для всех поддоменов adamhoffman.net направляется на wildcardsubdomain.cloudapp.net. Это относится не только к поддоменам 3-го уровня, но также и к 4-му уровню ( hello.world.adamhoffman.net ) и всем уровням за его пределами ( this.is.really.cool.adamhoffman.net ). Как только мы получим это, на самом деле достаточно просто проверить запрос на принятие мультитенантных решений в нашем коде приложения, используя Request.Url.Host, который будет содержать полное доменное имя, которое первоначально запрашивалось в запросе (а не cloudapp. сетевое имя), вот так:
protected void Page_Load(object sender, EventArgs e)
{
string[] domainparts = Request.Url.Host.Split(new char[] { '.' });
if (domainparts.Length > 2)
{
// there must be a subdomain in front of the two last parts
// (i.e. xxx.adamhoffman.net or xxx.yyy.adamhoffman.net, etc.)
System.Text.StringBuilder sbOut = new System.Text.StringBuilder("Subdomain Segments: <br/>");
for (int i = 0; i < domainparts.Length - 2; i++)
{
sbOut.Append(domainparts[i] + "<br/>");
}
this.output.Text = sbOut.ToString();
}
}
Теперь, некоторые из вас говорят, эй, я не могу использовать функции маршрутизации страниц ASP.NET или MVC Framework для добавления маршрутов к этой стороне? Опять да и нет. Похоже, что встроенная функция маршрутизации не поддерживает маршрутизацию на поддоменах, но Maarten Balliauw проделал определенную работу, чтобы расширить ее и сделать это возможным. Хотя это потенциальная мелочь, на самом деле нет необходимости выяснять, какой поддомен был источником исходного запроса, и поэтому мы не будем здесь это рассматривать.
Конечно, есть много DNS-провайдеров, которые поддерживают подстановочные знаки CNAME. Маршрут 53 является одним из них, а Go Daddy — нет. Если вы успешно сделали это с другим поставщиком DNS, напишите мне, и я добавлю детали здесь.
Исходный код здесь .
Интересное примечание — похоже, что вы действительно можете использовать записи A и полагаться на IP-адрес развертывания Azure, если вы не удаляете и не развертываете свое развертывание … Я по-прежнему не рекомендую это, поскольку вы несомненно, забудет обновить ваши DNS-серверы, когда вы действительно удалите и повторно развернете. Тем не менее, хорошее чтение на эту тему здесь .