@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）

マーケットプレイスから関数テンプレートをエクスポートすると（最後のページのテンプレートをエクスポート）、標準のアプリ設定としてWEBSITE_CONTENTSHAREを取得します。 これを使用すると、次のような状況が発生する可能性があります。

1）ARMテンプレートをデプロイし、2つのスロットを持つ空の関数を取得します
2）ステージングスロットにデプロイします
3）コンテンツを本番環境で利用できるように交換します
4）ARMテンプレートが再デプロイされ、アプリ設定が再適用されるときの意図しないスワップ（これは、appsettingsリソースが常にWEBSITE_CONTENTSHARE設定を上書きおよびリセットするため、増分ARMデプロイメント中にも発生します）
5）デプロイメントルーチンは、新しいコードをステージングスロットにデプロイし、本番スロットは以前のバージョンを含むのではなく空になりました。 私たちの生産関数は「意図せずに」ダウンしています

この特定のケースの顧客は、この記事を指摘しましたhttps://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/

これは、動作を修正するために、設定をスロット設定として設定する必要があることを示しています。 これは私のテストの動作を修正しますが、動作しないはずなので、間違っているようです。

以下は私のテストで起こったことの表です。 （スロット設定後）

私の（そして顧客の）認識は、スロットはもうまったく交換すべきではないということですが、記事で説明されているように、それでもとにかく機能します。

私もこれを社内で提起しましたが、アプリの設定を変更したときに一貫性のない動作が見られました。 （したがって、これが私のテストグリッドで強調表示されている理由）それをテストしている同僚の場合、アプリ設定を更新すると、スロット設定が再適用され、意図しないスワップが再び発生します。

そしてついに（長い返答で申し訳ありませんが）、結果が「設定をまったく設定しない」というサポートケースを提起することになりました。
私の個人的なテストでは、これで問題が解決することが示されましたが、これを確認するためのガイダンスがドキュメントにないため、このアイテムを提起したのはなぜですか。

お役に立てれば。
不明な点があれば教えてください。

@danielstockerは決定的に重要な情報であり、特にスロットとスワッピングが関数とWebジョブを備えた従来のWebアプリでどのように機能しているかを理解するために重要です。
また、ここでは「WEBSITE_CONTENTSHARE」が重要な役割を果たしているにもかかわらず、これはスロットのドキュメントでも説明されていません。 ステップ4には、それを表す

こんにちは@ ggirard07そして私の

@ ggirard07 @ ggailey777 @ mike-urnun-msft

この動作に関するドキュメントを明確にするために、より多くの情報が必要ですか？ このシナリオに関する公式ガイダンスがわからないため、ファンクションスロットの使用を停止することを検討しているお客様と協力しています。

ご協力いただきありがとうございます

@danielstockerこれに関連するドキュメントの問題に対処すると思われることを明確にするために、次のようにします。

• ここからWEBSITE_CONTENTSHAREデプロイメント設定を削除します。
• WEBSITE_CONTENTSHAREはランタイムによってのみ設定されるべきであるという注記を参照記事に追加してください。

それで十分だと思いますか？

cc。 @mattchenderson

こんにちは@ ggailey777
はい、それは良い解決策になると思います

WEBSITE_CONTENTSHAREは、ARMを使用して関数アプリをデプロイするときに必要なアプリ設定の1つではありませんか？

WEBSITE_CONTENTSHAREは、ARMを使用して関数アプリをデプロイするときに必要なアプリ設定の1つではありませんか？

それが適用されていない場合、ランタイムはあなたのためにそれを生成すると思います。

消費計画を備えたARMと、appsettingsという名前のセクション_Microsoft.Web / sites / config_と次のプロパティを備えた関数アプリをデプロイしました。

• 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も削除した後、展開はエラーなしで完了しました。 したがって、これら2つの設定の間にはいくつかの必要な関係があるようです。
この展開は成功しましたが、関数（パッケージ）が物理的に展開されているかどうか（そして、このケースがそもそも有効であるかどうか）を迷わせました。

@tjgalamaが説明した正確な動作を

