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

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

• Marcas estáveis - marcas reutilizáveis, por exemplo, para indicar uma versão principal ou secundária, como mycontainerimage:1.0.
• Marcas exclusivas – uma marca diferente para cada imagem enviada por push para um registro, como mycontainerimage:abc123.

Marcas estáveis

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

Com marcas estáveis, um desenvolvedor ou sistema de compilação pode continuar efetuando pull de uma marca específica, que continua a obter atualizações. Estável não significa que o conteúdo está congelado. Estável implica que a imagem deve ser estável para a intenção da versão. Para permanecer "estável", é possível fazer sua manutenção para aplicar patches de segurança ou atualizações de estrutura.

Exemplo

Uma equipe de estrutura fornece a versão 1.0. Essa equipe sabe que enviará atualizações, incluindo as secundárias. Para dar suporte a marcas estáveis para uma versão principal e uma secundária determinadas, elas têm dois conjuntos de marcas estáveis.

• :1 – uma marca estável para a versão principal. 1 representa a versão "mais nova" ou "mais recente" 1.*.
• :1.0 – uma marca estável para a versão 1.0 que permite que um desenvolvedor se vincule às atualizações da 1.0 e não sofra roll forward para a 1.1 quando ela for liberada.

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

Nesse caso, as marcas principal e secundária estão sendo atendidas continuamente. Em 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 marca estável for atualizada, a imagem marcada anteriormente será desmarcada, o que resulta em uma imagem órfã. O manifesto da imagem anterior e os dados da camada exclusiva permanecem no registro. Para manter o tamanho do registro, você pode excluir periodicamente os manifestos não marcados que são resultantes de atualizações de imagem estáveis. Por exemplo, limpe automaticamente os manifestos não marcados com mais tempo do que uma duração especificada ou defina uma política de retenção para eles.

Marcas exclusivas

Recomendação: use marcas exclusivas para implantações, especialmente em um ambiente com capacidade de dimensionamento para vários nós. Você provavelmente desejará implantações deliberadas de uma versão consistente dos componentes. Se o contêiner for reiniciado ou um orquestrador expandido para mais instâncias, seus hosts não farão pull acidental de uma versão mais nova, inconsistente com os outros nós.

A marcação exclusiva significa apenas que cada imagem enviada por push a um registro tem uma marca exclusiva. As marcas não são reutilizadas. Há vários padrões que podem ser seguidos ao gerar marcas exclusivas, incluindo:

• Carimbo de data/hora – essa abordagem é bastante comum, pois você sabe claramente quando a imagem foi criada. Mas como correlacioná-la ao sistema de compilação? Você precisa encontrar a compilação que foi concluída na mesma hora? Em qual fuso horário você está? Todos os sistemas de compilação estão calibrados para UTC?

• Confirmação do Git – essa abordagem funciona até que você comece a dar suporte a atualizações da imagem base. Se ocorrer uma atualização da imagem base, o sistema de compilação será iniciado com a mesma confirmação do Git da compilação anterior. No entanto, a imagem base tem um novo conteúdo. Em geral, uma confirmação do Git fornece uma marca semi-estável.

• Resumo de manifesto – cada imagem de contêiner enviada por push para um registro de contêiner é associada a um manifesto, identificado por um hash SHA-256 exclusivo ou um resumo. Embora seja exclusivo, o resumo é longo, difícil de ler e não correlacionado ao ambiente de compilação.

• ID de compilação – essa opção pode ser melhor, pois é provavelmente incremental e permite a correlação com a compilação específica para localizar todos os artefatos e logs. No entanto, como um resumo de manifesto, pode ser difícil para a leitura humana.

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

Bloquear marcas de imagem implantadas

Como prática recomendada, bloqueie qualquer marca de imagem implantada definindo o atributo write-enabled dela como false. Isso impede que você remova inadvertidamente uma imagem do registro, o que pode interromper suas implantações. Você pode incluir a etapa de bloqueio em seu pipeline de liberação.

O bloqueio de uma imagem implantada ainda permite remover do registro outras imagens não implantadas usando os recursos do Registro de Contêiner do Azure para mantê-lo. Por exemplo, limpe automaticamente os manifestos não marcados com mais tempo do que uma duração especificada ou defina uma política de retenção para eles.

Próximas etapas

Para obter uma discussão mais detalhada sobre os conceitos deste artigo, consulte a postagem do blog Marcação do Docker: práticas recomendadas para a marcação e o controle de versão de imagens do Docker.

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