問題タブ [azure-deployment-slots]

1 つの Premium App Service プランで複数の Web サイトを Azure に移行しようとしています。https://dotnetthoughts.net/deploying-multiple-application-in-webapp/で提供されている手順に従って、1 つの App Service プランで複数のサイトをホストできましたが、デプロイ スロットをどのように利用できるかを理解するのに苦労しています複数のサイト用。App Service プランごとに "Production" スロットが 1 つしかないようです。つまり、Deployment Slot を唯一の Production Slot とのみ交換できます。各 Web サイトに製品スロ​​ットと対応する「テスト」スロットを設定する方法を知っている人はいますか?

AZ PowerShell を使用して、クラシック クラウド サービス パッケージ (Microsoft.ClassicCompute) を Azure デプロイ スロットにデプロイできるかどうかを知りたいです。

Azure で既に作成されているリソース グループ内にクラシック サービスがあります。デプロイされるパッケージは、別のストレージ プロファイル BLOB にアップロードされます。

現在、Web ロールはREST APIを使用してデプロイされています。BLOB 内のパッケージへの適切なパスは、投稿要求の要素で指定されており、これは正常に機能します。

特に、次のように「-PropertyObject」パラメーターを指定して New-AzResource コマンドレットを呼び出すことにより、AZ PowerShell を使用して同じことを実行しようとしています。

しかし、エラーが返されます:

リクエストの内容が無効であり、逆シリアル化できませんでした: 「タイプ 'DeploymentSlotProperties' のオブジェクトでメンバー 'packageUrl' が見つかりませんでした。パス「プロパティ.packageUrl」

オブジェクトから「packageUrl」プロパティを削除してコマンドレットを再度実行すると、別のエラーが表示されます。

デプロイ リクエストにパッケージ リンクがありません。

残念ながら、「-PropertyObject」パラメーターの形式に関する情報は見つかりません。それとも、AZ 経由でパッケージを展開するためのより良い方法があるのでしょうか?

ドキュメントを読むとき: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#swap-operation-steps、ステップ 4、これは指定されています:

カスタム ウォームアップで自動スワップが有効になっている場合は、ソース スロットの各インスタンスでアプリケーション ルート (「/」) に HTTP リクエストを送信して、アプリケーションの開始をトリガーします。

applicationInitialization が指定されていない場合は、各インスタンスのソース スロットのアプリケーション ルートへの HTTP 要求をトリガーします。

インスタンスが HTTP レスポンスを返す場合、ウォームアップされていると見なされます。

1) スワップがルート (またはその他の URL) を呼び出すにはカスタム ウォームアップを有効にする必要がある、または 2) カスタム ウォームアップが有効になっていない場合はルートを呼び出すということですか? 1) または 2) に関係なく: 何も指定されていない場合、返されるすべてのステータス コードは、スロットがウォームアップされていることをスワップ プロセスに伝えますか?

UPDATE ドキュメントを読む方法（https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#swap-operation-steps）：

でも、読み方が間違っているような？

ステージと運用のデプロイ スロットを使用する 2 つの Azure 関数アプリがあります。これら 2 つの Azure Function アプリには、さまざまな API キー、アプリケーションの動作、接続文字列などを定義するために、Application Settings に約 50 ~ のキーと値のペアがあります。

これら 2 つの Azure Function アプリを 5 つの異なる環境 (CI、DEV、QA、STG、PROD) にデプロイしたいと考えています。ARM テンプレートを使用してこれらのリソースを Azure にデプロイすることは、Azure CLI よりも優れた選択肢であると私は信じています。これを実現するために、Azure DevOps リリース パイプラインでタスクを作成します。

ARM テンプレートを保守しやすいものに分解するために、環境ごとに ARM テンプレート パラメーター ファイルを作成したいと考えました。Azure Function のデプロイ ファイルを定義する場合、定義するプロパティの 1 つはsiteConfig オブジェクトです。ここで、nameValuePair オブジェクトを使用して appSettings オブジェクトを定義します。環境ごとに、ステージと運用スロットは異なる API キー、接続文字列、およびアプリケーションの動作を持ちます。私のデプロイ ファイルは、運用スロットとステージ スロットの両方で Azure Function アプリを作成します。デプロイ ファイルでは、appSettings NameValuePair オブジェクトを 2 回指定する必要があります。次に、環境ごとに 5 つの異なるパラメーター ファイルを作成する必要があります。スロットが 2 つあるので、これを 2 倍します。

また、パラメーター ファイルで定義されたすべてのパラメーターは、パラメーター オブジェクトの配置テンプレート ファイルで定義されなければならないというのは本当ですか?

パラメーター ファイルから NameValuePairs を使用してオブジェクトの配列を渡すだけでよいので、デプロイ ファイルの上部と関数アプリの siteConfig.appSettings の下にパラメーターのリスト全体を定義する必要はありませんか?

