Тестовый выпуск Azure Resource Manager

Статья
06/14/2024

Примечание.

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

Используйте этот тип, если у вас есть предложение в Azure Marketplace или AppSource, но вы хотите создать тестовый выпуск только с ресурсами Azure. Шаблон Azure Resource Manager (ARM) — это закодированный контейнер ресурсов Azure, который вы проектируете для лучшего представления своего решения. Тестовый выпуск использует указанный шаблон ARM и развертывает все необходимые ресурсы в группе ресурсов. Это единственный вариант тестового выпуска для виртуальных машин или предложений приложения Azure.

Если вы не знакомы с шаблоном ARM, ознакомьтесь с тем, что такое Azure Resource Manager? И изучите структуру и синтаксис шаблонов ARM, чтобы лучше понять, как создавать и тестировать собственные шаблоны .

Сведения о размещенном тестовом выпуске или тестовом выпуске приложения логики см. в статье Что такое тестовый выпуск?.

Совет

Чтобы просмотреть представление тестового выпуска клиента на коммерческой платформе, ознакомьтесь с разделом "Что такое Azure Marketplace?" и Что такое Microsoft AppSource?.

Техническая конфигурация

Шаблон развертывания содержит все ресурсы Azure, составляющие решение. Для этого сценария подходят приложения, использующие только ресурсы Azure. Задайте следующие свойства в Центре партнеров:

Регионы (обязательно) — в настоящее время Azure поддерживает 26 регионов для тестового выпуска. Для оптимальной производительности рекомендуется выбрать один регион, где ожидается, что наибольшее количество клиентов будет находиться. Вам потребуется убедиться, что подписка разрешена для развертывания всех ресурсов, необходимых для каждого выбранного региона.
Экземпляры — выберите тип (горячий или холодный) и количество доступных экземпляров, которые будут умножены на количество регионов, где доступно предложение.
- Горячий — этот тип экземпляра развертывается и ожидает доступа в выбранном регионе. Клиенты могут мгновенно получить доступ к горячим экземплярам тестового выпуска, не ожидая их развертывания. Компромисс заключается в том, что эти экземпляры всегда работают в вашей подписке Azure, поэтому они будут стоить больше времени простоя. Настоятельно рекомендуется иметь по крайней мере один горячий экземпляр, так как большинство клиентов не хотят ждать полных развертываний, что приводит к удалению использования клиентов, если горячий экземпляр недоступен.
- Холодный — этот тип экземпляра представляет общее количество экземпляров, которые могут быть развернуты для каждого региона. Для холодных экземпляров требуется полное развертывание шаблона тестового выпуска Resource Manager по запросу клиента, так что холодные экземпляры загружаются гораздо медленнее, чем горячие. Компромисс заключается в том, что вы должны платить только за время тестового выпуска, он не всегда работает в подписке Azure, как с горячим экземпляром.
Шаблон тестового выпуска Azure Resource Manager — отправьте ZIP-файл, содержащий шаблон Azure Resource Manager. Дополнительные сведения о создании шаблона Azure Resource Manager см. в кратком руководстве Создание и развертывание шаблонов Azure Resource Manager на портале Azure.

Примечание.

Для успешной публикации важно проверить форматирование шаблона ARM. Это можно сделать двумя способами: (1) с помощью интерактивного средства API или (2) с помощью тестового развертывания.
Продолжительность тестового выпуска (обязательно) — укажите количество часов, в течение которых тестовый выпуск будет оставаться активным. Тестовый выпуск автоматически завершит работу по истечении этого периода. Используйте только целые числа (например, "2" часы допустимы, "1,5" не является).

Создание шаблона тестового выпуска

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

Параметры

Большинство шаблонов имеют набор параметров, определяющих имена ресурсов, размеры ресурсов (например, типы учетных записей хранения или размеры виртуальных машин), имена пользователей и пароли, DNS-имена и т. д. При развертывании решений с помощью портала Azure можно вручную заполнить все эти параметры, выбрать доступные DNS-имена или имена учетных записей хранения и так далее.

Список параметров в Azure Resource Manager

Тем не менее тестовый выпуск работает в автоматическом режиме, без участия пользователя, поэтому он поддерживает только ограниченный набор категорий параметров. Если параметр в шаблоне ARM тестового выпуска не относится к одной из поддерживаемых категорий, необходимо заменить этот параметр значением переменной или константы.

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

"parameters": {
  ...
  "username": {
    "type": "string",
    "metadata": {
      "type": "username"
    }
  },
  ...
}

