We would like to enable the retention policy for our new Azure Container Registry (ACR) and are seeking clarification on how the policy behaves, specifically around untagged manifests and shared layers.

Question

Context: Services deployed in our AKS cluster reference container images by tag name. While reviewing our registry, we observed many untagged manifests and initially decided to clean them up. To do this, we implemented a custom cron job that deleted untagged manifests across all repositories in the ACR.

 

During this cleanup, we encountered an issue where some image layers that were still in use by tagged manifests were deleted. This resulted in ImagePullError failures in the cluster. After further review of the  documentation, we now understand the relationship between manifests and shared layers, and that our approach inadvertently removed layers still required by tagged images.

We are now considering enabling the native ACR retention policy to automatically delete untagged manifests. However, the documentation does not explicitly describe how shared layers are handled.

Specifically, we would like clarification on the following:

• If a manifest becomes untagged but its layers are still referenced by another tagged manifest, does the retention policy ensure that those layers are not deleted?
• Does the retention policy internally track layer references across manifests to prevent breaking existing tagged images?

Answer 1

@Anusha Rao Hoi Het lijkt erop dat je wat problemen ondervindt met Azure Container Registry (ACR) en ongetagde manifests. Laten we je vragen over het retentiebeleid en de omgang met gedeelde lagen eens nader bekijken.

Wat betreft ongetagde manifests en gedeelde lagen: Wanneer een manifest geen tag meer heeft, maar de lagen ervan nog steeds worden gebruikt door een ander getagd manifest, verwijdert het retentiebeleid die lagen niet. ACR houdt namelijk bij welke lagen worden gebruikt door middel van referentietelling. Als een laag nog steeds in gebruik is – oftewel, wordt gebruikt door een getagd manifest – blijft deze behouden, zelfs als het bijbehorende manifest geen tag meer heeft.

Over het bijhouden van laagreferenties: Ja, het retentiebeleid houdt rekening met laagreferenties tussen manifests. Dit betekent dat als er een bestaand getagd manifest is dat verwijst naar een laag van een ongetagd manifest, die lagen intact blijven en niet worden verwijderd door het retentiebeleid.

Houd de volgende belangrijke punten in gedachten wanneer je het retentiebeleid voor ongetagde manifests inschakelt:

Het retentiebeleid stelt je in staat om ongetagde manifests automatisch te verwijderen na een bepaalde periode, waardoor de opslagkosten voor ongebruikte artefacten worden verlaagd.

Ongetagde manifests vallen alleen onder het retentiebeleid als ze een tag hadden nadat het beleid was ingeschakeld.

Je kunt voorkomen dat bepaalde ongetagde manifests worden verwijderd door hun 'delete-enabled'-kenmerk op 'false' in te stellen.

Je kunt je retentiebeleid als volgt instellen:

Ga naar je Azure-containerregister in de Azure-portal.

Selecteer in het servicemenu onder 'Beleid' de optie 'Retentie (Preview)'.

Schakel het beleid in en geef een retentieperiode op tussen 0 en 365 dagen.

Hier zijn enkele links die je kunnen helpen om meer te weten te komen over ACR-beleid:

Een retentiebeleid instellen om ongetagde manifests te behouden

Hoe het retentiebeleid werkt

Een containerimage vergrendelen in een Azure-containerregister

Als je nog vragen hebt of meer uitleg nodig hebt, aarzel dan niet om contact met ons op te nemen! Hopelijk helpt dit je om je ACR effectief te beheren!

referenties

• Set a retention policy to retain untagged manifests
• How the retention policy works
• Lock a container image in an Azure container registry