@danielstocker Большое спасибо за то, что обратили на это наше внимание. Я поручил это ведущему специалисту по обслуживанию для дальнейшего расследования и внесу изменения, когда у нас будет больше ясности.

@ Mike-Ubezzi-MSFT @ mike-urnun-msft

Спасибо, что изучили это.

Вам нужна дополнительная информация, чтобы продвинуться в этом?

@danielstocker, можете ли вы подробнее рассказать о том, в чем заключалась ваша первоначальная проблема, которая unintentional swap )

Привет @ ggirard07!

Без проблем. Подведу итог.
Первоначально это возникло, потому что в нашей документации указано, что требуется WEBSITE_CONTENTSHARE. (см. здесь: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#windows)

Если мы экспортируем шаблон функций из Marketplace (шаблон экспорта на последней странице), мы получаем WEBSITE_CONTENTSHARE в качестве стандартной настройки приложения. Если мы воспользуемся этим, то может произойти следующая ситуация.

1) Разворачиваем шаблон ARM и получаем пустую функцию с двумя слотами
2) Разворачиваем в слот постановки
3) Мы меняем местами, чтобы сделать контент доступным в продакшене.
4) НЕПРЕДНАМЕРЕННЫЙ SWAP, поскольку шаблон ARM повторно развертывается и настройки приложения повторно применяются (это происходит даже во время инкрементного развертывания ARM, поскольку ресурс appsettings всегда перезаписывает и сбрасывает параметр WEBSITE_CONTENTSHARE)
5) Процедура развертывания теперь развертывает новый код в промежуточном слоте, а наш рабочий слот пуст, а не содержит предыдущую версию. Наша производственная функция «непреднамеренно» остановлена

Затем клиент в этом конкретном случае указал на эту статью https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/

Это предполагает, что параметр должен быть установлен как параметр слота, чтобы исправить поведение. Хотя это действительно исправляет поведение в моих тестах, это кажется неправильным, потому что оно не должно работать.

Ниже приведена таблица того, что произошло в моих тестах. (после настройки слота)

Мое (и клиентское) восприятие таково, что слоты больше не должны меняться местами, но, как описано в статье, это все равно работает.

Я поднял этот вопрос и внутри компании, и люди обнаружили непоследовательное поведение при изменении настроек приложения. (Следовательно, почему это выделено в моей таблице тестирования) Для коллег, тестирующих это, обновление настроек приложения заставило повторно применить настройки слота, что снова вызвало непреднамеренный своп.

Это, наконец, (извините за долгий ответ) заставило меня подать заявление в службу поддержки, в результате которого результатом было «просто не устанавливайте настройки вообще».
Мои личные тесты показали, что это решает проблему, но в документации нет указаний, подтверждающих это, поэтому я поднял этот вопрос.

Надеюсь это поможет.
Дайте мне знать, если что-то неясно.

@danielstocker, безусловно, важная информация, особенно для понимания того, как слоты и свопинг работают для функций по сравнению с традиционным веб-приложением с веб-заданиями.
Также это не объясняется в документации по шаге 4 есть только

Привет, @ ggirard07, и спасибо, что прочитали мою диатрибу. Так как же дальше двигаться дальше? :)

@ ggirard07 @ ggailey777 @ mike-urnun-msft

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

Спасибо за вашу помощь

@danielstocker Просто чтобы я четко

• Удалите отсюда параметр развертывания WEBSITE_CONTENTSHARE .
• Добавьте в справочную статью примечание, что WEBSITE_CONTENTSHARE должно устанавливаться только средой выполнения.

Как вы думаете, этого будет достаточно?

cc. @mattchenderson

Привет @ ggailey777
Да я думаю это было бы хорошее решение

Разве WEBSITE_CONTENTSHARE одним из необходимых приложений при развертывании приложения-функции с использованием ARM?

Разве WEBSITE_CONTENTSHARE одним из необходимых приложений при развертывании приложения-функции с использованием ARM?

Если он не применяется, я думаю, среда выполнения сгенерирует его для вас.

Я развернул ARM с планом потребления и приложение-функцию с разделом _Microsoft.Web / sites / config_ с именем appsettings и следующими свойствами

