对 Bicep 代码执行 Lint 分析和验证

  • 5 分钟

现在你已了解管道各阶段的用途后，接下来请考虑可添加到 Bicep 部署管道的第一组验证步骤。 本单元将介绍如何验证 Bicep 模板。 你还将了解验证阶段通常执行的两个活动：Lint 分析和预检验证。

什么是有效的 Bicep 文件？

有效的 Bicep 文件是不包含任何语法错误的文件。 此外，计划部署的 Azure 资源的定义必须有效。 部署文件中定义的资源时，它们必须保持在 Azure 订阅中存在的配额和限制范围内。

有些检查是单独对 Bicep 文件执行的，例如语法错误检查、Azure 资源定义有效性检查以及代码质量检查。 这些步骤是 Lint 分析过程的一部分。 若要检查其他问题，需要请求 Azure 资源管理器服务验证模板并考虑 Azure 环境。

有效的 Bicep 模板更有可能部署成功。 无需部署 Bicep 模板即可获得反馈。 验证是一种好的做法，因为如果你部署无效的 Bicep 文件，Azure 可能会只部署或更改模板中所述资源的子集。 结果可能是环境状态将不一致，并且可能不会按预期方式运行。

生成和 lint Bicep 代码

部署 Bicep 文件时，Bicep 工具首先运行一些基本验证步骤。 这些步骤与使用 Visual Studio Code 修改文件时运行的步骤相同。 它们检查是否正确使用了 Bicep 语言关键字，并根据每种资源类型的要求定义 Azure 资源。

此外，Bicep 还会对文件运行 Linter。 Lint 分析是根据一组建议检查代码的过程。 Bicep Linter 会审阅你的文件，并验证你是否遵循了有关可维护性、正确性、灵活性和可扩展性的最佳做法。

对于其中每个类别，Linter 都包含一组预定义的规则。 Linter 规则示例包括：

  • 未使用的参数。 Linter 会扫描在 Bicep 文件中任何位置都未使用的任何参数。 通过消除未使用的参数，可以更轻松地部署模板，因为无需提供不必要的值。 这还可在有人尝试使用你的 Bicep 文件时减少混淆。
  • 字符串内插。 Linter 检查文件是否使用 concat() 函数而不是 Bicep 字符串内插。 字符串内插使 Bicep 文件更具可读性。
  • 安全参数的默认值。 如果为用 @secure() 修饰器标记的参数设置默认值，linter 会发出警告。 安全参数的默认值是一种不良做法，因为它为安全参数提供了一个可读值，并且人们在部署之前可能不会更改它。

使用 Bicep 工具时，Bicep Linter 会自动运行。 每次生成 Bicep 文件时，Linter 都会根据最佳做法对其进行检查。 将 Bicep 文件部署到 Azure 时，会自动发生 Lint 分析。 但在管道中，通常需要在部署文件之前运行验证和 Lint 分析步骤。 可通过 Bicep CLI 手动生成 Bicep 文件，配置 Bicep 来验证文件：

az bicep build --file main.bicep

bicep build main.bicep

注意

运行 build 命令时，Bicep 还会将 Bicep 代码转译为 JSON ARM 模板。 你通常不需要它输出的文件，因此可忽略它。

因为你希望 Linter 在每次有人向你的存储库签入代码时检查 Bicep 模板，因此可向管道添加 Lint 分析阶段和作业：

示意图显示了一个管道，它具有一个“Lint 分析”阶段，其中有一个作业，它对文件运行 Linter。

可以在管道 YAML 文件中表达增加的该项内容，如下所示：

stages:

- stage: Lint
  jobs: 
  - job: Lint
    steps:
      - script: |
          az bicep build --file deploy/main.bicep

Linter 警告和错误

默认情况下，Linter 在发现 Bicep 文件违反规则时将发出警告。 Bicep Linter 发出的警告不会被视为错误，因此它们不会使管道或后续阶段停止运行。

可以通过配置 Bicep，将 Linter 规则冲突视为错误而不是警告，来更改此行为。 可通过将“bicepconfig.json”文件添加到包含你的 Bicep 文件的文件夹来执行此配置。 可以决定哪些 Linter 问题应被视为错误，哪些问题应保留为警告。 在本模块的后面，你将了解如何更新 Linter 规则。

提示

bicepconfig.json 文件还可控制 Visual Studio Code 在编辑器中显示错误和警告的方式。 它在 Bicep 模板中错误配置的部分下显示红色和黄色波浪线。 这些指标可让你在编写 Bicep 代码时更快获得反馈，进一步降低出错的可能性。

重新配置 Linter 以发出错误后，每当 Linter 检测到问题时，管道就会停止运行，后续作业或阶段也不会运行。 此设置有助于确保未部署有问题的 Bicep 代码。

预检验证

还应检查 Bicep 模板是否可能成功部署到 Azure 环境。 这项检查称为“预检验证”，它运行需要 Azure 提供的信息的检查。 这些类型的检查包括：

  • 为 Bicep 资源指定的名称是否有效？
  • 为 Bicep 资源指定的名称是否已被占用？
  • 要部署资源的区域是否有效？

预检验证需要与 Azure 通信，但它实际上不会部署任何资源。

示意图显示了一个管道，它包含 Lint 分析和验证阶段，其中每个阶段包含一个作业。验证阶段与 Azure 通信。

可以使用 AzureResourceManagerTemplateDeployment 任务提交 Bicep 文件进行预检验证。 将deploymentMode配置为Validation：

- stage: Validate
  jobs:
  - job: Validate
    steps:
      - task: AzureResourceManagerTemplateDeployment@3
        inputs:
          connectedServiceName: 'MyServiceConnection'
          ___location: $(deploymentDefaultLocation)
          deploymentMode: Validation
          resourceGroupName: $(ResourceGroupName)
          csmFile: deploy/main.bicep

此命令类似于已使用的部署任务，但它实际上不会部署任何资源。 它会对模板中使用的资源执行额外检查。

例如，假设 Bicep 文件包含存储帐户。 预检验证将检查另一个存储帐户是否已具有你选择的名称。 它还会检查为存储帐户选择的名称是否符合命名约定。

预检验证命令会运行 Bicep Linter。 但通常建议单独运行 Linter。 这样，如果存在任何 Linter 错误，就可以快速检测它们，而无需等待验证过程完成。 验证需要更长的时间。

重要

运行预检验证时，每个 Azure 资源提供程序都执行其自己的检查。 某些资源提供程序不会运行许多检查（而其他资源提供程序会运行许多检查），因此不能依赖预检验证来确定文件是否有效。 尽管如此，它还是一个很有用的工具，值得包含在管道中。

通过向管道添加验证阶段以运行 Linter 并执行预检验证，你将在部署 Bicep 文件之前更有信心。