関数アプリにはタイマートリガー関数も含まれているため、提案どおりにAzureWebJobsStorage設定を指定します。ランタイムが（現在は暗黙的な） WEBSITE_CONTENTAZUREFILECONNECTIONSTRING同じ接続文字列を使用することを推測/期待していました。 azure-webjobs-hostsとazure-webjobs-secrets blobコンテナーが表示されますが、ファイル共有は存在しません。

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 Functionsに移植しており、本番環境に展開する前にこれを把握したいので、この点についてある程度明確にしたいと思います。

いくつかのアドバイスに従って、スロット設定として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が_必須_であることを示しています： 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両方を削除し、良好な結果を得ることで検証しました。関数アプリにはこれら2つの設定がまったくなく（ランタイムによって割り当てられていません）、どのストレージアカウントでもファイル共有を使用しないでください（少なくとも私たちが見ることができるもの）。

したがって、覚えておくべきことの1つは、webapp / functionアプリのファイルシステムが次のようになっていることです。

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

run from packageを使用すると、このツリーの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に関するアナウンスを取得できますか？

こんにちは、これについて何か進展があったかどうかはわかりません。 WEBSITE_CONTENTSHAREフラグ付きのARMテンプレートを使用するのにまだ苦労しています。 @paulbatum ARMテンプレートから構成を省略するにはどうすればよいですか？ それを機能させるには、ステップを完全に無効にする必要がありました。

@gustavobmichel申し訳ありませんが、あなたの質問がわかりません。 ARMテンプレートはJSONであり、必要に応じて編集します。 これは、appsettingsセクションの一部として表示されます。例：

          "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テンプレートからプログラムで設定を省略することについておっしゃっていたと思いましたので、それが私の質問でした。

他の人が述べたように、私もこれら2つの設定が必要だと思ったので、ARMテンプレートから2つを削除しました。

ゼロダウンタイムでこの機能をテストするために、最小限のインフラストラクチャで簡単なテストを作成してテストしました。 リソースグループからすべてのリソースを削除し、リリースパイプラインの一部として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テンプレートからプログラムで設定を省略することについておっしゃっていたと思いましたので、それが私の質問でした。

他の人が述べたように、私もこれら2つの設定が必要だと思ったので、ARMテンプレートから2つを削除しました。

ゼロダウンタイムでこの機能をテストするために、最小限のインフラストラクチャで簡単なテストを作成してテストしました。 リソースグループからすべてのリソースを削除し、リリースパイプラインの一部として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を追加した後、ストレージへのアクセスに問題があります。 これらの2つの構成をfunctionappとslotの両方に追加しましたか？

正確なエラーは次のとおりです。AzureFunctionsランタイムに到達できません。

それは、最初の展開を行ってから、新しいバージョンの展開を試みた後です。

ymlファイルも追加しました。
yml file.txt
deploy.txt

ARMテンプレートも更新しました。

私の関数は、WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGとWEBSITE_RUN_FROM_PACKAGEを追加した後、ストレージへのアクセスに問題があります。 これらの2つの構成をfunctionappとslotの両方に追加しましたか？

正確なエラーは次のとおりです。AzureFunctionsランタイムに到達できません。

それは、最初の展開を行ってから、新しいバージョンの展開を試みた後です。

ymlファイルも追加しました。
yml file.txt
deploy.txt

ARMテンプレートも更新しました。

私は両方にそれを持っています。 実際、私は自分のプロダクションスロットに何も持っておらず、ステージングからすべてを交換しています。 これは、WEBSITE_CONTENTSHAREを定義するとき、またはコードがWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGに存在する正しいストレージアカウントを指していないときに見られました。 WEBSITE_CONTENTSHAREでどこにも何も向ける必要はありません。 実際、環境変数にWEBSITE_CONTENTSHAREを追加したために、あなたが参照しているエラーを見たと思います。 定義していないことを確認してください。

こんにちは@mslot 、問題は私の展開にあったと思います。 このスレッドhttps://stackoverflow.com/a/56205917でAzureDevOpsでの設定について読んだので、zipDeployに設定していました。 標準展開に変更した後、すべてが機能しているようです。 ご協力いただきありがとうございます。