• FUNCTIONS_EXTENSION_VERSION: «~ 2»,
• FUNCTIONS_WORKER_RUNTIME: "dotnet",
• WEBSITE_CONTENTAZUREFILECONNECTIONSTRING : [
• WEBSITE_NODE_DEFAULT_VERSION: 6.5.0

Развертывание вернуло следующую ошибку:

      "ErrorEntity": {
        "ExtendedCode": "01010",
        "MessageTemplate": "Required parameter {0} is missing.",
        "Parameters": [
          "WEBSITE_CONTENTSHARE"
        ],
        "Code": "BadRequest",
        "Message": "Required parameter WEBSITE_CONTENTSHARE is missing."

После того, как я _также_ удалил параметр WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, развертывание прошло без ошибок. Итак, похоже, существует некоторая необходимая связь между этими двумя настройками.
Несмотря на успех, это развертывание заставило меня задуматься о том, где и где функции (пакеты) развернуты физически (и действительно ли этот случай в первую очередь).

Мы наблюдали точное поведение, описанное @tjgalama , а также ресурсы с пакетами функций.

Наши приложения-функции также включают функцию, запускаемую таймером, поэтому мы указываем настройку AzureWebJobsStorage как предлагается : мы бы предположили / надеялись, что среда выполнения будет использовать ту же строку подключения для (теперь неявно) WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , но это не так: в указанной нами учетной записи хранения мы действительно видим контейнеры блобов azure-webjobs-hosts и azure-webjobs-secrets , но общие файловые ресурсы отсутствуют.

Я проверил Kudu на предмет подсказок, и похоже, что все файлы, которые должны быть там, есть в файловой системе (где бы это ни было, проверено на app-name.scm.azurewebsites.net/api/vfs/ ), но нет ссылки на какие-либо настройки ( WEBSITE_CONTENTSHARE или WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ) отображается на вкладке среды ( appname.scm.azurewebsites.net/Env.cshtml ).

Возможно, важно упомянуть, что наши приложения настроены с помощью WEBSITE_ENABLE_SYNC_UPDATE_SITE=True и WEBSITE_RUN_FROM_PACKAGE=1 .
Кажется, что приложения работают, но нам действительно нужна некоторая ясность в этом вопросе, поскольку мы переносим основную бизнес-службу в Функции Azure и хотим разобраться в ней перед развертыванием в производственной среде.

Следуя некоторым советам, мы установили WEBSITE_CONTENTSHARE в качестве настройки слота, чтобы убедиться, что значения различаются между нашими производственными и промежуточными слотами. Сегодня шаблон ARM, который мы используем, начал давать сбой с 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (хотя я подтвердил, что в настоящее время он действительно установлен в качестве настройки слота на портале). Изменилось ли что-то в этом поведении?

Мы заметили эту же проблему в течение последних нескольких дней, и нам нужны инструкции, как действовать дальше. Мы также следовали подходу к установке WEBSITE_CONTENTSHARE в качестве настройки слота, чтобы обойти непреднамеренную проблему подкачки, но теперь не можем выполнить развертывание из-за этой ошибки. Я попытался задним числом удалить как это, так и параметры WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, чтобы перейти к тому, что кажется рекомендуемым подходом - не использовать ни то, ни другое, но эти развертывания также не удались.

Следуя некоторым советам, мы установили WEBSITE_CONTENTSHARE в качестве настройки слота, чтобы убедиться, что значения различаются между нашими производственными и промежуточными слотами. Сегодня шаблон ARM, который мы используем, начал давать сбой с 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (хотя я подтвердил, что в настоящее время он действительно установлен в качестве настройки слота на портале). Изменилось ли что-то в этом поведении?

Удалите его и позвольте среде выполнения выбрать имя. Вот как я это делаю.

@jeffhollan, не могли бы вы

Это говорит о том, что WEBSITE_CONTENTSHARE и WEBSITE_CONTENTAZUREFILECONNECTIONSTRING _required_: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#create -a-function-app

Здесь комментаторы думают, что они _не_ требуются; ARM считает, что они необходимы ?; Служба поддержки Azure считает, что WEBSITE_CONTENTSHARE нарушает сценарии использования слотов.

В итоге мы проверили код узла функций Azure, и похоже , что при запуске из пакета параметр WEBSITE_CONTENTAZUREFILECONNECTIONSTRING не используется .
Мы проверили это, удалив из нашего шаблона ARM как WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE и получив хорошие результаты: наши приложения-функции вообще не имеют этих двух настроек (даже не назначенных средой выполнения), и они не используйте общие файловые ресурсы в каких-либо учетных записях хранения (по крайней мере, что мы видим).

Поэтому следует иметь в виду, что файловая система для приложения webapp / function выглядит примерно так:

|-data
|-LogFiles
|-site
  |-deployments
  |-tools
  |-wwwroot

Когда вы используете запуск из пакета, это заменяет только папку wwwroot в этом дереве. Все остальное обеспечивается основной файловой системой. Если вы создаете приложение-функцию потребления или эластичную премиум-функцию без WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, тогда основная файловая система недоступна за пределами модуля масштабирования, в котором было создано приложение-функция. Это не поддерживаемая / рекомендуемая конфигурация. Это означает, что ваше приложение-функция может не масштабироваться за пределы единицы масштабирования, в которой оно было создано, или, если это произойдет, вы не сможете быть уверены, что состояние файловой системы за пределами wwwroot остается согласованным.

Последнее руководство, которое я видел от разработчика, который владеет тем, как WEBSITE_CONTENTSHARE взаимодействует со слотами, выглядит следующим образом:

• WEBSITE_CONTENTSHARE НЕ должен быть настройкой слота. Изменение API, которое блокирует это, развертывается на момент написания.
• При первоначальном создании ресурса через ARM должен быть установлен WEBSITE_CONTENTSHARE. Однако после первоначального создания этот параметр следует опустить в шаблоне ARM (потому что, если он был включен, дальнейшее выполнение шаблона ARM может вызвать неожиданную замену содержимого)

Следуя моему комментарию выше ... Я также обнаружил, что в настоящее время система имеет некоторую непоследовательность в отношении создания WEBSITE_CONTENTSHARE, так что вам даже не нужно указывать его изначально. Некоторые из вас говорят, что вам не нужно его указывать, в то время как другие получают сообщение об ошибке, указывающее, что это необходимо. Насколько я могу судить, такое поведение работает правильно для потребления (т.е. шаблон ARM для потребления изначально не нуждается в этой настройке), но то же самое не относится к эластичной премии. Такое поведение исправляется, но, вероятно, потребуется 1-2 месяца, чтобы избавиться от него. А пока рекомендации, которыми я поделился выше (где вы устанавливаете его изначально, а затем удаляете из шаблона ARM), применимы.

@paulbatum

• При первоначальном создании ресурса через ARM должен быть установлен WEBSITE_CONTENTSHARE. Однако после первоначального создания этот параметр следует опустить в шаблоне ARM (потому что, если он был включен, дальнейшее выполнение шаблона ARM может вызвать неожиданную замену содержимого)

Вы ведь понимаете, что такое нарушение предназначения шаблона ARM, верно?

Такое поведение исправляется, но, вероятно, потребуется 1-2 месяца, чтобы избавиться от него. А пока рекомендации, которыми я поделился выше (где вы устанавливаете его изначально, а затем удаляете из шаблона ARM), применимы.

Какая здесь финальная ожидаемая конфигурация?
Можем ли мы получить объявление об Azure / app-service-announcements с правильной конфигурацией и официальным графиком после того, как все это будет действительно развернуто?

Привет, не уверен, есть ли какие-то разработки по этому поводу. Я все еще пытаюсь использовать шаблоны ARM с флагом WEBSITE_CONTENTSHARE. @paulbatum, как я могу

@gustavobmichel Извините, я не понимаю ваш вопрос. Шаблон ARM - это JSON, вы редактируете его по мере необходимости. Он появляется как часть раздела настроек приложения, например:

          "appSettings": [
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';EndpointSuffix=', environment().suffixes.storage, ';AccountKey=',listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },

Привет @paulbatum , спасибо, что вернулся ко мне. Я думал, вы упомянули о программном исключении настроек из шаблона JSON, так что это был мой вопрос.

Как утверждали другие, я также думал, что эти две настройки необходимы, поэтому я удалил их из своего шаблона ARM.

Чтобы протестировать эту функцию с нулевым временем простоя, я создал простой тест с чистой минимальной инфраструктурой. Я удалил все ресурсы из своей группы ресурсов и запустил шаблон ARM как часть конвейера выпуска, чтобы создать ресурсы без WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE и WEBSITE_RUN_FROM_PACKAGE.

Я провел пару тестов, и все еще работает нормально, используя план потребления. На этой неделе я проведу несколько тестов с премиум-уровнем.

Я также добавил эту конфигурацию WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG в 1 по этой ссылке: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

Я приложил свой тестовый шаблон ARM для справки.
azuredeploy.txt

Привет @paulbatum , спасибо, что вернулся ко мне. Я думал, вы упомянули о программном исключении настроек из шаблона JSON, так что это был мой вопрос.

Как утверждали другие, я также думал, что эти две настройки необходимы, поэтому я удалил их из своего шаблона ARM.

Чтобы протестировать эту функцию с нулевым временем простоя, я создал простой тест с чистой минимальной инфраструктурой. Я удалил все ресурсы из своей группы ресурсов и запустил шаблон ARM как часть конвейера выпуска, чтобы создать ресурсы без WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE и WEBSITE_RUN_FROM_PACKAGE.

Я провел пару тестов, и все еще работает нормально, используя план потребления. На этой неделе я проведу несколько тестов с премиум-уровнем.

Я также добавил эту конфигурацию WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG в 1 по этой ссылке: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

Я приложил свой тестовый шаблон ARM для справки.
azuredeploy.txt

Опуская WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, как ваша функция узнает, откуда взять код приложения?

Если это поможет, мы остановились на:

• установка WEBSITE_CONTENTAZUREFILECONNECTIONSTRING для учетной записи хранения, из которой мы хотим запускать код
• вообще не указывать WEBSITE_CONTENTSHARE в шаблоне руки (разрешить автоматическую генерацию для обоих слотов)
• WEBSITE_RUN_FROM_PACKAGE = 1

Я провел много тестов, и это показалось мне лучшей конфигурацией, чтобы избежать непреднамеренных свопов и знания, где находится код, и т. Д. Также не требуется управлять этими настройками вне шаблона ARM, что мне не нравилось. идея (кажется, что на этом этапе нет особого смысла использовать шаблоны ARM).

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

Если это поможет, мы остановились на:

• установка WEBSITE_CONTENTAZUREFILECONNECTIONSTRING для учетной записи хранения, из которой мы хотим запускать код
• вообще не указывать WEBSITE_CONTENTSHARE в шаблоне руки (разрешить автоматическую генерацию для обоих слотов)
• WEBSITE_RUN_FROM_PACKAGE = 1

Я провел много тестов, и это показалось мне лучшей конфигурацией, чтобы избежать непреднамеренных свопов и знания, где находится код, и т. Д. Также не требуется управлять этими настройками вне шаблона ARM, что мне не нравилось. идея (кажется, что на этом этапе нет особого смысла использовать шаблоны ARM).

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

Это именно то, что я обнаружил. Спасибо за подтверждение.

У моей функции возникают проблемы с доступом к хранилищу после добавления WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_RUN_FROM_PACKAGE. Ребята, вы добавили эти две конфигурации и в приложение, и в слот?

Точная ошибка: среда выполнения функций Azure недоступна.

Это происходит после того, как я выполняю первое развертывание, а затем пытаюсь развернуть новую версию.

Я также добавил свой yml файл.
yml file.txt
deploy.txt

Я также обновил свой шаблон ARM.

У моей функции возникают проблемы с доступом к хранилищу после добавления WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_RUN_FROM_PACKAGE. Ребята, вы добавили эти две конфигурации и в приложение, и в слот?

Точная ошибка: среда выполнения функций Azure недоступна.

Это происходит после того, как я выполняю первое развертывание, а затем пытаюсь развернуть новую версию.

Я также добавил свой yml файл.
yml file.txt
deploy.txt

Я также обновил свой шаблон ARM.

Он у меня на обоих. На самом деле у меня ничего нет в моем производственном слоте, и я меняю все, начиная с постановки. Я видел это, когда определял WEBSITE_CONTENTSHARE или не указывал на правильную учетную запись хранения, где код находится с WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Вам не нужно никуда указывать с помощью WEBSITE_CONTENTSHARE. Я действительно думаю, что видел ту ошибку, на которую вы ссылаетесь, из-за добавления WEBSITE_CONTENTSHARE к переменным среды. Убедитесь, что он не определен.

Привет @mslot , я думаю, проблема была в моем развертывании. Я установил для него zipDeploy, потому что прочитал в этой ветке https://stackoverflow.com/a/56205917 о настройке его в Azure DevOps. После того, как я изменил его на стандартное развертывание, все вроде работает. Спасибо за вашу помощь.

Такое поведение исправляется, но, вероятно, потребуется 1-2 месяца, чтобы избавиться от него.

Есть новости по этой проблеме? Согласовано ли поведение потребления и премиум-класса? Можно ли исключить WEBSITE_CONTENTSHARE из первоначального развертывания ARM и последующих развертываний? Как это повлияет на промежуточные слоты? Есть ли обновленные документы, на которые можно ссылаться, или руководство?

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

Привет. Не уверен, как вы можете это сделать, но похоже, что я не могу развернуть с
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING без WEBSITE_CONTENTSHARE. Даже через портал он выдал мне ошибку при попытке установить конфиг;
Failed to update web app settings: Required parameter WEBSITE_CONTENTSHARE is missing.

На странице обзора приложения-функции я также вижу это предупреждающее сообщение: Storage is not configured, Function scaling will be limited. Click to learn more. Я использую премиум-план. Есть ли какие-либо обновления или официальные рекомендации о том, как мы должны настраивать наши функциональные приложения?

Для плана Premium (не на 100% уверен в плане потребления) вот матрица того, что работает / не работает:

• если вы развернете новый ресурс:
  
  
  
  • если вы не укажете ни один параметр, развертывание завершится успешно, но вы получите сообщение Storage is not configured, Function scaling will be limited
  
  
  • если вы поставите только WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , это не сработает с Required parameter WEBSITE_CONTENTSHARE is missing
  
  
  • если вы укажете оба значения, он работает
  
  
• если вы развертываете на существующий ресурс
  
  
  
  • если вы не укажете ни один параметр, развертывание завершится успешно, но вы получите сообщение Storage is not configured, Function scaling will be limited
  
  
  • если вы предоставите только WEBSITE_CONTENTAZUREFILECONNECTIONSTRING , он будет успешным (и, похоже, будет работать нормально после этого), даже если WEBSITE_CONTENTSHARE должен быть обязательным
  
  
  • если вы указываете оба значения, он «работает» в том смысле, что часть ARM не выходит из строя, но вызывает проблему с множественным перезапуском, и приведенное выше руководство MS состоит в том, чтобы не устанавливать WEBSITE_CONTENTSHARE в обновлениях.
  
  

Таким образом, на данный момент не существует единого шаблона ARM, который работал бы для обоих сценариев.

Я также вижу это предупреждающее сообщение: Storage is not configured, Function scaling will be limited. Click to learn more . У вас не было веб-сайта WEBSITE_CONTENTAZUREFILECONNECTIONSTRING или WEBSITE_CONTENTSHARE. Как упоминает Коркяк, какое-нибудь обновленное или официальное руководство?

Недавно мы начали видеть сообщение «Хранилище не настроено, масштабирование функций будет ограничено. Щелкните, чтобы узнать больше» на портале Azure для существующих функций Azure, которые были развернуты четыре недели назад. Мы никогда не использовали WEBSITE_CONTENTAZUREFILECONNECTIONSTRING или WEBSITE_CONTENTSHARE, и до сих пор они работали нормально.

@paulbatum Похоже, что эта проблема портале появилось сообщение «Хранилище не настроено, масштабирование функций будет ограничено». Есть ли новое руководство по правильной настройке всего этого?

Я только что добавил «WEBSITE_CONTENTSHARE» не может быть ошибкой настройки слота, как упоминалось выше, при развертывании нового приложения-функции впервые за несколько месяцев с использованием шаблона, который раньше работал нормально.
В шаблоне есть параметр «WEBSITE_CONTENTSHARE» в качестве настройки слота, который определен как в приложении-функции, так и в настройках приложения слота развертывания в соответствии со следующей статьей, которая также была упомянута выше:
https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
Чтение этой темы удалило это как настройку слота и попробовало различные комбинации настройки WEBSITE_CONTENTSHARE, и я не получаю того же поведения, что и другие. Я могу выполнить развертывание без ошибок, как показано ниже:

• Укажите WEBSITE_CONTENTSHARE как для приложения-функции, так и для слота развертывания
• Укажите WEBSITE_CONTENTSHARE только для приложения-функции

Если я вообще не укажу «WEBSITE_CONTENTSHARE» в шаблоне, я получу ошибку «Требуемый параметр WEBSITE_CONTENTSHARE отсутствует».

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

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

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

1. У вас должны быть определены WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE

или

1. Если вы используете запуск из zip / package, тогда вам должно быть присвоено значение «WEBSITE_USE_ZIP», «WEBSITE_RUN_FROM_ZIP» или «WEBSITE_RUN_FROM_PACKAGE», отличное от пустого, 0 или 1.

Мы должны исправить это где-то на следующей неделе.

Спасибо @ehamai - за № 2, когда вы говорите «установить что-то другое, кроме пустого, 0 или 1» - это правильно? Разве 0 и 1 не противоположны? (У нас есть свой набор 1 и мы предположили , что означало да / верно (бегут из пакета) как описано здесь: https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from -развертывание-пакет)

Привет, Эллиотт, большое спасибо за очень быстрый ответ.

Итак, чтобы прояснить:
При развертывании из шаблона ARM в план потребления и использовании слота развертывания, но без zip / package

• Я должен определить как WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, так и WEBSITE_CONTENTSHARE как в производственном, так и в промежуточном слотах.

• Я НЕ должен определять WEBSITE_CONTENTSHARE как настройку слота развертывания для любого слота.

С наилучшими пожеланиями

Оуайн

От: Эллиотт Хамаи [email protected]
Отправлено: 22 июнь 2020 17:31
Кому: MicrosoftDocs / azure-docs [email protected]
Копия: Оуайн Винтербоун (ITCS - персонал) [email protected] ; Руководство [email protected]
Тема: Re: [MicrosoftDocs / azure-docs] WEBSITE_CONTENTSHARE не следует использовать для получения поддержки (# 36458)

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

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

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

1. У вас должны быть определены WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE

или

1. Если вы используете запуск из zip / package, тогда вам должно быть присвоено значение «WEBSITE_USE_ZIP», «WEBSITE_RUN_FROM_ZIP» или «WEBSITE_RUN_FROM_PACKAGE», отличное от пустого, 0 или 1.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647631943&data = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cecd3322262374fb9ffb608d816c9ad12% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% 7C637284402737046987 & SData = woJvSwWrHgKQIV3xQ8QX3vIOULv6ZNfn5wln4tPn3EA% 3D & зарезервирован = 0 , или отказаться от https://eur01.safelinks.protection.outlook.com/?url= HTTPS% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-AUTH% 2FAGFS4PC23VOJOEKS6ESN2C3RX6BM5ANCNFSM4IJGDPBQ & данных = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cecd3322262374fb9ffb608d816c9ad12% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% 7C637284402737056941 & SData = StHshC6EtV6A% 2BLi3g7x0xfNx56POAYnwjMWihEf% 2BCYM% 3D & = защищены 0 .

@briandunnington - Да, извините, это сбивает с толку.

• 0 означает отключено
• 1 означает запуск из локального zip-архива, но для правильной работы вам также необходимо, чтобы в первом операторе были определены WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE.

@OwainWin - Извините, меня смущает ваш вопрос. Вы спросили, следует или не следует включать WEBSITE_CONTENTSHARE.

Я считаю, что у вас должны быть определены WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE как в производственном, так и в промежуточном слотах.

Спасибо @ehamai - так что вернемся к исходному вопросу этой ветки: каковы рекомендации по настройке WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE в шаблоне ARM, который работает для начального и последующего развертывания? Для плана Premium (не уверен на 100% в плане потребления, но считаю, что он такой же), вот матрица того, что работает / не работает:

• если вы развернете новый ресурс:
  
  
  
  • если вы не укажете ни один параметр, развертывание завершится успешно, но в итоге хранилище не настроено, масштабирование функции будет ограничено.
  
  
  • если вы предоставляете только WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, он не работает с отсутствующим обязательным параметром WEBSITE_CONTENTSHARE
  
  
  • если вы укажете оба значения, он работает
  
  
• если вы развертываете на существующий ресурс
  
  
  
  • если вы не укажете ни один параметр, развертывание завершится успешно, но в итоге хранилище не настроено, масштабирование функции будет ограничено.
  
  
  • если вы предоставите только WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, он будет успешным (и, похоже, будет работать нормально после этого), даже если предполагается, что WEBSITE_CONTENTSHARE является обязательным
  
  
  • если вы указываете оба значения, он «работает» в том смысле, что часть ARM не выходит из строя, но вызывает проблему с множественным перезапуском, и приведенное выше руководство MS состоит в том, чтобы не устанавливать WEBSITE_CONTENTSHARE в обновлениях.
  
  

Таким образом, на данный момент не существует единого шаблона ARM, который работал бы для обоих сценариев.

Привет Эллиотт

По второму пункту я хотел сказать, что WEBSITE_CONTENTSHARE следует определять как параметр приложения, но не делать его настройкой слота развертывания.
Таким образом, у него не должно быть галочки, как показано ниже:

[cid: [email protected]]

От: Эллиотт Хамаи [email protected]
Отправлено: 22 июнь 2020 18:38
Кому: MicrosoftDocs / azure-docs [email protected]
Копия: Оуайн Винтербоун (ITCS - персонал) [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [MicrosoftDocs / azure-docs] WEBSITE_CONTENTSHARE не следует использовать для получения поддержки (# 36458)

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

@OwainWin https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOwainWin&data=02%7C01%7Co.winterbone%40uea.ac.ac.uk%7Cafedec71710f8c07d6d8c7d8c7d8c7d8c7d7d7d8d8d7d7d7d7d7d7d7d8d8d7d7d8d6d8d8d8d6d6 % 7C0% 7C637284442665654874 & sdata = x3m7KNp6hoQJMCqfb4aEUSNnmE6E5N7geDa8Vu7AUaw% 3D & reserved = 0 - Извините, меня смущает ваш вопрос. Вы спросили, следует или не следует включать WEBSITE_CONTENTSHARE.

Я считаю, что у вас должны быть определены WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE как в производственном, так и в промежуточном слотах.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647674267&data = 02% 7C01% 7Co.winterbone% 40uea.ac.uk% 7Cafedec71775f4f42d84108d816d2f967% 7Cc65f8795ba3d43518a070865e5d8f090% 7C0% 7C0% 7C637284442665664832 & SData = ctK99d4qO2YuIN% 2F07lwuHC0wNut% 2Fx8LjgLd7v55rTAM% 3D & зарезервирован = 0 , или отказаться от https://eur01.safelinks.protection.outlook.com /?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGFS4PEPPJE7NN6RO5D4SSLRX6JGNANCNFSM4IJGDPBQ&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d84108d816d2f967%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284442665664832&sdata=wXaMW%2Fx% 2B5RXDtrfiQgHeZYtpc% 2BhLyI9w6f9ut9NTFjM% 3D & reserved = 0 .

@paulbatum

• При первоначальном создании ресурса через ARM должен быть установлен WEBSITE_CONTENTSHARE. Однако после первоначального создания этот параметр следует опустить в шаблоне ARM (потому что, если он был включен, дальнейшее выполнение шаблона ARM может вызвать неожиданную замену содержимого)

Вы ведь понимаете, что такое нарушение предназначения шаблона ARM, верно?

Такое поведение исправляется, но, вероятно, потребуется 1-2 месяца, чтобы избавиться от него. А пока рекомендации, которыми я поделился выше (где вы устанавливаете его изначально, а затем удаляете из шаблона ARM), применимы.

Какая здесь финальная ожидаемая конфигурация?
Можем ли мы получить объявление об Azure / app-service-announcements с правильной конфигурацией и официальным графиком после того, как все это будет действительно развернуто?

Это большой блокиратор для нас. Нам нужно иметь возможность использовать тот же шаблон ARM для развертывания в новой группе ресурсов, который мы будем использовать для развертывания в существующей группе ресурсов. Мы специально запускаем наши шаблоны ARM в режиме Complete, чтобы предоставить немного больше контекста.

Прямо сейчас наш шаблон ARM выглядит примерно так:

{
  "apiVersion": "2016-08-01",
  "type": "Microsoft.Web/sites",
  "name": "[variables('functionAppName')]",
  "location": "[variables('defaultLocation')]",
  "kind": "functionapp",
  "properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  },
  "resources": [
    {
      "name": "slotconfignames",
      "type": "config",
      "apiVersion": "2016-08-01",
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "appSettingNames": [
          "SomeSlotSpecificSetting"
        ]
      }
    },
    {
      "name": "staging",
      "type": "slots",
      "apiVersion": "2016-08-01",
      "location": "[variables('defaultLocation')]",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "siteConfig": {
          "appSettings": [
            {
              "name": "AzureWebJobsStorage",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "AzureWebJobsDashboard",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "SomeSetting__Foo",
              "value": "[parameters('someSettings').foo]"
            },
            {
              "name": "SomeSetting__Bar",
              "value": "[parameters('someSettings').bar]"
            },
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },
            {
              "name": "FUNCTIONS_EXTENSION_VERSION",
              "value": "~3"
            },
            {
              "name": "FUNCTIONS_WORKER_RUNTIME",
              "value": "dotnet"
            },
            {
              "name": "SomeSlotSpecificSetting",
              "value": "abc 123"
            },
            {
              "name": "WEBSITE_RUN_FROM_PACKAGE",
              "value": "1"
            }
          ]
        }
      }
    }
  ],
  "dependsOn": [
    "[resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName'))]",
    "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  ]
}

Обратите внимание на следующие детали: Мы указываем нашу конфигурацию _в промежуточном слоте_, а не в производственном слоте. Это позволяет нам сначала развернуть новые настройки (и обновления существующих) в промежуточном слоте. Итак, наш конвейер DevOps делает следующее:

• Шаг 1) Разверните шаблон ARM в группе ресурсов
• Шаг 2) Разверните приложение с функциями в промежуточный слот
• Шаг 3) Запустите дымовые тесты против промежуточного слота.
• Шаг 4) Поменяйте местами промежуточные и производственные слоты.

