Visual Studio 2012

Статья
07/03/2015

Разработка и развертывание облачных сервисов Microsoft Azure с применением Visual Studio

В этой статье обсуждаются предварительные версии Visual Studio 2012 и компонентов Microsoft Azure. Любая изложенная здесь информация может быть изменена.

Продукты и технологии:
Microsoft Azure SDK for .NET (June 2012), Visual Studio 2010 SP1, Visual Studio 2012
В статье рассматриваются:

создание проектов для Microsoft Azure;
преобразование проектов веб-приложений в проекты облачных сервисов;
локальная отладка;
публикация в Microsoft Azure;
работа с Server Explorer;
анализ проблем с помощью Visual Studio.

Microsoft Azure SDK for .NET прошел долгий путь с момента первого выпуска. Функциональность платформы Microsoft Azure и ее инструментария регулярно расширялась, в частности были добавлены проекты Microsoft Azure Cloud Service во все проекты веб-приложений, поддержка проектов ASP.NET MVC версий 3 и 4; кардинально упрощена публикация. Это согласуется с общим курсом Microsoft на улучшение инструментария, используемого для облачных разработок, и более тесную интеграцию со всеми аспектами жизненного цикла разработки приложений.

По состоянию на июнь 2012 в Microsoft Azure предлагаются три варианта вычислительных контейнеров (compute containers) для разработки и выполнения приложений. К ним относятся Microsoft Azure Web Sites (Preview) для быстрого и простого развертывания веб-сайтов и веб-приложений, Microsoft Azure Virtual Machines (Preview) для поддержки отказоустойчивых виртуальных машин (VM) с Windows Server и Linux в виде Infrastructure as a Service (IaaS) и приложений, выполняемых в них, а также Microsoft Azure Cloud Services, которые обеспечивают возможности резервирования, бесконечного масштабирования и поддержки многоуровневых приложений, выполняемых на основе Platform as a Service (PaaS). В этой статье основное внимание уделяется разработке облачных сервисов; об остальных вариантах можно узнать больше на сайте windowsazure.com.

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

Приступаем

Microsoft Azure SDK for .NET (June 2012) включает средства, работающие поверх Visual Studio 2010 SP1 и Visual Studio 2012 RC (или выше). В этой статье мы задействуем Visual Studio 2012 RC. Лучший способ установки этих средств таков: запустите Visual Studio, откройте диалоговое окно New Project и выберите узел Cloud. В нем появится Get Microsoft Azure SDK for .NET.

По этой ссылке вы перейдете в .NET Developer Center (bit.ly/v5MF7m) для Microsoft Azure, и на странице будет выделена ссылка на скачивание установщика этого SDK.

Создание проектов Microsoft Azure

После того как вы все установили, можно приступать к созданию Microsoft Azure Cloud Service — центрального проекта для работы с Microsoft Azure Cloud Services. Облачный сервис является вычислительным контейнером (compute container) для бесконечно масштабируемых, высокодоступных и многоуровневых облачных приложений. Полезная новинка в этом выпуске SDK заключается в том, что он может работать параллельно с выпуском Microsoft Azure SDK for .NET November 2011 (1.6). То есть вы можете по-прежнему работать с проектами под версию 1.6 без их обновления. В целом, у вас есть два варианта создания приложения для Microsoft Azure. Первый подход — создание проекта Microsoft Azure с нуля. Для этого запустите Visual Studio с повышенными привилегиями, откройте меню File и выберите New | Project для запуска диалога New Project. В Installed Templates | Visual C# (или Visual Basic, или F#) выберите узел Cloud, а затем шаблон проекта Microsoft Azure Cloud Service, чтобы появился диалог New Cloud Service Project. В этом диалоге вы можете добавить роли в облачный сервис.

Если июньский SDK (за 2012 г.) установлен параллельно с ноябрьским (за 2011 г.), в верхней части этого диалога появляется раскрывающийся список для выбора версии SDK, что позволяет указать версию SDK, с помощью которой вы создаете роль.

