Tworzenie i używanie modułów Bicep

Ukończone

Moduły są niezależnymi plikami Bicep. Zazwyczaj zawierają zestawy zasobów, które są wdrażane razem. Moduły mogą być używane z dowolnego innego szablonu Bicep.

Korzystając z modułów, można ponownie użyć kodu Bicep, a pliki Bicep mogą być bardziej czytelne i zrozumiałe, ponieważ są one skoncentrowane na konkretnym zadaniu. Główne szablony następnie tworzą wiele modułów razem.

Zalety modułów

W firmie z toy aprowizowano zasoby w chmurze przy użyciu wielu pojedynczych plików Bicep. W miarę upływu czasu te szablony znacznie rosną. W końcu masz monolityczny kod, który jest trudny do odczytania i nawigacji, a nawet trudniejsze do utrzymania.

Takie podejście wymusza również zduplikowanie części kodu, gdy chcesz użyć go ponownie w innych szablonach. Gdy coś zmienisz, musisz wyszukać i zaktualizować wiele plików.

Moduły Bicep pomagają sprostać tym wyzwaniom, dzieląc kod na mniejsze, bardziej zarządzane pliki, do których może się odwoływać wiele szablonów. Moduły zapewniają pewne kluczowe korzyści.

Możliwość ponownego zastosowania

Po utworzeniu modułu można użyć go ponownie w wielu plikach Bicep, nawet jeśli pliki są przeznaczone dla różnych projektów lub obciążeń. Na przykład podczas kompilowania jednego rozwiązania można utworzyć oddzielne moduły dla składników aplikacji, bazy danych i zasobów związanych z siecią. Następnie, gdy zaczniesz pracować nad innym projektem z podobnymi wymaganiami sieciowymi, możesz ponownie użyć odpowiedniego modułu.

Możesz nawet udostępniać moduły w zespole, w organizacji lub społeczności platformy Azure. Więcej informacji na temat udostępniania modułów Bicep znajdziesz w przyszłym module Microsoft Learn.

Hermetyzacja

Moduły pomagają zachować powiązane definicje zasobów razem. Na przykład podczas definiowania aplikacji usługi Azure Functions zazwyczaj wdrażasz aplikację, plan hostingu aplikacji i konto magazynu dla metadanych aplikacji. Te trzy składniki są definiowane oddzielnie, ale reprezentują logiczne grupowanie zasobów, więc warto zdefiniować je jako moduł.

W ten sposób główny szablon nie musi być świadomy szczegółów sposobu wdrażania aplikacji funkcji. Jest to odpowiedzialność za moduł.

Składalność

Po utworzeniu zestawu modułów można utworzyć je razem. Możesz na przykład utworzyć moduł, który wdraża sieć wirtualną, oraz inny moduł, który wdraża maszynę wirtualną. Zdefiniuj parametry i dane wyjściowe dla każdego modułu, aby można było pobrać ważne informacje z jednego modułu i wysłać je do drugiego.

Napiwek

Warto traktować moduły Bicep jako bloki konstrukcyjne, które można łączyć na różne sposoby w celu obsługi wdrożeń.

Funkcje

Czasami może być konieczne użycie modułów w celu uzyskania dostępu do niektórych funkcji. Na przykład można użyć modułów i pętli razem, aby wdrożyć wiele zestawów zasobów. Moduły umożliwiają również definiowanie zasobów w różnych zakresach w jednym wdrożeniu.

Tworzenie modułu

Moduł jest normalnym plikiem Bicep. Utworzysz go tak samo jak w przypadku dowolnego innego pliku Bicep.

Ogólnie rzecz biorąc, nie jest dobrym rozwiązaniem, aby utworzyć moduł dla każdego wdrażanego zasobu. Dobry moduł Bicep zwykle definiuje wiele powiązanych zasobów. Jeśli jednak masz złożony zasób z dużą ilością konfiguracji, warto utworzyć pojedynczy moduł w celu hermetyzacji złożoności. Takie podejście zapewnia proste i nieukończone szablony główne.