Проблема, однако, в том, что поскольку WEBSITE_CONTENTSHARE устанавливается внутри шаблона ARM, производственный слот и промежуточный слот немедленно принимают новую версию приложения сразу после шага 2 (до того, как произойдет свопинг). Я считаю, что это то, о чем люди говорят, когда говорят «непреднамеренная операция подкачки».

Мы _НЕ_ НЕ хотим устанавливать настройки производственного слота в нашем шаблоне ARM, и мы _НЕ_ НЕ хотим, чтобы какие-либо настройки производственного слота были удалены в результате работы нашего шаблона ARM. Принцип работы развертывания шаблона ARM в режиме Complete состоит в том, что если мы укажем какие-либо настройки для производственного слота, то все настройки, которые не указаны явно, удаляются автоматически.

Надеюсь, все это имеет смысл. В настоящее время мы пытаемся удалить WEBSITE_CONTENTSHARE из нашего шаблона ARM в надежде, что среда выполнения будет генерировать значение во всех сценариях и больше не будет приводить к «непреднамеренным свопам».

Привет всем, я являюсь основным разработчиком слотов развертывания, и я отвечу на ваши вопросы относительно настройки WEBSITE_CONTENTSHARE и WEBSITE_CONTENTAZUREFILECONNECTIONSTRING:

Вот официальное руководство:

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

WEBSITE_CONTENTSHARE:

• Теперь это можно полностью исключить из шаблонов ARM для функций SKU потребления, которые будут автоматически генерировать поле и избегать непреднамеренных свопов. Это означает, что вы можете использовать один и тот же шаблон для создания и обновления в дальнейшем.

• К сожалению, мы обнаружили, что это автоматическое создание WEBSITE_CONTENTSHARE не было учтено для лыж Elastic Premium, поэтому проблема включения его во время создания и опускания во время обновлений все еще не решена. Исправление для этого в настоящее время развертывается и достигло половины нашего парка. Он должен быть полностью развернут в течение следующих 2 недель, после чего руководство будет одинаковым для SKUS, а WEBSITE_CONTENTSHARE можно полностью опустить.

Надеюсь, это решит некоторые из ваших проблем!

@shubDhond Большое спасибо. Можем ли мы получить официальное обновление документации?

@shubDhond для планов потребления Windows, если я предоставляю только WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, я получаю сообщение об ошибке при развертывании шаблона руки, в котором говорится, что WEBSITE_CONTENTSHARE отсутствует.
Мне не нужны слоты. Если опустить оба, развертывание будет выполнено, но я получаю предупреждение «хранилище не настроено. Масштабирование функции будет ограничено».

