Разработка облачных приложений для Microsoft Azure в VS 2013

Цель лекции

Ознакомление с типами проектов Visual Studio 2013 для облачных вычислений, созданием облачного проекта, его реализацией, отладкой, публикацией в облаке Microsoft Azure и использованием.

13.1. Введение. Облачные проекты в Visual Studio 2013. Состав Azure SDK

Лекция посвящена разработке облачных сервисов Microsoft Azure [27, 28] в интегрированной среде Visual Studio 2013. По умолчанию даже в самом полном варианте Visual Studio Ultimate облачные проекты (типа Cloud) в набор проектов не входят.

На рис. 13.1 изображено создание облачного проекта.

увеличить изображение
Рис. 13.1. Создание облачного проекта

Для того, чтобы это осуществилось, необходимо, после инсталляции Visual Studio, инсталлировать комплекс программ Azure SDK (номер версии 2.3 по состоянию на июнь 2014 г.). На рис. 13.2 изображен список инсталлированных компонент Azure SDK. Общий объем скачивания - порядка 300 мегабайт.

увеличить изображение
Рис. 13.2. Список инсталлированных компонент Azure SDK

Инсталлируем на наш компьютер Visual Studio 2013, затем - Azure SDK 2.3.

13.2. Создание облачного проекта

Теперь создаем в VS 2013 облачный проект на языке C# ( рис. 13.1). С помощью Visual Studio 2013 можно теперь разрабатывать и публиковать в Azure облачные сервисы. Для того, чтобы можно было разрабатывать также другие облачные продукты - например, мобильные сервисы, необходимы дополнительные инсталляции. Об этом - в следующих лекциях и лабораторных работах.

Продолжим создание проекта. Назовем его WindowsAzure4.

Очень важная деталь: для разработки облачного проекта среда Visual Studio должна быть вызвана от имени администратора. В Windows 8 это осуществляется следующим образом, как показано на рис. 13.3.

увеличить изображение
Рис. 13.3. Запуск Visual Studio 2013 от имени администратора в Windows 8

Более подробно: выполняется такая последовательность шагов. Переходим на стартовую страницу Windows 8 (с изображением плиток - tiles), на ней находим значок VS 2013, переходим в контекстное меню (правым кликом) и в нем выбираем Запуск от имени администратора. Контекстное меню в таких случаях отображается на месте панели инструментов.

В Windows 7 аналогичные действия реализуются несколько иначе: на панели инструментов находим значок VS 2013, правым кликом переходим в контекстное меню и в нем выбираем Запуск от имени администратора.

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

Вернемся к созданию проекта. Итак, мы в среде VS 2013 от имени администратора. Нажимаем OK для создания облачного проекта.

Открывается окно для выбора роли проекта. Как вы уже знаете из моих курсов по Azure [27, 28], роль - это разновидность облачного приложения. Интуитивно термин роль в контексте Microsoft Azure достаточно точно отражает суть: роль - это разновидность облачного приложения с определенной функцией (ролью) в облаке и в данном проекте. Роль - это код приложения. Экземпляр роли - это экземпляр (запуск) приложения. Число экземпляров ролей - это число запусков облачного приложения. Число экземпляров ролей очень важно: оно фактически выражает степень надежности облачного сервиса. Как правило, рекомендуется иметь как минимум по 2-3 экземпляра каждой роли для большей надежности облака, поскольку облачный сервис - это серверный код, на который ложится большая нагрузка (например, к нему могут обратиться одновременно несколько миллионов пользователей облака). В Microsoft Azure различают следующие основные виды ролей: Web-роль - облачный Web-сервис, Worker-роль - фоновый процесс, реализующий какие-либо вычисления. В новой версии Azure в качестве одного из видов ролей рассматривается также виртуальная машина (VM-роль). В таком случае можно сказать, что Web-роли и Worker-роли могут работать в облаке в нескольких экземплярах (и это даже рекомендуется для надежности), а VM-роль, разумеется, существует всегда в одном экземпляре. Трудно было бы представить себе, если бы виртуальные машины клонировались во многих экземплярах: виртуальная машина - это весьма серьезный облачный ресурс, а надежность виртуальной машины обеспечивается другими средствами - серверной операционной системой, которая реализует данную VM на конкретном компьютере центра обработки данных (в настоящее время это Windows Server 2012 Release 2, либо Linux).

