Поделиться через

Изменения после миграции

  • Статья

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

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

Незначительные изменения вносятся в файлы .csdef и .cscfg клиента, чтобы обеспечить соответствие файлов развертывания требованиям Azure Resource Manager и облачных служб (расширенная поддержка). После миграции извлекает новые файлы развертывания или обновляет существующие файлы, необходимые для операций обновления и удаления.

  • Виртуальная сеть использует полный Azure Resource Manager идентификатор ресурса вместо имени ресурса в подразделе NetworkConfiguration файла CSCFG. Например, /subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.Network/virtualNetworks/vnet-name. Для виртуальных сетей, принадлежащих к той же группе ресурсов, что и облачная служба, можно обновить файл CSCFG, используя только имя виртуальной сети.

  • Классические размеры, например Small, Large, ExtraLarge, заменяются новыми именами размеров, Standard_A*. Имена размеров необходимо заменить на новые имена в файле CSDEF. Дополнительные сведения см. в статье Предварительных условия для развертывания Облачных служб (расширенная поддержка)

  • Используйте API Get для получения последней копии файлов развертывания.

Изменения в автоматизации клиента, конвейера CI/CD, пользовательских скриптах, пользовательских панелях мониторинга, пользовательских инструментах и т. д.

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

  • Изменения в именах ресурсов и групп ресурсов после миграции

    • В процессе миграции имена некоторых ресурсов, таких как облачная служба, общедоступные IP-адреса и т. д., меняются. Эти изменения могут быть отражены в файлах развертывания перед обновлением облачной службы. Дополнительные сведения об изменении имен ресурсов.

  • Повторное создание правил и политик, необходимых для управления и масштабирования облачных служб

    • Правила автомасштабирования не переносятся. После миграции создайте правила автоматического масштабирования.
    • Оповещения не переносятся. После миграции создайте оповещения заново.
    • Key Vault создается без каких-либо политик доступа. Чтобы просмотреть сертификаты или управлять ими, создайте соответствующие политики в Key Vault. Сертификаты отображаются в параметрах на вкладке с именем секретов.

Изменения, внесенные в управление сертификатами после миграции

Как стандартная практика управления сертификатами, все допустимые PFX-файлы сертификатов должны быть добавлены в хранилище сертификатов в Key Vault и обновления будут работать прекрасно через любой клиент — портал, PowerShell или REST API.

В настоящее время портал Azure выполняет проверку, чтобы проверить, передаются ли все необходимые сертификаты в хранилище сертификатов в Key Vault и предупреждает, не найден ли сертификат. Однако если вы планируете использовать сертификаты в качестве секретов, эти сертификаты не могут быть проверены для их отпечатка, и любая операция обновления, которая включает добавление секретов, завершится сбоем через портал. Клиентам рекомендуется использовать PowerShell или RestAPI для продолжения обновлений, связанных с секретами.

Изменения для обновления с помощью Visual Studio

Если вы опубликовали обновления непосредственно через Visual Studio, сначала необходимо скачать последний CSCFG-файл из развертывания после миграции. Используйте этот файл в качестве ссылки для добавления сведений о конфигурации сети в текущий CSCFG-файл в проекте Visual Studio. Затем выполните сборку решения и опубликуйте его. Для этого обновления может потребоваться выбрать Key Vault и группу ресурсов.

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