Каковы рекомендации по планам потребления в отношении этих двух параметров, которые я использую для плана потребления Windows .net core?

Ditto! Я тоже получаю эту ошибку. Когда это будет исправлено?

У меня такая же проблема с потреблением и гибким планом, это вызывает у нас много проблем с автоматическим развертыванием.

Мне удалось опустить WEBSITE_CONTENTSHARE для Premium при развертывании настроек непосредственно в свойствах Microsoft.Web/sites (siteConfig, appSettings), но не при указании настроек как отдельного ресурса с помощью Microsoft.Web/sites/config с "type": "config" .

@shubDhond Эта проблема точно не исправлена. В плане потребления Windows, если вы развертываете шаблон только с WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и без WEBSITE_CONTENTSHARE, вы получите ошибку «WEBSITE_CONTENTSHARE is missing».

Попытка использовать задачи развертывания службы приложений в Azure DevOps и установка только WEBSITE_CONTENTAZUREFILECONNECTIONSTRING также приведет к ошибке HTTP 400.

Автоматизация приложений функций Azure в плане потребления в настоящее время полностью нарушена.

Имеет ту же проблему, что и

Мы также сталкиваемся с той же проблемой, что и @clawrenceks.
Мы также не можем установить только WEBSITE_CONTENTAZUREFILECONNECTIONSTRING без WEBSITE_CONTENTSHARE через портал Azure. У нас также WEBSITE_RUN_FROM_PACKAGE установлено в 1.

