Иногда возникает необходимость обновить приложение без прерывания его работы. Помогают ли в этом слоты развертывания Azure App Service и функция маршрутизации трафика? Что это всё вообще такое? Читайте под катом.
Мы продолжаем цикл статей «Как мы внедряли DevOps» от команды Vorlon.JS.
Vorlon.JS — это основанный на node.js инструмент, который позволяет веб-разработчикам удобный способ удаленно тестировать, контролировать и отлаживать веб-приложение, особенно на мобильных и embedded системах. В своем блоге на MSDN, команда подробно описывала поэтапное внедрение DevOps практик в организацию работы над Vorlon.JS и выбор инструментов для решения ежедневных задач. Vorlon.JS является проектом с открытым исходным кодом.
В предыдущей статье из этой серии мы обсуждали, как Visual Studio Team Services и инструмент Release Management могут использоваться для автоматизированного создания необходимых сред и развертывания приложений в этих средах.
Если вы обратите внимание на содержание шаблона Azure Resource Management, который мы используем для развертывания Vorlon.JS, то сможете заметить, что для production окружения мы применяем другой шаблон. Это обусловлено тем, что мы не развертываем приложение непосредственно в Azure Web App, вместо этого мы используем очень удобную функцию Web App под названием «слоты развертывания».
Что представляют собой слоты развертывания?
Слоты развертывания доступны в Azure App Service, начиная с сервисного плана Standard. Эта функция позволяет развернуть приложение в другом слоте, отличном от production. С технической точки зрения, слот — это просто еще одно веб-приложение, запускаемое в том же сервисном плане и со своим собственным URL.
Слоты позволяют использовать такие возможности, как мгновенное переключение сред (swapping) или тестирование в production среде. Swap — это действительно полезная функция, которая делает возможным обновление до новой версии приложения без перерывов в обслуживании и простоев.
При развертывании нового приложения всегда требуется некоторое время на «разогрев». Это может повлиять на мнение ваших пользователей в той или иной степени. С помощью слотов новую версию приложения можно развернуть в отдельном staging слоте, запустить приложение, а затем воспользоваться функцией swap, поменяв местами виртуальные IP-адреса слотов на уровне конфигурации балансировщиков нагрузки.
В случае Vorlon.JS шаблон ARM, который описывает production среду, отвечает за создание слота внутри Web App с именем staging, и мы используем Release Management (инструмент) для развертывания приложения в этом слоте. В результате развертывания мы получим два запущенных веб-приложения, в нашем production экземпляре Azure Web App:
В этом примере production-версия приложения Vorlon.JS (версия 1.4) развертывается и используется в production слоте Azure Web App под именем vorlonjs-production. Новая версия 1.5 развернута в staging слоте с именем staging.
После запуска приложения и проведения заключительных проверок в staging слоте, мы воспользуемся функцией swap, и версия 1.5 станет доступна по адресу URL. Как было сказано выше, функция swap не выполняет развертывание версии 1.5 в production слоте, а лишь обновляет конфигурацию сети, поэтому все будет сделано за несколько секунд, без простоев.
Функция swap доступна на портале Azure или через интерфейс командной строки (PowerShell или Azure Cross Platform CLI):
Что представляет собой тестирование в production?
Тестирование в production — общепринятая практика, которая заключается в перенаправлении группы избранных пользователей на новую версию. Это позволяет получить раннюю и более расширенную обратную связь, прежде чем сделать приложение доступным для всех остальных пользователей.
Azure App Service и слоты развертывания значительно упрощают тестирование в production среде. Когда у вас две версии приложения в разных слотах (например Vorlon.JS 1.4 и 1.5, описанные выше), вам достаточно просто перейти на портал Azure и в настройках маршрутизации выбрать опцию Traffic Routing (Маршрутизация трафика):
Затем вы можете настроить маршрутизацию Azure Web App таким образом, чтобы определенный процент пользователей автоматически перенаправлялся в другой слот. Например, можно перенаправить 30 % трафика production приложения на staging слот, то есть 30 % ваших пользователей будут использовать уже новую версию приложения:
Примечание. После перенаправления пользователя на данный слот с помощью функции маршрутизации трафика автоматически создается файл cookie, чтобы гарантировать, что пользователь не будет перенаправлен на другую версию при отправке следующего HTTP-запроса от его браузера.
Заключение
Как стало понятно из этой статьи, слоты развертывания Azure App Service и функция маршрутизации трафика действительно позволяют обновить приложение без прерывания его работы. Тестирование в production среде в сочетании с инструментами аналитики, такими как Azure Application Insights, позволяет получить информацию и необходимые метрики, чтобы понять, будет ли новая версия по достоинству оценена пользователями.
Автор: sahsAGU
