Aanbevelingen voor het taggen en versiebeheer van containerinstallatiekopieën

Wanneer u containerinstallatiekopieën naar een containerregister pusht en deze vervolgens implementeert, hebt u een strategie nodig voor het taggen en versiebeheer van installatiekopieën. In dit artikel worden twee benaderingen besproken en waar elke benadering past tijdens de levenscyclus van de container:

• Stabiele tags : tags die u opnieuw gebruikt, bijvoorbeeld om een primaire of secundaire versie aan te geven, zoals mycontainerimage:1.0.
• Unieke tags : een andere tag voor elke installatiekopie die u naar een register pusht, zoals mycontainerimage:abc123.

Stabiele tags

Aanbeveling: Gebruik stabiele tags om basisinstallatiekopieën voor uw container-builds te onderhouden. Vermijd implementaties met stabiele tags, omdat deze tags updates blijven ontvangen en inconsistenties kunnen veroorzaken in productieomgevingen.

Stabiele tags betekenen dat een ontwikkelaar of een buildsysteem een specifieke tag kan blijven ophalen, die updates blijft ontvangen. Stabiel betekent niet dat de inhoud is geblokkeerd. In plaats daarvan impliceert stable dat de installatiekopieën stabiel moeten zijn voor de intentie van die versie. Om 'stabiel' te blijven, kan het worden onderhouden om beveiligingspatches of frameworkupdates toe te passen.

Opmerking

Een frameworkteam verzendt versie 1.0. Ze weten dat ze updates verzenden, inclusief kleine updates. Voor ondersteuning van stabiele tags voor een bepaalde primaire en secundaire versie hebben ze twee sets stabiele tags.

• :1 – een stabiele tag voor de primaire versie. 1 vertegenwoordigt de 1.*-versie 'nieuwste' of 'nieuwste'.
• :1.0- een stabiele tag voor versie 1.0, zodat een ontwikkelaar verbinding kan maken met updates van 1.0 en niet kan worden doorgestuurd naar 1.1 wanneer deze wordt uitgebracht.

Wanneer updates voor basisinstallatiekopieën beschikbaar zijn of elk type onderhoudsrelease van het framework, worden installatiekopieën met de stabiele tags bijgewerkt naar de nieuwste samenvatting die de meest recente stabiele release van die versie vertegenwoordigt.

In dit geval worden zowel de primaire als de secundaire tags voortdurend onderhouden. Vanuit een basisinstallatiekopieënscenario kan de eigenaar van de installatiekopieën service-installatiekopieën leveren.

Niet-gemarkeerde manifesten verwijderen

Als een afbeelding met een stabiele tag wordt bijgewerkt, wordt de eerder getagde afbeelding niet gemarkeerd, wat resulteert in een zwevende afbeelding. Het manifest en de unieke laaggegevens van de vorige installatiekopieën blijven in het register staan. Als u de registergrootte wilt behouden, kunt u regelmatig niet-gemarkeerde manifesten verwijderen die het gevolg zijn van stabiele installatiekopieënupdates. U kunt bijvoorbeeld manifesten zonder vlag automatisch opschonen die ouder zijn dan een opgegeven duur, of een bewaarbeleid instellen voor niet-gemarkeerde manifesten.

Unieke tags

Aanbeveling: Gebruik unieke tags voor implementaties, met name in een omgeving die op meerdere knooppunten kan worden geschaald. Waarschijnlijk wilt u opzettelijke implementaties van een consistente versie van onderdelen. Als uw container opnieuw wordt opgestart of als een orchestrator meer exemplaren uitschaalt, halen uw hosts niet per ongeluk een nieuwere versie op, inconsistent met de andere knooppunten.

Unieke tagging betekent gewoon dat elke installatiekopieën die naar een register worden gepusht, een unieke tag hebben. Tags worden niet opnieuw gebruikt. Er zijn verschillende patronen die u kunt volgen om unieke tags te genereren, waaronder:

• Datum-tijdstempel : deze benadering is vrij gebruikelijk, omdat u duidelijk kunt zien wanneer de installatiekopie is gemaakt. Maar hoe kunt u deze correleren met uw buildsysteem? Moet u de build vinden die tegelijkertijd is voltooid? In welke tijdzone bevindt u zich? Zijn al uw buildsystemen gekalibreerd naar UTC?

• Git-doorvoer : deze aanpak werkt totdat u updates van basisinstallatiekopieën gaat ondersteunen. Als er een update van de basisinstallatiekopieën plaatsvindt, wordt uw buildsysteem gestart met dezelfde Git-doorvoering als de vorige build. De basisinstallatiekopieën hebben echter nieuwe inhoud. Over het algemeen biedt een Git-doorvoer een semi-stabiele tag.

• Manifestsamenvating : elke containerinstallatiekopieën die naar een containerregister worden gepusht, zijn gekoppeld aan een manifest, geïdentificeerd door een unieke SHA-256-hash of digest. Hoewel dit uniek is, is de digest lang, moeilijk te lezen en niet gerelateerd aan uw buildomgeving.

• Build-id : deze optie kan het beste zijn, omdat deze waarschijnlijk incrementeel is en u hiermee kunt correleren met de specifieke build om alle artefacten en logboeken te vinden. Net als een manifestsamenvattering kan het echter moeilijk zijn voor een mens om te lezen.

  Als uw organisatie meerdere buildsystemen heeft, is het voorvoegsel van de tag met de naam van het buildsysteem een variatie op deze optie: <build-system>-<build-id>. U kunt bijvoorbeeld builds onderscheiden van het Jenkins-buildsysteem van het API-team en het Azure Pipelines-buildsysteem van het webteam.

Geïmplementeerde installatiekopietags vergrendelen

Als best practice raden we u aan een geïmplementeerde installatiekopietag te vergrendelen door het kenmerk in write-enabled te stellen op false. Deze procedure voorkomt dat u per ongeluk een installatiekopieën uit het register verwijdert en mogelijk uw implementaties onderbroken. U kunt de vergrendelingsstap opnemen in uw release-pijplijn.

Als u een geïmplementeerde installatiekopie vergrendelt, kunt u nog steeds andere, niet-geïmplementeerde installatiekopieën uit uw register verwijderen met behulp van Azure Container Registry-functies om uw register te onderhouden. Bijvoorbeeld: manifesten zonder vlag automatisch opschonen of ontgrendelde afbeeldingen die ouder zijn dan een opgegeven duur, of een bewaarbeleid instellen voor niet-gemarkeerde manifesten.

Volgende stappen

Zie het blogbericht Docker Tagging: Aanbevolen procedures voor het taggen en versiebeheer van Docker voor meer informatie over de concepten in dit artikel.

Raadpleeg de aanbevolen procedures voor Azure Container Registry om de prestaties en het rendabele gebruik van uw Azure-containerregister te maximaliseren.