その動作は修正されつつありますが、それが解消されるまでにはおそらく1〜2か月かかります。

この問題に関する更新はありますか？ 消費とプレミアムの動作は調整されましたか？ 最初のARMデプロイメントとその後のデプロイメントからWEBSITE_CONTENTSHAREを省略できますか？ これはステージングスロットにどのように影響しますか？ リンクする更新されたドキュメントまたはガイダンスはありますか？

私たちは基本的に@thomaswilkinや@mslotと同じアプローチを採用しましたが、実験と試行錯誤を繰り返しました。 WEBSITE_CONTENTSHAREが設定されていないため、ランタイムがファイルの場所をどのように認識している

やあ。 どうすればいいのかわからないけど、一緒にデプロイできないようです
WEBSITE_CONTENTSHAREなしのWEBSITE_CONTENTAZUREFILECONNECTIONSTRING。 ポータルを介しても、構成を設定しようとしたときにエラーが発生しました。
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.プレミアムプランを実行しています。 関数アプリをどのように構成する必要があるかについての更新または公式ガイドラインはありますか？

プレミアムプラン（消費プランについては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という警告メッセージも表示されます。 Haventには、WebサイトWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGまたはWEBSITE_CONTENTSHAREがありました。 Korkiakが言及しているように、更新された、または公式のガイドラインはありますか？

最近、4週間前にデプロイされた既存のAzure関数について、Azureポータルに「ストレージが構成されていません。関数のスケーリングが制限されます。クリックして詳細を確認してください」というメッセージが表示されるようになりました。 WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGもWEBSITE_CONTENTSHAREも使用したことがなく、これまで正常に機能していました。

@paulbatum 「ストレージが構成されていないため、関数のスケーリングが制限されます」というメッセージがポータルに表示され始めたため、この問題は過去数日間でより多くのアクティビティを取得しているようです。 これらすべてを構成する正しい方法に関する新しいガイダンスはありますか？

以前は正常に機能していたテンプレートを使用して、数か月ぶりに新しいFunction Appをデプロイするときに、上記のように「WEBSITE_CONTENTSHARE」がスロット設定エラーになることはありません。
テンプレートにはスロット設定として「WEBSITE_CONTENTSHARE」があり、上記でも言及されている次の記事に従って、関数アプリと展開スロットアプリ設定の両方で定義されています。
https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
このスレッドを読むと、これがスロット設定として削除され、設定「WEBSITE_CONTENTSHARE」のさまざまな組み合わせを試しましたが、他のスレッドと同じ動作が得られません。 以下のようにエラーなしでデプロイできます。

• FunctionAppとDeploymentSlotの両方に「WEBSITE_CONTENTSHARE」を指定します
• 関数アプリにのみ「WEBSITE_CONTENTSHARE」を指定します

テンプレートで「WEBSITE_CONTENTSHARE」をまったく指定しないと、「必須パラメーターWEBSITE_CONTENTSHAREがありません」というエラーが表示されます。

したがって、この現在の動作では本番環境にデプロイできないため、実際の設定を更新してください。

みなさん、ここで混乱してすみません。 構成でスケーリングの問題が発生する可能性がある場合は、Azure Portalに通知させることで賢くしようとしていましたが、ロジックを間違えたため、警告が誤って表示される可能性があります。 現在修正に取り組んでいますが、それまでの間、アプリでスケーリングの問題が発生する可能性があるかどうかを検証する方法は次のとおりです。

弾力性のあるプレミアムまたは消費で実行している場合は、次のいずれかの基準を満たす必要があります。

1. WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGとWEBSITE_CONTENTSHAREを定義しておく必要があります

また

1. run from zip / packageを使用している場合は、「WEBSITE_USE_ZIP」、「WEBSITE_RUN_FROM_ZIP」、または「WEBSITE_RUN_FROM_PACKAGE」を空、0、または1以外に設定する必要があります。

来週までにこれを修正する必要があります。

@ehamaiに感謝しないものであることを想定：https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from -デプロイメントパッケージ）

こんにちはエリオット、非常に迅速な返信に感謝します。

