Que regras de retenção de imagens mantêm um registo de contentores pequeno sem eliminar imagens que ainda estão implantadas?

Pergunta em aberto

A documentação do Distribution (citada) explica que as camadas (layers) são guardadas uma única vez, por endereço de conteúdo, e partilhadas entre manifests, que eliminar um manifest através da API só remove referências, e que a garbage collection elimina depois os blobs que nenhum manifest referencia, numa execução mark-and-sweep durante a qual o registo deve ficar apenas de leitura. Os registos geridos (managed) envolvem isto em regras de lifecycle: o guia do ECR (citado) descreve políticas que fazem expirar imagens por ordem de prioridade da regra, dentro de cerca de 24 horas após a correspondência, e recomenda pré-visualizar que imagens uma política faria expirar antes de a aplicar.

O que a documentação não diz é quais as regras seguras para uma equipa que constrói uma imagem por commit, implanta por digest e ocasionalmente faz rollback semanas depois:

• Expiração baseada em idade ou em contagem ("eliminar manifests sem tag com mais de N dias", "manter os últimos N por repositório") versus regras sensíveis à implantação, que consultam o que está atualmente referenciado por cargas de trabalho em execução ou por registos de releases.
• Como é que os builds de pull request e de branch são separados dos builds de release, de forma a que os primeiros possam ter vida curta sem que uma regra alguma vez apanhe os segundos.
• Se as definições de imutabilidade de tags, imagens assinadas ou atestações anexadas como referrers mudam o que uma regra de lifecycle tem de preservar. O guia do ECR (citado) afirma que uma imagem referenciada por uma manifest list não pode expirar antes da própria lista, e que os artefactos referrer expiram automaticamente junto com a sua imagem sujeito (subject image); se outros registos se comportam da mesma forma faz parte da pergunta.
• O que aconteceu quando uma regra estava errada: desapareceu alguma imagem necessária para um rollback ou para uma análise forense, e como foi recuperada?
• A que taxa de crescimento as regras mantiveram o registo, e se o problema motivador foi o custo de armazenamento ou a latência dos pulls.

O que uma resposta útil contém

O tipo de registo e o seu mecanismo de retenção, as regras exatas com a sua ordem, como as imagens de release são distinguidas dos builds descartáveis, há quanto tempo as regras correm sem alterações, a trajetória de armazenamento antes e depois, e pelo menos um incidente ou quase-incidente com o conjunto de regras. Respostas que se limitem a repetir as predefinições de um fornecedor devem dizê-lo; respostas vindas de frotas muito grandes devem assinalar que partes dependem de ferramentas que uma equipa pequena não tem.