Я также не уверен, как это будет работать, если у вас установлен режим развертывания шаблона ARM на Complete ? Не удалит ли созданный параметр приложения WEBSITE_CONTENTSHARE ?

Как и большинство, мы тоже потерялись.

Теперь у меня есть шаблон ARM, успешно развертывающий мое приложение-функцию в План потребления Windows. При развертывании сообщение Storage is not configured, Function scaling will be limited. Click to learn more больше не отображается. Свопы слотов также работают должным образом.

Мои основные выводы из этого процесса:

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

Ключевым моментом является наличие WEBSITE_CONTENTAZUREFILECONNECTIONSTRING как части создания ресурса. При использовании ARM я пришел к выводу, что он должен быть развернут как параметр приложения во время развертывания основной службы приложений с типом ресурса Microsoft.Web/sites . Наличие в шаблоне ARM отдельного типа ресурса Microsoft.Web/sites/config для развертывания настроек приложения не сработает.

Я не включаю параметр WEBSITE_CONTENTSHARE в свой шаблон ARM. Это создается средой выполнения при развертывании моего шаблона ARM. Это признак того, что развертывание работает хорошо. Благодаря подходу, описанному здесь, я могу развернуть исходные ресурсы, а затем повторно развернуть шаблон несколько раз, не получая ошибок, связанных с параметром WEBSITE_CONTENTSHARE .

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

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

