Hallo,
ich bin gerade am Einrichten einer eigenen Containerregistry. Neben technischen Dingen beschäftigen mich gerade organisatorische Abläufe. Welche Erfahrungen habt ihr bisher mit der Gestaltung von Lebenszyklen von Images gemacht? Wenn Nutzer ein bestimmtes Containerimage mit bestimmten Tags wollen, ist es ja schnell in der Containerregistry bereit gestellt. Doch wie werde ich veraltete/ nicht mehr verwendete Images wieder los, wenn sie die entsprechenden Nutzer nicht selbst wieder löschen? Macht es vielleicht Sinn, Jedes Tag oder wenigstens jedes Containerimage mit einem Ablaufdatum zu versehen? Wäre eine regelmäßige Brauche-ich-noch Bestätigung durch Nutzer besser?
Viele Grüße Norman
Moin,
On Wed Mar 11, 2026 at 9:52 PM CET, N. Schwirz wrote:
Welche Erfahrungen habt ihr bisher mit der Gestaltung von Lebenszyklen von Images gemacht? Wenn Nutzer ein bestimmtes Containerimage mit bestimmten Tags wollen, ist es ja schnell in der Containerregistry bereit gestellt. Doch wie werde ich veraltete/ nicht mehr verwendete Images wieder los, wenn sie die entsprechenden Nutzer nicht selbst wieder löschen? Macht es vielleicht Sinn, Jedes Tag oder wenigstens jedes Containerimage mit einem Ablaufdatum zu versehen? Wäre eine regelmäßige Brauche-ich-noch Bestätigung durch Nutzer besser?
Oh hey, mein Fachgebiet.
Quelle: Ich bin Lead-Developer und Service-Owner für (unter anderem) eine selbstentwickelte Registry. https://github.com/sapcc/keppel
Was auf jeden Fall stimmt, ist, dass man darauf vorbereitet sein muss, dass Nutzer ihre Images selbst nicht löschen. Das passiert faktisch nie.
Für unsere eigenen Repos haben wir GC-Policies in der Form: (aus dem Gedächtnis, aus didaktischen Gründen leicht vereinfacht)
- Lösche alle ungetaggten Images, die älter als 3h sind - Schütze alle Images, die als /.*latest/ getaggt sind - Schütze die fünf neuesten Images pro Repo (nach Push-Timestamp) - Lösche alle Images, die länger als 28 Tage nicht gepullt wurden
Hierbei gewinnt pro Image die erste passende Regel in der präsentierten Reihenfolge. Mit der letzten Regel schützen wir alle Images, die aktiv im Einsatz sind, weil Audit-Prozesse alle Images von aktiven Containern regelmäßig auf bekannte Sicherheitslücken untersuchen. Also anstatt der expliziten "Brauche-ich-noch-Bestätigung" reicht halt aktiver Einsatz in einem Kubernetes-Cluster. Das ist kein perfektes System, weil Images auch woanders eingesetzt werden können, sei es auf Workstations oder in CI-Pipelines. Aber es ist im Großen und Ganzen gut genug.
Das alles ist empirisch ausreichend, um das Wachstum der Image-Menge auf sinnvolle Maße zu begrenzen (für unsere Organisationseinheit mit mehreren hundert Entwicklern und Admins sind wir bei Größenordnung 10k-20k Images). Eventuell muss ich irgendwann mal die "schütze die fünf neuesten Images"-Regel fallen lassen, aber ich glaube, dass die der wesentliche Grund ist, dass es auch mit dem Usecase "Image läuft nur auf Workstations oder in CI-Pipelines" gut geht, weil dort meistens die neuesten Images eingesetzt werden.
Für die Accounts von Kunden trifft das alles natürlich nicht zu. Da lösen wir das Problem hauptsächlich dadurch, dass Storage Geld kostet und die Kunden damit zumindest ein bisschen einen Anreiz haben, sich ebenfalls GC-Policies einzurichten. Wir haben einen automatischen Alarm, wenn Kunden mehr als 100k Images haben, und initiieren dann aktiv eine Kommunikation von unserer Seite, sofern die Kunden noch keine GC-Policies eingerichtet sind oder die Policies nicht optimal formuliert sind. Das wird meistens dankend angenommen.
Hope that helps.
Schöne Grüße Stefan
Hallo Stefan,
vielen Dank für die Antwort. Ich werde es wohl so machen, das das ich jeweils die Tags stable/ LTS-Version, old-stable und development vorhalte und alte Images ohne Tag automatisch nach einiger Zeit löschen lasse. Achja, und Tags werden spätestens zum EOL gelöscht. Bleibt nun nur noch die Frage ob Nutzer regelmäßig bestätigen müssen, das sie alle ihre Tags noch brauchen oder ob ich es lieber über den Speicherplatz mache.
Viele Grüße Norman
Am 11.03.26 um 23:37 schrieb Stefan Majewsky:
Moin,
On Wed Mar 11, 2026 at 9:52 PM CET, N. Schwirz wrote:
Welche Erfahrungen habt ihr bisher mit der Gestaltung von Lebenszyklen von Images gemacht? Wenn Nutzer ein bestimmtes Containerimage mit bestimmten Tags wollen, ist es ja schnell in der Containerregistry bereit gestellt. Doch wie werde ich veraltete/ nicht mehr verwendete Images wieder los, wenn sie die entsprechenden Nutzer nicht selbst wieder löschen? Macht es vielleicht Sinn, Jedes Tag oder wenigstens jedes Containerimage mit einem Ablaufdatum zu versehen? Wäre eine regelmäßige Brauche-ich-noch Bestätigung durch Nutzer besser?
Oh hey, mein Fachgebiet.
Quelle: Ich bin Lead-Developer und Service-Owner für (unter anderem) eine selbstentwickelte Registry. https://github.com/sapcc/keppel
Was auf jeden Fall stimmt, ist, dass man darauf vorbereitet sein muss, dass Nutzer ihre Images selbst nicht löschen. Das passiert faktisch nie.
Für unsere eigenen Repos haben wir GC-Policies in der Form: (aus dem Gedächtnis, aus didaktischen Gründen leicht vereinfacht)
- Lösche alle ungetaggten Images, die älter als 3h sind
- Schütze alle Images, die als /.*latest/ getaggt sind
- Schütze die fünf neuesten Images pro Repo (nach Push-Timestamp)
- Lösche alle Images, die länger als 28 Tage nicht gepullt wurden
Hierbei gewinnt pro Image die erste passende Regel in der präsentierten Reihenfolge. Mit der letzten Regel schützen wir alle Images, die aktiv im Einsatz sind, weil Audit-Prozesse alle Images von aktiven Containern regelmäßig auf bekannte Sicherheitslücken untersuchen. Also anstatt der expliziten "Brauche-ich-noch-Bestätigung" reicht halt aktiver Einsatz in einem Kubernetes-Cluster. Das ist kein perfektes System, weil Images auch woanders eingesetzt werden können, sei es auf Workstations oder in CI-Pipelines. Aber es ist im Großen und Ganzen gut genug.
Das alles ist empirisch ausreichend, um das Wachstum der Image-Menge auf sinnvolle Maße zu begrenzen (für unsere Organisationseinheit mit mehreren hundert Entwicklern und Admins sind wir bei Größenordnung 10k-20k Images). Eventuell muss ich irgendwann mal die "schütze die fünf neuesten Images"-Regel fallen lassen, aber ich glaube, dass die der wesentliche Grund ist, dass es auch mit dem Usecase "Image läuft nur auf Workstations oder in CI-Pipelines" gut geht, weil dort meistens die neuesten Images eingesetzt werden.
Für die Accounts von Kunden trifft das alles natürlich nicht zu. Da lösen wir das Problem hauptsächlich dadurch, dass Storage Geld kostet und die Kunden damit zumindest ein bisschen einen Anreiz haben, sich ebenfalls GC-Policies einzurichten. Wir haben einen automatischen Alarm, wenn Kunden mehr als 100k Images haben, und initiieren dann aktiv eine Kommunikation von unserer Seite, sofern die Kunden noch keine GC-Policies eingerichtet sind oder die Policies nicht optimal formuliert sind. Das wird meistens dankend angenommen.
Hope that helps.
Schöne Grüße Stefan
lug-dd@mailman.schlittermann.de
-
N. Schwirz -
Stefan Majewsky