Publikowanie modułu w rejestrze prywatnym

4 min

Teraz rozumiesz, czym są rejestry Bicep i jak mogą one być przydatne podczas udostępniania modułów w organizacji. W tej lekcji dowiesz się, jak opublikować moduł w rejestrze prywatnym.

Ścieżki modułu

Podczas pracy z modułami w przeszłości prawdopodobnie użyto ścieżki pliku modułu do odwoływania się do niego w szablonach. Podczas pracy z modułami i prywatnymi rejestrami należy użyć innej ścieżki modułu, aby Bicep wiedział, jak zlokalizować moduł w rejestrze.

Oto przykładowa ścieżka modułu w prywatnym rejestrze kontenerów platformy Azure:

Diagram that shows the syntax for a module path.

Ścieżka zawiera cztery segmenty:

Schemat: Bicep obsługuje kilka typów modułów, które są nazywane schematami. W przypadku pracy z rejestrami Bicep schemat to br.
Rejestr: nazwa rejestru, który zawiera moduł, którego chcesz użyć. W poprzednim przykładzie nazwa rejestru to toycompany.azurecr.io, czyli nazwa rejestru kontenerów.
Identyfikator modułu: pełna ścieżka do modułu w rejestrze.
Tag: Tagi zazwyczaj reprezentują wersje modułów, ponieważ jeden moduł może mieć wiele wersji opublikowanych. Więcej informacji na temat tagów i wersji znajdziesz w następnej sekcji.

Podczas publikowania własnego identyfikatora modułu użyj znaczącego identyfikatora, który wskazuje cel modułu. Opcjonalnie możesz użyć przestrzeni nazw, w których używasz ukośników (/), aby odróżnić części nazwy. Jednak usługa Azure Container Registry i Bicep nie rozumieją hierarchii. Traktują identyfikator modułu jako pojedynczą wartość.

Tagi i wersje

Tag reprezentuje wersję modułu. Pojedynczy moduł w rejestrze może mieć wiele wersji. Wszystkie wersje współużytkują identyfikator modułu, ale mają różne tagi. W przypadku korzystania z modułu należy użyć tagu , aby określić wersję, której chcesz użyć, aby Bicep wiedział, który plik modułu ma zostać pobrany.

Dobrym pomysłem jest dokładne zaplanowanie sposobu, w jaki będą wersjonować moduły. Dwie kluczowe decyzje, które należy podjąć, to schemat przechowywania wersji i zasady przechowywania wersji do użycia.

Schematy przechowywania wersji

Schemat przechowywania wersji określa sposób generowania numerów wersji. Typowe schematy przechowywania wersji obejmują:

Podstawowe liczby całkowite mogą być używane jako numery wersji. Na przykład pierwsza wersja może mieć nazwę 1, drugą wersję 2itd. Możesz też dodać prefiks do każdego numeru wersji, takiego jak v1 i v2.
Daty również mają dobre numery wersji. Jeśli na przykład opublikujesz pierwszą wersję modułu 16 stycznia 2022 r., możesz nazwać wersję 2022-01-16 (przy użyciu formatu rrrr-mm-dd ). Podczas publikowania innej wersji 3 marca można ją 2022-03-03nazwać .
Semantyczne przechowywanie wersji to system przechowywania wersji często używany w oprogramowaniu, w którym pojedynczy numer wersji zawiera wiele części. Każda część sygnalizuje różne informacje o charakterze zmiany.

Chociaż można użyć dowolnego schematu przechowywania wersji, warto wybrać coś, co można posortować w zrozumiałą kolejność. Liczby i daty są często dobrymi wyborami.

Uwaga

Usługa Azure Container Registry przechowuje datę utworzenia każdego tagu. Nawet jeśli nie używasz przechowywania wersji opartych na dacie, nadal możesz zobaczyć te informacje.

Zasady przechowywania wersji

Moduły zapewniają elastyczność wyboru, kiedy utworzyć nowe wersje lub zaktualizować istniejącą wersję. Na przykład możesz skutecznie zrezygnować z przechowywania wersji, tworząc i publikując pojedynczą wersję o nazwie latest. Za każdym razem, gdy musisz zmienić moduł, wystarczy zaktualizować wersję. Chociaż te zasady działają, nie jest to dobre rozwiązanie.

Z drugiej strony, jeśli wprowadzisz niewielką zmianę w istniejącym module, który nie ma wpływu na sposób jego użycia, utworzenie nowej wersji prawdopodobnie nie jest dobrym pomysłem. Należy przekazać nowy numer wersji każdemu, kto korzysta z modułu.

Oto zasady przechowywania wersji, które często działają dobrze:

Za każdym razem, gdy wprowadzisz istotne zmiany w module, utwórz nową wersję. Istotne zmiany obejmują wszystkie elementy, które mogą mieć wpływ na kogoś, kto korzysta z modułu. Przykłady obejmują dodanie innego zasobu do modułu lub zmianę właściwości zasobu.
Za każdym razem, gdy wprowadzisz niewielkie zmiany w module, które są czasami nazywane poprawką, zaktualizuj istniejącą wersję modułu.
Usuń stare wersje, gdy nie są już istotne lub gdy nie chcesz, aby ktokolwiek z nich korzystał.

Napiwek

Rozważ użytkowników modułu i pamiętaj, aby zastanowić się, czego się spodziewają. Jeśli ktoś używa modułu wiele razy i otrzymuje jeden wynik, a następnie używa go ponownie po poprawce i otrzyma inny wynik, prawdopodobnie będzie zaskoczony. Staraj się unikać zaskakujących użytkowników.