2) Настройки приложения в шаблоне ARM всегда применяются к промежуточному слоту. Затем они передаются в производство с помощью слота подкачки.

Для достижения вышеуказанного параметры appSettings для производственного сайта в моем шаблоне ARM являются условными. Если ресурс не существует, я развертываю полный набор настроек приложения в шаблоне (чтобы убедиться, что служба приложения создана правильно). Если ресурс уже был создан, я передаю значение NULL для параметров приложения. При развертывании это сохраняет настройки приложения, которые уже существуют для производственного сайта.

Я тоже в полном замешательстве. Если для планов потребления требуется WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, но его нельзя настроить для привязки к слоту, как я должен переключаться между промежуточным и производственным слотами, когда я хочу, чтобы каждый из них работал с другой учетной записью хранения? Это было возможно с веб-приложениями навсегда и кажется очень распространенным вариантом использования. Насколько я могу судить, слоты приложений с функцией обмена полностью сломаны / непригодны для использования, пока это не будет исправлено. Хотел бы, чтобы кто-нибудь сказал мне, почему / как я ошибаюсь! Я знаю, что исходная проблема связана с шаблонами ARM, но это кажется гораздо более широкой проблемой.

Та же проблема с планом Elastic Premium. Развертывание в слот рабочей области того же шаблона ARM с тем же WEBSITE_CONTENTSHARE приводит к тому, что рабочий слот указывает на те же двоичные файлы, что и слот сцены.
Невозможно развернуть без WEBSITE_CONTENTSHARE вообще, так как я получаю ошибку 2020-09-08T10:15:32.8385428Z ##[debug]Set-AzWebAppSlot : Operation returned an invalid status code 'BadRequest'

Я смущен. Что делать правильно?

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

У вас должны быть определены WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE

или

Если вы используете запуск из zip / package, тогда вам должно быть присвоено значение «WEBSITE_USE_ZIP», «WEBSITE_RUN_FROM_ZIP» или «WEBSITE_RUN_FROM_PACKAGE», отличное от пустого, 0 или 1.

как говорит @ehamai ?

или

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

WEBSITE_CONTENTSHARE:

Теперь это можно полностью исключить из шаблонов ARM для функций SKU потребления, которые будут автоматически генерировать поле и избегать непреднамеренных свопов. Это означает, что вы можете использовать один и тот же шаблон для создания и обновления в дальнейшем.

К сожалению, мы обнаружили, что это автоматическое создание WEBSITE_CONTENTSHARE не было учтено для лыж Elastic Premium, поэтому проблема включения его во время создания и опускания во время обновлений все еще не решена. Исправление для этого в настоящее время развертывается и достигло половины нашего парка. Он должен быть полностью развернут в течение следующих 2 недель, после чего руководство будет одинаковым для SKUS, а WEBSITE_CONTENTSHARE можно полностью опустить.

Надеюсь, это решит некоторые из ваших проблем!

