Rekommendationer för taggning och versionshantering av containeravbildningar

När du push-överför containeravbildningar till ett containerregister och sedan distribuerar dem behöver du en strategi för avbildningstaggning och versionshantering. Den här artikeln beskriver två metoder och var var och en passar under containerns livscykel:

• Stabila taggar – Taggar som du återanvänder, till exempel för att ange en större eller delversion, till exempel mycontainerimage:1.0.
• Unika taggar – En annan tagg för varje avbildning som du skickar till ett register, till exempel mycontainerimage:abc123.

Stabila taggar

Rekommendation: Använd stabila taggar för att underhålla basavbildningar för dina containerversioner. Undvik distributioner med stabila taggar eftersom taggarna fortsätter att ta emot uppdateringar och kan introducera inkonsekvenser i produktionsmiljöer.

Stabila taggar innebär att en utvecklare, eller ett byggsystem, kan fortsätta att hämta en specifik tagg som fortsätter att hämta uppdateringar. Stabil betyder inte att innehållet är fruset. Stabil innebär i stället att avbildningen ska vara stabil för avsikten med den versionen. För att vara "stabil" kan det vara service för att tillämpa säkerhetskorrigeringar eller ramverksuppdateringar.

Exempel

Ett ramverksteam levererar version 1.0. De vet att de kommer att skicka uppdateringar, inklusive mindre uppdateringar. För att stödja stabila taggar för en viss högre och lägre version har de två uppsättningar stabila taggar.

• :1 – en stabil tagg för huvudversionen. 1 representerar den "senaste" eller "senaste" 1.* versionen.
• :1.0– en stabil tagg för version 1.0, vilket gör att en utvecklare kan binda till uppdateringar av 1.0 och inte rullas vidare till 1.1 när den släpps.

När basavbildningsuppdateringar är tillgängliga, eller någon typ av serviceversion av ramverket, uppdateras avbildningar med stabila taggar till den senaste sammanfattningen som representerar den senaste stabila versionen av den versionen.

I det här fallet hanteras både huvudtaggar och deltaggar kontinuerligt. Från ett basavbildningsscenario gör detta att avbildningsägaren kan tillhandahålla serviceavbildningar.

Ta bort otaggade manifest

Om en bild med en stabil tagg uppdateras tas inte den tidigare taggade avbildningen bort, vilket resulterar i en överbliven bild. Den tidigare avbildningens manifest och unika lagerdata finns kvar i registret. Om du vill behålla registerstorleken kan du regelbundet ta bort otaggade manifest till följd av stabila avbildningsuppdateringar. Du kan till exempel rensa otaggade manifest som är äldre än en angiven varaktighet, eller ange en kvarhållningsprincip för icke-taggade manifest.

Unika taggar

Rekommendation: Använd unika taggar för distributioner, särskilt i en miljö som kan skalas på flera noder. Du vill förmodligen ha avsiktliga distributioner av en konsekvent version av komponenter. Om containern startas om eller om en orkestrerare skalar ut fler instanser hämtar värdarna inte av misstag en nyare version, inkonsekvent med de andra noderna.

Unik taggning innebär helt enkelt att varje avbildning som skickas till ett register har en unik tagg. Taggar återanvänds inte. Det finns flera mönster som du kan följa för att generera unika taggar, inklusive:

• Datum-tidsstämpel – Den här metoden är ganska vanlig eftersom du tydligt kan se när avbildningen skapades. Men hur korrelerar du tillbaka det till ditt byggsystem? Måste du hitta den version som slutfördes samtidigt? Vilken tidszon befinner du dig i? Är alla dina byggsystem kalibrerade till UTC?

• Git-incheckning – Den här metoden fungerar tills du börjar stödja uppdateringar av basavbildningar. Om en basavbildningsuppdatering inträffar startar byggsystemet med samma Git-incheckning som föregående version. Basavbildningen har dock nytt innehåll. I allmänhet tillhandahåller en Git-incheckning en semi-stabil tagg.

• Manifestsammandrag – Varje containeravbildning som skickas till ett containerregister är associerad med ett manifest som identifieras av en unik SHA-256-hash eller sammandrag. Även om den är unik är sammandraget långt, svårt att läsa och okorrelerat med din byggmiljö.

• Bygg-ID – Det här alternativet kan vara bäst eftersom det förmodligen är inkrementellt och gör att du kan korrelera tillbaka till den specifika versionen för att hitta alla artefakter och loggar. Men som en manifestsammandrag kan det vara svårt för en människa att läsa.

  Om din organisation har flera byggsystem är prefixet för taggen med namnet på byggsystemet en variant av det här alternativet: <build-system>-<build-id>. Du kan till exempel skilja byggen från API-teamets Jenkins-byggsystem och webbteamets Azure Pipelines-byggsystem.

Lås distribuerade avbildningstaggar

Vi rekommenderar att du låser alla distribuerade avbildningstaggar genom att ange dess write-enabled attribut till false. Den här metoden förhindrar att du oavsiktligt tar bort en avbildning från registret och eventuellt stör dina distributioner. Du kan inkludera låsningssteget i versionspipelinen.

Om du låser en distribuerad avbildning kan du fortfarande ta bort andra, odistribuerade avbildningar från registret med hjälp av Azure Container Registry funktioner för att underhålla registret. Du kan till exempel rensa otaggade manifest automatiskt eller olåsta bilder som är äldre än en angiven varaktighet, eller ange en kvarhållningsprincip för icke-taggade manifest.

Nästa steg

En mer detaljerad beskrivning av begreppen i den här artikeln finns i blogginlägget Docker-taggning: Metodtips för taggning och versionshantering av Docker-avbildningar.

Information om hur du maximerar prestanda och kostnadseffektiv användning av azure-containerregistret finns i Metodtips för Azure Container Registry.