Javaslatok tárolólemezképek címkézéséhez és verziószámozásához
Amikor tárolórendszerképeket küld le egy tárolóregisztrációs adatbázisba, majd üzembe helyezi őket, a rendszerképek címkézésére és verziószámozására vonatkozó stratégiára van szükség. Ez a cikk két megközelítést tárgyal, és hogy hol illeszkednek a tároló életciklusa során:
- Stabil címkék – Olyan címkék, amelyeket újra felhasználhat például egy fő- vagy alverzió, például a mycontainerimage:1.0 jelzésére.
- Egyedi címkék – A beállításjegyzékbe leküldendő minden képhez más címke, például mycontainerimage:abc123.
Stabil címkék
Javaslat: Használjon stabil címkéket a tároló buildjeihez tartozó alaprendszerképek karbantartásához. Kerülje a stabil címkékkel rendelkező üzemelő példányokat, mert ezek a címkék továbbra is frissítéseket kapnak, és inkonzisztenciákat okozhatnak éles környezetekben.
A stabil címkék azt jelentik, hogy egy fejlesztő vagy egy buildrendszer továbbra is lekérhet egy adott címkét, amely továbbra is frissítéseket kap. A stabil nem jelenti azt, hogy a tartalom le van fagyasztva. A stabil azt jelenti, hogy a rendszerképnek stabilnak kell lennie az adott verzió szándékához. A "stabil" állapot megőrzése érdekében előfordulhat, hogy biztonsági javításokat vagy keretrendszerfrissítéseket kell alkalmazni.
Példa
A keretrendszer csapata az 1.0-s verziót szállítja. Tudják, hogy frissítéseket fognak szállítanának, beleértve az apró frissítéseket is. Egy adott fő- és alverzió stabil címkéinek támogatása érdekében két stabil címkével rendelkeznek.
:1– a főverzió stabil címkéje.1a "legújabb" vagy "legújabb" 1.* verziót jelöli.:1.0- egy stabil címke az 1.0-s verzióhoz, amely lehetővé teszi a fejlesztők számára, hogy az 1.0-s frissítésekhez kössenek, és a kiadásukkor ne legyenek továbbítva az 1.1-es verzióra.
Ha rendelkezésre állnak alaprendszerkép-frissítések, vagy a keretrendszer bármilyen karbantartási kiadása, a stabil címkékkel rendelkező rendszerképek a legújabb kivonatra frissülnek, amely az adott verzió legújabb stabil kiadását képviseli.
Ebben az esetben mind a fő, mind az alcímkék folyamatosan szervizelve vannak. Alaprendszerkép-forgatókönyv esetén ez lehetővé teszi, hogy a rendszerkép tulajdonosa szervizelt lemezképeket biztosítson.
Nem megjelölt jegyzékfájlok törlése
Ha egy stabil címkével rendelkező kép frissül, a korábban címkézett kép címkézetlen lesz, ami árva képet eredményez. Az előző rendszerkép jegyzékfájlja és egyedi rétegadatai a beállításjegyzékben maradnak. A beállításjegyzék méretének fenntartása érdekében rendszeres időközönként törölheti a stabil rendszerkép-frissítésekből származó, nem megjelölt jegyzékfájlokat. Például automatikusan törli a megadott időtartamnál régebbi, nem megjelölt jegyzékfájlokat, vagy beállíthat egy adatmegőrzési szabályzatot a nem megjelölt jegyzékfájlokhoz.
Egyedi címkék
Javaslat: Használjon egyedi címkéket az üzemelő példányokhoz, különösen olyan környezetben, amely több csomóponton is méretezhető. Valószínűleg az összetevők konzisztens verziójának szándékos üzembe helyezését szeretné. Ha a tároló újraindul, vagy egy vezénylő több példányt skáláz fel, a gazdagépek nem fognak véletlenül újabb verziót lekérni, amely nem konzisztens a többi csomóponttal.
Az egyedi címkézés egyszerűen azt jelenti, hogy a beállításjegyzékbe leküldett összes rendszerkép egyedi címkével rendelkezik. A címkék nem lesznek újra felhasználva. Az egyedi címkék létrehozásához számos mintát követhet, többek között a következőket:
Dátum-idő bélyeg – Ez a módszer meglehetősen gyakori, mivel egyértelműen megállapíthatja, hogy mikor készült a rendszerkép. De hogyan lehet korrelálni a buildrendszerrel? Meg kell találnia az egyidejűleg befejezett buildet? Melyik időzónában van? Minden buildrendszer utc-ra van kalibrálva?
Git commit – Ez a módszer addig működik, amíg el nem kezdi támogatni az alaprendszerkép-frissítéseket. Ha alaprendszerkép-frissítés történik, a buildrendszer ugyanazzal a Git-véglegesítéssel indul el, mint az előző build. Az alaprendszerkép azonban új tartalommal rendelkezik. A Git-véglegesítések általában egy félig stabil címkét biztosítanak.
Jegyzék-kivonat – A tárolóregisztrációs adatbázisba leküldett tárolórendszerképek egy egyedi SHA-256 kivonat vagy kivonat által azonosított jegyzékfájlhoz vannak társítva. Bár egyedi, a kivonat hosszú, nehezen olvasható, és nem felel meg a buildkörnyezetnek.
Buildazonosító – Ez a beállítás lehet a legjobb, mivel valószínűleg növekményes, és lehetővé teszi az adott buildhez való visszatérést az összes összetevő és napló megkereséséhez. A jegyzék-kivonathoz hasonlóan azonban nehéz lehet elolvasni az embert.
Ha a szervezet több buildrendszerrel is rendelkezik, a címke a buildrendszernévvel való előtagja a következő beállítás egyik változata:
<build-system>-<build-id>. Megkülönböztetheti például a buildeket az API-csapat Jenkins buildrendszerétől és a webcsapat Azure Pipelines-buildrendszerétől.
Telepített rendszerképcímkék zárolása
Ajánlott eljárásként javasoljuk, hogy zárolja az üzembe helyezett rendszerképcímkét úgy, hogy attribútumát értékre falseállítjawrite-enabled. Ez a gyakorlat megakadályozza, hogy véletlenül eltávolítson egy lemezképet a beállításjegyzékből, és esetleg megzavarja az üzemelő példányokat. A zárolási lépést belefoglalhatja a kiadási folyamatba.
Az üzembe helyezett rendszerképek zárolásával továbbra is eltávolíthat más, üzembe nem helyezett lemezképeket a beállításjegyzékből Azure Container Registry funkciókkal a beállításjegyzék fenntartásához. Például automatikusan kiürítheti a nem megjelölt jegyzékfájlokat vagy a nem zárolt képeket, amelyek régebbiek egy megadott időtartamnál, vagy beállíthat egy adatmegőrzési szabályzatot a nem megjelölt jegyzékfájlokhoz.
Következő lépések
A cikkben szereplő fogalmak részletesebb ismertetését a Docker-címkézés: Ajánlott eljárások a Docker-rendszerképek címkézéséhez és verziószámozásához című blogbejegyzésben találja.
Az Azure-tárolóregisztrációs adatbázis teljesítményének és költséghatékony használatának maximalizálása érdekében tekintse meg a Azure Container Registry ajánlott eljárásait.