Облачные службы Azure (расширенная поддержка)

Это важно

По состоянию на 31 марта 2025 г. облачные службы (расширенная поддержка) устарели и будут полностью прекращены 31 марта 2027 г. Узнайте больше об этом отказе и о том, как осуществить миграцию.

Облачные службы (расширенная поддержка) — это новая модель развертывания на основе Azure Resource Manager для продукта Azure Облачные службы, и теперь она общедоступна. Облачные службы (расширенная поддержка) обладают основным преимуществом, заключающимся в обеспечении региональной устойчивости и равенства функций с Облачными службами Azure, развернутыми с помощью Azure Service Manager. Она также предлагает некоторые возможности Azure Resource Manager, такие как доступ и управление на основе ролей (RBAC), теги, политика и поддерживает шаблоны развертывания.

При этом изменении модель развертывания на основе Azure Service Manager для Облачные службы переименована в Облачные службы (классическая модель). Вы сохраняете возможность создавать и быстро развертывать веб-приложения и облачные службы. Вы можете масштабировать инфраструктуру облачных служб на основе текущего спроса и обеспечить производительность приложений, одновременно уменьшая затраты.

Видеоролик на YouTube, посвященный Облачным службам (расширенная поддержка).

Что осталось прежним

  • Вы создаете код, определяете конфигурации и выполняете развертывание в Azure. Azure настраивает вычислительную среду, запускает код, а затем отслеживает и обслуживает его.
  • Облачные службы (расширенная поддержка) также поддерживают два типа ролей — веб-роль и рабочую роль. В конструировании, архитектуре или компонентах веб- и рабочих ролей изменений нет.
  • Три компонента облачной службы, определение службы (CSDEF), конфигурация службы (CSCFG) и пакет службы (CSPKG) переносятся вперед и не изменяются в форматах.
  • Не нужно вносить изменения в код среды выполнения, так как меняется только уровень управления, а плоскость данных остается прежней.
  • Выпуски и связанные обновления гостевой ОС Azure согласованы с Облачными службами (классические).
  • Базовый процесс обновления с учётом доменов обновления, ход обновления, откат и разрешённые изменения службы во время обновления не меняются.

Изменения в модели развертывания

Для развертывания облачных служб (расширенная поддержка) требуется внести минимальные изменения в файлы конфигурации службы (CSCFG) и определения службы (CSDEF). Для кода среды выполнения изменения не требуются. Однако для вызова новых API на основе Azure Resource Manager необходимо обновить скрипты развертывания.

На рисунке показана классическая конфигурация облачной службы с добавлением раздела шаблона.

Основные различия между облачными службами (классические) и облачными службами (расширенная поддержка) в отношении развертывания:

  • При развертывании Azure Resource Manager используются шаблоны ARM, которые являются JSON-файлом, определяющим инфраструктуру и конфигурацию вашего проекта. Шаблон использует декларативный синтаксис, который позволяет указать объект, который вы собираетесь развернуть. При этом, для развертывания объекта, не нужно писать последовательность команд. Файл конфигурации службы и определения службы должен быть согласован с шаблоном ARM при развертывании Облачных служб (расширенная поддержка). Это можно сделать вручную, создав шаблон ARM или с помощью PowerShell, портала и Visual Studio.

  • Для управления сертификатами в Облачных службах (расширенная поддержка) клиенты должны использовать Azure Key Vault. Azure Key Vault позволяет безопасно хранить учетные данные приложения и управлять ими, такими как секреты, ключи и сертификаты в центральном и безопасном облачном репозитории. Приложения могут проходить проверку подлинности в Key Vault во время выполнения для получения необходимых учетных данных.

  • Все ресурсы, развернутые через Azure Resource Manager, должны находиться в виртуальной сети. Виртуальные сети и подсети создаются в Azure Resource Manager с помощью существующих API Azure Resource Manager. Они должны указываться в разделе NetworkConfiguration файла .cscfg при развертывании облачных служб (расширенная поддержка).

  • Каждая облачная служба (расширенная поддержка) — это одно независимое развертывание. Облачные службы (расширенная поддержка) не поддерживает несколько слотов в одной облачной службе.

    • Возможность смены VIP может использоваться для переключения между двумя облачными службами (с расширенной поддержкой). Чтобы протестировать и разместить новый выпуск облачной службы, разверните облачную службу (расширенная поддержка) и отметьте её как службу, которую можно заменить на другую облачную службу (расширенная поддержка) с возможностью переключения VIP.
  • Метка службы доменных имен (DNS) является необязательной для облачной службы (расширенная поддержка). В Azure Resource Manager метка DNS является свойством ресурса общедоступного IP-адреса, связанного с облачной службой.

Миграция на Azure Resource Manager

Облачные службы (расширенная поддержка) предоставляют два пути для миграции из Azure Service Manager в Azure Resource Manager.

  1. Клиенты развертывают облачные службы непосредственно в Azure Resource Manager, а затем удаляют старую облачную службу в Azure Service Manager.
  2. Миграция на месте поддерживает возможность миграции Облачных служб (классические) в Облачные службы (расширенная поддержка) с минимальным временем простоя.

Дополнительные параметры миграции

При оценке планов миграции с Облачные службы (классической) на Облачные службы (расширенная поддержка) может потребоваться изучить другие службы Azure, такие как: Масштабируемые наборы виртуальных машин, Служба приложений, Служба Azure Kubernetes и Azure Service Fabric. Эти службы продолжают иметь дополнительные возможности, в то время как Облачные сервисы (расширенная поддержка) обеспечивают равенство функционала с Облачными сервисами (классическими).

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

Следующие шаги