Опубликован: 28.01.2014 | Доступ: свободный | Студентов: 2078 / 183 | Длительность: 14:33:00
Лекция 4:

Разработка приложений с Windows Azure Cloud Services

Конфигурация Cloud Service

В данном случае под Cloud Services мы понимаем проект (набор файлов), который описывает облачный сервис, данный проект может использоваться средой разработки Visual Studio. Конфигурация состоит из двух XML-файлов:

  • Файл определения сервиса (Service Definition file, файл с расширением .csdef), содержащий описание ролей, точек входа в них (порты с указанными протоколами, открытые клиенту) и настройки конфигурации без заданных значений (например, строки подключения).
  • Файл конфигурации сервиса (Service Configuration file, файл с расширением .cscfg), содержащий непосредственные значения для различных настроек, например, количество экземпляров-серверов, которые будут обслуживать конкретную роль, или значения для описанных в файле определения сервиса настроек конфигурации.

В файлах конфигурации Windows Azure также есть возможность задать два параметра, указывающих версию операционной системы, которая будет обслуживать развернутый сервис. Первый параметр – "семейство" операционной системы, атрибут osFamily в файле конфигурации сервиса. Может иметь следующие значения: 1 (Windows 2008), 2 (Windows 2008 R2), 3 (Windows 2012). Второй параметр – "версия" операционной системы, атрибут osVersion в файле конфигурации, имеющий вид типа WA-GUEST-OS-2.15_201305-01. Получающий подобную настройку сервис Windows Azure производит поиск конкретного образа операционной системы определенного разработчиком семейства. Необходимо упомянуть, что стандартным значением этой настройки является "*", которое обозначает, что сервис будет запущен на самой новой версии операционной системы и по мере выхода новых версий будет обновлён. Механизм обновления сначала обновляет все сервисы с указанным атрибутом osVersion="*".

Корректная настройка конфигурационных файлов имеет критическое значение для развертывания в облако. Оба конфигурационных файла при развертывании решения Cloud Service в Windows Azure попадают на обработку специальному автоматическому сервису Windows Azure Fabric, который, согласно этим файлам, производит поиск свободных ресурсов, удовлетворяющих конфигурации, инициирует создание и установку виртуальных машин и дальнейшее развертывание решения на эти виртуальные машины. Таким образом, если в конфигурации сервиса настроено N экземпляров для Web-роли и M экземпляров для Worker-роли, то конфигурация развернутого в облако решения примет вид, как на изображении.

Стенды