Прежде чем продолжить, давайте кратко рассмотрим, что такое роли и экземпляры. Роль — это в основном определение как для приложения, так и для PaaS-управляемой VM, в которой оно будет выполняться; в свою очередь это определяет, например, какую ОС и модули нужно установить в VM, какие параметры диагностики следует использовать и какие конечные точки предполагается предоставлять. Считайте роль своего рода шаблоном, позволяющим «штамповать» столько экземпляров (т. е. VM), сколько вам необходимо для масштабирования под текущие требования к вашему облачному сервису. В настоящее время из Visual Studio можно создать два типа ролей:

веб-роль (Web Role) — веб-приложение, выполняемое в IIS. Оно доступно через конечную точку HTTP или HTTPS. Как правило, используется для интерфейсных веб-приложений и сервисов;
рабочая роль (Worker Role) — приложение фоновой обработки, выполняющее произвольный .NET-код. Оно также может предоставлять внешний фасад для Интернета и внутренние конечные точки по протоколам HTTP, HTTPS, TCP и UDP.

Экземпляры прямо соответствуют VM в облаке, выполняющим роли, которые были определены шаблоном роли.

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

Рис. 1. Общие компоненты облачного сервиса

Load Balancer	Средство балансировки нагрузки
Cloud Service	Облачный сервис
Web Role 1 (IIS) Port 80	Веб-роль 1 (IIS), порт 80
Worker Role 1	Рабочая роль 1
Microsoft Azure SQL Database	База данных Microsoft Azure SQL
Microsoft Azure Storage	Microsoft Azure Storage

Как отмечалось, в июньском выпуске был введен другой тип вычислительного контейнера — Microsoft Azure Virtual Machine (Preview). VM позволяют создавать полностью настраиваемые рабочие нагрузки с применением любой ОС или любого ПО (например, баз данных, серверов приложений или унаследованных компонентов). Это очень удобно для добавления собственного уровня, который можно использовать в сочетании с облачными сервисами. Этот контейнер позволяет создавать VM с нуля или использовать VM, предоставляемые галереей VM в Microsoft Azure. На момент написания этой статьи вы должны сначала создать VM в портале управления (а не из Visual Studio), но, как вы потом увидите, VM и их свойства можно изучать в Server Explorer, так что ссылаться на рабочие нагрузки VM в коде вашего облачного сервиса несложно. Заметьте: в отличие от VM веб- и рабочих ролей, управляемых и обновляемых Microsoft, свои Microsoft Azure Virtual Machines вы будете обновлять и контролировать самостоятельно.

Если ваше приложение находится под интенсивной нагрузкой, вам может понадобиться горизонтальное масштабирование (scale out). Для этого вы добавляете больше экземпляров в свой облачный сервис.

После добавления ролей в облачный сервис и щелчка кнопки OK среда Visual Studio создаст решение, которое включает проект облачного сервиса и проекты, соответствующие каждой добавленной вами роли.

Веб-роли — это проекты веб-приложений ASP.NET с несколькими отличиями. Проект веб-роли, MVCWebRole1, содержит ссылки на следующие библиотеки, который нет в стандартном веб-приложении ASP.NET.

Microsoft.WindowsAzure.Configuration: Вспомогательная библиотека конфигурации. Эта сборка появилась только в выпуске за июнь 2012 г. и позволяет разработчикам получать конфигурационные значения сервисов Microsoft Azure независимо от того, где размещено приложение — локально на предприятии, в облачном сервисе, на веб-сайтах Microsoft Azure или в IaaS VM. Это означает, что, в каком бы конфигурационном файле (web.config или cloud.cscfg) ни содержалась ваша строка подключения или любой другой параметр, вы можете получить доступ к этому значению, используя один и тот же метод. В примере ниже показано, как использовать CloudConfigurationManager для чтения ключа «MyConnectionString» из конфигурационного файла:

private string conn = CloudConfigurationManager.GetSetting("MyConnectionString");

Microsoft.WindowsAzure.Diagnostics: Содержит API диагностики и протоколирования, позволяющие включать и настраивать уровень диагностики для вашего приложения в Microsoft Azure. На рис. 2 показано, как инициализировать монитор диагностики и добавить некоторые источники данных журнала событий Windows в методе OnStart роли в WebRole.cs.
Microsoft.WindowsAzure.ServiceRuntime: Сборка, включающая API исполняющей среды для Microsoft Azure. В следующем примере показано, как использовать свойство CurrentRoleInstance класса RoleEnvironment:

var roleInstance = RoleEnvironment.CurrentRoleInstance;

Microsoft.WindowsAzure.StorageClient: .NET API для доступа к сервисам хранилищ Microsoft Azure для больших двоичных объектов (Binary Large Objects, BLOB), таблиц и очередей. Ниже демонстрируется, как создать объект учетной записи хранилища и новый клиент для BLOB-сервиса:

CloudStorageAccount storageAccount = 
  CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting(
  "MyConnectionString"));
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

Рис. 2. Инициализация монитора диагностики и добавление некоторых источников данных журнала событий Windows

public class WebRole : RoleEntryPoint
{
  public override bool OnStart()
  {
    DiagnosticMonitorConfiguration diagConfig = 
    DiagnosticMonitor.GetDefaultInitialConfiguration();
    diagConfig.WindowsEventLog.DataSources.Add("System!*");
    diagConfig.WindowsEventLog.DataSources.Add("Application!*");
    diagConfig.WindowsEventLog.ScheduledTransferPeriod =
      TimeSpan.FromMinutes(1.0);
    diagConfig.WindowsEventLog.ScheduledTransferLogLevelFilter = LogLevel.Error;
    DiagnosticMonitor.Start(
      "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", diagConfig);
    return base.OnStart();
  }
}

Кроме Micro¬soft.WindowsAzure.Diagnostics и Microsoft.WindowsAzure.Ser¬viceRuntime, на все перечисленные выше сборки ссылаются как на NuGet-пакеты, что упрощает обслуживание вашего приложения при появлении более новых версий этих библиотек.

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

Для создания облачного сервиса с любым количеством веб- и рабочих ролей можно использовать диалог New Project | Cloud | Microsoft Azure Cloud Service и применять разные шаблоны для каждой роли. После создания проекта вам нужно сконфигурировать каждую роль, дважды щелкая в Solution Explorer узел роли (в нашем примере — MvcWebRole1 в папке Roles). Дизайнер ролей позволяет настроить важные параметры, относящиеся к роли. Так, вы можете независимо задать нужное число экземпляров каждой роли для большей производительности и обеспечения избыточности. Microsoft Azure фактически требует минимум двух экземпляров, чтобы гарантировать высокую доступность, определенную в соглашении уровня сервиса.

Все параметры хранятся в конфигурационном файле Microsoft Azure Service. Начиная с выпуска 1.6 за ноябрь 2011 г., вы можете создавать несколько конфигурационных файлов для поддержки разных сценариев. Например, вам могла бы понадобиться конфигурация сервиса, которая содержит только два экземпляра для промежуточной среды и четыре экземпляра для производственной. По умолчанию, существуют конфигурационные файлы для локальной и облачной сред, но вы можете создавать свои конфигурации, используя элемент <Manage…> в раскрывающемся списке Service Configuration, как показано на рис. 3. Портал управления Microsoft Azure поддерживает изменение некоторых конфигурационных параметров после развертывания через Web UI.

Рис. 3. Конфигурационные файлы сервиса

Чтобы лучше понять, как это работает, посмотрите на то, как мы оперируем строками подключения к хранилищам. Допустим, вы хотите создать приложение, которое хранит данные о клиентах, такие как имена и телефонные номера. При локальном выполнении (например, в отладочном режиме) эти данные будут храниться в локальном хранилище, используемом эмулятором или механизмом локальных баз данных, таким как SQL Server 2012 LocalDB. Конфигурация локального хранилища не годится для облачного, потому что в вашей роли нет механизма постоянного хранения наподобие LocalDB, а значит, вы предпочтете задействовать возможности хранилищ Microsoft Azure, например Microsoft Azure Storage или Microsoft Azure SQL Database. Строка подключения тоже указывает на локальное хранилище или DNS-имя localhost, так что и она не будет работать в облаке.

