部署堆栈的已知问题

本文列出了Azure部署堆栈的已知限制和已知问题，以及建议的解决方法（如果可用）。

已知的限制

• 在单个范围内最多可以创建 800 个部署堆栈 。
• 在任何给定作用域内，最多可有 2,000 个拒绝分配项。
• 部署堆栈不管理隐式创建的资源。 因此，不能对这些资源使用 拒绝分配 或清理。
• 拒绝分配不支持标记。
• 管理组范围内不支持拒绝分配。 但是，当部署目标为订阅范围时，它们则受管理组堆栈支持。
• 部署堆栈无法删除密钥保管库机密。 如果要从模板中删除 密钥保管库 机密，还请使用分离模式运行部署堆栈更新或删除命令。 最新版本的Azure PowerShell和Azure CLI包括一个选项，用于分离不可删除的资源，从而防止意外失败。

已知问题

• 删除资源组会绕过拒绝分配规则。 在资源组范围内创建的部署堆栈不会管理父资源组，因为资源组未在Bicep文件中定义。 因此，即使部署堆栈创建拒绝分配，仍可以删除资源组。 删除资源组会删除部署堆栈及其托管资源。 建议的指南是部署到订阅范围，并将资源组包含在 Bicep 文件中。 或者，如果 锁定 在组中的任何资源上处于活动状态，则删除操作将失败。
• 移动托管资源会删除其堆栈保护。 对于移动操作，拒绝分配是在资源组范围内进行评估的，而不是在单个资源范围内。 因此，即使某项拒绝分配保护着该单个资源，该资源仍然可以从其资源组中移出；而且，部署堆栈的保护不会在资源移动后随之转移。 移动的资源不再受堆栈保护，可以在其原始边界之外进行管理。 作为临时缓解措施，对资源组施加只读锁以阻止移动操作。 部署堆栈操作在只读锁生效的情况下仍可继续运行——例如，读取堆栈以及堆栈的防删除保护仍然有效。 若要更新堆栈，请在更改期间暂时解除锁定，并在之后重新设置锁定。
• 管理组范围的堆栈无法部署到另一个管理组。 它只能部署到堆栈本身的管理组或子订阅。
• DeleteResourcesAndResourceGroups 值正在被移除。 Azure PowerShell 命令可帮助列出 DeleteResourcesAndResourceGroups 开关的 ActionOnUnmanage 值。 使用此值时，该命令会分离托管资源和资源组。 此值即将在即将进行的更新中删除。 不要使用此值。
• 通用模板验证错误。 在某些情况下，New-*和Set-*Azure PowerShell cmdlet 可能会返回一个无法明确操作的泛型模板验证错误。 如果错误不清楚，请在调试模式下重新运行 cmdlet，以查看原始响应中更详细的错误。
• 不支持使用 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（或BypassStackOutOfSyncErrorAzure CLI）中使用--bypass-stack-out-of-sync-error开关重新运行命令。 仅在全面查看资源列表后使用此开关。 默认情况下不要使用它。

后续步骤

• 在 Bicep 中创建和部署Azure部署堆栈
• 模板规格的已知问题