Создание и использование файлов ресурсов

  • Статья

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

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

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

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

Типы файлов ресурсов

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

URL-адрес контейнера хранилища

Использование URL-адреса контейнера хранилища означает, что с подходящими разрешениями вы можете получить доступ к файлам в любом контейнере хранилища в Azure.

В этом примере C# файлы уже были переданы в контейнер хранилища Azure в качестве хранилища BLOB-объектов. Чтобы получить доступ к данным, необходимым для создания файла ресурсов, сначала нужно получить доступ к контейнеру хранилища. Это можно сделать несколькими способами.

Подписанный URL-адрес

Создайте URI подписанного URL-адреса (SAS) с подходящими разрешениями для доступа к контейнеру хранилища. Задайте срок действия и разрешения для SAS. В этом случае время начала не указано, поэтому SAS начинает действовать немедленно, а срок его действия истекает через два часа после создания.

SharedAccessBlobPolicy sasConstraints = new SharedAccessBlobPolicy
{
    SharedAccessExpiryTime = DateTime.UtcNow.AddHours(2),
    Permissions = SharedAccessBlobPermissions.Read | SharedAccessBlobPermissions.List
};

Примечание.

Для доступа к контейнеру необходимо иметь разрешения Read и List, в то время как для доступа к BLOB-объектам требуется только разрешение Read.

После настройки разрешений создайте маркер SAS и отформатируйте подписанный URL-адрес для доступа к контейнеру хранилища. Используя отформатированный подписанный URL-адрес для контейнера хранилища, создайте файл ресурсов с FromStorageContainerUrl.

CloudBlobContainer container = blobClient.GetContainerReference(containerName);

string sasToken = container.GetSharedAccessSignature(sasConstraints);
string containerSasUrl = String.Format("{0}{1}", container.Uri, sasToken);

ResourceFile inputFile = ResourceFile.FromStorageContainerUrl(containerSasUrl);

При необходимости можно использовать свойство blobPrefix, чтобы ограничивать загрузку только теми BLOB-объектами, имя которых начинается с указанного префикса:

ResourceFile inputFile = ResourceFile.FromStorageContainerUrl(containerSasUrl, blobPrefix = yourPrefix);

Управляемое удостоверение

Создайте управляемое удостоверение, назначаемое пользователем, и назначьте ему роль Storage Blob Data Reader для вашего контейнера хранилища Azure. Затем назначьте управляемое удостоверение для своего пула, чтобы ваши виртуальные машины могли получить доступ к удостоверению. Наконец, можно получить доступ к файлам в вашем контейнере, указав идентификатор для использования пакетной службы Azure.

CloudBlobContainer container = blobClient.GetContainerReference(containerName);

ResourceFile inputFile = ResourceFile.FromStorageContainerUrl(container.Uri, identityReference: new ComputeNodeIdentityReference() { ResourceId = "/subscriptions/SUB/resourceGroups/RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity-name" });

Открытый доступ

В качестве альтернативы созданию подписанного URL-адреса или использованию управляемого удостоверения можно включить анонимный открытый доступ с правом чтения к контейнеру и его большим двоичным объектам в хранилище BLOB-объектов Azure. Таким образом можно предоставить доступ только для чтения к этим ресурсам, не передавая ключ учетной записи и не требуя подписанного URL-адреса. Открытый доступ обычно используется для сценариев, когда определенные большие двоичные объекты нужно сделать всегда доступными для анонимного доступа на чтение. Если этот сценарий подходит для вашего решения, см. статью Настройка анонимного общего доступа с правом чтения для контейнеров и больших двоичных объектов, чтобы узнать больше об управлении доступом к данным большого двоичного объекта.

Имя контейнера хранилища (автоматическое хранение)

Вместо настройки и создания подписанного URL-адреса для доступа к данным BLOB-объектов можно использовать имя контейнера хранилища Azure. Используемый контейнер хранилища должен находиться в учетной записи хранения Azure, связанной с вашей учетной записью пакетной службы, которую еще называют учетной записью автоматического хранения. Используя контейнер автоматического хранения, можно обойти настройку и создание подписанного URL-адреса для доступа к контейнеру хранилища. Вместо этого нужно указать имя контейнера хранилища в связанной учетной записи хранения.

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

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

ResourceFile inputFile = ResourceFile.FromAutoStorageContainer(containerName);

Как и в случае с URL-адресом контейнера хранения, можно использовать свойство blobPrefix, чтобы указать, какие BLOB-объекты будут загружены:

ResourceFile inputFile = ResourceFile.FromAutoStorageContainer(containerName, blobPrefix = yourPrefix);

Один файл ресурсов из конечной точки веб-узла

Чтобы создать один файл ресурсов, можно указать допустимый URL-адрес HTTP, содержащий входные данные. URL-адрес предоставляется API пакетной службы, а затем данные используются для создания файла ресурсов. Этот метод можно использовать независимо от того, где находятся данные для создания файла ресурсов: в службе хранилища Azure или в любом другом расположении в Интернете, например в конечной точке GitHub.

В следующем примере используется FromUr для получения файла из строки, содержащей допустимый URL-адрес, а затем создается файл ресурсов, который будет использоваться задачей. Для этого сценария учетные данные не требуются. (При использовании хранилища BLOB-объектов требуются учетные данные, если только общий доступ на чтение не включен в контейнере BLOB-объектов.)

ResourceFile inputFile = ResourceFile.FromUrl(yourURL, filePath);

Можно также использовать строку, определяемую в качестве URL-адреса (или сочетание строк, которые вместе создают полный URL-адрес для файла).

ResourceFile inputFile = ResourceFile.FromUrl(yourDomain + yourFile, filePath);

Если ваш файл находится в хранилище Azure, можно использовать управляемое удостоверение вместо создания подписанного URL-адреса для файла ресурсов.

ResourceFile inputFile = ResourceFile.FromUrl(yourURLFromAzureStorage, 
    identityReference: new ComputeNodeIdentityReference() { ResourceId = "/subscriptions/SUB/resourceGroups/RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity-name"},
    filePath: filepath
);

Примечание.

Проверка подлинности управляемого удостоверения будет работать только с файлами в хранилище Azure. Для управляемого удостоверения требуется назначение роли Storage Blob Data Reader для контейнера, в котором находится файл, и она также должна быть назначена для пула пакетной службы.

Советы и рекомендации

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

Множество файлов ресурсов

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

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

Количество файлов ресурсов на задачу

Если задача задает большое количество файлов ресурсов, пакетная служба может отклонить задачу как слишком большую. Это зависит от общей длины имен файлов или URL-адресов (а также ссылки на удостоверения) для всех файлов, добавленных в задачу. Лучше всего делать задачи небольшими, минимизировав количество файлов ресурсов в них.

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

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