Microsoft Azure
Облачный бизнес
Вам понадобится

Microsoft Azure

Попробуйте платформу Microsoft Azure совершенно бесплатно.

Visual Studio

Бесплатная версия Visual Studio, позволяющая создавать приложения для платформы Microsoft Azure.

SDKs и дополнительные
инструменты

Инструменты разработки приложений для платформы Microsoft Azure.

 

Создание Windows Azure Virtual Machine для хостинга web-приложений

Добрый день!

В своей  предыдущей статье я рассказывал о том, как можно легко и просто опубликовать веб-приложение, написанное на ASP.NET MVC 4 в новом сервисе Windows Azure Web Sites.

В сегодняшней статье я постараюсь рассказать, как можно расширить границы использования Azure на примере создания в нем виртуальной машины и хостинга на ней веб-приложения.

Шаг 0. Получения доступа.

Для тех, кто поленился перейти по ссылке в начале статьи, я напомню, как можно получить бесплатный доступ к новым возможностям Windows Azure. 

Для начала вам надо зарегистрироваться на  90-дневный триал, после чего добавить к своей подписке новые preview-функции (как раз те самые, о которых идет речь). Делается это на странице Предварительный просмотр компонентов, где можно выбрать то, что вы хотите попробовать. В данном случае выбираем Virtual Machine.

Шаг 1. Создание виртуальной машины


После того, как мы получили доступ к компонентам Windows Azure, самое время начать их использовать. Для этого в  портале управления выберите пункт Virtual Machines и внизу страницы нажмите большую кнопку плюс (не промахнетесь):

Нам будет доступно два пункта: Quick Create и From Gallery. На самом деле разница между ними невелика, поэтому рассмотрим более полный путь. Выбираем From Gallery:

В данном диалоговом окне у нас есть несколько вариантов на выбор. Начнем с того, что помимо готовых образов ОС (видно на скриншоте), нам также предоставляется возможность загрузить свой собственный образ или VHD-диск, из которого впоследствие создастся виртуальная машина. Это будет удобно для крупных проектов, где нужно создать ферму одинаковых машин, не заморачиваясь с настройкой каждой из них. Нас же сейчас это не интересует, поэтому обратим свой взгляд на доступные готовые образы.

На выбор нам предлагается несколько вариантов. Есть Windows Server 2008 R2 (двух версий), линуксовые машинки, специализированный сервер под SQL Server (про этот образ, кстати, недавно  писали на хабре) и герой нашего сегодняшнего эксперимента — Windows Server 2012. Почему именно он? Это лично мой выбор. Поскольку я использую Windows Azure пока больше в ознакомительных целях, то я решил, что было бы неплохо попробовать и «новинку сезона» — новый сервер 2012.

Итак, выбираем нужную нам ОС и жмем стрелку снизу. Попадаем на следующий экран мастера создания виртуальной машины:

Здесь все довольно понятно. Надо указать имя VM, пароль администратора и выбрать одну из предложенных конфигураций будущего «железа». Выбор довольно неплохой и может покрыть большинство требований по производительности для разных типов проекта. Я выбрал Small, что вполне меня устраивает. Идем дальше.

На третьем шаге мастера все тоже довольно понятно:

Для начала надо определиться с назначением будущей машины. Если мы хотим использовать ее как самостоятельный ресурс (а в данный момент мы именно этого и хотим), то выбираем Standalone. РежимConnect To, как написано в подсказке, позволит нам подключить данную ВМ в некую существующую сеть для разделения нагрузки. Нас это пока не интересует.

Затем надо придумать имя хоста, по которому будет доступна машина. Тут надо не путать имя машины на предыдущем шаге и данное имя хоста. Имя машины — это имя компьютера в Windows. Имя хоста же — это субдомен в домене cloudapp.net, по которому будет осуществляться доступ и управление сервером. Это имя должно быть уникально, поэтому нам тут же в мастере предоставляется подсказка о доступности или занятости того или иного имени.

Остальные поля довольно понятны и особо заострять внимание на них не стоит. Там надо выбрать аккаунт хранилища (либо существующий, либо создать новый), расположение ВМ и подписку, в рамках которой данная машина будет тарифицироваться.

На четвертом шаге вообще ничего делать не нужно, оставляем все как есть:

Нажимаем на галку внизу, и виртуальная машина начнет создаваться.

Шаг 2. Управление виртуальной машиной

После того, как вы создали виртуальную машину, она будет доступна в соответствующем списке:

Обязательно дождитесь, когда статус машины сменится с Provisioning на Running. Это будет означать, что машина готова к использованию. Если нажать на ее имя, то откроется панель управления виртуальной машиной:

Внизу страницы есть кнопка Connect. Она поможет вам получить правильный файл rdp для подключения к этой машине с помощью удаленного рабочего стола. Настало самое время зайти на свеженький сервер и поуправлять им.

Шаг 3. Управление сервером

На самом деле, в этой статье я не буду подробно рассказывать об администрировании Windows Server 2012. Поскольку в названии данной статьи упоминаются web-приложения, вот именно этим мы и займемся — установим IIS.

При первом логине в новый сервер нам откроется окно Server Manager:

По умолчанию, в Windows Server 2012 службы IIS не включены, поэтому их надо добавить. Выбираем пунктAdd roles and features, после чего открывается мастер добавления ролей. Три раза жмем Next (особо любопытные почитают, что там пишут, но сейчас нас это не интересует), и в открывшемся дереве выбираем Web Server (IIS). Далее нам необходимо обязательно выбрать нужные компоненты IIS, которые позволят запускать на нем ASP.NET MVC приложения. Точные параметры настройки я писать не буду, каждый сам решит, что именно ему нужно. Обязательно надо включить ASP.NET, остальное по вкусу.

