Publicar um código Bicep usando um pipeline de implantação

  • 5 minutos

Ao automatizar o processo de publicação para uma especificação de modelo ou um módulo Bicep, você precisa garantir que tudo o que você normalmente faz manualmente possa ser automatizado e executado dentro do pipeline. Nesta unidade, você aplica princípios que aprendeu anteriormente a publicar especificações de modelo e módulos Bicep de um pipeline de implantação.

Especificações de modelo e módulos

O Bicep permite que você reutilize o código facilmente. Duas abordagens comuns para reutilização do código Bicep entre implantações são:

  • Especificações de modelo, que são otimizadas para a implantação de soluções completas. Por exemplo, considere que você definiu um conjunto de recursos protegidos com segurança para implantar uma máquina virtual completa de acordo com as especificações da empresa. Você pode publicar esse código como uma especificação de modelo. Depois, seus colegas poderão usar a especificação de modelo para implantar uma máquina virtual completa, mesmo que seja usando o portal do Azure.
  • Módulos, que são projetados para serem componentes de outras implantações. Por exemplo, considere que você criou um arquivo Bicep que cria uma conta de armazenamento. Provavelmente você precisará de contas de armazenamento em várias outras implantações para que possa publicar o arquivo Bicep em um registro e usá-lo como um módulo em todas as implantações da organização.

Quando você está decidindo entre especificações de modelo e módulos Bicep, uma boa regra geral é: se o modelo for implantado como está em toda a sua organização, as especificações de modelo provavelmente serão uma boa medida. Mas se você tiver a probabilidade de reutilizar esse modelo em vários modelos pai, os módulos Bicep poderão atender melhor às suas necessidades.

Validar o código reutilizável em um pipeline

Ao contrário das implantações Bicep regulares, ao criar uma especificação de modelo ou um módulo, você não implanta os recursos diretamente no Azure. Nesse caso, você publica a especificação de modelo ou o módulo. Depois, você pode usar a especificação de modelo ou módulo em outra implantação. Essa implantação, em seguida, implanta os recursos que você definiu. Consequentemente, as maneiras pelas quais você valida e testa suas especificações de modelo e módulos Bicep podem ser diferentes do processo que você usa para implantações regulares do Bicep.

Fazer link no código Bicep é uma boa prática. O linter detecta problemas sintáticos e avisa quando você não está seguindo as práticas recomendadas.

Além do lint, você pode considerar testar as especificações de modelo e os módulos usando a validação de simulação. Você pode até considerar implantar as especificações de modelo e os módulos no Azure e testar se os recursos que eles criam se comportam conforme o esperado. No entanto, pode ser difícil executar esses tipos de testes usando um pipeline de implantação por dois motivos:

  • A validação de simulação e as implantações exigem um ambiente do Azure no qual os recursos serão implantados. Talvez seja necessário manter uma assinatura ou um grupo de recursos do Azure dedicado a ser usado para implantar e testar os módulos.
  • Muitas especificações de modelo e módulos exigem que você especifique um conjunto de parâmetros. Pode ser necessário criar um conjunto de parâmetros de teste para as especificações de modelo ou os módulos usarem quando forem implantados.

Você precisará decidir se deseja incluir as etapas de pipeline que implantam e testam suas especificações e módulos de modelo. Neste módulo do Microsoft Learn, fazemos lint no código Bicep, mas não incluímos outras formas de teste. Se você quiser testar suas especificações e módulos de modelo, considere como implantá-los no Azure. Considere também se é necessário usar assinaturas dedicadas ou grupos de recursos para implantar os recursos.

Dica

Recomendamos que você confira Testar o código Bicep usando o Azure Pipelines para obter mais informações de como testar arquivos Bicep em um pipeline automatizado.

Autenticação e autorização

Quando você publica as especificações de modelo no Azure por conta própria, o usuário do Microsoft Entra precisa receber acesso ao grupo de recursos que contém o recurso de especificação de modelo. Da mesma forma, quando você publica um módulo Bicep em um registro, o usuário do Microsoft Entra precisa de permissão para gravar na instância do Registro de Contêiner do Azure que a organização usa para os módulos Bicep.

Quando você trabalha com um pipeline de implantação automatizado, os mesmos princípios se aplicam. Mas, como você não é a pessoa que executa a implantação, é necessário garantir que a entidade de serviço do pipeline receba o acesso apropriado ao grupo de recursos para publicar a especificação de modelo ou ao registro de contêiner para publicar os módulos.

Dica

Quando você publica um módulo em um registro, a entidade de serviço que executa a implantação geralmente não precisa de muitas permissões. Quando o registro usa a autorização do Microsoft Entra, a entidade de serviço precisa apenas da permissão AcrPush no registro.

Considere usar o princípio de privilégios mínimos de segurança. Forneça acesso à entidade de serviço do pipeline apenas ao registro de contêiner e não ao grupo de recursos ou à assinatura.

Publicar especificações de modelo e módulos usando um pipeline

Ao publicar uma especificação de modelo do seu computador usando a CLI do Azure, você usa um comando como este:

az ts create \
  --name StorageWithoutSAS \
  --resource-group MyResourceGroup \
  --location westus3 \
  --display-name "Storage account with SAS disabled" \
  --description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
  --version 1 \
  --template-file main.bicep

Você pode converter este comando da CLI do Azure em uma etapa do pipeline:

- task: AzureCLI@2
  name: Publish
  displayName: Publish template spec
  inputs:
    azureSubscription: $(ServiceConnectionName)
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az ts create \
        --name StorageWithoutSAS \
        --resource-group MyResourceGroup \
        --location westus3 \
        --display-name "Storage account with SAS disabled" \
        --description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
        --version 1 \
        --template-file main.bicep

O pipeline usa o mesmo processo para publicar a especificação de modelo que você usaria.

Da mesma forma, ao publicar um módulo Bicep do seu computador usando a CLI do Azure, você usa um comando este:

az bicep publish \
   --file module.bicep \
   --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

Você também pode converter este comando da CLI do Azure em uma etapa do pipeline:

- task: AzureCLI@2
  name: Publish
  displayName: Publish Bicep module
  inputs:
    azureSubscription: $(ServiceConnectionName)
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az bicep publish \
        --file module.bicep \
        --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

Dica

Neste exemplo, o nome do host do registro Bicep (toycompany.azurecr.io) é inserido na definição da etapa do pipeline. Essa não é uma prática recomendada. Você pode usar variáveis de ambiente para definir configurações como essa. Mostraremos como isso funciona mais adiante neste módulo do Microsoft Learn.

Como publicar uma especificação de modelo de um pipeline é descrito nesta unidade.

Usar um módulo ou uma especificação de modelo

Nos módulos de treinamento anteriores do Microsoft Learn, você aprendeu como implantar os recursos definidos em especificações de modelo e como usar módulos Bicep armazenados em registros. Se você publica as especificações de modelo e os módulos manualmente ou usando um pipeline de implantação, eles são usados e implantados da mesma forma.

Por exemplo, você implanta uma especificação de modelo ou um arquivo Bicep em um grupo de recursos usando o comando az deployment group create da CLI do Azure ou o cmdlet New-AzResourceGroupDeployment com o Azure PowerShell.