Непосредственно при развертывании разработчиком проводится настройка того расположения, в которое будет развернуто его решение. В Windows Azure Cloud Services доступно два расположения для развернутого решения – это Production и Staging (используемые для решения, работающего в реальной среде, и решения, развернутого для тестирования, соответственно). Эти расположения, называемые ячейками развертывания, фактически отличаются только доменным именем и внутренними правилами маршрутизации. Так, для Production-ячейки внутренними сервисами настраивается DNS-имя, которое указал разработчик при создании Cloud Service (например, http://appname.cloudapp.net, собственное доменное имя указать при развертывании нельзя), для Staging же создается временное DNS-имя типа http://[guid].cloudapp.net. При переразвертывании решения в Staging-развертывание DNS-имя сбрасывается на новое.

В том же случае, если решение успешно прошло тестирование в Staging-ячейке, разработчик вместо развертывания решения в Production-ячейку, может нажатием кнопки на портале управления инициировать процедуру VIP Swap. Данная процедура отправляет запрос балансировщику нагрузки, который "меняет местами" Virtual IP, используемый для развертывания, и, таким образом, без каких-бы то ни было физических переносов и миграций за несколько минут решение в Staging-ячейке переходит в ячейку Production. Если же во время выполнения в ячейке Production выявляются ошибки, процедура VIP Swap может быть инициирована повторно, и разработчики могут исправить ошибки и протестировать решение в Staging-ячейке, недоступной конечному пользователю.

VIP Swap

Рис. 5.4. VIP Swap

Масштабирование Cloud Service

Windows Azure Cloud Services могут быть автоматически масштабируемы на основе загрузки CPU или текущего количества сообщений в очереди сообщений хранилища Windows Azure. В панели администрирования Windows Azure Cloud Service пользователь может просматривать прогноз масштабирования, который сообщает о необходимости выполнить масштабирование для развернутого облачного сервиса. Для настройки автоматического масштабирования облачного сервиса необходимо указать период ожидания после каждого изменения масштаба. Пользователь может указать время ожидания в минутах перед следующим увеличением или уменьшением масштаба.

Маштабирование Cloud Service

увеличить изображение
Рис. 5.5. Маштабирование Cloud Service

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

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

Также возможна установка дополнительного программного обеспечения, которое называется WASABi, для осуществления автомасштабирования без участия портала управления Windows Azure, и с помощью REST API.

Windows Azure Tools for Visual Studio

Windows Azure Tools for Visual Studio является пакетом инструментов, которыми пользуется разработчик для создания, управления, запуска и развертывания Web-приложений в Windows Azure. В данный пакет входят шаблоны проектов (например, Web-роли, Worker-роли, Worker-роли с поддержкой Caching и т.д.), расширения интерфейса Visual Studio (например, новое представление Windows Azure Log, в реальном времени оповещающее разработчика о статусе развертывания), расширения Storage Explorer и Server Explorer (например, после установки Windows Azure Tools for Visual Studio появляется возможность управлять аккаунтом хранилища, созданным в Windows Azure Storage, Service Bus и т.д.), в Visual Studio появляется интегрированное развертывание с помощью Web Deploy прямо в облако, IntelliTrace и многое другое. С каждой новой версией Windows Azure Tools появляется большое количество серьезных нововведений, с которыми можно ознакомиться по следующей ссылке - http://msdn.microsoft.com/ru-ru/library/windowsazure/ff683673.aspx.

Windows Azure Tools могут быть установлены со следующими версиями Visual Studio:

  • Visual Studio 2012
  • Visual Studio Express 2012 для Web
  • Visual Studio 2010 SP1
  • Visual Web Developer 2010 SP1
Добавление роли в Cloud Service

Рис. 5.6. Добавление роли в Cloud Service

Windows Azure SDK

Ядром всей функциональности, которую использует разработчик локально, является Windows Azure SDK. Windows Azure SDK не является частью .NET Framework, поэтому она должна устанавливаться отдельно для возможности разработки для Windows Azure.

Основными компонентами Windows Azure SDK являются эмуляторы вычислений и хранилища. Эмулятор вычислений используется для запуска, отладки и тестирования Cloud Services на локальном компьютере, что может быть осуществлено даже без подключения к Интернет. Эмулятор вычислений предоставляет графический интерфейс для базовых задач по управлению и просмотра диагностических логов для уже запущенного решения Cloud Service.

Просмотр диагностических логов запущенного Cloud Service

увеличить изображение
Рис. 5.7. Просмотр диагностических логов запущенного Cloud Service

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

  • Эмулятор поддерживает ограниченное количество ролей и экземпляров. Максимальное количество ролей на развертывание равно 25, максимальное количество поддерживаемых ядер равно 20.
  • Эмулятор предоставляет запущенным решениям администраторские права, тогда как решение, запущенное в Windows Azure, по умолчанию не имеет администраторских прав.
  • Эмулятор не предоставляет балансировку нагрузки.
  • По умолчанию эмулятор использует IIS Express, Windows Azure – IIS.

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

Эмулятор хранилища предоставляет возможность запуска трех сервисов хранилища Windows Azure на локальном компьютере – блобов, таблиц и очередей. Сервисы запускаются в виде REST-сервисов и далее могут быть использованы из любого локального приложения по определенным портам. Основным механизмом локального эмулятора хранилища является SQL Server.

Интерфейс эмулятора хранилища

увеличить изображение
Рис. 5.8. Интерфейс эмулятора хранилища
Руслан Муравьев
Руслан Муравьев

Сайт dreamspark пишет что код истек :(

Andriy Zymenko
Andriy Zymenko

Этот курс требует оновления https://portal.azure.com/#create/hub здесь нет пункта Web Site в разделе Compute. К тому же для создание трубуется подписка

Евгений Ермолов
Евгений Ермолов
Россия, Москва
Игорь Афанасьев
Игорь Афанасьев
Украина, Харьков, ХПИ, 2001