Microsoft Azure PaaS для .NET приложений

В данный момент мы наблюдаем трансформацию IT-отрасли, вызванную внедрением облачных вычислений (Cloud computing). IT-департаменты компаний меняют свою роль и круг ответственности, благодаря использованию инфраструктуры как сервиса (Infrastructure as a Service, IaaS) и программных сервисов (Software as a Service, SaaS). Развивающаяся концепция платформы приложений как сервиса (Platform as a Service, PaaS) меняет подходы к разработке программного обеспечения. Изменяется рабочее окружение (runtime environment) приложений, ключевые функции переносятся с локальных компонентов на программные сервисы, меняются модели развертывания, процессы тестирования и диагностики.

В компании Sitecore мы адаптировали основной продукт — Sitecore Experience Platform для запуска на платформе Azure PaaS с возможностью развертывания из Azure Marketplace. В данной статье мы проведем обзор возможностей Microsoft Azure PaaS и сервиса Azure App Service, а также рассмотрим некоторые практические аспекты миграции распределенного .NET приложения на примере Sitecore.

Что предоставляет Microsoft Azure для разработчиков приложений

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

В качестве инструментов разработки выступают Microsoft Visual Studio с установленным Microsoft Azure SDK, богатый набор пакетов интеграции в репозитории nuget.org, а также сервис Visual Studio Online, предоставляющий платформу управления проектом и исходным кодом, а также сборки, развертывания и тестирования приложения.

В качестве операционного окружения выступают сервисы Azure Virtual Machines, Azure Cloud Services и Azure App Service, которые отличаются уровнем контроля, легкостью развертывания и гибкостью масштабирования:

• Сервис Azure VM предоставляет абстракцию аппаратного обеспечения и лицензию на операционную систему (иногда — с предустановленным программным обеспечением). Разработчик и администратор получают полный доступ ко всем функциям операционной системы, однако должны сами решать вопросы развертывания приложения, безопасности, поддержки, устойчивости к отказам и масштабирования.
• Сервис Azure Cloud Services предоставляет операционную систему для запуска приложения, включая обновления, защиту от вирусов, поддержку горизонтального масштабирования (scale out) и устойчивости к отказам. Сервис ограничивает возможности разработчика и администратора, т.к. любые изменения кода приложения и большинство изменений конфигурации требуют повторного развертывания приложения.
• Сервис Azure App Service предоставляет абстракцию операционной среды, т.н. песочницу (sandbox) для запуска веб-приложений. Сервис позволяет легко размещать приложения, а также масштабировать как вертикально (scale up), так и горизонтально (scale out). Разработчик или администратор получает полный доступ к файлам приложения и конфигурации веб-сервера.

Облачные сервисы, входящие в состав Microsoft Azure, призваны решать типовые задачи, которые встают перед разработчиками приложений. В таблице ниже приведены возможные задачи, примеры их решения в локальной среде (on premise), а также сервисы Microsoft Azure, которые предоставляют необходимую функциональность.

*Данные примеры приведены для иллюстрации не обязательно являются полными аналогами сервисов Microsoft Azure

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

Для управления службами и выделения ресурсов Microsoft Azure предоставляет как графический интерфейс portal.azure.com, так и наборы интерфейсов Azure Service Management, Azure Resource Manager, модуль Azure PowerShellи инструмент Azure CLI.

Обзор Azure App Service

Сервис Azure App Service (ранее Azure Web Sites) является самым молодым и активно развивающимся вариантом операционной среды в платформе Microsoft Azure. Сервис предоставляет поддержку выполнения веб-приложений и прикладных служб (API Services), использующих различные технологии, и ориентирован на легкость развертывания (deployment), конфигурирования, диагностики и масштабирования приложений. В то же время имеют место существенные ограничения для приложений, выполняемых в среде Azure App Service.

Существует несколько способов размещения приложений в Azure App Service, которые обеспечивают совместимость с различными технологиями и сценариями разработки веб-приложений:

• Размещение через FTP будет знакомо пользователям веб-отелей и услуг хостинга. Этот способ также является частью интеграции с различными средами разработки: Eclipse, XCode, IntelliJ Idea, NetBeans.
• Размещение через Web Deploy является основным способом при использовании Microsoft Visual Studio для разработки .NET веб-приложений. Web Deploy является универсальным инструментом синхронизации содержимого и конфигурации веб-сайтов в Microsoft IIS и часто используется разработчиками и администраторами для управления локальными серверами.
• Размещение через Git или синхронизацию папок с использованием механизма Kudu (Kudu Deployment Engine). Этот способ может использоваться во множестве сценариев разработки приложения и поддерживает автоматическое выполнение задач сборки и развертывания на стороне Azure App Service. Например, можно настроить обновление приложения через синхронизацию с папкой (Dropbox или OneDrive) или внешним Git репозиторием (Github или Bitbucket). Можно обновить код приложения через git push непосредственно из локального репозитория или как часть процесса непрерывного развертывания (continuous deployment).

Azure App Service поддерживает размещение нескольких экземпляров приложения в так называемых слотах (deployment slots) с возможностью горячего переключения (hot swap) между слотами. Это позволяет реализовать поэтапное развертывание (staged deployment) приложения с возможностью отката (rollback) и тестирование новых функций в промышленных условиях без вмешательства в работу основного экземпляра приложения.

При использовании Azure App Service конфигурирование приложения происходит через изменение настроек (Application Settings) и строк подключения (Connection Strings) в свойствах службы Azure App Service. Таким образом рабочая конфигурация приложения хранится отдельно от файлов приложения, что повышает безопасность всего решения. Настройки передаются приложению через переменные окружения, а также доступны для .NET приложений через свойства ConfigurationManager.AppSettingsи ConfigurationManager.ConnectionStrings. Технология ASP.NET Core предоставляет собственный механизмполучения конфигурации.

Для диагностики приложений Azure App Service предоставляет несколько инструментов:

• Расширенные инструменты Kudu позволяют просмотреть файлы приложения и рабочее окружение, а также провести профилирование производительности с помощью проводника процессов. Инструменты доступны из портала Microsoft Azure или по адресу https://{имя-приложения}.scm.azurewebsites.net/.
• Azure App Service Editor является реализацией интерфейса Visual Studio Code в окне браузера и позволяет просматривать и редактировать файлы приложения, отслеживать диагностические сообщения (diagnostic trace) в реальном времени и выполнять задачи в командной строке. Редактор доступен из портала Microsoft Azure или по адресу https://{имя-приложения}.scm.azurewebsites.net/dev/wwwroot/
• Интеграция Microsoft Visual Studio позволяет просматривать диагностические сообщения в режиме онлайн и отлаживать приложение непосредственно в окружении Azure App Service.
• Часть диагностических сообщений приложения доступна через FTP в папке /LogFiles/Application.

Следует отметить, что инструменты Azure App Service взаимодействуют с подсистемой System.Diagnostics.Trace приложений .NET. Это важно учитывать, если приложение использует другие технологии для протоколирования событий, такие как log4net или Serilog.

Гибкость масштабирования приложений обеспечивается динамической привязкой к хостинг плану. Хостинг план представляет собой вычислительный ресурс: некоторое количество выделенных виртуальных машин с определенными характеристиками или место в общем пространстве хостинга. Параметры хостинг плана, а также привязку приложений можно менять без повторного развертывания приложения.

Все приложения Azure App Service получают доменное имя {имя-приложения}.azurewebsites.net и поддержку HTTPS с использованием SSL/TLS сертификата *.azurewebsites.net, что облегчает размещение полнофункциональных тестовых окружений. Для промышленных окружений поддерживается настройка доменных имен и собственных SSL/TLS сертификатов.

Практические аспекты миграции .NET приложения на платформу Azure PaaS

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

В процессе миграции был решен комплекс задач:

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

Среда Azure App Service предоставляет множество преимуществ, однако накладывает существенные ограничения на функциональность приложений. Некоторые ограничения, для которых нам пришлось написать собственное решение:

