Rekommendationer för taggning och versionshantering av containeravbildningar

När du skickar containeravbildningar till ett containerregister och sedan distribuerar dem behöver du en strategi för avbildningstaggning och versionshantering. I den här artikeln beskrivs 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 mindre version, 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 införa 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 användas för att tillämpa säkerhetskorrigeringar eller ramverksuppdateringar.

Exempel

Ett ramverksteam levererar version 1.0. De vet att de kommer att leverera uppdateringar, inklusive mindre uppdateringar. För att stödja stabila taggar för en viss huvudversion och delversion har de två uppsättningar med 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 bilder med stabila taggar till den senaste sammanfattningen som representerar den senaste stabila versionen av den versionen.

I det här fallet hanteras både större och mindre taggar kontinuerligt. Från ett basavbildningsscenario gör det möjligt för avbildningsägaren att tillhandahålla serviceavbildningar.

Ta bort otaggade manifest

Om en bild med en stabil tagg uppdateras tas den tidigare taggade avbildningen inte upp, 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 som uppstår 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 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 som är 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, bland annat:

• 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 byggsystemet? Måste du hitta den version som slutfördes samtidigt? I vilken tidszon befinner du dig? Är alla byggsystem kalibrerade till UTC?

• Git-incheckning – Den här metoden fungerar tills du börjar stödja basavbildningsuppdateringar. Om en basavbildningsuppdatering sker 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 semistabil 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 sammanfattningen lång, svår att läsa och okorrigerad med din byggmiljö.

• Bygg-ID – Det här alternativet kan vara bäst eftersom det sannolikt ä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 byggsystemets namn en variant på 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 attributet write-enabled till false. Den här metoden hindrar dig från att oavsiktligt ta bort en avbildning från registret och eventuellt störa 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 automatiskt rensa otaggade manifest eller olåsta bilder som är äldre än en angiven varaktighet, eller ange en kvarhållningsprincip för otaggade manifest.

Nästa steg

En mer detaljerad beskrivning av begreppen i den här artikeln finns i blogginlägget Docker Tagging: Best practices for tagging and versionsing docker images (Metodtips för taggning och versionshantering av Docker-avbildningar).

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