Разработка приложений под Windows Azure. Жизненный цикл. Часть №2–Управление и обновление.

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

Напомню, что достучаться до него мы можем по следующему url: http://windows.azure.com. Понятное дело, что первым делом мы пройдем процедуру аутентификации при помощи нашего Live ID.  После чего сможем насладится всеми прелестями работы с новейшим интерфейсом, написанным на Silverlight.
Первым делом мы пойдем в подраздел “Hosted Services, Storage Accounts & CDN ”. Здесь увидим привычную картину, а именно развернутые в облаке наши сервисы.

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

 Идем слева направо и видим, что первая возможность это – Апгрейд. Апгрейд предполагает полное уничтожение приложения на целевом слоте и загрузке на него нового пакета. Как по мне очень грубый вариант, а также длительный (в течении этого процесса можно смело идти пить чай ибо как правило это занимает до 20 минут)
Следующая удобная возможность это конфигурация. Здесь мы можем поменять некоторые настройки приложения, например, такие как количество экземпляров текущего сервиса.

Также мы можем полностью остановить сервис, либо удалить из текущего слота. Одна из наиболее часто используемых возможностей это так называемый Swap VIP. Запуская этот процесс, мы фактически меняем между собой содержимое продакшен слота и тестового. Это очень удобно, так как позволяет быстро откатить назад неработающий билд (если не дай Бог такое случится). А также это очень быстро, так как фактически на уровне виртуальной машины это просто смена ip-адресов. Оставшиеся возможности как по мне – это дополнительные “вкусности” как, например, возможность удаленного доступа к Вашей web-роли посредством протокола RDP, перезагрузка виртуальной машины, перенакатывание изначального образа операционной системы на Вашу виртуальную машину и т.д. и т.п. Кроме всего прочего на портале мы можем управлять нашими SQL Azure базами данных (об этом я более подробно расскажу в последующих постах), управлять Windows Azure Storage, а также многими многими другими параметрами, включая управление сертификатами, возможностями организации командного доступа к центру управления и т.д. и т.п.
При работе с порталом необходимо понимать, что  это фактически UI поверх API. То есть, если нас каким-то образом не устраивает или не нравится портал, мы можем со спокойной душой написать свое собственное решение, которое будет взаимодействовать с облаком посредством Windows Azure Service Management API. Более того, на данный момент мы уже имеем некоторые альтернативные варианты по управлению приложениями в облаке. Это утилиты командной строки, которые абстрагируют от нас детали взаимодействия с API:

• CSPack – фактически  выполняет упаковку проекта в cspkg-файл а также создает необходимые конфигурационные файлы. Visual Studio использует эту утилиту для автоматического создания пакетов.
  
• CSRun – контролирует состояние эмуляторов (Development Fabric и Development Storage), запускает пакеты на эмуляторе, а также управляет запущенным на эмуляторе сервисами.
  
• CSManage – по сути это и есть оболочка над Service Management API, с помощью этой утилиты мы можем совершать практически все что есть на портале разработчика.

Вышеназванные утилиты конечно удобны в определенных ситуациях. Но я считаю, что более совершенный вариант для работы с Service Management API – это использование командных файлов PowerShell. Я надеюсь, что все IT-профессионалы будут взаимодействовать с облаком при помощи этих командных файлов. Кроме того, что это высокоуровневый код, значительно упрощающий взаимодействие с API, он также позволяет организовывать так называемые  pipelines, когда результат предыдущей команды передается на вход следующей. Более подробно с этим подходом можно ознакомится, пройдя по ссылке: http://tinyurl.com/azurecmdlets.
Итак я думаю мы уже достаточно узнали о процессе управления нашими приложениями в облаке, но я хотел бы описать процесс апгрейда чуть более подробно. Во-первых, хочу заметить что на последнем PDC была объявлена новая фантастическая фича, а именно возможность запуска приложения в FULL IIS режиме, что предоставляет нам кучу плюшек, начиная от управления ASP.NET модулями и заканчивая возможностью использования различных технологий IIS таких как URL Rewrite, Web Deploy и др. Хочу остановится на WebDeploy. Теперь с помощью этой штуки можно выполнять мгновенные апдейты ваших web-ролей. Это значит, что не надо ждать 20 минут пока роль запустится, процесс обновления исчисляется СЕКУНДАМИ, повторюсь СЕКУНДАМИ.
Также в процессе апдейта нас всех я думаю волнует такой немаловажный вопрос, как : что произойдет с моим приложением во время апгрейда ?? Станет ли оно недоступным для конечных пользователей ?? И ответ на этот вопрос – нет, оно останется доступным. Это достигается с помощью таких 2-х понятий как “Домен обновления” (Upgrade Domain) и “Домен отказоустойчивости” (Fault Domain). По умолчанию Ваше приложения распределяется по разным доменам отказоустойчивости. Это значит что ваше приложение будет располагаться на разных машинах, а скорее всего даже в разных серверных стойках датацентра. Поэтому благодаря такому сценарию, если какой-то Вася выдернет кабель из стойки, Fabric Controller автоматически перекинет траффик системы на другие доступные домены отказоустойчивости. Домены обновления – это несколько иное понятие. Они вступают в игру когда мы обновляем наше приложение. Суть заключается в том, что процесс обновления происходит поэтапно и каждый отдельный этап захватывает все домены отказоустойчивости но на каждом из них обновляются не все виртуальные машины, а только часть из них, таким образом гарантируя постоянную доступность системы. Суть доменов отказоустойчивости и обновления доступно проиллюстрирована на рисунке ниже.

Как мы видим в данном сценарии у нас есть приложение, содержащее в себе 4 инстанса Web-роли и 4 инстанса Worker-роли. Это приложение автоматически распределяется между 2-мя доменами отказоустойчивости, тем самым гарантируя высочайшую отказоустойчивость. Когда мы решаем обновить наше приложение, то этот процесс происходит в данном случае в 2 этапа, захватывая одновременно по 2 виртуальные машины для каждой из ролей, при этом оставшиеся машины остаются работоспособны. Тем самым гарантируется постоянная доступность вашего приложения. Как видите Upgrade Domains и Fault Domains – это как X и Y, комплексное применение которых подымает отказоустойчивость приложения до невероятных высот.
На этом я завершаю часть, посвященную жизненному циклу разработки и поддержки облачных приложений. В последующих постах постараюсь раскрыть интересные особенности работы с Windows Azure Storage, а также рассказать о масштабируемости, безопасности и гибкости ваших облачных приложений. Оставайтесь на моем блоге, будет интересно =)