Recomendações para marcação e controle de versão de imagens de contêiner

Ao enviar imagens de contêiner para um registro de contêiner e, em seguida, implantá-las, você precisa de uma estratégia para marcação e controle de versão de imagens. Este artigo discute duas abordagens e onde cada uma se encaixa durante o ciclo de vida do contêiner:

• Tags estáveis - Tags que você reutiliza, por exemplo, para indicar uma versão principal ou secundária, como mycontainerimage:1.0.
• Tags exclusivas - Uma tag diferente para cada imagem enviada por push para um registro, como mycontainerimage:abc123.

Tags estáveis

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

Tags estáveis significam que um desenvolvedor, ou um sistema de compilação, pode continuar a extrair uma tag específica, que continua a receber atualizações. Estável não significa que o conteúdo está congelado. Em vez disso, estável implica que a imagem deve ser estável para a intenção dessa versão. Para se manter "estável", ele pode ser atendido para aplicar patches de segurança ou atualizações de estrutura.

Exemplo

Uma equipe de estrutura é lançada na versão 1.0. Eles sabem que enviarão atualizações, incluindo atualizações menores. Para suportar tags estáveis para uma determinada versão principal e secundária, eles têm dois conjuntos de tags estáveis.

• :1 – uma tag estável para a versão principal. 1 representa a versão "mais recente" ou "mais recente" 1.*.
• :1.0- uma tag estável para a versão 1.0, permitindo que um desenvolvedor se vincule a atualizações de 1.0 e não seja rolado para a 1.1 quando for lançado.

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

Neste caso, as tags principais e secundárias estão sendo continuamente atendidas. A partir de um cenário de imagem base, isso permite que o proprietário da imagem forneça imagens atendidas.

Excluir manifestos não marcados

Se uma imagem com uma tag estável for atualizada, a imagem marcada anteriormente será desmarcada, resultando em uma imagem órfã. O manifesto da imagem anterior e os dados de camada exclusivos permanecem no registro. Para manter o tamanho do registro, você pode excluir periodicamente manifestos não marcados resultantes de atualizações de imagem estáveis. Por exemplo, limpe automaticamente manifestos não marcados com mais de uma duração especificada ou defina uma política de retenção para manifestos não marcados.

Tags exclusivas

Recomendação: use tags exclusivas para implantações, especialmente em um ambiente que pode ser dimensionado em vários nós. Você provavelmente deseja implantações deliberadas de uma versão consistente dos componentes. Se o contêiner for reiniciado ou um orquestrador escalar mais instâncias, os hosts não puxarão acidentalmente uma versão mais recente, inconsistente com os outros nós.

A marcação exclusiva significa simplesmente que cada imagem enviada para um registro tem uma tag exclusiva. As tags não são reutilizadas. Há vários padrões que você pode seguir para gerar tags exclusivas, incluindo:

• Carimbo de data /hora - Esta abordagem é bastante comum, uma vez que você pode dizer claramente quando a imagem foi construída. Mas, como correlacioná-lo de volta ao seu sistema de compilação? Você tem que encontrar a construção que foi concluída ao mesmo tempo? Em que fuso horário você está? Todos os seus sistemas de compilação estão calibrados para UTC?

• Git commit – Essa abordagem funciona até que você comece a oferecer suporte a atualizações de imagem base. Se uma atualização de imagem base acontecer, seu sistema de compilação começará com a mesma confirmação do Git que a compilação anterior. No entanto, a imagem base tem novo conteúdo. Em geral, uma confirmação Git fornece uma tag semiestável.

• Resumo do manifesto – cada imagem de contentor enviada para um registo de contentor está associada a um manifesto, identificado por um hash SHA-256 exclusivo ou um resumo. Embora único, o resumo é longo, difícil de ler e não está correlacionado com o seu ambiente de construção.

• ID de compilação - Esta opção pode ser melhor, pois provavelmente é incremental, e permite que você se correlacione de volta à compilação específica para encontrar todos os artefatos e logs. No entanto, como um resumo manifesto, pode ser difícil para um ser humano ler.

  Se sua organização tiver vários sistemas de compilação, prefixar a tag com o nome do sistema de compilação é uma variação desta opção: <build-system>-<build-id>. Por exemplo, você pode diferenciar compilações do sistema de compilação Jenkins da equipe de API e do sistema de compilação Azure Pipelines da equipe Web.

Bloquear tags de imagem implantadas

Como prática recomendada, recomendamos que você bloqueie qualquer tag de imagem implantada, definindo seu write-enabled atributo como false. Essa prática impede que você remova inadvertidamente uma imagem do registro e, possivelmente, interrompa suas implantações. Você pode incluir a etapa de bloqueio no pipeline de liberação.

Bloquear uma imagem implantada ainda permite remover outras imagens não implantadas do seu Registro usando os recursos do Registro de Contêiner do Azure para manter seu registro. Por exemplo, limpe automaticamente manifestos não marcados ou imagens desbloqueadas anteriores a uma duração especificada ou defina uma política de retenção para manifestos não marcados.

Próximos passos

Para obter uma discussão mais detalhada dos conceitos neste artigo, consulte a postagem do blog Docker Tagging: Best practices for tagging and versioning docker images.

Para ajudar a maximizar o desempenho e o uso econômico do seu Registro de contêiner do Azure, consulte Práticas recomendadas para o Registro de Contêiner do Azure.