明確にするために：
ARMテンプレートから消費プランにデプロイし、デプロイメントスロットを使用しているが、zip /パッケージを使用していない場合

• ProductionスロットとStagingスロットの両方でWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGとWEBSITE_CONTENTSHAREの両方を定義する必要があります。

• WEBSITE_CONTENTSHAREをどちらのスロットの展開スロット設定としても定義しないでください。

よろしくお願いします

オウェイン

差出人：エリオットハマイ[email protected]
送信日：2020年6月22日17:31
宛先：MicrosoftDocs / azure-docs [email protected]
Cc：Owain Winterbone（ ITCS-スタッフ） [email protected]
件名：Re：[MicrosoftDocs / azure-docs] WEBSITE_CONTENTSHAREは、サポートのために使用しないでください（＃36458）

警告：このメールはUEAシステムの外部からのものです。 送信者からの期待があり、コンテンツが安全であることがわかっている場合を除いて、リンクや添付ファイルをクリックしないでください。

みなさん、ここで混乱してすみません。 構成でスケーリングの問題が発生する可能性がある場合は、Azure Portalに通知させることで賢くしようとしていましたが、ロジックを間違えたため、警告が誤って表示される可能性があります。 現在修正に取り組んでいますが、それまでの間、アプリでスケーリングの問題が発生する可能性があるかどうかを検証する方法は次のとおりです。

弾力性のあるプレミアムまたは消費で実行している場合は、次のいずれかの基準を満たす必要があります。

1. WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGとWEBSITE_CONTENTSHAREを定義しておく必要があります

また

1. run from 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 = 0.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＆データ= 0.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が欠落しているため失敗します。
  
  
  • 両方の値を指定すると、機能します
  
  
• 既存のリソースにデプロイする場合
  
  
  
  • どちらの設定も指定しない場合、展開は成功しますが、ストレージが構成されていないことになり、関数のスケーリングが制限されますというメッセージが表示されます
  
  
  • WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGのみを指定すると、WEBSITE_CONTENTSHAREが必要であると想定されていても、成功します（その後、正常に機能しているように見えます）。
  
  
  • 両方の値を指定すると、ARM部分が失敗しないという点で「機能」しますが、複数の再起動の問題が発生し、上記のMSガイダンスでは、更新時にWEBSITE_CONTENTSHAREを設定しません。
  
  

したがって、現時点では、両方のシナリオで機能する単一のARMテンプレートを作成する方法はないようです。

こんにちはエリオット

2番目のポイントで言いたかったのは、WEBSITE_CONTENTSHAREはアプリケーション設定として定義する必要がありますが、展開スロット設定にするべきではないということです。
したがって、以下のようなチェックマークは付けないでください。

[cid：[email protected]]

差出人：エリオットハマイ[email protected]
送信日：2020年6月22日18:38
宛先：MicrosoftDocs / azure-docs [email protected]
Cc：Owain Winterbone（ ITCS-スタッフ） @ 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.uk%7Cafedec71775f4f42d84108d816d2f967%7Cc65f879 ％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 = 0.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テンプレートを完全モードで実行して、もう少しコンテキストを提供できるようにします。

現在、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テンプレートを展開する方法は、実稼働スロットに設定を指定すると、明示的に指定されていないすべての設定が自動的に削除されることです。

これがすべて理にかなっていることを願っています。 現在、ランタイムがすべてのシナリオで値を生成し、「意図しないスワップ」を引き起こさないことを期待して、ARMテンプレートからWEBSITE_CONTENTSHAREを削除しようとしています。

みなさん、こんにちは。私はデプロイメントスロットの主要な開発者です。WEBSITE_CONTENTSHAREとWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGの設定に関する懸念に対処します。

公式ガイダンスは次のとおりです。

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING：これは、コンテンツの保存にAzureファイルを使用していることをアプリサービスに通知するため、常に設定する必要があります。

WEBSITE_CONTENTSHARE：

• これは、フィールドを自動生成し、意図しないスワップを回避するConsumptionsku関数のARMテンプレートから完全に省略できるようになりました。 これは、作成とその後の更新に同じテンプレートを使用できることを意味します。

