Жизненный цикл любого приложения подразумевает его поддержку. Это могут быть какие-либо патчи, хот-фиксы, новые версии и т.д. В случае с desktop приложением все достаточно понятно и привычно. Однако давайте разберемся, как происходит механизм обновления вашего приложения, если оно размещено в облаке. В нашем случае мы будет разговаривать об облаке Microsoft Azure.
Итак, Microsoft Azure предоставляет достаточно широкие средства для автоматического обновления вашего приложения, причем как правило приложением в данный момент пользуются другие люди, поэтому важнейшим вопросом становится обновление «на лету», то есть незаметно для пользователя. Давайте рассмотрим все возможные способы, которые возможно применить для приложения Microsoft Azure.
Web Deploy
Этот механизм обновления применим в большей степени только в процессе тестирования и разработки. Как мы знаем Microsoft Azure поддерживает два механизма развертывания приложения: PaaS и IaaS. Вариант Web Deploy выполняется в рамках PaaS. В общих чертах механизм публикации приложения из Visual Studio выглядит следующим образом:
- Сборка приложения со всеми зависимостями
- Архивация
- Загрузка в Azure Storage
- Разворачивание виртуальной машины из образа
- Копирование архива с Azure Storage на диск виртуальной машины
- Распаковка архива
- Настройка IIS
Предположим ребята из команды разработчиков сейчас активно внедряют новый функционал, часть из которого уже можно проверять тестерам. Полный процесс развертывания занимает достаточно много времени, поэтому из-за каких-то мелких изменений запускать его каждый раз накладно. В этом случае можно использовать механизм WebDeploy. Схема его представлена ниже:
Механизм работает следующим образом. Предположим, что у нас уже есть виртуальная машина, на которой выполняется версия 1.0 нашего приложения. Нам необходимо обновить ее до 1.0.1, в которой были внесены достаточно маленькие изменения, таким образом дельта изменений (размер архива) небольшой. Web Deploy в таком случае собирает проект (естественно), архивирует только измененные файлы, загружает архив с изменениями на Azure Storage. После этого по RDP протоколу (обязательное требование к виртуальной машине) копируется архив с изменениями на работающую виртуальную машину. Архив распаковывается и происходит подмена измененных файлов в каталоге IIS. Затем происходит перезапуск IIS.
Давайте теперь посмотрим на плюсы и минусы такого подхода.
Плюсы:
- Сокращается время развертывания новой версии приложения
- Небольшой размер изменений
- Публикация прямо из Visual Studio
Минусы:
- Если машина будет пересоздана (recycling), то изменения внесенные в процессе Web Deploy не попадут в исходный архив (package, .cspkg)
- Поддерживаются только веб-роли (Web Roles). Рабочие роли (Worker Roles) не поддерживаются
- RDP соединение с виртуальной машиной – обязательное условие
- Поддерживается только одна виртуальная машина в рамках одного облачного сервиса (Cloud Service)
- Метод применим только в рамках PaaS развертывания
Как мы видим данный метод врядли можно рассматривать как production, однако свои преимущества у него тоже есть, поэтому он имеет право на жизнь.
VIP Swap
Продолжаем рассматривать варианты обновления приложения в рамках PaaS развертывания. В отличие от предыдущего варианта, следующий подход вполне применим и применяется в production окружении.
Предположим, что наш заказчик использует наше приложение версии 1.0 по адресу (contoso.cloudapp.net). Наша задача состоит в том, чтобы обновить версию приложения на 1.1 незаметно для пользователя.
Microsoft Azure предлагает удобную концепцию слотов в облачных сервисах. Когда мы публикуем наше приложение в облако через Visual Studio нас всегда спрашивают, в какой именно слот мы хотим опубликовать наше приложение: Staging или Production.
Соответственно разница между этими слотами заключается лишь в том, что production слот имеет DNS привязанный к конкретному имени (в нашем тесте test-app-1.cloudapp.net), а Staging – к имени вида GUID.cloudapp.net. Таким образом можно одновременно в одном облачном сервисе держать несколько версий одного приложения. Как я уже упоминал выше, заказчик использует production слот, а мы можем использовать Staging допустим для проведения тестов или подготовки окружения к релизу.
При создании облачного сервиса внутренний балансировщик нагрузки Azure создает таблицу IP адресов, привязанных к конкретному DNS имени. Идея VIP Swap очень проста – это замена IP адресов машин, привязанных к Staging слоту на IP адреса машин, привязанных к Production слоту. Операция обновления внутренней таблицы IP адресов балансировщика нагрузки Azure занимает считанные секунды. Таким образом с точки зрения пользователя обновление приложения на новую версию происходит мгновенно.
Давайте теперь посмотрим на плюсы и минусы такого подхода.
Плюсы:
- Смена IP адресов в таблице балансировщика нагрузки занимает секунды
- Тестовые и production окружения изолированы друг от друга
- При необходимости есть возможность «вернуть все назад» (Swap в обратную сторону)
- Поддержка как Web ролей, так и Worker
- Развертывание прямо из Visual Studio
Минусы:
- Конфигурация виртуальных машин в Staging и Production слотах должна быть одинакова
- Нет поддержки виртуальных машин, развернутых в рамках IaaS
- Дополнительные затраты на виртуальные машины развернутые в параллельном слоте
Анализ этого метода обновления показывает, что он вполне пригоден для использования в production окружении. При использовании PaaS подхода к развертыванию приложения он является одним из самых оптимальных.
На сегодня это пока все, о чем я хотел вам рассказать. В следующий раз мы посмотрим, какими средствами Microsoft Azure можно воспользоваться для обновления приложения развернутого в рамках IaaS. Не переключайтесь!
Автор: RisingStar