Вместо этого вам нужно указать в строке подключения учетную запись хранилища Microsoft Azure, подходящую для целевой среды в Microsoft Azure. Вот здесь и становится понятным, насколько удобен механизм поддержки нескольких конфигураций. Вы можете определять такие параметры, как строки подключения, в разделе Settings дизайнера ролей. Там можно добавить новый параметр типа Connection String и назвать его, например, «MyConnectionString».

Теперь вы можете ввести строку подключения, щелкнув кнопку с многоточием и тем самым открыв окно формирователя Storage Account Connection String. Сначала добавьте значение для локального хранилища, выбрав параметр Use the Microsoft Azure storage emulator. Потом введите строку подключения, которую будет использовать ваше публикуемое приложение. Для этого нужно переключить параметр конфигурации сервиса (показанный на рис. 3) в Cloud и снова открыть Storage Account Connection String (рис. 4).

Рис. 4. Формирователь Storage Account Connection String для облачной конфигурации

Далее введите удостоверения учетной записи хранилища, которые вы хотите использовать при сохранении своих данных по клиентам. Ключ учетной записи можно получить, используя параметр «manage keys» в разделе Storage портала управления Microsoft Azure.

Как упоминалось, вы можете теперь обращаться к значению строки подключения из кода через объект CloudConfigurationManager:

var conn = CloudConfigurationManager.GetSetting("MyConnectionString");

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

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

Другой интересный новый аспект ролей в выпуске за июнь 2012 г. — Microsoft Azure Caching (Preview). Как и любое другое решение для кеширования, цель этого — повысить производительность и уменьшить задержки. В отличие от других решений оно работает в экземплярах роли и может действовать как распределенный и высокодоступный сервис для экземпляров роли. Его можно использовать в качестве провайдера для существующих API кеширования, таких как кеширования в ASP.NET, кеша вывода, кеша состояния сеанса или кеша памяти (memcache). Кеширование включается и конфигурируется в роли. Вы можете просто установить флажок Enable Caching, чтобы получить оптимальные настройки по умолчанию и сразу же ввести их в действие.

Существующие роли с избыточной памятью могут быть совмещены с сервисом кеша либо вы можете создать новую выделенную роль кеша. Вариант совмещения имеет то преимущество, что это позволяет задействовать избыточные ресурсы в экземплярах роли, за которые вы уже заплатили. Каждый «внутриролевой» сервис кеша можно настроить для хостинга нескольких именованных кешей с индивидуальными политиками, которые контролируют доступность каждого именованного кеша, правила замещения данных и др. Каждый именованный кеш можно сконфигурировать на совместимость с memcache и для программного доступа, а также для его использования существующими решениями кеширования (например, кешем вывода или кешем состояния сеанса) в качестве резервного хранилища. Новый «внутриролевой» сервис кеша совместим с локальными ApplicationServer API для кеширования, что упрощает миграцию в облако. Как упоминалось, вы можете даже создать выделенную роль кеширования (Caching Role), выбрав шаблон Cache Worker Role при добавлении новой роли в свой проект. Подробнее о настройке кеширования см. в статье MSDN Library «How To: Use Microsoft Azure Caching (Preview)» по ссылке bit.ly/LRFStZ.

Преобразование проектов веб-приложений в проекты облачных сервисов

Помимо традиционного способа создания проекта для Microsoft Azure, также можно «азурифицировать» существующий проект веб-приложения. Допустим, у вас уже есть проект Web Application, например проект ASP.NET MVC 4, который вы хотите развернуть в Microsoft Azure. Щелкните свой проект правой кнопкой мыши и выберите команду Add Microsoft Azure Cloud Service Project.

Это приведет к добавлению в решение проекта облачного сервиса. Кроме того, Visual Studio добавит NuGet-ссылки, необходимые для проекта Microsoft Azure в проект MVC. Наряду с этим свойство Copy Local для сборки System.Web.MVC устанавливается в true, так как эта сборка отсутствует в Microsoft Azure.

Локальная отладка приложения Microsoft Azure

