Блог

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

 az storage account create -g <my-rg-name> --name <my-storage-account-name> --sku Standard_RAGRS --kind StorageV2 --hns --min-tls-version TLS1_2 --access-tier Hot
 

с последующим

 az storage container create --auth-mode login -g <my-rg-name> --account-name <my-storage-account-name> --name documents --public-access off
 

В последний раз я успешно запускал его 15 сентября. В следующий раз я попытался сделать это 27 сентября, и это не удалось, и с тех пор это продолжалось.

Сообщение об ошибке при создании контейнера для хранения содержит следующее:

 azure.common.AzureException: HTTPSConnectionPool(host='<my-account-name>.blob.core.windows.net', port=443):
 Max retries exceeded with url: /documents?restype=container (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x04D38928>:
 Failed to establish a new connection: [Errno 11001] getaddrinfo failed'))
 

Итак, вот что интересно — это была попытка <my-account-name>.blob.core.windows.net , но на самом деле, если я посмотрю на конечные точки во вновь созданной учетной записи хранения, они:

  "primaryEndpoints": {
    "blob": "https://<my-account-name>.z47.blob.storage.azure.net/",
    "dfs": "https://<my-account-name>.z47.dfs.storage.azure.net/",
    "file": "https://<my-account-name>.z47.file.storage.azure.net/",
    "internetEndpoints": null,
    "microsoftEndpoints": null,
    "queue": "https://<my-account-name>.z47.queue.storage.azure.net/",
    "table": "https://<my-account-name>.z47.table.storage.azure.net/",
    "web": "https://<my-account-name>.z47.web.storage.azure.net/"
  },
 

так что там, где мы и ожидали «xxx.blob.core.windows.net», мы получаем «xxx.z47.blob.storage.azure.net».
Это потенциально хорошо, я думаю, мы могли бы запросить за это имя, и использовать его — но я не могу легко исправить аз командной строки и тот факт, что они имеют твердую надежду, что blob.core.windows.net доменное имя заставляет меня думать, что существует много других вещей, которые вам нужно использовать его будет нарушена (мой АДФ трубопроводы, которые используют для хранения счет наверняка есть — но может быть, я бы их исправить, чтобы справиться с разных URL-адреса, если это все — но я подозреваю, что это ненормально и хочу понять, почему).

Я подтвердил, что это не относится к конкретному интерфейсу командной строки — если я создам учетную запись хранения на портале, мы все равно получим нестандартные конечные точки. Так что это что-то в нашей группе подписки/ресурсов, но я просто понятия не имею, почему она так себя ведет и что с этим делать. Безусловно, документация Microsoft устанавливает четкое ожидание того, что мы получим blob.core.windows.net конечная точка (например, https://docs.microsoft.com/en-us/azure/storage/common/storage-account-overview).

Кто-нибудь знает, что могло бы заставить Azure вести себя таким образом?

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

Поддержка в пакетах SDK не завершена. Среди тех, кто в настоящее время не поддерживается, есть AZ CLI. Отсюда проблемы, которые мы видели (в частности — не удалось создать контейнер для хранения, и az storage account show-connection-string возвращает ложь). JS и Powershell также не поддерживаются.

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

Подробные сведения

Вот некоторые подробности того, что мы обнаружили, и что мы с этим сделали.

• az CLI — не может исправить, но может сделать что-то по-другому
  • создавайте контейнеры с помощью шаблона arm — вот подход, который мы использовали
  • azcopy включает возможность создания контейнеров — я не рассматривал этот вариант
  • делайте все на портале
• .NET — изменена строка подключения для явного указания конечной точки — все, кажется, работает
• Python — измененная строка подключения явно указывает конечную точку — кажется, все работает
• Конвейеры Devops (AzureFileCopy@3) — работает, если указать параметр командной строки «Тип объекта:большой двоичный объект»
• Фабрика данных Azure:
  • Может выполнять конвейеры, включающие задачи копирования с хранилищем Azure в качестве источника и/или приемника, предоставляя связанной службе полный URL-адрес конечной точки dfs.
  • Не удается заставить триггеры событий хранения работать ни при каких обстоятельствах

Чтобы попытаться решить проблему с триггерами событий хранилища, я попытался создать события хранилища со стороны хранилища Azure, вместо того, чтобы заставить ADF сделать это (подумав, что, возможно, у ADF был core.windows.net предположение, и если бы я создал части отдельно, я мог бы соединить их), но, увы, не повезло. Я не могу найти способ создания событий хранилища Azure с этими разделенными конечными точками DNS. На данный момент мы реализуем временный обходной путь в ADF, который запускается по расписанию, и опросы для файлов в хранилище Azure (и даже это непросто — нет блока ADF, в котором перечислены большие двоичные объекты, нам пришлось написать функцию Azure). Фу. Надеюсь, Microsoft скоро закроет этот пробел.

Как предложил @Gaurav Mantri, пожалуйста, отправьте заявку в службу поддержки azure.

Перейдите на портал azure>>> справка поддержка >>>>>>>нажмите создать новый билет в службу поддержки, заполните необходимые данные и отправьте билет