Microsoft Windows Azure. Начнем с простого (или локальная разработка для «облака»). Часть 2

  • Article

В предыдущей части данного обзора мы познакомились с набором расширений для Microsoft Visual Studio, который позволяет разрабатывать приложения для Windows Azure. Мы обсудили процесс установки этих расширений и упомянули, что существует возможность локальной разработки для Windows Azure с использованием эмуляторов как самой платформы, так и облачного хранилища.

В этой части мы рассмотрим, из чего состоит «облачное» приложение и попробуем эмулятор Windows Azure в действии.

Приложение на Windows Azure

Запустим Visual Studio Web Developer Express и создадим новый проект – New Windows Azure Project и назовем его WA_Test. Добавим к проекту два «строительных блока» - один экземпляр веб-роли и один экземпляр прикладной роли. В результате в Visual Studio мы получим решение (solution), которое будет состоять из трех проектов – проекта для нашего приложения, проекта для веб-роли и проекта для прикладной роли.

AZLocal_09

Рис. «Облачное» решение в Visual Studio

Проект для нашего приложения – WA_Test содержит ссылки на проекты для веб и прикладной роли, а также два конфигурационных файла – ServiceConfiguration.cscfg и ServiceDefinition.csdef. Таким образом можно считать, что базовое приложение в Windows Azure – это набор и одного или более экземпляров веб или прикладной роли и два конфигурационных файла, описывающих данное приложение.

AZLocal_10

Рис. Приложение на Windows Azure

Введение в роли в Windows Azure

Как мы отметили выше, в Windows Azure используется концепция «ролей» - строительных блоков, из которых создается «облачное» приложение. По сути, каждый экземпляр той или иной роли - веб-роли или прикладной роли – это автоматически создаваемая виртуальная машина с рядом предопределенных характеристик. Третий тип роли – это VM-роль, которая представляет собой механизм хостинга самостоятельно создаваемой виртуальной машины на основе Windows Server 2008 R2. Ниже мы остановимся на веб и прикладной роли.

Веб-роль

Веб-роль – это аналог сайта на ASP.NET, который хостится под Internet Information Service (IIS). Данная роль подходит для хостинга веб-сайтов, веб-сервисов и кода, который взаимодействует по протоколу HTTP/S и может работать под управлением IIS/ASP.NET. Существует еще две разновидности веб-роли – CGI веб-роль и WCF-сервис. Платформа Windows Azure обеспечивает возможность хостинга языков программирования и сред выполнения, которые поддерживают протокол FastCGI. Шаблон проекта CGI в Visual Studio реализует представляет собой расширение веб-роли за счет включения опции поддержки CGI. WCF-сервис – это еще один вариант веб-роли, предназначенный для хостинга сервисов, созданных на основе технологии Windows Communication Foundation. Выбор в Visual Studio шаблона проекта данного типа приводит к добавлению в проект кода, облегчающего создание WCF-сервисов.

Прикладная роль

Прикладная роль служит для реализации логики приложения и может использоваться для выполнения фоновых активностей, асинхронной обработки данных, хостинга серверов приложений, написанных на различных языках программирования, включая Java и т.п.

По аналогии с традиционными многоуровневыми (многозвенными) приложениями, код, выполняющийся в веб-роли можно рассматривать как интерфейсный уровень, а код в прикладной роли – как реализацию уровня бизнес-логики.

Роли и виртуальные машины

Как мы отметили выше, каждый экземпляр роли представляет собой автоматически создаваемую виртуальную машину с рядом предопределенных характеристик. Тип виртуальной машины задает число ядер процессора, объем памяти и объем локальной файловой системы, выделяемой для работы экземпляра роли. В настоящее время можно выбрать из следующего набора предопределенных виртуальных машин:

  • Ультра Mалая
    • 1-ядерный процессор, 1ГГц, 768 Мбайт памяти, 20 Гбайт дискового пространства
  • Малая
    • 1-ядерный процессор, 1,6 ГГц, 1.75 Гбайт памяти, 225 Гбайт дискового пространства
  • Средняя
    • 2-ядерный процессор, 1,6 ГГц, 3.5 Гбайт памяти, 490 Гбайт дискового пространства
  • Большая
    • 4-ядерный процессор, 1,6 ГГц, 7 Гбайт памяти, 1000 Гбайт дискового пространства
  • Супер Большая
    • 8-ядерный процессор, 1,6 ГГц, 14Гбайт памяти, 2040 Гбайт дискового пространства

Тип виртуальной машины задается в файле, описывающем создаваемое приложение – об этом мы поговорим в следующем разделе. Каждая виртуальная машина может содержать либо 64-битную версию Windows Server 2008, либо 64-битную версию Windows Server 2008 R2. В виртуальной машине установлены следующие компоненты:

  • .NET 3.5 SP1
  • .NET 4 (RTM)
  • VC80 CRT (8.0.50727)
  • VC90 CRT (9.0.30729)
  • URL Rewrite Module 2.0