После создания проекта вам наверняка потребуется его отладка. Всегда помните, что для отладки приложения Microsoft Azure среду Visual Studio нужно запускать с привилегиями администратора. Как и в случае любого другого проекта Visual Studio, вы можете начать отладку, установив точку прерывания и нажав F5. Стоит отметить, что в SDK 1.7 по умолчанию Visual Studio и Compute Emulator используют IIS Express для хостинга экземпляров и LocalDB для хранилища на этапе разработки — в противоположность IIS и SQL Express в SDK 1.6 (не волнуйтесь, этот вариант сохранен в свойствах проекта).

При отладке Visual Studio будет автоматически использовать локальную конфигурацию сервиса. Как и в предыдущих версиях, вы можете задействовать Microsoft Azure Compute Emulator для выполнения различных операций, таких как просмотр журналов, а также перезапуск и удаление развернутых версий (рис. 5). Чтобы открыть Compute Emulator, щелкните правой кнопкой мыши значок Microsoft Azure на панели задач и выберите Show Compute Emulator UI. Заметьте, что Microsoft Azure Compute Emulator содержит новую конфигурацию развертывания, где размещаются два экземпляра веб-роли и два экземпляра рабочей роли.

Рис. 5. Microsoft Azure Compute Emulator

Публикация в Microsoft Azure

Теперь, когда вы создали приложение, отредактировали его и локально отладили, вы готовы к его развертыванию в Microsoft Azure. В целом, считается хорошей практикой следовать жизненному циклу разработки приложения до финальной публикации в производственной среде Microsoft Azure. Сначала вы должны опубликовать приложение в тестовой среде. Тестовая среда — это обычно облачный сервис, который создается и используется исключительно для тестовых целей. Эта среда позволяет проверить, соответствует ли поведение приложения ожидаемому при хостинге в Microsoft Azure. После успешного выполнения всех тестов приложение можно опубликовать в промежуточной среде (staging environment). В ней можно выполнять тесты приемки пользователями (user-acceptance tests) для проверки того, предоставляет ли приложение задуманную функциональность. Наконец, если все тесты пройдены, приложение можно публиковать в производственной среде.

Процесс публикации существенно улучшился в выпуске за ноябрь 2011 г. с введением нового мастера публикации. Чтобы открыть этот мастер, щелкните правой кнопкой мыши проект Microsoft Azure и выберите Publish. Заметьте, что щелкать правой кнопкой мыши следует именно проект Microsoft Azure, а не проект веб-приложения вроде ASP.NET MVC. Иначе будет запущен мастер веб-публикации для развертывания в Web, а не мастер публикации в Microsoft Azure.

При первой публикации в Microsoft Azure нужно щелкнуть ссылку Sign in to download credentials настранице публикации, чтобы скачать файл .publishsettings. Этот файл содержит метаданные и удостоверения, необходимые Visual Studio для работы с вашей подпиской в Microsoft Azure. Страница скачивания файла .publishsettings создаст сертификат управления Microsoft Azure для Visual Studio и встроит его в файл .publishsettings наряду с информацией о вашей подписке. Все это будет установлено и сохранено на вашем локальном компьютере разработки при импорте. Важное замечание: этот файл содержит конфиденциальную информацию вроде идентификаторов подписок и вашего сертификата управления, поэтому лучше всего хранить этот файл в защищенном месте или удалять его сразу после импорта.

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

Рис. 6. Мастер публикации

Щелкнув кнопку Next, вы попадете на вкладку Common Settings (рис. 7). Она позволяет выбрать существующий облачный сервис или даже создать новый. Кроме того, вы можете выбрать, в какой среде следует выполнить развертывание — в производственной или промежуточной, и указать нужную вам конфигурацию сервиса. Вспомните, что говорилось раньше о нескольких конфигурациях сервиса. Это как раз то место, где можно выбрать конфигурацию, подходящую для данного развертывания.

Рис. 7. Вкладка Common Settings

