デプロイ スタックに関する既知の問題

この記事では、Azureデプロイ スタックの既知の制限事項と既知の問題と、使用可能な場合の推奨される回避策を示します。

既知の制限

  • 1 つのスコープ内に最大 800 個のデプロイ スタック を作成できます。
  • 任意のスコープで最大 2,000 個の拒否割り当てを 使用できます。
  • デプロイ スタックでは、暗黙的に作成されたリソースは管理されません。 その結果、これらのリソースでは deny-assignments やクリーンアップを使用できません。
  • 拒否の割り当てでは、タグはサポートされていません。
  • 拒否の割り当ては、管理グループのスコープではサポートされていません。 ただし、デプロイがサブスクリプション スコープで指定されている場合は、管理グループ スタックでサポートされます。
  • デプロイ スタックでは、Key Vaultシークレットを削除できません。 テンプレートからKey Vaultシークレットを削除する場合は、デタッチ モードでデプロイ スタックの更新または削除コマンドも実行します。 最新バージョンのAzure PowerShellとAzure CLIには、削除できないリソースをデタッチするオプションが含まれており、偶発的な障害を防ぐことができます。

既知の問題

  • リソース グループを削除すると、拒否割り当てがバイパスされます。 リソース グループがBicep ファイルで定義されていないため、リソース グループ スコープで作成されたデプロイ スタックは親リソース グループを管理しません。 その結果、デプロイ スタックによって拒否割り当てが作成された場合でも、リソース グループを削除できます。 リソース グループを削除すると、デプロイ スタックとそのマネージド リソースが削除されます。 推奨されるガイダンスは、サブスクリプション スコープにデプロイし、Bicep ファイルにリソース グループを含める方法です。 または、グループ内のリソースで ロック がアクティブな場合、削除操作は失敗します。
  • マネージド リソースを移動すると、そのスタック保護が削除されます。 拒否割り当ては、個々のリソース スコープではなく、移動操作のリソース グループ スコープで評価されます。 その結果、その個別のリソースが拒否割り当てによって保護されている場合でも、また移動後にデプロイ スタックの保護がそのリソースに引き継がれない場合でも、リソースをリソース グループの外に移動できます。 移動されたリソースはスタックによって保護されなくなり、元の境界外で管理できます。 暫定的な軽減策として、リソース グループに読み取り専用 ロック を適用して、移動操作をブロックします。 デプロイ スタック操作は引き続き読み取り専用ロックで動作します。たとえば、スタックの読み取りとスタックの deny-delete 保護は引き続き機能します。 スタックを更新するには、変更中にロックを一時的に削除し、後で再適用します。
  • 管理グループ スコープのスタックは、別の管理グループにデプロイできません。 スタック自体の管理グループまたは子サブスクリプションにのみデプロイできます。
  • DeleteResourcesAndResourceGroups 値が削除されています。 Azure PowerShell コマンドを使用すると、DeleteResourcesAndResourceGroups スイッチのActionOnUnmanage値を一覧表示できます。 この値を使用すると、コマンドによってマネージド リソースとリソース グループがデタッチされます。 この値は、今後の更新プログラムで削除されます。 この値は使用しないでください。
  • 汎用テンプレート検証エラー。 場合によっては、New-*コマンドレットとSet-* Azure PowerShell コマンドレットは、明確に対処できない一般的なテンプレート検証エラーを返す場合があります。 エラーが明確でない場合は、デバッグ モードでコマンドレットを再実行して、生の応答でより詳細なエラーを確認します。
  • Microsoft Graph プロバイダーはサポートされていません。 Microsoft Graph プロバイダーはデプロイ スタックをサポートしていません。
  • What-if はまだ使用できません。 What-If 操作は、デプロイ スタックではまだサポートされていません。

同期外れのスタックエラーを処理する。

デプロイ スタックを更新または削除するときに、スタックのリソース一覧が正しく同期されていないことを示すスタックアウトオブシンク エラーが発生する可能性があります。

The deployment stack '{0}' might not have an accurate list of managed resources. To prevent resources from being accidentally deleted, check that the managed resource list doesn't have any additional values. If there is any uncertainty, it's recommended to redeploy the stack with the same template and parameters as the current iteration. To bypass this warning, specify the 'BypassStackOutOfSyncError' flag.

Azure ポータルからマネージド リソースの一覧を確認するか、同じパラメーターを使用して現在デプロイされているBicep ファイルを再デプロイして、マネージド リソースの一覧を取得します。 一覧を確認したら、Azure PowerShell (または Azure CLI でBypassStackOutOfSyncError) の--bypass-stack-out-of-sync-errorスイッチを使用してコマンドを再実行します。 このスイッチは、リソース一覧を十分に確認した後にのみ使用します。 既定では使用しないでください。

次のステップ