Zalecenia dotyczące tagowania i przechowywania wersji obrazów kontenerów

Podczas wypychania obrazów kontenerów do rejestru kontenerów, a następnie wdrażania ich, potrzebna jest strategia tagowania i przechowywania wersji obrazów. W tym artykule omówiono dwa podejścia i miejsca, w których każdy pasuje do cyklu życia kontenera:

• Tagi stabilne — tagi używane ponownie, na przykład w celu wskazania wersji głównej lub pomocniczej, takiej jak mycontainerimage:1.0.
• Unikatowe tagi — inny tag dla każdego obrazu wypychanego do rejestru, na przykład mycontainerimage:abc123.

Stabilne tagi

Zalecenie: użyj stabilnych tagów, aby zachować podstawowe obrazy kompilacji kontenera. Unikaj wdrożeń ze stabilnymi tagami, ponieważ te tagi nadal otrzymują aktualizacje i mogą wprowadzać niespójności w środowiskach produkcyjnych.

Stabilne tagi oznaczają dewelopera lub system kompilacji, który może nadal ściągać określony tag, który nadal pobiera aktualizacje. Stabilna nie oznacza, że zawartość jest zamrożona. Raczej stabilna oznacza, że obraz powinien być stabilny dla intencji tej wersji. Aby zachować "stabilność", może być obsługiwane stosowanie poprawek zabezpieczeń lub aktualizacji struktury.

Przykład

Zespół platformowy jest dostarczany w wersji 1.0. Wiedzą, że będą dostarczać aktualizacje, w tym aktualizacje pomocnicze. Aby obsługiwać stabilne tagi dla danej wersji głównej i pomocniczej, mają dwa zestawy stabilnych tagów.

• :1 — stabilny tag wersji głównej. 1 reprezentuje wersję "najnowszą" lub "najnowszą" 1.*.
• :1.0— stabilny tag wersji 1.0, który umożliwia deweloperowi powiązanie z aktualizacjami wersji 1.0, a nie jest przekazywany do wersji 1.1 po jej wydaniu.

Gdy aktualizacje obrazu podstawowego są dostępne lub dowolny typ wersji obsługi platformy, obrazy ze stabilnymi tagami są aktualizowane do najnowszego skrótu, który reprezentuje najnowszą stabilną wersję tej wersji.

W takim przypadku zarówno główne, jak i pomocnicze tagi są stale obsługiwane. W scenariuszu obrazu podstawowego umożliwia to właścicielowi obrazu dostarczanie obrazów obsługiwanych.

Usuwanie nieotagowanych manifestów

Jeśli obraz ze stabilnym tagiem zostanie zaktualizowany, wcześniej oznaczony obraz jest nieotagowany, co spowoduje, że obraz jest oddzielony. Manifest poprzedniego obrazu i unikatowe dane warstwy pozostają w rejestrze. Aby zachować rozmiar rejestru, można okresowo usuwać nieotagowane manifesty wynikające z stabilnych aktualizacji obrazów. Na przykład automatyczne przeczyszczanie manifestów bez tagów starszych niż określony czas trwania lub ustawianie zasad przechowywania dla manifestów bez tagów.

Unikatowe tagi

Zalecenie: użyj unikatowych tagów dla wdrożeń, szczególnie w środowisku, które może być skalowane na wielu węzłach. Prawdopodobnie potrzebujesz celowych wdrożeń spójnych wersji składników. Jeśli kontener zostanie uruchomiony ponownie lub koordynator skalowa w poziomie więcej wystąpień, hosty nie będą przypadkowo ściągać nowszej wersji, niespójnej z innymi węzłami.

Unikatowe tagowanie oznacza po prostu, że każdy obraz wypychany do rejestru ma unikatowy tag. Tagi nie są ponownie używane. Istnieje kilka wzorców, które można wykonać, aby wygenerować unikatowe tagi, w tym:

• Sygnatura daty i godziny — takie podejście jest dość powszechne, ponieważ można wyraźnie określić, kiedy obraz został skompilowany. Jak jednak skorelować go z systemem kompilacji? Czy musisz znaleźć kompilację, która została ukończona w tym samym czasie? W jakiej strefie czasowej się znajdujesz? Czy wszystkie systemy kompilacji są skalibrowane do czasu UTC?

• Zatwierdzanie usługi Git — to podejście działa do momentu rozpoczęcia obsługi aktualizacji obrazu podstawowego. Jeśli wystąpi aktualizacja obrazu podstawowego, system kompilacji rozpocznie się z tym samym zatwierdzeniem usługi Git co poprzednia kompilacja. Jednak obraz podstawowy ma nową zawartość. Ogólnie rzecz biorąc, zatwierdzenie usługi Git zapewnia półstabilny tag.

• Skrót manifestu — każdy obraz kontenera wypychany do rejestru kontenerów jest skojarzony z manifestem identyfikowanym przez unikatowy skrót SHA-256 lub skrót. Mimo że skrót jest długi, trudny do odczytania i niekorzystywany w środowisku kompilacji.

• Identyfikator kompilacji — ta opcja może być najlepsza, ponieważ prawdopodobnie jest przyrostowa i umożliwia skorelowanie z określoną kompilacją w celu znalezienia wszystkich artefaktów i dzienników. Jednak jak skrót manifestu, może być trudne dla człowieka do odczytania.

  Jeśli organizacja ma kilka systemów kompilacji, prefiks tagu z nazwą systemu kompilacji jest odmianą tej opcji: <build-system>-<build-id>. Można na przykład odróżnić kompilacje od systemu kompilacji serwera Jenkins zespołu interfejsu API i systemu kompilacji usługi Azure Pipelines zespołu internetowego.

Blokowanie wdrożonych tagów obrazów

Najlepszym rozwiązaniem jest zablokowanie dowolnego wdrożonego tagu obrazu przez ustawienie jego write-enabled atrybutu na false. Ta praktyka uniemożliwia nieumyślne usunięcie obrazu z rejestru i prawdopodobnie zakłócanie wdrożeń. Możesz uwzględnić krok blokowania w potoku wydania.

Zablokowanie wdrożonego obrazu nadal umożliwia usunięcie innych, nieużywanych obrazów z rejestru przy użyciu funkcji usługi Azure Container Registry w celu obsługi rejestru. Na przykład automatyczne przeczyszczanie manifestów bez tagów lub odblokowanych obrazów starszych niż określony czas trwania lub ustawianie zasad przechowywania dla manifestów bez tagów.

Następne kroki

Aby uzyskać bardziej szczegółową dyskusję na temat pojęć w tym artykule, zobacz wpis w blogu Docker Tagging: Best practices for taging and versioning docker images (Najlepsze rozwiązania dotyczące tagowania i przechowywania wersji obrazów platformy Docker).

Aby pomóc zmaksymalizować wydajność i ekonomiczne wykorzystanie rejestru kontenerów platformy Azure, zobacz Najlepsze rozwiązania dotyczące usługi Azure Container Registry.