На рис. 13.4 изображено окно выбора роли.

увеличить изображение
Рис. 13.4. Окно выбора роли

Мы видим более детально, каковы разновидности ролей в новой версии Azure:

• ASP.NET Web Role - облачный сервис с пользовательским Web-интерфейсом, реализованным по технологии ASP.NET, основной технологии разработки Web-приложений для платформы .NET;
• WCF Web Role - Web-роль, реализуемая с помощью Windows Communication Foundation (WCF). Эта технология, как вы уже знаете из лекции 3, обеспечивает создание Web-сервисов. В Microsoft Azure значительная часть сервисной функциональности реализована с помощью WCF;
• Worker Role - фоновый вычислительный процесс;
• Cache Worker Role - worker-роль, реализующая кластер кэш-памяти, доступный всем экземплярам роли;
• Worker Role with Service Bus Queue - worker-роль, реазилующая обработку сообщений, помещенных в очередь сервисной шины (Service Bus) - см. курс [28].

Таким образом, Web-роли реализуют различные виды Web-интерфейса, а worker-роли - обработку различных облачных ресурсов, совместно используемых экземплярами ролей.

Выбираем наиболее часто используемый вариант - ASP.NET Web Role. Создается облачный проект и его конфигурационные файлы, которые отображаются на вкладке Solution Explorer ( рис. 13.5). Подчеркну, что сама роль еще не создана, но информация о виде роли была необходима для формирования конфигурационных файлов облачного сервиса.

Рис. 13.5. Структура облачного проекта, отображенная в Solution Explorer

Рассмотрим более подробно структуру конфигурационных файлов и всех прочих файлов проекта, автоматически сгенерированных средой VS 2013. Имя созданного сервиса - WindowsAzure4. Среда создала для него три конфигурационных файла: ServiceDefinition.csdef.xml, ServiceConfiguration.Cloud.cscfg.xml и ServiceConfiguration.Cloud.Local.cscfg.xml - определение сервиса, конфигурация сервиса при запуске на локальном компьютере на эмуляторе облака и конфигурация сервиса для его развертывания в облаке. Для полноты привожу начальные состояния этих трех файлов.

ServiceDefinition.csdef.xml:

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzure4" 
    xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" 
    schemaVersion="2014-01.2.3">
</ServiceDefinition>
    

ServiceConfiguration.Cloud.cscfg.xml:

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName=" WindowsAzure4" 
    xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" 
    osFamily="4" osVersion="*" schemaVersion="2014-01.2.3">
</ServiceConfiguration>
    

Файл ServiceConfiguration.Local.cscfg.xml идентичен предыдущему файлу.

Содержание файлов очевидно и особых комментариев не требует: в них указаны имя сервиса, ссылка на пространство имен для используемых в файлах XML-тегов, номера версий XML и XML-схем, ссылка на версию ОС.

Теперь создадим роль в данном проекте. Для этого в контекстном меню пункта Roles выбираем пункт Add (добавление роли) / New Web Role Project. Открывается окно Add New .NET 4.5 Role Project ( рис. 13.6).

увеличить изображение
Рис. 13.6. Окно добавления роли в облачный проект

Выбираем из двух вариантов ASP.NET Web Role. Открывается другое окно - New ASP.NET Web project: WebRole1 ( рис. 13.7).

увеличить изображение
Рис. 13.7. Окно New ASP.NET Project: Web Role1

В этом окне предлагаются варианты шаблонов для создания Web-роли:

• Empty - пустая роль (шаблон кода, в который необходимо добавить нужные действия роли при наступлении типовых событий);
• Web Forms - реализация роли на основе Web-формы;
• MVC (Model - Vew - Controller) - реализация роли на основе известной парадигмы Модель - Вид - Контроллер;
• Web API - реализация роли на основе Web API;
• Single Page Application - реализация роли на основе шаблона кода, управляющего единственной Web-страницей;
• Facebook - реализация роли на основе шаблона кода, обращающегося к широко известной социальной сети Facebook.

Выбираем вариант Single Page Application, в котором создается Web-страница с возможностью регистрации на ней и последующего входа по зарегистрированному имени. Для управления страницей используются скрипты на языке JavaScript, которые генерируются автоматически средой VS 2013.