Dzielenie istniejącego szablonu Bicep na moduły

Możesz utworzyć duży szablon Bicep, a następnie zdecydować, że powinien zostać podzielony na moduły. Czasami jest oczywiste, jak należy podzielić duży plik Bicep. Może istnieć zestaw zasobów, które wyraźnie należą do modułu. Innym razem nie jest tak proste, aby określić zasoby, które powinny zostać zgrupowane w module.

Wizualizator Bicep może pomóc umieścić cały plik Bicep w perspektywie. Wizualizator jest zawarty w rozszerzeniu Bicep dla programu Visual Studio Code.

Aby wyświetlić wizualizator, otwórz Eksploratora programu Visual Studio Code, wybierz i przytrzymaj (lub kliknij prawym przyciskiem myszy) plik Bicep, a następnie wybierz polecenie Otwórz Bicep Visualizer. Wizualizator przedstawia graficzną reprezentację zasobów w pliku Bicep. Zawiera on wiersze między zasobami, aby pokazać zależności wykryte przez Bicep.

Możesz użyć wizualizatora, aby ułatwić podzielenie plików. Zastanów się, czy wizualizacja ilustruje wszystkie klastry zasobów. Warto przenieść te klastry do modułu razem.

Rozważmy na przykład następującą wizualizację dla pliku Bicep. Definiowane są dwa odrębne zestawy zasobów. Warto je zgrupować w oddzielne moduły bazy danych i sieci .

Wizualizacji

Grupowanie

Moduły zagnieżdżenia

Moduły mogą zawierać inne moduły. Korzystając z tej techniki zagnieżdżania, można utworzyć kilka modułów, które wdrażają małe zestawy zasobów, a następnie tworzyć je w większych modułach definiujących złożone topologie zasobów. Szablon łączy te elementy w artefakt możliwy do wdrożenia.

Napiwek

Chociaż istnieje możliwość zagnieżdżania wielu warstw modułów, może to stać się złożone. Jeśli wystąpi błąd lub coś innego pójdzie nie tak, trudniej jest wypracować, co należy naprawić, gdy masz wiele warstw zagnieżdżania.

W przypadku złożonych wdrożeń czasami warto używać potoków wdrażania do wdrażania wielu szablonów zamiast tworzenia pojedynczego szablonu, który wykonuje wszystko z zagnieżdżaniem. Więcej informacji na temat potoków wdrażania znajdziesz w przyszłym module Microsoft Learn.

Wybieranie dobrych nazw plików

Pamiętaj, aby użyć opisowej nazwy pliku dla każdego modułu. Nazwa pliku staje się identyfikatorem modułu. Ważne jest, aby współpracownicy mogli zrozumieć przeznaczenie modułu tylko po zapoznaniu się z nazwą pliku.

Używanie modułu w szablonie Bicep

Użyjesz modułu w szablonie Bicep przy użyciu słowa kluczowego module , takiego jak:

module appModule 'modules/app.bicep' = {
  name: 'myApp'
  params: {
    location: location
    appServiceAppName: appServiceAppName
    environmentType: environmentType
  }
}

Definicja modułu zawiera następujące składniki:

• Słowo kluczowe module.
• Nazwa symboliczna, na przykład appModule. Ta nazwa jest używana w tym pliku Bicep za każdym razem, gdy chcesz odwołać się do modułu. Nazwa symboliczna nigdy nie jest wyświetlana na platformie Azure.
• Ścieżka modułu, na przykład modules/app.bicep. Zazwyczaj jest to ścieżka do pliku Bicep w lokalnym systemie plików. W przyszłym module Microsoft Learn dowiesz się, jak można udostępniać moduły przy użyciu rejestrów i specyfikacji szablonów, które mają własne formaty ścieżki modułu.

  Napiwek

  Szablon usługi Azure Resource Manager (ARM) w formacie JSON można również użyć jako modułu. Ta możliwość może być przydatna, jeśli masz zestaw szablonów, które nie zostały jeszcze zmigrowane do Bicep.

