Устранение ошибок типа "Ресурс не найден"

В этой статье описываются ошибки, которые могут возникнуть, когда во время операции не удается найти ресурс. Как правило, эта ошибка происходит при развертывании ресурсов с помощью файла 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.

Причина

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

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

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

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

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

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

Решение 2. Задание зависимостей

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

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

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

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

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 использует символьное имя, чтобы создать неявную зависимость от другого ресурса. Ключевое слово existing ссылается на развернутый ресурс. Если существующий ресурс находится в другой группе, чем ресурс, который вы хотите развернуть, включите область действия и используйте функцию 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. Получение управляемого удостоверения из ресурса

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

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

vm.identity.principalId

vm.identity.tenantId

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

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

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

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

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

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

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

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