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

  • Artykuł

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 miejsce, w których każde 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.

Tagi stabilne

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

Tagi stabilne oznaczają dewelopera lub system kompilacji, który może nadal ściągać określony tag, co w dalszym ciągu pobiera aktualizacje. Stabilne nie oznacza, że zawartość jest zamrożona. Raczej stabilne 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ół struktury jest dostarczany w wersji 1.0. Wiedzą, że będą dostarczać aktualizacje, w tym drobne aktualizacje. 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ę "latest" lub "latest" 1.*.
  • :1.0— stabilny tag dla wersji 1.0, który umożliwia deweloperowi powiązanie z aktualizacjami wersji 1.0 i nie można go przekazać 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 reprezentującego najbardziej stabilną wersję tej wersji.

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

Usuwanie nieoznakowanych manifestów

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

Tagi unikatowe

Zalecenie: używaj unikatowych tagów dla wdrożeń, szczególnie w środowisku, które może być skalowane w 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ójne z innymi węzłami.

Unikatowe tagowanie oznacza po prostu, że każdy obraz wypchnięty do rejestru ma unikatowy tag. Tagi nie są ponownie używane. Istnieje kilka wzorców, które można śledzić, 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ł utworzony. Ale jak skorelować go z systemem kompilacji? Czy musisz znaleźć kompilację, która została ukończona w tym samym czasie? W jakiej strefie czasowej jesteś? Czy wszystkie systemy kompilacji są skalibrowane do czasu UTC?

  • Zatwierdzenie 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 rozpoczyna się od tego samego zatwierdzenia 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. Chociaż jest to unikatowe, skrót jest długi, trudny do odczytania i nieskorelowany ze środowiskiem 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 przypadkowe usunięcie obrazu z rejestru i ewentualne zakłócenia wdrożeń. Krok blokowania można uwzględnić w potoku wydania.

Zablokowanie wdrożonego obrazu nadal umożliwia usunięcie innych, niewydajnych obrazów z rejestru przy użyciu funkcji Azure Container Registry do obsługi rejestru. Na przykład automatyczne przeczyszczanie nieoznakowanych manifestó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 zapoznać się z bardziej szczegółowym omówieniem pojęć w tym artykule, zobacz wpis w blogu Docker Tagging: Best practices for taging and versioning docker images (Tagowanie platformy Docker: 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 Azure Container Registry.