Publicar código Bicep a partir de um fluxo de trabalho de implantação
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 normalmente faria por conta própria possa ser automatizado e executado dentro do fluxo de trabalho. Nesta unidade, você aprenderá a aplicar alguns dos princípios que aprendeu anteriormente ao publicar especificações de modelo e módulos Bicep de um fluxo de trabalho 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 fluxo de trabalho
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. Essa implantação implantará os recursos que você definiu. Devido a essa diferença, as maneiras de validar e testar suas especificações de modelo e módulos Bicep podem ser diferentes 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 fluxo de trabalho 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ê deve escolher se deseja incluir etapas de fluxo de trabalho que implantam e testam suas especificações e módulos de modelo. Neste módulo de treinamento do Microsoft Learn, usamos 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 você usará assinaturas dedicadas ou grupos de recursos para implantar os recursos.
Gorjeta
Recomendamos que você revise Testar seu código Bicep usando Ações do GitHub para obter mais informações sobre como testar seus arquivos Bicep em um fluxo de trabalho 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 fluxo de trabalho 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 identidade do fluxo de trabalho tenha o acesso apropriado ao grupo de recursos para publicar a especificação do modelo ou ao registro de contêiner para publicar módulos.
Gorjeta
Quando você publica um módulo em um registro, a identidade da carga de trabalho que executa a implantação provavelmente não precisa de muita permissão. Quando seu registro usa a autorização do Microsoft Entra, a identidade da carga de trabalho precisa apenas da permissão AcrPush no registro.
Considere usar o princípio de segurança de menor privilégio. Forneça a identidade do fluxo de trabalho com acesso somente ao registro do contêiner, e não a um grupo de recursos ou assinatura.
Publicar especificações e módulos de modelo a partir de um fluxo de trabalho
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 \
--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 Ações do GitHub:
- 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ê 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 Ações do GitHub:
- name: Publish Bicep module
uses: azure/cli@v1
with:
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 fluxo de trabalho. 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 de treinamento do Microsoft Learn.
Em breve, você verá como publicar uma especificação de modelo de um fluxo de trabalho usando as etapas descritas 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 fluxo de trabalho 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 Azure ou o cmdlet com o az deployment group create
New-AzResourceGroupDeployment
Azure PowerShell.