Как мы внедряли DevOps: тестирование production-окружения с Azure Web App

Иногда возникает необходимость обновить приложение без прерывания его работы. Помогают ли в этом слоты развертывания Azure App Service и функция маршрутизации трафика? Что это всё вообще такое? Читайте под катом.

Мы продолжаем цикл статей «Как мы внедряли DevOps» ^[1] от команды Vorlon.JS.
Vorlon.JS — это основанный на node.js инструмент, который позволяет веб-разработчикам удобный способ удаленно тестировать, контролировать и отлаживать веб-приложение, особенно на мобильных и embedded системах. В своем блоге на MSDN, команда подробно описывала поэтапное внедрение DevOps практик в организацию работы над Vorlon.JS и выбор инструментов для решения ежедневных задач. Vorlon.JS является проектом с открытым исходным кодом ^[2].

В предыдущей ^[3] статье из этой серии мы обсуждали, как Visual Studio Team Services и инструмент Release Management могут использоваться для автоматизированного создания необходимых сред и развертывания приложений в этих средах.

Если вы обратите внимание на содержание шаблона Azure Resource Management ^[4], который мы используем для развертывания Vorlon.JS, то сможете заметить, что для production окружения ^[5] мы применяем другой шаблон. Это обусловлено тем, что мы не развертываем приложение непосредственно в 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 ^[6]. Новая версия 1.5 развернута в staging слоте с именем staging ^[7].

После запуска приложения и проведения заключительных проверок в 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

Источник ^[8]