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

Concluído

Ao automatizar o processo de publicação de uma especificação de modelo ou de 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 para publicar especificações de modelo e módulos Bicep a partir de um pipeline de implantação.

Especificações e módulos do modelo

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

• Especificações de modelo, que são otimizadas para a implantação de soluções completas. Por exemplo, suponha que você tenha definido um conjunto de recursos com segurança reforçada para implantar uma máquina virtual completa de acordo com as especificações da sua empresa. Você pode publicar esse código como uma especificação de modelo. Seus colegas poderiam usar sua especificação de modelo para implantar uma máquina virtual completa, mesmo a partir do portal do Azure.
• Módulos, que são projetados para serem componentes de outras implantações. Por exemplo, suponha que você criou um arquivo Bicep que cria uma conta de armazenamento. É provável que você precise de contas de armazenamento em muitas 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 sua organização.

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

Validar código reutilizável em um pipeline

Ao contrário das implantações regulares do Bicep, quando você cria uma especificação de modelo ou um módulo, não implanta os recursos diretamente no Azure. Em vez disso, você publica a especificação ou o módulo do modelo. Em seguida, você pode usar a especificação ou módulo do modelo em outra implantação. Em seguida, essa implantação implanta os recursos que você definiu. Consequentemente, as maneiras como você valida e testa suas especificações de modelo e módulos Bicep podem diferir do processo que você usa para implantações regulares do Bicep.

Linting seu código Bicep é uma boa prática. O linter deteta problemas sintáticos e avisa se você não está seguindo as práticas recomendadas.

Além do linting, convém considerar testar as especificações e os módulos do modelo usando a validação de comprovação. Você pode até considerar implantar suas especificações e módulos de modelo no Azure e testar se os recursos criados por eles se comportam como você espera. No entanto, pode ser um desafio executar esses tipos de testes a partir de um pipeline de implantação por dois motivos:

• A validação e as implantações de comprovação exigem um ambiente do Azure para implantar os recursos. Talvez seja necessário manter uma assinatura dedicada do Azure ou um grupo de recursos para usar para implantar e testar seus módulos.
• Muitas especificações e módulos de modelo exigem que você especifique um conjunto de parâmetros. Talvez seja necessário criar um conjunto de parâmetros de teste para as especificações ou módulos do modelo a serem usados quando forem implantados.

Você precisará decidir se deseja incluir etapas de pipeline que implantam e testam suas especificações e módulos de modelo. Neste módulo do Microsoft Learn, temos o 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 deve usar assinaturas dedicadas ou grupos de recursos para implantar os recursos.

Gorjeta

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

Autenticação e autorização

Quando você mesmo publica especificações de modelo no Azure, seu usuário do Microsoft Entra precisa ter 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, seu usuário do Microsoft Entra precisa ter permissão para gravar na instância do Registro de Contêiner do Azure que sua organização usa para seus módulos Bicep.

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

Gorjeta

Quando você publica um módulo em um registro, a entidade de serviço que executa a implantação provavelmente não precisa de muita permissão. Quando seu 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 segurança de menor privilégio. Forneça à entidade de serviço do pipeline acesso somente ao registro de contêiner, e não a um grupo de recursos ou assinatura.

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

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

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 de 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 do modelo que você mesmo usaria.

Da mesma forma, quando você publica um módulo Bicep de seu próprio computador usando a CLI do Azure, você usa um comando como o seguinte:

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

Você também pode converter esse comando da CLI do Azure em uma etapa de 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'

Gorjeta

Neste exemplo, o nome do host do registro Bicep (toycompany.azurecr.io) é incorporado na definição da etapa do pipeline. Esta não é uma boa prática. Você pode usar variáveis de ambiente para definir definições de configuração como esta. Você verá 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 uma especificação de módulo ou modelo

Em módulos de treinamento anteriores do Microsoft Learn, você aprendeu como implantar os recursos definidos nas especificações de modelo e como usar os módulos Bicep armazenados em registros. Quer publique as especificações e os módulos do modelo manualmente ou a partir de um pipeline de implementação, utiliza-os e implementa-os da mesma forma.

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