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

Concluído

Ao automatizar o processo de publicação de uma especificação de modelo ou de um módulo Bicep, é necessário garantir que tudo o que seria feito por você seja automatizado e executado no fluxo de trabalho. Nesta unidade, você aprenderá a aplicar alguns dos princípios que já aprendeu ao publicar especificações de modelo e módulos Bicep, mas usando um fluxo de trabalho 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 fluxo de trabalho

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 implantará os recursos que você definiu. Devido a essa diferença, as maneiras de validar e testar as especificações de modelo e os módulos Bicep podem ser diferentes do processo usado para implantações Bicep regulares.

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 fluxo de trabalho 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ê deve decidir se quer incluir etapas de fluxo de trabalho que implantam e testam as especificações de modelo e os módulos. Neste módulo de treinamento do Microsoft Learn, fazemos lint no código Bicep, mas não incluímos outras formas de teste. Se você quiser testar as especificações de modelo e os módulos, considere como os implantará no Azure. Considere também se você usará assinaturas dedicadas ou grupos de recursos para implantar os recursos.

Dica

Recomendamos que você confira Testar o código Bicep usando o GitHub Actions para obter mais informações de como testar arquivos Bicep em um fluxo de trabalho 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 fluxo de trabalho 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 identidade de serviço do fluxo de trabalho 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 identidade de carga de trabalho que executa a implantação geralmente não precisa de muitas permissões. Quando o registro usa a autorização do Microsoft Entra, a identidade de carga de trabalho precisa apenas da permissão AcrPush no registro.

Considere usar o princípio de privilégios mínimos de segurança. Forneça a identidade do fluxo de trabalho com acesso apenas ao registro de contêiner e não a um grupo de recursos ou assinatura.

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

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 \
  --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 GitHub Actions:

- name: Publish template spec
  uses: azure/cli@v1
  with:
    inlineScript: |
      az ts create \
        --name StorageWithoutSAS \
        --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 fluxo de trabalho 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 GitHub Actions:

- name: Publish Bicep module
  uses: azure/cli@v1
  with:
    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 fluxo de trabalho. 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 de treinamento do Microsoft Learn.

Em breve, você verá como publicar uma especificação de modelo usando um fluxo de trabalho com as etapas descritas 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 fluxo de trabalho 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.