ここのドキュメントは、文字列の配列または多数のキー:値を持つ単一のオブジェクトのみを提供できることを示しています。ただし、appSettings はオブジェクトの配列であり、各オブジェクトには 3 つのキーと値のペアがあります。

これは、デプロイ ファイルでリソースがどのように見えるかです。パラメーター ファイルからオブジェクトの配列全体を単純に参照したいのですが、デプロイ ファイルの先頭に 50 個のパラメーターすべてを定義するとドキュメントに記載されているようで、Azure CLI またはAzure DevOps タスク。

私の不満に加えて... 5 つの環境すべてと 2 つのスロットを持つ 2 つの Azure 関数に対して 20 個のパラメーター ファイルを作成する必要があるとは信じられません。独自のアプリケーション設定で ARM テンプレートとパラメーター ファイルを使用して、すべての環境とそのデプロイ スロットにデプロイするより良い方法はありますか?

アップデート：

環境固有の ARM テンプレートを作成するためのさまざまな方法を組み合わせることができ、次のような結果になりましたが、いくつかの不便な問題がありました。まず、現在の状況を説明してから、設計に関連する問題を取り上げます。

私の展開テンプレートでは、2 つのパラメーターを定義しました。どうぞ：

私の function.parameters.json は次のような構造を持っています:

環境ごとに、すべての接続文字列、API キー、およびアプリケーション設定を配置しました。

関数アプリの運用スロットには、構成を適用する "resources" プロパティを追加できます。関数アプリのデプロイ全体を次に示します。

次は、ステージ スロットのデプロイ リソースを定義しました。ここにあります：

このソリューションを使用すると、環境ごとにたくさんの parameters.json ファイルを用意する必要がなくなります。

問題点...

parameters.json ですべてのアプリケーション設定を定義すると、テンプレート関数を使用して接続文字列や Azure Key Vault 値を取得できなくなります。

これは、テンプレート機能を使用するために、アプリケーション設定の一部を配置テンプレートに移動し始めたときです。したがって、parameters.json ファイルに APPINSIGHTS_INSTRUMENTATIONKEY とその他の AzureWebJobs* アプリケーション設定を含める代わりに、 Microsoft.Web/Sites リソースとMicrosoft.Web/Sites/Slots リソースの "プロパティ" オブジェクトにsiteConfig オブジェクトを指定しました。

これは本当に残念です - デプロイが実行されると、関数アプリで siteConfig.appsettings 値が適用され、次に parameters.json ファイルが適用されると、アプリケーション設定が削除され、マージする代わりに json からのものだけが適用されました。それらを一緒に。それは大きな失望でした。AzureCLI を使用した最初のテストでは、このコマンドを使用az functionapp config appsettings set --name $functionAppName --resource-group $resourceGroupName --settings $settingsFile --slot $slotして、json ファイルに含まれていないアプリケーション設定で何が起こるかをテストしましたが、アプリケーション設定が削除されないことに満足しました。powershell コマンドは、値を取得して設定し、適切にマージして削除しません。ただし、ARM API は、これらの名前と値のペアをすべて削除し、定義されているものだけを適用します。つまり、テンプレート関数を使用して動的アプリケーション設定を作成したり、json ファイルを使用して静的アプリケーション設定を適用したりすることはできません。

今のところ、適切な ARM テンプレートのデプロイを行う唯一の方法は、siteConfig オブジェクトまたは config リソースを使用せずにリソースをデプロイしてアプリケーション設定を適用し、Azure CLI をフォローアップしてアプリケーション設定をデプロイすることだと思います。Azure CLI または Azure DevOps パイプライン タスクを使用して Key Vault シークレットを取得する方法を学べると思いますが、すべてを 1 つの ARM テンプレートにまとめたほうがよいでしょう。

参考までに、動的に生成された appSettings と構成リソースを使用してさらに appsettings を定義しようとしたときのデプロイ テンプレート全体を以下に示します。

更新 2:

私は github の問題を提起して、ARM テンプレートが各展開のすべてのアプリケーション設定を置き換えるという問題を修正してもらいました。 FWIW - Azure フィードバック投稿にも投票しました。

デプロイ専用のステージ スロットを持つ Azure App Service があります。本番スロットへのトラフィックを 100% に設定しました。しかし、ときどき本番トラフィックがランダムにステージ スロットにリダイレクトされ、すべてのユーザーがダウンしました。数分後、トラフィックは本番スロットに戻り、すべてが正常に戻ります。

IMG: ステージ スロットでのリクエスト。私の最後のデプロイ (およびステージ使用) は、その 1 日前でした 。

このようなことを経験した人はいますか？