• 残念ながら、このWEBSITE_CONTENTSHAREの自動生成は、Elastic Premiumスキーでは見落とされていたため、作成時に含め、更新時に省略しなければならないという問題が残っています。 この修正は現在展開中であり、フリートの半分に達しています。 今後2週間で完全に展開され、その後はskusのガイダンスは同じになり、WEBSITE_CONTENTSHAREは完全に省略できます。

それがあなたの懸念のいくつかに対処することを願っています！

@shubDhondありがとうございます。 ドキュメントの公式アップデートを入手できますか？

WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGのみを指定した場合、Windows消費プランの@shubDhondは、ARMテンプレートの展開を介してWEBSITE_CONTENTSHAREが欠落しているというエラーが発生します。
スロットを使う必要はありません。 省略した場合、両方の展開は実行されますが、「ストレージが構成されていません。関数のスケーリングが制限されます」という警告が表示されます。

.net Core Windowsの消費プランを使用している2つのパラメーターについて、消費プランに関するガイダンスは何ですか？

同上！ このエラーも発生します。 これはいつ修正されますか？

消費と弾力性のある計画についても同じ問題があります。自動展開で多くの問題が発生しています。

Microsoft.Web/sitesプロパティ（siteConfig、appSettings）に直接設定をデプロイする場合、PremiumのWEBSITE_CONTENTSHAREを省略して成功しましたが、 Microsoft.Web/sites/configを使用して個別のリソースとして設定を指定する場合は成功しませんでした。 "type": "config" 。

@shubDhondこの問題は完全に修正されていません。 Windows消費プランでは、WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGのみを含み、WEBSITE_CONTENTSHAREを含まないテンプレートを展開すると、「WEBSITE_CONTENTSHAREがありません」というエラーが発生します。

AzureDevOpsでAppServiceデプロイメントタスクを使用しようとし、WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGのみを設定しようとすると、HTTP400エラーも生成されます。

現在、消費プランでのAzureFunctionアプリの自動化は完全に機能していません。

@clawrenceksと同じ問題があり

@clawrenceksと同じ問題が発生しています。
また、AzureポータルからWEBSITE_CONTENTSHAREなしでWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGのみを設定することはできません。 また、 WEBSITE_RUN_FROM_PACKAGEを1に設定しています。

ARMテンプレートの展開モードをComplete設定した場合、これがどのように機能するかもわかりません。 生成されたアプリ設定WEBSITE_CONTENTSHAREは削除されませんか？

ほとんどのように、私たちも失われています。

これで、ARMテンプレートが関数アプリをWindows消費プランに正常にデプロイできました。 デプロイされると、メッセージStorage is not configured, Function scaling will be limited. Click to learn moreは表示されなくなります。 スロットスワップも期待どおりに機能しています。

このプロセスからの私の主な発見は次のとおりです。

現在、 WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGおよびWEBSITE_CONTENTSHAREアプリケーション設定のないAzure Functionアプリを使用している場合、これを修正する唯一の方法は、アプリを再デプロイして、 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING確認することだと思います。

リソース作成の一部としてWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGを配置することが重要です。 ARMを使用する場合、メインのアプリサービスのデプロイ中に、リソースタイプがMicrosoft.Web/sitesアプリ設定としてARMをデプロイする必要があることがわかりました。 アプリケーション設定をデプロイするためにARMテンプレートにMicrosoft.Web/sites/config個別のリソースタイプがあると機能しません。

ARMテンプレートにWEBSITE_CONTENTSHARE設定を含めていません。 これは、ARMテンプレートがデプロイされたときにランタイムによって作成されます。 これは、展開が正常に機能していることを示しています。 ここで説明するアプローチを使用すると、 WEBSITE_CONTENTSHARE設定に関連するエラーを受け取ることなく、初期リソースをデプロイしてから、テンプレートを複数回再デプロイできます。

私にとってのもう1つの重要な要件は、本番サイトのアプリケーション設定は、最初のリソース作成時にのみ展開する必要があるということでした。 新しい（将来の）アプリケーション設定を本番サイトに取り込む唯一の方法は、スロットスワップを使用することです。 これを実現するために、ARMテンプレートにいくつかのロジックを追加して以下を処理しました。