Жмем несколько раз Next, настраиваем будущую роль как нам надо и после завершения процесса установки наш сервер с радостью готов принимать гостей. Убедиться в этом можно, перейдя по  localhost/. Должно появиться что-то вроде этого:

Шаг 4. Открытие доступа

Все здорово, вот мы наконец наладили веб-сервер, разместили на нем какое-то приложение и оно открывается по localhost. Как же теперь открыть его извне? На самом деле все довольно просто. Наверняка вы еще на этапе создания вирутальной машины пытались нажимать на ссылку в панели управления, которая имеет вид <ваша_вирут_машина>.cloudapp.net. И наверняка у вас ничего не отобразилось. Все потому, что к виртуальной машине закрыт доступ извне, причем не на уровне фаерволла самой операционной системы, а на уровне инфраструктуры Windows Azure.

Если вы в панели управления виртуальной машиной посмотрите наверх, то увидите там три пункта меню:DashboardEndpoints и Configure. С первым мы разобрались в самом начале, с последним все понятно — там настраиваются параметры «железа», а вот что такое Endpoints давайте разберемся.

В закладке Endpoints мы можем задавать то, какие протоколы и какие порты будут открыты для данной виртуальной машины и на какие физические порты они будут перенаправлены:

По умолчанию в этом списке будет лишь один порт — тот, по которому вы соединяетесь через Remote Desktop. Причем публичный порт может быть любым, что, видимо, сделано для большей безопасности. Для того, чтобы открывать веб-приложения на данной виртуальной машине, необходимо открыть 80й порт. На скриншоте выше это показано. После этого действия по ссылке  <ваша_вирут_машина>.cloudapp.net вы должны будете увидеть ваше собственное приложение. Маленькая победа достигнута.

Шаг 5. Присваиваем собственный домен

На предыдущем шаге мы сделали все, чтобы приложение заработало в облаке и было доступно извне. Однако согласитесь, что было бы совсем не круто, если бы мы могли обращаться к нему только по субдомену и никак бы не могли присвоить свой один или несколько доменов.

Конечно же это сделать возможно и довольно просто. Для этого официальная документация советует два разных пути и оба из них связаны с редактированием зоны DNS. Первый подразумевает под собой то, что вы создаете CNAME запись, в которой указываете, что, например,  www.mydomain.com будет перенаправляться на mywinazure.cloudapp.net. Этот метод прост, но слишком уж прямолинеен. Если у вас на сервере размещено несколько веб-приложений, или же на основном домене может быть несколько субдоменов, то этот способ не сработает. Благо, что есть второй, более качественный способ.

В качестве решения, которым, кстати, воспользовался и я, предлагается редактирование A записи в зоне DNS. В панели управления виртуальной машиной, в области справа, вы могли заметить два IP адреса. Один называется приватным и является IP самой машины, а второй — публичный, виртуальный (Virtual IP, VIP). Вот именно его и надо указывать в зоне A для редактируемого домена. В данном случае весь трафик будет посылаться на вашу виртуальную машину, где IIS будет определять домен и выдавать соответствующее приложение (при условии правильной настройки Web Sites в самом IIS). Все просто и очевидно до неприличия, но именно так оно и работает.

Шаг 6. Бонус

В качестве бонуса я расскажу о примере интеграции одного сервиса Windows Azure с другим. Если вы читали предыдущую мою статью, то вы знаете, что в ней я описывал сервис фактов о программировании. В рамках той статьи я описал процесс публикации ASP.NET MVC 4 приложения в облако с использованием Windows Azure Web Sites и Windows Azure SQL Database. Сейчас же, при изучении Virtual Machines, я решил перенести этот же сервис из Web Sites на виртуальную машину, дабы иметь возможность привязать собственный домен, да и вообще иметь все в одном месте (сейчас в ВМ хостится несколько сайтов).

Файлы самого приложения я перенес безболезненно. Но когда я вспомнил о базе, то сначала немного опечалился. Я сразу представил себе, что мне придется сначала скачать дистрибутив, затем отвести под его установку некое место. Запустить службу БД на и без того не самой быстрой машине. Иметь БД и веб-приложение на одном сервере. Переносить данные с одного сервера на другой. Ну и еще несколько подобных неприятностей. Не сказать, чтобы это было прям так уж сложно, но, честно говоря, лениво.

И тут я подумал — а что если я натравлю приложение, размещенное в виртуальной машине, на БД, которая была создана в рамках хостинга сайта на Web Sites? Ведь с точки зрения приложения данная БД точно такая же, как если бы она была установлена на локальном сервере. Сказано — сделано. Я поменял web.config нужным образом, указав в качестве сервера БД тот самый сервер, который у меня существовал в Windows Azure. И что бы вы думали? Оно работает. Теперь у меня есть отдельный сервер приложений и отдельная база данных, которые можно независимо друг от друга замещать, расширять и зеркалить в случае необходимости. Спасибо Azure за такие приятности.

Заключение

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

Если кому инетерсно посмотреть, что за приложение работает в облаке, то вот ссылки:  prog-facts.ru и ss10.ru (второе привел просто в качестве примера, что два домена отлично направляются на один хостинг).

Спасибо за внимание!

Благодарим Георгия Могелашвили, Microsoft MCP за подготовку статьи