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


Устранение ошибок, связанных с отсутствием ресурса

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

Симптомы

Существует два кода ошибки, указывающие, что ресурс не найден. Ошибка NotFound возвращает результат, аналогичный следующему:

Code=NotFound;
Message=Cannot find ServerFarm with name exampleplan.

Ошибка ResourceNotFound возвращает результат, аналогичный следующему:

Code=ResourceNotFound;
Message=The Resource 'Microsoft.Storage/storageAccounts/{storage name}' under resource
group {resource group name} was not found.

Причина

Resource Manager должен получить свойства ресурса, но не удается найти ресурс в подписке.

Решение 1. Проверка свойств ресурса

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

  • Имя ресурса
  • Имя группы ресурсов
  • Подписка

Если вы используете PowerShell или Azure CLI, убедитесь, что вы выполняете команды в подписке, содержащей ресурс. Вы можете изменить подписку командой Set-AzContext или az account set. У многих команд есть параметр подписки, позволяющий задать другую подписку, отличающуюся от текущего контекста.

Если вы не можете проверить свойства, войдите на портал Microsoft Azure. Найдите ресурс, который пытаетесь использовать, и проверьте имя ресурса, группу ресурсов и подписку.

Решение 2. Установка зависимостей

Если при развертывании шаблона возникает эта ошибка, может потребоваться добавить зависимость. Resource Manager оптимизирует развертывания, создавая ресурсы параллельно, когда это возможно.

Например, при развертывании веб-приложения план службы приложений должен существовать. Если вы не указали, что веб-приложение зависит от плана службы приложений, Resource Manager создает оба ресурса одновременно. Веб-приложение завершается ошибкой, что ресурс плана службы приложений не найден, так как он еще не существует. Эту ошибку можно предотвратить, задав зависимость в веб-приложении.

Используйте неявную зависимость , а не функцию resourceId . Зависимость создается с помощью символьного имени ресурса и свойства идентификатора.

Например, свойство веб-приложения serverFarmId использует servicePlan.id для создания зависимости от плана App Service.

resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  properties: {
    serverFarmId: servicePlan.id
  }
}

resource servicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  ...

Для большинства развертываний не требуется использовать dependsOn для создания явной зависимости.

Избегайте настройки зависимостей, которые не нужны. Ненужные зависимости продлевают длительность развертывания, так как ресурсы не развертываются параллельно. Кроме того, можно создать циклические зависимости, которые блокируют развертывание.

Порядок развертывания

При появлении проблем с зависимостью необходимо получить представление о порядке развертывания ресурсов. Вы можете использовать портал для просмотра порядка операций развертывания:

  1. Войдите на портал.

  2. На странице Обзор группы ресурсов выберите ссылку на историю развертывания.

    Снимок экрана: портал Azure, на котором выделена ссылка на журнал развертывания группы ресурсов в разделе

  3. Для названия развертывания, которое вы хотите просмотреть, выберите Связанные события.

    Снимок экрана: портал Azure с именем развертывания со ссылкой

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

    Снимок экрана: журнал действий портала Azure с тремя учетными записями хранения, развернутыми параллельно, с их метками времени и состояниями.

    На следующем рисунке показаны три учетные записи хранения, которые не развертываются параллельно. Вторая учетная запись хранения зависит от первой учетной записи хранения, а третья учетная запись хранения зависит от второй учетной записи хранения. Первая учетная запись хранения помечена как "Запущено", "Принято" и "Выполнено успешно " до следующего запуска.

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

Решение 3. Получение внешнего ресурса

Bicep использует символьное имя для создания неявной зависимости от другого ресурса. Существующее ключевое слово ссылается на развернутый ресурс. Если существующий ресурс находится в другой группе ресурсов, отличной от ресурса, который требуется развернуть, включите область и используйте функцию resourceGroup .

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

resource servicePlan 'Microsoft.Web/serverfarms@2022-03-01' existing = {
  name: hostingPlanName
  scope: resourceGroup(rgname)
}

resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  name: siteName
  properties: {
    serverFarmId: servicePlan.id
  }
}

Решение 4. Получение управляемого удостоверения из ресурса

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

Вы можете получить идентификатор участника и идентификатор арендатора для управляемого удостоверения, примененного к виртуальной машине. Например, если ресурс виртуальной машины имеет символическое имя vm, используйте следующий синтаксис:

vm.identity.principalId

vm.identity.tenantId

Решение 5. Проверка функций

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

В следующем примере осуществляется ссылка на существующую учетную запись хранения в другой группе ресурсов.

resource stgAcct 'Microsoft.Storage/storageAccounts@2022-05-01' existing = {
  name: stgname
  scope: resourceGroup(rgname)
}

Решение 6. После удаления ресурса

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

Снимок экрана: портал Azure с удаленным ресурсом с сообщением об ошибке

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