1）ARMテンプレートのアプリ設定は、最初のサイト作成時に本番サイトにのみデプロイされ、将来のデプロイの一部として本番サイトに追加されることはありません。

2）ARMテンプレートのアプリ設定は、常にステージングスロットに適用されます。 次に、スワップスロットを使用して本番環境にスワップされます。

上記を実現するために、ARMテンプレートの本番サイトのappSettingsは条件付きです。 リソースが存在しない場合は、アプリ設定のフルセットをテンプレートにデプロイします（アプリサービスが正しく作成されるようにするため）。 リソースがすでに作成されている場合は、アプリの設定にnullを渡します。 デプロイすると、本番サイトにすでに配置されているアプリ設定が保持されます。

私も完全に混乱しています。 消費プランにWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGが必要であるが、スロットに固定するように構成できない場合、それぞれを異なるストレージアカウントで実行するステージングスロットと本番スロットをどのように交換する必要がありますか？ これはWebアプリで永遠に可能であり、非常に一般的なユースケースのようです。 私の知る限り、スワップ機能のアプリスロットは完全に壊れているか、これが修正されるまで使用できません。 誰かが私に理由/私が間違っている方法を教えてくれるのが大好きです！ 元の問題がARMテンプレートを参照していることは知っていますが、これははるかに広範な問題のようです。

ElasticPremiumプランでも同じ問題。 同じWEBSITE_CONTENTSHAREを使用して同じARMテンプレートをステージスロットにデプロイすると、プロダクションスロットはステージスロットと同じバイナリを指すようになります。
2020-09-08T10:15:32.8385428Z ##[debug]Set-AzWebAppSlot : Operation returned an invalid status code 'BadRequest'エラーが発生するため、WEBSITE_CONTENTSHAREなしではデプロイできません

私は混乱しています。 正しいことは何ですか？

弾力性のあるプレミアムまたは消費で実行している場合は、次のいずれかの基準を満たす必要があります。

WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGとWEBSITE_CONTENTSHAREを定義しておく必要があります

また

run from zip / packageを使用している場合は、「WEBSITE_USE_ZIP」、「WEBSITE_RUN_FROM_ZIP」、または「WEBSITE_RUN_FROM_PACKAGE」を空、0、または1以外に設定する必要があります。

@ehamaiが言うように？

また

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING：これは、コンテンツの保存にAzureファイルを使用していることをアプリサービスに通知するため、常に設定する必要があります。

WEBSITE_CONTENTSHARE：

これは、フィールドを自動生成し、意図しないスワップを回避するConsumptionsku関数のARMテンプレートから完全に省略できるようになりました。 これは、作成とその後の更新に同じテンプレートを使用できることを意味します。

残念ながら、このWEBSITE_CONTENTSHAREの自動生成は、Elastic Premiumスキーでは見落とされていたため、作成時に含め、更新時に省略しなければならないという問題が残っています。 この修正は現在展開中であり、フリートの半分に達しています。 今後2週間で完全に展開され、その後はskusのガイダンスは同じになり、WEBSITE_CONTENTSHAREは完全に省略できます。

それがあなたの懸念のいくつかに対処することを願っています！

@shubDhondが言うように？

どちらのスロットにもWEBSITE_CONTENTSHAREがない（実際には本番スロットにはappsettingsがまったくない）消費プランにAzure関数があると、エラーが発生します。

1. ARMをステージングスロットに展開します
2. スワップ
3. ステージングスロットに再デプロイ

次に、WEBSITE_CONTENTSHAREが必要であることが通知されます。 古いプロダクションスロットのシェアを生成できないようなものです。 WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGを削除しようとはしていません。このスレッドは、「WEBSITE_RUN_FROM_PACKAGE」を実行すると実行できることを通知する@ehamaiを除いて、削除しないように指示しているためです。

面白いことに、このセットアップで実行されている関数がありますが、ランタイムは〜3ではなく〜2であり、機能しています。 〜3と展開スロットに問題はありますか？
これは非常に紛らわしいです。