как говорит @shubDhond ?

Я получаю сообщение об ошибке, если у меня есть лазурная функция в плане потребления без WEBSITE_CONTENTSHARE (на самом деле производственный слот вообще не имеет настроек приложения) в любом слоте и i:

1. развернуть ARM в промежуточный слот
2. поменять местами
3. повторно развернуть в промежуточный слот

Затем он сообщает мне, что мне нужен WEBSITE_CONTENTSHARE. Это похоже на то, что он не может генерировать долю для старого производственного слота. Я не пытался удалить WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, потому что этот поток говорит не делать этого, за исключением @ehamai , который сообщает мне, что я могу это сделать, если я сделаю «WEBSITE_RUN_FROM_PACKAGE».

Забавно то, что у меня есть функция, работающая с этой настройкой, но со средой выполнения ~ 2 вместо ~ 3, и она работает. Есть проблема с ~ 3 и слотами развертывания?
Это очень сбивает с толку.

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

переназначить: @mattchenderson

Есть новости по этому поводу?

Служба поддержки Microsoft также посоветовала нам установить свойство «WEBSITE_CONTENTSHARE». Когда невозможно установить его как настройку слота, это довольно проблематично для наших конвейеров сборки и шаблонов ARM. Пожалуйста посоветуй!

Я тоже согласен. Пришло время объяснить, как здесь использовать слоты!

Я также согласен, эта ветка была запущена более 15 месяцев назад, и до сих пор нет стабильного разрешения.
Мы не можем использовать слоты, пока это не будет должным образом решено с помощью надежного решения. Слоты - это фантастическая функция, но они должны быть надежными.

Всем привет,

Крайне извините за задержку ответа, этот поток не отслеживался так хорошо, как должен.

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

В настоящее время API работает следующим образом: при создании сайта (ресурс «Microsoft.Web / sites»), если вы предоставите WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, а не WEBSITE_CONTENTSHARE, для вас будет сгенерирован общий доступ к контенту. Однако при обновлении существующего ресурса «Microsoft.Web / sites» или ресурса «Microsoft.Web / sites / config» API проверяет, есть ли уже значение для WEBSITE_CONTENTSHARE для приложения и его нет. , это вызывает ошибку.

Я предполагаю, что это было сделано для защиты от клиентов, непреднамеренно стирающих свой контент при переключении на файлы azure, в случае, если они предоставляют WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, и мы генерируем для них новый WEBSITE_CONTENTSHARE (по сути стирая их контент, поскольку этот общий ресурс будет новым). Это намного безопаснее при создании сайта, потому что сайт в любом случае будет запускаться с чистого листа, и мы не рискуем стереть ваш контент.

Я могу полностью понять путаницу для всех вас, желающих использовать лазурные файлы. Мне нужно будет подумать, как лучше всего решить эту проблему, сохранив при этом безопасность наших операций обновления от удаления вашего контента. Что касается руководства для всех вас, у кого не настроены файлы azure и которые хотят выполнить переключение, вам необходимо предоставить WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE для первоначального переключения, а затем руководство будет таким же, чтобы исключить WEBSITE_CONTENTSHARE из вашего шаблон после этого.

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

@shubDhond, поэтому нам нужно развернуть параметры приложения строки подключения и совместного использования содержимого при первом развертывании в производственный слот, но не при развертывании после этого. Есть ли способ сделать это автоматически? Как определить, был ли ресурс развернут через ARM? Или нам нужно вручную передать эту информацию в ARM (fx через параметр, который сообщает, первое ли это развертывание?

@mslot, к сожалению, я не думаю, что можно сказать в шаблоне, существует ли ресурс уже или нет, но это должно быть возможно с этим (https://docs.microsoft.com/en-us/azure/azure-resource- manager / templates / template-tutorial-use-conditions) в сочетании с параметром, переданным в шаблон, который сообщает ему, настроен ли уже сайт для файлов Azure. Это можно определить, получив сайт и посмотрев, есть ли в настройках приложения WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE.

@mslot, к сожалению, я не думаю, что можно сказать в шаблоне, существует ли ресурс уже или нет, но это должно быть возможно с этим (https://docs.microsoft.com/en-us/azure/azure-resource- manager / templates / template-tutorial-use-conditions) в сочетании с параметром, переданным в шаблон, который сообщает ему, настроен ли уже сайт для файлов Azure. Это можно определить, получив сайт и посмотрев, есть ли в настройках приложения WEBSITE_CONTENTAZUREFILECONNECTIONSTRING и WEBSITE_CONTENTSHARE.

Я очень надеюсь, что это скоро исправят. Это делает бесполезным использование слотов в моем рабочем процессе. Он должен быть полностью автоматическим. На мой взгляд, это решение - обходной путь, и его не имеет смысла вводить, когда оно работает для веб-приложений, потому что оно сильно расходится в том, что должно работать так же, как введение «черной магии» для других, приходящих в проект.

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

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

@shubDhond Я не совсем понимаю "часть" файлов Azure. Я развертываю свой проект функций Azure с помощью Azure DevOps, сначала создавая слот развертывания, развертывая его, а затем меняя местами. Я использую метод развертывания «RunFromPackage», и он, похоже, не работает при использовании классического StorageAccount. Я НЕ использую файлы Azure, и, похоже, у меня такая же проблема, связанная с параметром WEBSITES_CONTENTSHARE для двух слотов.

Привет, @cannehag, не могли бы вы открыть для этого новый выпуск? Может произойти странное поведение, когда параметр приложения RunFromPackage помечен как липкий, вызывая симптомы, аналогичные описанным здесь. Я бы предложил новую проблему, чтобы мы не добавляли здесь путаницы, поскольку проблемы, скорее всего, не связаны между собой.