• Właściwość name , która określa nazwę wdrożenia. Więcej informacji na temat wdrożeń znajdziesz w następnej sekcji.
• Właściwość params , w której można określić wartości parametrów, których oczekuje moduł. Więcej informacji na temat parametrów modułu znajdziesz w następnej lekcji.

Jak działają moduły

Zrozumienie, jak działają moduły, nie jest konieczne do ich używania, ale może pomóc w zbadaniu problemów z wdrożeniami lub wyjaśnić nieoczekiwane zachowanie.

Wdrożenia

Na platformie Azure wdrożenie to specjalny zasób reprezentujący operację wdrażania. Wdrożenia to zasoby platformy Azure, które mają typ Microsoft.Resources/deploymentszasobu . Podczas przesyłania wdrożenia Bicep należy utworzyć lub zaktualizować zasób wdrożenia. Podobnie podczas tworzenia zasobów w witrynie Azure Portal portal tworzy zasób wdrożenia w Twoim imieniu.

Jednak nie wszystkie zmiany w zasobach platformy Azure tworzą lub używają wdrożeń. Na przykład gdy używasz witryny Azure Portal do modyfikowania istniejącego zasobu, zwykle nie tworzy wdrożenia w celu wprowadzenia zmiany. Jeśli do wdrażania lub konfigurowania zasobów są używane narzędzia innych firm, takie jak Terraform, mogą nie tworzyć wdrożeń.

Podczas wdrażania pliku Bicep przy użyciu interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell można opcjonalnie określić nazwę wdrożenia. Jeśli nie określisz nazwy, interfejs wiersza polecenia platformy Azure lub program Azure PowerShell automatycznie utworzy nazwę wdrożenia na podstawie nazwy pliku szablonu. Jeśli na przykład wdrożysz plik o nazwie main.bicep, domyślną nazwą wdrożenia jest main.

W przypadku korzystania z modułów Bicep tworzy oddzielne wdrożenie dla każdego modułu. Właściwość określona name dla modułu staje się nazwą wdrożenia. Podczas wdrażania pliku Bicep zawierającego moduł tworzone są wiele zasobów wdrażania: jeden dla szablonu nadrzędnego i jeden dla każdego modułu.

Załóżmy na przykład, że utworzysz plik Bicep o nazwie main.bicep. Definiuje moduł o nazwie myApp. Podczas wdrażania pliku main.bicep tworzone są dwa wdrożenia. Pierwszy ma nazwę maini tworzy kolejne wdrożenie o nazwie myApp , które zawiera zasoby aplikacji.

Możesz wyświetlić i wyświetlić szczegóły zasobów wdrażania, aby monitorować stan wdrożeń Bicep lub wyświetlić historię wdrożeń. Jednak w przypadku ponownego użycia tej samej nazwy wdrożenia platforma Azure zastępuje ostatnie wdrożenie o tej samej nazwie. Jeśli chcesz zachować historię wdrażania, upewnij się, że używasz unikatowej nazwy dla każdego wdrożenia. Możesz uwzględnić datę i godzinę wdrożenia w nazwie, aby ułatwić jej unikatowość.

Wygenerowane szablony usługi ARM w formacie JSON

Podczas wdrażania pliku Bicep Bicep konwertuje go na szablon usługi ARM w formacie JSON. Ta konwersja jest również nazywana transpilacją. Moduły używane przez szablon są osadzone w pliku JSON. Niezależnie od liczby modułów dołączanych do szablonu zostanie utworzony tylko jeden plik JSON.

W przykładzie opisanym w poprzedniej sekcji Bicep generuje pojedynczy plik JSON, mimo że pierwotnie były dwa pliki Bicep.