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

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

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

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

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

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

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

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

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

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

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

Общий код доступа

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

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

Примечание.

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

После настройки разрешений создайте SAS-токен и отформатируйте SAS URL для доступа к контейнеру хранилища. Используя форматированный SAS 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. Затем назначьте управляемое удостоверение для своего пула, чтобы ваши виртуальные машины могли получить доступ к удостоверению. Наконец, можно получить доступ к файлам в вашем контейнере, указав Batch идентификатор для использования.

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" });

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

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

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

Вместо настройки и создания SES URL-адреса вы можете использовать имя контейнера Azure-хранилища для доступа к вашим BLOB-данным. Используемый контейнер хранилища должен находиться в учетной записи хранения Azure, связанной с вашей учетной записью пакетной службы, которую еще называют учетной записью автоматического хранения. Использование контейнера автохранения позволяет обойти процесс настройки и создания SAS 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, можно использовать управляемую удостоверенность вместо создания маркера общего доступа для файла ресурса.

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 и по мере необходимости используйте один из описанных выше методов для создания файлов ресурсов.

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

  • Last updated on