この自発的なスロットスワップが非常に恐ろしいものであっても、とにかく、ここでの定義に従って、ARMに入力するこれらのWEBSITE_変数の両方を作成する必要があるためです。 ポータルのwebapp構成診断ツールにエラーは表示されなくなりました。

再割り当て：@mattchenderson

これに関する更新はありますか？

また、Microsoftのサポートから、「WEBSITE_CONTENTSHARE」プロパティを設定する必要があるとのアドバイスを受けました。 スロット設定として設定できない場合、これはビルドパイプラインとARMテンプレートにとって非常に問題があります。 アドバイスを下さい！

私も同意します。 ここでスロットの使用方法について説明する時が来ました！

また、このスレッドは15か月以上前に開始されたものであり、安定した解決策はまだありません。
信頼できるソリューションでこれが適切に解決されるまで、スロットを使用することはできません。スロットは素晴らしい機能ですが、信頼できる必要があります。

こんにちは、みんな、

ここでの応答の遅延について非常に申し訳ありませんが、このスレッドは監視されているはずのように監視されていませんでした。

混乱に対処するために、上記の@clawrenceksで説明されている動作は

APIが現在機能する方法は、サイトの作成時（ 'Microsoft.Web / sites'リソース）で、WEBSITE_CONTENTSHAREではなくWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGを指定すると、コンテンツ共有が生成されます。 ただし、既存の「Microsoft.Web / sites」リソースまたは「Microsoft.Web / sites / config」リソースの更新時に、APIは、アプリのWEBSITE_CONTENTSHAREの値がすでに存在するかどうか、および存在しないかどうかを確認します。 、エラーをスローします。

これは、顧客がWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGを提供し、新しいWEBSITE_CONTENTSHAREを生成した場合に、紺碧のファイルに切り替えているときに誤ってコンテンツをワイプするのを防ぐためだと思います（この共有は新しいため、基本的にコンテンツをワイプします）。 とにかくサイトは白紙の状態で始まり、コンテンツをワイプするリスクがないため、これはサイトの作成時にはるかに安全です。

ファイルを紺碧にしたい皆さんにとっては、混乱は完全に理解できます。 更新操作でコンテンツがワイプされないようにしながら、これに対処する最善の方法を考える必要があります。 今のところ、Azureファイルが構成されておらず、切り替えを希望するすべてのユーザー向けのガイダンスとして、最初の切り替えにWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGとWEBSITE_CONTENTSHAREの両方を提供する必要があります。その後、ガイダンスは同じで、WEBSITE_CONTENTSHAREを省略します。その後のテンプレート。

更新ケースの処理方法について何か提案があれば、それも大歓迎です！

@shubDhondなので、本番スロットへの最初のデプロイでconnectionstringとcontentshare appsettingsをデプロイする必要がありますが、その後のデプロイではデプロイしません。 これを自動的に行う方法はありますか？ リソースが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があるかどうかを確認することで判断できます。

私はこれがすぐに修正されることを本当に望んでいます。 それは私のワークフローでスロットの使用を役に立たなくします。 完全に自動化する必要があります。 このソリューションは私の目にはハックの回避策であり、プロジェクトに参加する他の人に「黒魔術」を導入するのと同じように機能するはずの何かに分岐するため、Webアプリで機能しているときに導入するのは意味がありません。

これが修正されて使用を開始できるようになることを心から願っています。多くの人がこの機能を使用できなくなっていると思います。

@mslotこれに関するあなたの苦痛を完全に理解しており、この問題をより早く特定できなかったことを

@shubDhondAzureファイルの「一部」がよくわかりません。 最初にデプロイメントスロットを作成し、これにデプロイしてからスワップすることにより、AzureDevOpsを使用してAzureFunctionプロジェクトをデプロイします。 「RunFromPackage」デプロイメントメソッドを使用していますが、従来のStorageAccountを使用している場合は機能しないようです。 Azureファイルを使用しておらず、2つのスロットのWEBSITES_CONTENTSHARE設定に関連して同じ問題が発生しているようです。

こんにちは@cannehagこのための新しい問題を開いて