Примечание.

Все параметры являются необязательными, поэтому, если вы не хотите использовать какие-либо из ним, можете так и поступить.

Допустимые типы метаданных параметров

Тип метаданных	Тип параметра	Description	Образец значения
baseuri	строка	Базовый универсальный код ресурса (URI) пакета развертывания	`https://<..>.blob.core.windows.net/<..>`
username	строка	Новое случайное имя пользователя.	admin68876
пароль	защищенная строка	Новый случайный пароль	Lp! ACS^2kh
session id	строка	Уникальный идентификатор сеанса тестового выпуска (GUID)	b8c8693e-5673-449c-badd-257a405a6dee

baseuri

Тестовый выпуск инициализирует этот параметр с помощью базового URI пакета развертывания, поэтому с помощью этого параметра можно создать URI любого файла, включенного в пакет.

Примечание.

Параметр baseUri нельзя использовать в сочетании с расширением пользовательского скрипта.

"parameters": {
  ...
  "baseuri": {
    "type": "string",
    "metadata": {
      "type": "baseuri",
      "description": "Base Uri of the deployment package."
    }
  },
  ...
}

Используйте этот параметр внутри шаблона, чтобы создать URI любого файла из пакета развертывания тестового выпуска. В приведенном ниже примере показано, как построить URI связанного шаблона.

"templateLink": {
  "uri": "[concat(parameters('baseuri'),'templates/solution.json')]",
  "contentVersion": "1.0.0.0"
}

username

Тестовый выпуск инициализирует этот параметр с помощью нового случайного имени пользователя:

"parameters": {
  ...
  "username": {
    "type": "string",
    "metadata": {
      "type": "username",
      "description": "Solution admin name."
    }
  },
  ...
}

Пример значения: admin68876

Для вашего решения можно задействовать как случайные, так и постоянные имена пользователей.

password

Тестовый выпуск инициализирует этот параметр с помощью нового случайного пароля:

"parameters": {
  ...
  "password": {
    "type": "securestring",
    "metadata": {
      "type": "password",
      "description": "Solution admin password."
    }
  },
  ...
}

Пример значения: Lp!ACS^2kh

Для вашего решения можно задействовать как случайные, так и постоянные пароли.

Идентификатор сеанса

Тестовый выпуск инициализирует этот параметр с помощью уникального идентификатора GUID, который представляет собой идентификатор сеанса тестового выпуска:

"parameters": {
  ...
  "sessionid": {
    "type": "string",
    "metadata": {
      "type": "sessionid",
      "description": "Unique test drive session id."
    }
  },
  ...
}

Пример значения: b8c8693e-5673-449c-badd-257a405a6dee

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

Уникальные имена

Для некоторых ресурсов Azure, например учетных записей хранения или DNS-имен, требуются глобально уникальные имена. Это означает, что каждый раз, когда тестовый выпуск развертывает шаблон ARM, он создает группу ресурсов с уникальным именем для всех его ресурсов. Поэтому необходимо использовать функцию uniquestring, сцепленную с именами переменных в идентификаторах групп ресурсов, чтобы создавать случайные уникальные значения:

"variables": {
  ...
  "domainNameLabel": "[concat('contosovm',uniquestring(resourceGroup().id))]",
  "storageAccountName": "[concat('contosodisk',uniquestring(resourceGroup().id))]",
  ...
}

Не забудьте сцепить строки параметров/переменных (contosovm) с уникальными строковыми выходными данными (resourceGroup().id), так как это гарантирует уникальность и надежность каждой переменной.

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

Дополнительные сведения о правилах именования ресурсов и ограничениях см. в разделе "Разработка стратегии именования и тегов для ресурсов Azure".

Расположение развертывания

Тестовый выпуск можно сделать доступным в разных регионах Azure.

Когда тестовый выпуск создает экземпляр лаборатории, он всегда создает группу ресурсов в одном из выбранных регионов, а затем выполняет шаблон развертывания в контексте этой группы. Таким образом, шаблон должен выбирать расположение развертывания из группы ресурсов:

"variables": {
  ...
  "location": "[resourceGroup().location]",
  ...
}

А затем использовать это расположение для каждого ресурса в конкретном экземпляре лаборатории:

"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/publicIPAddresses",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/virtualNetworks",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/networkInterfaces",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Compute/virtualMachines",
    "location": "[variables('location')]",
    ...
  }
]

