Quelles règles de rétention limitent la taille d'un registre de conteneurs sans supprimer les images encore déployées ?

Question ouverte

La documentation de Distribution (citée) explique que les couches sont stockées une seule fois, adressées par leur contenu et partagées entre manifestes, que supprimer un manifeste via l'API ne fait que retirer des références, et que le ramasse-miettes supprime ensuite les blobs qu'aucun manifeste ne référence, lors d'une passe de marquage-balayage pendant laquelle le registre devrait être en lecture seule. Les registres gérés intègrent ce fonctionnement à des règles de cycle de vie : le guide ECR (cité) décrit des politiques qui font expirer les images selon la priorité des règles, dans un délai d'environ 24 heures après qu'elles remplissent les critères, et recommande de prévisualiser les images qu'une politique ferait expirer avant de l'appliquer.

La documentation ne précise pas quelles règles sont sûres pour une équipe qui construit une image par commit, déploie par digest et effectue parfois un retour arrière plusieurs semaines plus tard :

• Une expiration fondée sur l'ancienneté ou le nombre (« supprimer les manifestes sans tag vieux de plus de N jours », « conserver les N derniers par dépôt »), comparée à des règles tenant compte des déploiements et vérifiant ce qui est actuellement référencé par les charges de travail en cours d'exécution ou par les enregistrements de versions publiées.
• La façon de séparer les builds de pull requests et de branches des builds de versions publiées, pour que les premiers puissent être éphémères sans qu'une règle ne s'applique jamais aux seconds.
• L'effet éventuel des paramètres d'immutabilité des tags, des images signées ou des attestations rattachées comme artefacts référents sur ce qu'une règle de cycle de vie doit conserver. Le guide ECR (cité) indique qu'une image référencée par une liste de manifestes ne peut pas expirer avant la liste elle-même, et que les artefacts référents expirent automatiquement avec l'image qu'ils concernent ; savoir si les autres registres se comportent de la même façon fait partie de la question.
• Ce qui s'est passé lorsqu'une règle était incorrecte : une image nécessaire à un retour arrière ou à une investigation numérique avait-elle disparu, et comment a-t-elle été récupérée ?
• Le taux de croissance auquel les règles ont permis de limiter le registre, et le problème à l'origine de leur adoption : coût du stockage ou latence de récupération des images.

Ce qu'une réponse utile contient

Le type de registre et son mécanisme de rétention, les règles exactes et leur ordre d'application, la façon de distinguer les images de versions publiées des builds jetables, la durée pendant laquelle les règles ont été utilisées sans modification, l'évolution du stockage avant et après, et au moins un incident ou quasi-incident lié à cet ensemble de règles. Les réponses qui ne font que reformuler les valeurs par défaut d'un fournisseur doivent le préciser ; celles qui proviennent de très grands parcs doivent indiquer quelles parties dépendent d'un outillage dont une petite équipe ne dispose pas.