• Подсистема COM ограничена запуском только стандартных компонентов в процессе приложения. Например, не поддерживается запуск компонента Internet Explorer WebBrowser.
• Не поддерживаются большинство функций графического интерфейса и оболочки Windows Shell. Например, невозможно получить значки типов файлов для использования в пользовательском интерфейсе.
• Не поддерживается запись в реестр Windows, и, как следствие, не поддерживаются счетчики производительности.
• Ограничение на количество активных TCP соединений может привести к сбоям в работе приложения.

Отдельно следует отметить организацию файловой системы в среде AzureApp Service, которая привела к пересмотру взаимодействия приложения с диском:

• Системный диск C:\ доступен только для чтения и запуска приложений.
• Диск данных D:\ содержит рабочие данные системы, а также две папки приложения:
  
  • Папка D:\home является корневой папкой приложения и содержит файлы приложения, расширений, протоколы событий и т.д. Папка доступна для чтения и записи, однако размещена на сетевом диске и, как следствие, имеет низкую производительность ввода/вывода. Кроме того, при масштабировании приложения следует учитывать, что все экземпляры приложения взаимодействуют с одной копией папки D:\home.
  • Папка D:\local предоставлена для хранения временных данных, размещена на локальном диске и имеет высокую производительность ввода/вывода. Каждый экземпляр приложения работает с собственным экземпляром папки D:\local, и содержимое папки теряется при каждом перезапуске приложения. Кроме того, папка D:\local по умолчанию не доступна из редактора Azure App Service Editor или инструментов диагностики Kudu. Это ограничение можно временно обойти, установивследующее значение в настройках приложения (Application Settings): WEBSITE_DISABLE_SCM_SEPARATION=true.

Среди интеграций со службами Microsoft Azure можно отметить сбор телеметрии приложения с помощью Microsoft Application Insights. Инструментарий Application Insights SDK легко интегрируется с ASP.NET приложениями и предоставляет функции захвата сообщений диагностики (trace), необработанных исключений, запросов ASP.NET и обращений к SQL базам данных и сторонним веб-службам. В процессе интеграции мы реализовали сбор значений счетчиков производительности и маршрутизацию диагностических сообщений через System.Diagnostics.Trace. Все сообщения телеметрии маркируются идентификатором окружения и ролью экземпляра приложения для облегчения диагностики.

Для развертывания конфигураций Sitecore Experience Platform в Microsoft Azure был использован механизм Azure Resource Manager (ARM) templates. Мы создали шаблоны развертывания (deployment templates) для каждой из четырех поддерживаемых конфигураций: от 1 веб-приложения в минимальной конфигурации до 4 связанных веб-приложений с поддержкой масштабирования в наиболее сложной конфигурации. Каждый шаблон размещает необходимые базы данных, SQL сервера, службы Redis Cache, Application Insights и Azure Search, и приложения Azure App Service, предоставляя полностью готовое окружение для начала работы.

Для создания установочных пакетов приложения был создан инструментарий упаковки, основанный на Microsoft Web Deploy и SQL Server Data-tier Application Framework (DAC FX).

Использование ARM позволило существенно упростить процесс развертывания сложных конфигураций, что в свою очередь упростило процесс создания тестовых окружений. В комбинации с расширениями системы непрерывной интеграции это позволило организовать процесс непрерывного тестирования системы на платформе Microsoft Azure. Azure Resource Manager также является механизмом размещения ресурсов в Azure Marketplace.

Заключение

Платформа Microsoft Azure предоставляет широкий спектр инструментов разработки и программных сервисов для создания веб-приложений. Это позволяет успешно размещать в Microsoft Azure распределенные веб-приложения с богатым функционалом.

Ссылки

• Сравнение моделей облачных сервисов: www.ibm.com/…​ry/cl-cloudservices2paas
• Сравнение операционных сред Microsoft Azure: docs.microsoft.com/…​web-site-cloud-service-vm
• Список ограничений Azure App Service: github.com/…​iki/Azure-Web-App-sandbox