На этой же вкладке можно разрешить использование Remote Desktop и Web Deploy. Включение Remote Desktop реально помогает, если вы хотите впоследствии подключаться к конкретным экземплярам роли в Microsoft Azure для диагностических целей. После того как вы включили Remote Desktop и публикация прошла успешно, можно подключаться напрямую к экземпляру роли, используя контекстное меню Connect using Remote Desktop экземпляра в Server Explorer (рис. 8). Контекстное меню в Server Explorer автоматически показывает элементы в зависимости от функциональности, включенной при публикации. В нашем примере включен Remote Desktop.

Рис. 8. Подключение через Remote Desktop

На вкладке Advanced Settings мастера публикации есть некоторые полезные настройки. Здесь вы можете указать учетную запись хранилища, которую следует использовать для публикации, или создать новую. Мы рекомендуем всегда создавать или использовать учетные записи хранилища в одном месте (т. е. в информационном центре), чтобы избежать влияния задержек на производительность облачного сервиса, применяющего их. Кроме того, вы можете контролировать поведение обновления развернутого вами приложения, а также средства анализа проблем, нужные вам для диагностики.

После применения параметров публикации вы попадете на сводную страницу мастера. На этой странице перечисляются все выбранные вами настройки и дается возможность сохранить целевой профиль для публикации. В отличие от облачной конфигурации в профиле хранится конфигурация публикации из Visual Studio. Целевой профиль — это, по сути, файл определения MSBuild с расширением .azurePubxml. Все параметры, примененные в мастере публикации, сохраняются в этот файл. Это удобно, когда вы используете разные настройки публикации или несколько целевых сред. Вспомните хотя бы тестовую и производственную среды. В тестовой среде вы, вероятно, предпочтете включить IntelliTrace, а в производственной — выключить. Теперь — вместо того чтобы снова проходить всю процедуру под руководством мастера — перед публикацией в производственной среде достаточно выбрать профиль публикации для этой среды. Это весьма полезно для стандартизации процессов публикации.

И последнее, о чем стоит упомянуть в связи с публикацией: Visual Studio выполнит разовое обновление строк подключения в конфигурационном файле сервиса для диагностики и кеширования — по умолчанию со значением для учетной записи хранилища публикации, если этим значением все еще является UseDevelopmentStorage=true, как показано на рис. 9. Такое поведение можно отключить в Role Designer, сбросив флажок «Update development storage connection strings…».

Рис. 9. Обновление строк подключения к хранилищу этапа разработки для диагностики и кеширования

Щелчок кнопки Publish запустит процесс публикации после успешной сборки. Поскольку этот процесс занимает некоторое время, Visual Studio предоставляет детальный отчет о состоянии текущего этапа публикации в окне Microsoft Azure Activity Log. На рис. 10 показано это окно после успешной публикации.

Рис. 10. Окно Microsoft Azure Activity Log

Теперь вы можете перейти в свой облачный сервис с помощью браузера, щелкнув «Web site URL» в окне.

Работа с Server Explorer для доступа к Microsoft Azure

Мы уже рассмотрели, как подключиться к одному из экземпляров с помощью Server Explorer. Хотя подключение к экземплярам Microsoft Azure Compute и Microsoft Azure VM через Remote Desktop определенно отличная возможность, стоит обсудить и некоторые другие полезные функции Server Explorer. В SDK за июнь 2012 г. можно напрямую подключаться к Microsoft Azure Service Bus, предоставляя пространство имен и ключ для этого пространства. После подключения вы сможете видеть очереди и топики (topics) Service Bus. Вы даже можете создавать новые очереди и топики Service Bus, как показано на рис. 11.

Рис. 11. Создание новой очереди Service Bus

Кроме того, можно добавить учетные записи хранилища к узлу хранилища Microsoft Azure и посмотреть, что содержится в BLOB и таблицах. В настоящее время через Server Explorer поддерживается лишь чтение данные в хранилищах Microsoft Azure. Наконец, Server Explorer теперь умеет перечислять виртуальные машины Microsoft Azure и все конечные точки, предоставляемые этими VM.

Варианты анализа проблем

Ранее вы видели пример кода, который инициализирует монитор диагностики для сбора информации из источников данных журнала событий Windows. Объяснение того, как работает диагностика в Microsoft Azure, выходит далеко за рамки этой статьи; однако мы все же кратко рассмотрим его.

