Publicar um módulo num registo privado

4 minutos

Agora você entende o que são registros Bicep e como eles podem ser úteis quando você está compartilhando módulos em sua organização. Nesta unidade, você aprenderá como publicar um módulo em um registro privado.

Caminhos do módulo

Quando você já trabalhou com módulos no passado, provavelmente usou o caminho do arquivo do módulo para se referir a ele em seus modelos. Quando você trabalha com módulos e registros privados, você precisa usar um caminho de módulo diferente para que o Bicep saiba como localizar o módulo em seu registro.

Aqui está um caminho de exemplo para um módulo em um registro de contêiner privado do Azure:

Diagrama que mostra a sintaxe de um caminho de módulo.

O caminho contém quatro segmentos:

Esquema: O Bicep suporta vários tipos de módulos, que são chamados de esquemas. Quando você trabalha com registros Bicep, o esquema é br.
Registo: O nome do registo que contém o módulo que pretende utilizar. No exemplo anterior, o nome do Registro é toycompany.azurecr.io, que é o nome do Registro do contêiner.
Identificador do módulo: O caminho completo para o módulo dentro do registro.
Tag: As tags normalmente representam versões de módulos, porque um único módulo pode ter várias versões publicadas. Saiba mais sobre tags e versões na próxima seção.

Ao publicar seu próprio identificador de módulo, use um identificador significativo que indique a finalidade do módulo. Opcionalmente, você pode usar namespaces, onde você usa barras (/) para distinguir entre partes de um nome. No entanto, o Azure Container Registry e o Bicep não entendem uma hierarquia. Eles tratam o identificador do módulo como um único valor.

Tags e versões

Uma tag representa a versão de um módulo. Um único módulo em um registro pode ter várias versões. Todas as versões compartilham um identificador de módulo, mas têm tags diferentes. Ao usar um módulo, você precisa usar uma tag para especificar a versão que deseja usar, para que o Bicep saiba qual arquivo de módulo recuperar.

É uma boa ideia planejar cuidadosamente como você fará a versão de seus módulos. Duas decisões importantes que você precisa tomar são o esquema de controle de versão e a política de controle de versão a ser usada.

Esquemas de controle de versão

Seu esquema de controle de versão determina como você gera números de versão. Os esquemas comuns de controle de versão incluem:

Inteiros básicos podem ser usados como números de versão. Por exemplo, sua primeira versão pode ser chamada 1de , sua segunda versão 2e assim por diante. Ou, você pode adicionar um prefixo a cada número de versão, como v1 e v2.
As datas também fazem bons números de versão. Por exemplo, se você publicar a primeira versão do módulo em 16 de janeiro de 2022, poderá nomear a versão 2022-01-16 (usando o formato aaaa-mm-dd ). Quando você publicar outra versão em 3 de março, você pode nomeá-lo 2022-03-03.
O versionamento semântico é um sistema de versionamento frequentemente usado em software, onde um único número de versão contém várias partes. Cada parte sinaliza informações diferentes sobre a natureza da mudança.

Embora você possa usar qualquer esquema de controle de versão que desejar, é uma boa ideia escolher algo que possa ser classificado em uma ordem significativa. Números e datas costumam ser boas escolhas.

Nota

O Registro de Contêiner do Azure armazena a data em que cada marca é criada. Mesmo que você não use o controle de versão baseado em data, ainda poderá ver essas informações.

Políticas de controle de versão

Os módulos oferecem a flexibilidade de escolher quando criar novas versões ou atualizar uma versão existente. Por exemplo, você pode efetivamente desativar o controle de versão criando e publicando uma única versão chamada latest. Sempre que precisar de alterar o seu módulo, basta atualizar essa versão. Embora esta política funcione, não é uma boa prática.

Por outro lado, se você fizer uma pequena alteração em um módulo existente que não afete como ele é usado, criar uma nova versão provavelmente não é uma boa ideia. Você precisaria comunicar o novo número de versão para qualquer pessoa que use o módulo.

Aqui está uma política de controle de versão que geralmente funciona bem:

Sempre que você fizer alterações significativas em um módulo, crie uma nova versão. Mudanças significativas incluem qualquer coisa que possa fazer a diferença para alguém que usa seu módulo. Os exemplos incluem adicionar outro recurso ao módulo ou alterar as propriedades de um recurso.
Sempre que você fizer pequenas alterações em um módulo, que às vezes são chamadas de hotfix, atualize a versão do módulo existente.
Exclua versões antigas quando elas não forem mais relevantes ou quando você não quiser que ninguém as use.

Gorjeta

Considere os usuários do seu módulo e certifique-se de pensar no que eles esperam que aconteça. Se alguém usar seu módulo várias vezes e obtiver um resultado, e depois usá-lo novamente após um hotfix e obtiver um resultado diferente, provavelmente ficará surpreso. Tente evitar surpreender seus usuários.

Publique o módulo

Quando você cria um módulo Bicep que você deseja compartilhar, você cria o arquivo Bicep como normal. Em seguida, você publica o arquivo em um registro usando o bicep publish comando. Ao publicar, você precisa especificar o caminho do módulo para salvar o módulo em:

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

bicep publish module.bicep `
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

A operação de publicação executa as mesmas etapas de validação que acontecem quando você cria ou implanta um arquivo Bicep. Estes passos incluem:

Verificar se o código não tem erros sintáticos.
Verificar se você está especificando definições de recursos válidas.
Executando o linter Bicep para verificar se seu código passa por uma série de verificações de qualidade.