При необходимости использования VC10 CRT (т.е. MSVCR100.DLL), эта библиотека должна быть развернута вместе с ролью, использующей ее. Подробнее о том, какие пакеты обновлений установлены для текущей версии операционной системы, работающей внутри виртуальной машины, см. http://msdn.microsoft.com/en-us/library/ee924680.aspx

Конфигурационные файлы

Конфигурационные файлы - ServiceConfiguration.cscfg и ServiceDefinition.csdef используются для задания основных характеристик «облачного» приложения и составляющих его экземпляров ролей. Эти файлы упаковываются вместе с кодом приложения и разворачиваются в Windows Azure.

Файл ServiceDefinition.csdef служит для описания приложения, включая составляющие его роли. В ем содержатся настройки, распространяющиеся на все экземпляры ролей. Эти настройки могут быть прочитаны в режиме выполнения с помощью программного интерфейса Windows Azure Service Hosting Runtime API. Содержимое файла не может быть изменено после запуска приложения.

Файл ServiceConfiguration.cscfg задает значения настроек, описанных в файле ServiceDefinition.csdef и указывает число экземпляров для каждой роли. Содержимое файла можно изменять и после запуска приложения.

Расширения Visual Studio - Windows Azure Tools for Microsoft Visual Studio содержат страницы свойств, которые можно использовать для изменения значений, хранимых в конфигурационных файлах. Для доступа к страницам свойств следует выбрать роль в Solution Explorer и по нажатию правой кнопки «мыши» выполнить команду Properties. Давайте сделаем это. Начнем с веб-роли.

AZLocal_11

Рис. Панель свойств для веб-роли

В разделе Configuration мы можем указать т.н. «уровень доверия .NET», число экземпляров роли (Instance Count) и размер виртуальной машины (по умолчанию используется Малая виртуальная машина). Также можно указать протокол взаимодействия с веб-ролью – HTTP или HTTPS и необходимость в использовании диагностики и хранилище, куда будут помещаться диагностические данные. Так как мы используем локальную эмуляцию Windows Azure, для хранения диагностических данных будет использовано локальное хранилище – Development Storage, о котором более подробно мы поговорим в одной из следующих частей данного цикла.

В разделе Settings можно задать конфигурационные настройки, которые будут доступны программно и в дальнейшем могут быть изменены.

Раздел Endpoints описывает «точки входа» в наше приложение. По умолчанию – это HTTP-протокол и стандартный 80-й порт. Есть возможность указания HTTPS-протокола и задания необходимого SSL-сертификата.

Раздел Local Storage служит для управления локальным хранилищем, раздел Certificates позволяет загрузить сертификаты Х.509, используемые, например, для программного управления приложением по протоколу REST. Раздел Virtual Network позволяет активировать сервис Azure Connect, который служит для объединения локальных и «облачных» ресурсов в VPN-сеть.

Панель свойств для прикладной роли выглядит практически также, за исключением того, что здесь отсутствует понятие «начальной точки входа».

AZLocal_12

Рис. Панель свойств для прикладной роли

После того как мы разобрались с ролями, экземплярами и базовыми настройками, давайте запустим наше «облачное» приложение в режиме эмуляции.

Локальный запуск «облачного» приложения

Чтобы запустить наше «облачное» приложение в режиме эмуляции Visual Studio должна быть запущена с повышенными привилегиями – это требуется для загрузки среды эмуляции Windows Azure. Если вы уже запустили Visual Studio под стандартной учетной записью, вы можете запустить среду эмуляции с помощью утилиты CSRun, которая находится в каталоге \Program Files\Windows Azure SDK\v1.3\bin. Эта утилита должна быть запущена с повыщенными привилегиями.

Нажмем кнопку F5 и дождемся построения нашего «облачного» приложения и запуска среды эмуляции Windows Azure. В результате, мы увидим веб-страницу, запущенную на локальном веб-сервере. Наше «облачное» приложение заработало. В правой части панели задач найдем иконку с флажком Windows Azure (см. ниже) и нажмем на ней правую кнопку «мыши»

AZLocal_13

Рис. Иконка эмулятора Windows Azure

AZLocal_14

Рис. Команды эмулятора Windows Azure

Выберем команду Show Compute Emulator UI для просмотра того, как наше приложение работает в режиме эмуляции Windows Azure. Перейдем в разделы Web Role и Worker Role и посмотрим на статус экземпляра каждой роли. Для веб-роли мы увидим:

[fabric] Role Instance: deployment(1).WA_Test.WebRole1.0

[fabric] Role state Started

А для прикладной роли:

[fabric] Role Instance: deployment(1).WA_Test.WorkerRole1.0

[fabric] Role state Started

Information: Working

AZLocal_15

Рис. Работа «облачного» приложения в режиме эмуляции

Fabric – это основной компонент Windows Azure, можно сказать, ядро «облачной» операционной системы, отвечающий за управление виртуальными машинами и экземплярами ролей. Развертывание и старт экземпляра роли начинают ее жизненный цикл. Подробнее об этом мы поговорим в следующей части.

В следующей части

В следующей части мы продолжим знакомство с созданием приложений в Windows Azure и обсудим жизненный цикл роли и объектную модель Windows Azure.

/АФ