Помимо использования источников данных журнала событий Windows, у вас есть вариант с добавлением кода, который будет запускать сбор журналов трассировки, журналов инфраструктур, аварийных дампов Microsoft Azure и т. д. Подробнее о включении и настройке диагностики в Microsoft Azure см. по ссылке bit.ly/MMkwiK.

Основное отличие в сборе диагностической информации в Microsoft Azure и в локальном приложении — место хранения диагностических данных. Microsoft Azure помещает их в свое хранилище (мы обсуждали учетную запись хранилища для диагностических данных ранее в разделе «Публикация в Microsoft Azure»). Некоторые диагностические данные, например журналы IIS и неудачные запросы IIS, помещаются в хранилище BLOB, а другие данные, такие как журналы трассировки, счетчики производительности и журналы событий Windows, — в хранилище таблиц. На рис. 12 показаны учетная запись intellitracetest с хранилищами BLOB и таблиц, содержащими диагностические данные Microsoft Azure. BLOB и таблицы легко различать, так как они начинаются с «wad-» или «WAD».

Рис. 12. Учетная запись хранилища, содержащего диагностические данные

Чтобы переместить данные в это хранилище, важно всегда использовать свойство ScheduledTransferPeriod. В следующем коде показан пример для журналов событий Windows:

diagConfig.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(1.0);

Включение диагностики определенно помогает при анализе проблем и мониторинге. Но мы — как разработчики — любим отладчик. В настоящее время Visual Studio не предоставляет готовой поддержки отладки, однако можно использовать привычные инструменты вроде IntelliTrace и Profiling. Давайте в заключение рассмотрим IntelliTrace. Увы, этот инструмент доступен только в Visual Studio редакции Ultimate, хотя он просто бесценен для облачной разработки. Допустим, вам нужно проверить, запускается ли какая-то рабочая роль в вашем проекте так, как ожидалось. Поскольку в классе WorkerRole:RoleEntryPoint есть кое-какой код трассировки, вы можете использовать IntelliTrace для отладки события Roleenvironment¬OnStart.

Помните, мы уже обсуждали включение IntelliTrace для вашего развернутого приложения? После успешной публикации, когда вы щелкнете правой кнопкой мыши вычислительный экземпляр в Server Explorer и включите IntelliTrace, вы увидите еще один элемент контекстного меню — View IntelliTrace logs (он работает так же, если вы включили Profiling). Не забывайте, что IntelliTrace и Profiling — взаимоисключающие средства (это текущее ограничение, как мы надеемся, снимут в будущем).

Как только вы щелкнете View IntelliTrace logs, Visual Studio загрузит журналы и отобразит их, как показано на рис. 13.

Рис. 13. Отладка с применением IntelliTrace

Теперь вы можете видеть все события и начать отладку с события, в котором вы заинтересованы. Окно IntelliTrace сообщает полезную информацию о последовательности событий, конкретных событиях и исключениях. При щелчке какого-либо события Visual Studio переключает вас прямо в релевантный редактор кода.

Хотя мы лишь поверхностно рассказали об инструментарии для Microsoft Azure, вы должны были получить представление о том, насколько легко разрабатывать и отлаживать облачные сервисы с применением Visual Studio. Самые свежие новости и прочую информацию о .NET-разработке в Microsoft Azure, пожалуйста, читайте по ссылке bit.ly/v5MF7m.

Борис Шолл (Boris Scholl) — старший менеджер программ в группе инструментария для облака, используемого в Visual Studio. Основное внимание уделяет созданию полнофункциональной среды для разработок под Microsoft Azure. До присоединения к этой группе работал в группе инструментария SharePoint для Visual Studio, а также был архитектором в области проектирования решений для SharePoint и облака.

Пол Юкневич (Paul Yuknewicz) — главный менеджер программ, возглавляющий группу инструментария для облака. Ранее занимался Windows Forms и Visual Basic 6 для Visual Studio.

Выражаем благодарность за рецензирование статьи экспертам Гордону Ходженсону (Gordon Hodgenson), Джиму Накашиме (Jim Nakashima) и Мохиту Сриваставе (Mohit Srivastava).