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 wordt beschreven waar elke methode past tijdens de levenscyclus van de container:

• Stabiele tags : tags die u bijvoorbeeld opnieuw gebruikt 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 containerbuilds 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. Stabiel betekent eerder dat de afbeelding stabiel moet zijn voor de intentie van die versie. Om 'stabiel' te blijven, kan het worden uitgevoerd om beveiligingspatches of frameworkupdates toe te passen.

Voorbeeld

Een frameworkteam wordt versie 1.0 geleverd. Ze weten dat er updates worden verzonden, inclusief kleine updates. Ter 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 'nieuwste' of 'nieuwste' 1.*-versie.
• :1.0- een stabiele tag voor versie 1.0, zodat een ontwikkelaar zich kan binden aan updates van 1.0 en niet verder kan worden gerold naar 1.1 wanneer deze wordt uitgebracht.

Wanneer er updates voor de basisinstallatiekopieën beschikbaar zijn, of een ander 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 secundaire tags voortdurend onderhouden. Vanuit een basisinstallatiekopieënscenario kan de eigenaar van de installatiekopieën dan 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 periodiek niet-gemarkeerde manifesten verwijderen die het gevolg zijn van stabiele installatiekopieënupdates. U kunt bijvoorbeeld niet-gemarkeerde manifesten die ouder zijn dan een opgegeven duur automatisch opschonen of een bewaarbeleid instellen voor manifesten zonder vlag.

Unieke tags

Aanbeveling: gebruik unieke tags voor implementaties, met name in een omgeving die op meerdere knooppunten kan worden geschaald. U wilt waarschijnlijk 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.

Uniek taggen betekent simpelweg 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 methode is vrij gebruikelijk, omdat u duidelijk kunt zien wanneer de afbeelding is gemaakt. Maar hoe kunt u deze weer 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 doorvoeren : deze methode 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-doorvoer als in 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 uniek, is de samenvatting lang, moeilijk te lezen en niet gerelateerd aan uw build-omgeving.

• Build-id : deze optie is mogelijk het beste omdat deze waarschijnlijk incrementeel is en u hiermee terug kunt correleren met de specifieke build om alle artefacten en logboeken te vinden. Net als een manifestsamenvatt 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 variant op deze optie: <build-system>-<build-id>. U kunt bijvoorbeeld builds onderscheiden van het Jenkins-buildsysteem van het API-team en het Build-systeem van Azure Pipelines van het webteam.

Geïmplementeerde installatiekopietags vergrendelen

Als best practice raden we u aan om een geïmplementeerde installatiekopietag te vergrendelen door het kenmerk ervan write-enabled in te stellen op false. Op deze manier voorkomt u dat u per ongeluk een installatiekopieën uit het register verwijdert en mogelijk uw implementaties verstoort. 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. U kunt bijvoorbeeld niet-gemarkeerde manifesten of ontgrendelde afbeeldingen die ouder zijn dan een opgegeven duur automatisch opschonen of een bewaarbeleid instellen voor niet-gemarkeerde manifesten.

Volgende stappen

Zie het blogbericht Docker Tagging: Best practices voor het taggen en versiebeheer van Docker-installatiekopieën voor een gedetailleerdere bespreking van de concepten in dit artikel.

Zie Best practices voor Azure Container Registry om de prestaties en het rendabele gebruik van uw Azure-containerregister te maximaliseren.