Убедитесь, что подписка может развернуть все нужные ресурсы в каждом из выбранных вами регионов. Кроме того, убедитесь, что образы виртуальных машин доступны во всех регионах, которые вы включите, в противном случае шаблон развертывания не будет работать для некоторых регионов.

Выходные данные

Обычно с помощью шаблонов Resource Manager можно выполнить развертывание без выходных данных. Причина в том, что вам известны все значения, используемые для заполнения параметров шаблона, и всегда можно вручную проверить свойства любого ресурса.

Однако для шаблонов тестового выпуска Resource Manager важно возвращать тестовому выпуску все сведения, которые ему требуются для получения доступа к лаборатории (URI веб-сайтов, имена узлов виртуальных машин, имена пользователей и пароли). Убедитесь, что все имена выходных данных доступны для чтения, так как эти переменные будут представлены клиенту.

Для выходных данных шаблона отсутствуют ограничения. Тестовый выпуск преобразует все выходные значения в строки, поэтому, если вы отправите в выходные данные какой-либо объект, пользователь увидит строку JSON.

Пример:

"outputs": {
  "Host Name": {
    "type": "string",
    "value": "[reference(variables('pubIpId')).dnsSettings.fqdn]"
  },
  "User Name": {
    "type": "string",
    "value": "[parameters('adminName')]"
  },
  "Password": {
    "type": "string",
    "value": "[parameters('adminPassword')]"
  }
}

Ограничения подписки

Не забывайте об ограничениях подписки и служб. Например, если требуется развернуть до десяти 4-ядерных виртуальных машин, необходимо убедиться, что с подпиской, используемой для лаборатории, разрешено использовать 40 ядер. Дополнительные сведения о подписке Azure и ограничениях служб см. в статье Подписка Azure и ограничения служб, квоты и ограничения. Так как одновременно можно запустить несколько тестовых выпусков, убедитесь, что ваша подписка может обрабатывать количество ядер, умноженное на общее число параллельных тестовых выпусков, которые могут быть запущены.

Что следует отправлять

Шаблон ARM тестового выпуска отправляется в виде ZIP-файла, который может включать в себя различные артефакты развертывания, но обязательно должен содержать файл с именем main-template.json. Этот файл является шаблоном развертывания ARM, и с его помощью тестовый выпуск создает экземпляр лаборатории. Если помимо этого файла у вас есть дополнительные ресурсы, можно указать ссылку на них в качестве внешних ресурсов внутри шаблона или включить эти ресурсы в ZIP-файл.

В ходе сертификации публикации тестовый выпуск распаковывает пакет развертывания и помещает его содержимое во внутренний контейнер больших двоичных объектов тестового выпуска. Структура контейнера отражает структуру пакета развертывания:

package.zip	Контейнер больших двоичных объектов тестового выпуска
`main-template.json`	`https:\//\<\...\>.blob.core.windows.net/\<\...\>/main-template.json`
`templates/solution.json`	`https:\//\<\...\>.blob.core.windows.net/\<\...\>/templates/solution.json`
`scripts/warmup.ps1`	`https:\//\<\...\>.blob.core.windows.net/\<\...\>/scripts/warmup.ps1`

Мы называем URI этого контейнера больших двоичных объектов базовым URI. Каждой редакции лаборатории соответствует собственный контейнер больших двоичных объектов и, соответственно, собственный базовый URI. Тестовый выпуск может передавать базовый URI разархивированного пакета развертывания в шаблон через параметры шаблона.

Преобразование примеров шаблонов для тестового выпуска

Процесс преобразования архитектуры ресурсов в шаблон Resource Manager тестового выпуска может показаться сложной задачей. Для получения дополнительных сведений см. примеры рекомендуемых способов преобразования текущих шаблонов развертывания в статье Что такое тестовый выпуск?.

Сведения о подписке, связанной с развертыванием тестового выпуска

Заключительный раздел состоит в том, чтобы автоматически развернуть тестовые диски, подключив подписку Azure и идентификатор Microsoft Entra.

Получите идентификатор подписки Azure. Предоставляет доступ к службам Azure и порталу Azure. Именно в подписке производится учет использования ресурсов и выставляются счета за услуги. Если у вас еще нет отдельной подписки Azure только для тестовых дисков, сделайте его. Чтобы найти идентификаторы подписок Azure (такие как 1a83645ac-1234-5ab6-6789-1h234g764ghty1), войдите на портал Azure и выберите Подписки в меню слева.
Получите идентификатор клиента Microsoft Entra. Если у вас уже есть идентификатор клиента, его можно найти в идентификаторе каталога свойств>идентификатора>Microsoft Entra:

Если у вас нет идентификатора клиента, создайте его в идентификаторе Microsoft Entra. Сведения о настройке клиента см. в разделе Краткое руководство. Настройка клиента.
Подготовьте приложение Microsoft Test-Drive для вашего клиента. Мы будем использовать это приложение для выполнения операций с ресурсами тестового выпуска.
1. Если у вас еще нет этого модуля, установите модуль Azure Az PowerShell.
2. Добавьте субъект-службу для приложения Microsoft Test-Drive.
  1. Запустите Connect-AzAccount и укажите учетные данные для входа в учетную запись Azure, для которой требуется встроенная роль глобального администратора Microsoft Entra ID.
  2. Создайте субъект-службу: New-AzADServicePrincipal -ApplicationId d7e39695-0b24-441c-a140-047800a05ede -DisplayName 'Microsoft TestDrive'
  3. Убедитесь, что субъект-служба был создан: Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive'
Для идентификатора приложения Microsoft Entra вставьте следующий идентификатор приложения: d7e39695-0b24-441c-a140-047800a05ede
Для ключа приложения Microsoft Entra, так как секрет не требуется, вставьте фиктивный секрет, например "без секрета".
Так как мы используем приложение для развертывания в подписке, необходимо добавить приложение в качестве участника подписки из портал Azure или PowerShell:
1. На портале Azure
  1. Выберите подписку, используемую для тестового выпуска.
  2. Выберите Управление доступом (IAM).
  3. Выберите "Добавить" > "Добавить назначение ролей".
  4. На вкладке "Роль" выберите "Участник".
  5. На вкладке "Участники" выберите "Пользователь", "Группа" или "Субъект-служба", а затем выберите "Выбрать участников".
  6. Выберите созданный ранее субъект-службу Microsoft TestDrive.
  7. Чтобы назначить роль, на вкладке Проверка и назначение выберите Проверка и назначение.
    
    Дополнительные сведения о назначении ролей см. в статье Назначение ролей Azure с помощью портала Azure
2. При использовании PowerShell:
  1. Выполните следующую команду, чтобы получить идентификатор объекта ServicePrincipal: (Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive').id.
  2. Выполните команду с идентификатором объекта и идентификатором подписки: New-AzRoleAssignment -ObjectId <objectId> -RoleDefinitionName Contributor -Scope /subscriptions/<subscriptionId>

Примечание.

Перед удалением старого идентификатора приложения перейдите в портал Azure, а затем группы ресурсов и выполните поискCloudTry_. Проверьте событие, инициированное столбцом .

Не удаляйте старый идентификатор приложения, если для Microsoft TestDrive не задан хотя бы один ресурс (имя операции).

Чтобы удалить идентификатор приложения, в меню навигации слева выберите "Регистрация приложений Идентификатора>Майкрософт", а затем на вкладке "Все приложения". Выберите приложение и нажмите кнопку "Удалить".

Повторная публикация

Теперь, когда все поля тестового выпуска заполнены, используйте функцию Повторить публикацию для своего предложения. Как только ваш тестовый запуск пройдет сертификацию, проверьте качество обслуживания клиентов в предварительной версии предложения:

Запустите тестовый выпуск в пользовательском интерфейсе.
Откройте подписку Azure на портале Azure.
Убедитесь, что тестовый выпуск развертывается правильно.

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

Когда вы комфортно с предложением предварительной версии, пришло время жить! Существует окончательный процесс проверки, чтобы дважды проверить весь комплексный интерфейс. Если мы отклоним предложение, мы отправим электронное письмо техническому контакту для вашего предложения, объясняя, что необходимо исправить.

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

Если вы следовали инструкциям по созданию предложения в Центре партнеров, вернитесь к этому разделу с помощью стрелки "Назад".
Дополнительные сведения о других типах тестовых выпусков см. в статье Что такое тестовый выпуск?.

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

Тестовый выпуск Azure Resource Manager

Техническая конфигурация

Создание шаблона тестового выпуска

Параметры

Допустимые типы метаданных параметров

baseuri

username

password

Идентификатор сеанса

Уникальные имена

Расположение развертывания

Выходные данные

Ограничения подписки

Что следует отправлять

Преобразование примеров шаблонов для тестового выпуска

Сведения о подписке, связанной с развертыванием тестового выпуска

Повторная публикация

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

Обратная связь

Обратная связь

Дополнительные ресурсы