Recomendações para etiquetagem e versionamento de imagens de contentores

Ao enviar imagens de contentores para um registo de contentores e depois as implementar, é necessário uma estratégia para a marcação e versionamento de imagens. Este artigo discute duas abordagens e onde cada uma se encaixa durante o ciclo de vida do contentor:

• Etiquetas estáveis - Etiquetas que reutiliza, por exemplo, para indicar uma versão maior ou menor, como mycontainerimage:1.0.
• Etiquetas únicas - Uma etiqueta diferente para cada imagem que envia para um registo, como mycontainerimage:abc123.

Etiquetas estáveis

Recomendação: Use tags estáveis para manter as imagens base para as suas construções de contentores. Evite implementações com etiquetas estáveis, porque essas etiquetas continuam a receber atualizações e podem introduzir inconsistências em ambientes de produção.

Etiquetas estáveis significam que um programador, ou um sistema de build, pode continuar a puxar uma tag específica, que continua a receber atualizações. Estável não significa que o conteúdo esteja congelado. Pelo contrário, estável implica que a imagem deve ser estável para os propósitos dessa versão. Para se manter "estável", pode ser servido para aplicar patches de segurança ou atualizações do framework.

Example

Uma equipa de framework lança a versão 1.0. Eles sabem que vão enviar atualizações, incluindo atualizações menores. Para suportar etiquetas estáveis para uma dada versão maior e menor, têm dois conjuntos de etiquetas estáveis.

• :1 – uma etiqueta estável para a versão principal. 1 representa a versão 1.* "mais recente" ou "última".
• :1.0- uma etiqueta estável para a versão 1.0, permitindo que um programador se vincule às atualizações da versão 1.0, sem ser automaticamente atualizado para a versão 1.1 quando esta for lançada.

Quando há atualizações de imagem base disponíveis, ou qualquer tipo de versão de manutenção do framework, as imagens com as tags estáveis são atualizadas para o digest mais recente que representa a versão estável mais recente dessa versão.

Neste caso, tanto as tags principais como as secundárias estão continuamente em manutenção. Com um cenário de imagem base, isto permite ao proprietário da imagem fornecer imagens geridas.

Eliminar manifestos não etiquetados

Se uma imagem com uma etiqueta estável for atualizada, a imagem anteriormente etiquetada perde a etiqueta, resultando numa imagem órfã. Os dados do manifesto e da camada única da imagem anterior permanecem no registo. Para manter o tamanho do seu registo, pode periodicamente eliminar manifestos não etiquetados resultantes de atualizações estáveis de imagens. Por exemplo, purgar automaticamente manifestos não etiquetados mais antigos do que uma duração especificada, ou definir uma política de retenção para manifestos não etiquetados.

Etiquetas únicas

Recomendação: Use etiquetas únicas para implementações, especialmente num ambiente que possa escalar em vários nós. Provavelmente queres implementações deliberadas de uma versão consistente dos componentes. Se o teu contentor reiniciar ou um orquestrador escalar mais instâncias, os teus anfitriões não vão puxar acidentalmente uma versão mais recente, inconsistente com os outros nós.

Etiquetagem única significa simplesmente que cada imagem enviada para um registo tem uma etiqueta única. As etiquetas não são reutilizadas. Existem vários padrões que pode seguir para gerar etiquetas únicas, incluindo:

• Carimbo de data-hora - Esta abordagem é bastante comum, pois você pode ver claramente quando a imagem foi gerada. Mas, como é que o correlaciono com o teu sistema de construção? É preciso encontrar a construção que foi concluída ao mesmo tempo? Em que fuso horário estás? Todos os teus sistemas de construção estão calibrados para UTC?

• Git commit – Esta abordagem funciona até começares a suportar atualizações de imagem base. Se houver uma atualização da imagem base, o teu sistema de build arranca com o mesmo commit Git da versão anterior. No entanto, a imagem base tem novo conteúdo. Em geral, um commit Git fornece uma etiqueta semi-estável.

• Digestão do manifesto - Cada imagem de contentor enviada para um registo de contentores está associada a um manifesto, identificado por um hash SHA-256 único, ou digestão. Embora único, o resumo é longo, difícil de ler e não está relacionado com o ambiente de construção.

• ID da build - Esta opção pode ser a melhor, pois provavelmente é incremental, e permite-te correlacionar com a build específica para encontrar todos os artefactos e logs. No entanto, tal como um resumo de manifesto, pode ser difícil para um humano entender.

  Se a sua organização tem vários sistemas de compilação, prefixar a etiqueta com o nome do sistema de construção é uma variação desta opção: <build-system>-<build-id>. Por exemplo, poderias diferenciar os builds do sistema de build Jenkins da equipa de API e dos builds do sistema Azure Pipelines da equipa web.

Bloquear tags de imagem implementadas

Como boa prática, recomendamos que bloqueie qualquer tag de imagem implementada, definindo o seu write-enabled atributo como false. Esta prática impede que remova inadvertidamente uma imagem do registo e possivelmente interrompa as suas implementações. Pode incluir a etapa de bloqueio no seu pipeline de lançamento.

Bloquear uma imagem implementada ainda permite remover outras imagens não implementadas do seu registo usando funcionalidades do Azure Container Registry para manter o seu registo. Por exemplo, eliminar automaticamente manifestos não etiquetados ou imagens desbloqueadas com duração superior a uma duração especificada, ou definir uma política de retenção para manifestos não etiquetados.

Conteúdo relacionado

Para ajudar a maximizar o desempenho e a utilização económica do seu registo de contentores Azure, consulte Melhores práticas para o Registo de Contentores Azure.