【发布时间】:2022-10-13 15:07:27
【问题描述】:
我目前正在使用使用 ARM/Bicep 部署的 Azure 应用程序网关的解决方案。随着时间的推移,会部署使用此 AppGw 的其他应用程序,因此会在以下位置为这些应用程序创建规则/后端池/侦听器他们的通过 Az CLI(中央基础设施 IaC 管道/流程之外)的部署时间。在重新部署/更新中央 AppGw 时,我遇到了 ARM/Bicep 模板覆盖所有这些额外添加的经典问题,因为 AppGw 是单个资源,并且更改不在 ARM/Bicep 文件中,它们是删除。
我过去通过检查 AppGw 的存在、输出现有的规则/池/等来解决这个问题。然后在重新部署之前将它们合并到 ARM/Bicep JSON 中。这工作得很好,但 AppGw 现在变得如此庞大/复杂,以至于我在通过 Azure Devops 构建管道部署更新时遇到了 Bash 字符限制。因此,我正在寻找一种更好的方法来处理这个问题。我还尝试将现有配置输出到文件并通过 Azure Bicep 中的文件加载进行摄取,但我需要在全球范围内部署多个具有不同配置的 AppGws,因此由于 Bicep 中的编译时文件引用限制,这对我不起作用.
我需要确保我的 AppGw 基线模板文件(它设置了 TLS 级别或诊断设置等核心内容)以某种方式得到尊重,同时不会覆盖单独部署过程中发生的修改。
我的问题是我是否可以将这个现有 AppGw 的状态与我的基线模板合并/合并,或者使用 Azure Bicep,或者如果这暴露了功能,则重新工具化为 Pulumi/Terraform 之类的东西。我想到的那种方法是:
- 管道 CLI 任务检查 AppGw 是否已存在
- 如果否,则使用具有基本要求的基线模板进行部署
- 如果是,则获取现有的后端池/侦听器/等。 (或获取整体状态)
- 与模板 IaC 文件比较
- 合并状态,确保应用来自 IaC 文件的核心设置(即诊断设置、TLS 级别等),同时现有后端池/侦听器/等。被保留
我知道但没有体验过 Pulumi 的 ignoreChanges 和转换概念。我不确定这是否涵盖了这里的用例。我在这里试图实现的目标可能与这些声明性语言的目的相冲突,但我只是想问问其他人是否有任何想法。
首先十分感谢!
【问题讨论】:
标签: azure pulumi azure-bicep