¿Qué reglas de retención de imágenes mantienen pequeño un registro de contenedores sin borrar imágenes que todavía están desplegadas?

Pregunta abierta

La documentación de Distribution (citada) explica que las capas se almacenan una sola vez por dirección de contenido y se comparten entre manifiestos, que eliminar un manifiesto a través de la API solo elimina referencias, y que la recolección de basura elimina después los blobs que ningún manifiesto referencia, en una ejecución de marcado y barrido (mark-and-sweep) durante la cual el registro debería estar en modo de solo lectura. Los registros gestionados envuelven esto en reglas de ciclo de vida: la guía de ECR (citada) describe políticas que caducan las imágenes según la prioridad de la regla, en un plazo de unas 24 horas desde que se cumple la condición, y recomienda previsualizar qué imágenes caducaría una política antes de aplicarla.

Lo que la documentación no dice es qué reglas son seguras para un equipo que construye una imagen por cada commit, despliega por digest, y de vez en cuando hace un rollback semanas después:

• Caducidad basada en antigüedad o en cantidad («eliminar los manifiestos sin etiqueta con más de N días», «conservar los últimos N por repositorio») frente a reglas conscientes del despliegue, que consultan qué está referenciado actualmente por las cargas de trabajo en ejecución o por los registros de release.
• Cómo se separan las compilaciones de pull request y de rama de las compilaciones de release, de modo que las primeras puedan ser efímeras sin que ninguna regla llegue a afectar nunca a las segundas.
• Si la configuración de inmutabilidad de etiquetas, las imágenes firmadas o las attestations adjuntas como referrers cambian lo que una regla de ciclo de vida debe conservar. La guía de ECR (citada) indica que una imagen referenciada por una manifest list no puede caducar antes que la propia lista, y que los artefactos referrer caducan automáticamente junto con su imagen sujeto (subject image); si otros registros se comportan igual forma parte de la pregunta.
• Qué ocurrió cuando una regla resultó equivocada: ¿llegó a faltar una imagen necesaria para un rollback o para un análisis forense, y cómo se recuperó?
• A qué tasa de crecimiento mantuvieron las reglas al registro, y si el problema que motivó todo esto fue el coste de almacenamiento o la latencia de las descargas (pull).

Qué contiene una respuesta útil

El tipo de registro y su mecanismo de retención, las reglas exactas con su orden de aplicación, cómo se distinguen las imágenes de release de las compilaciones desechables, cuánto tiempo llevan las reglas sin cambiar, la trayectoria de almacenamiento antes y después, y al menos un incidente o un caso cercano al fallo con ese conjunto de reglas. Las respuestas que se limiten a repetir los valores por defecto de un proveedor deben decirlo; las respuestas provenientes de flotas muy grandes deben señalar qué partes dependen de herramientas de las que carece un equipo pequeño.