Grupowanie powiązanych zasobów przy użyciu modułów

Ukończone

Zaczęliśmy używać szablonów Bicep na potrzeby ostatnich uruchomień produktów i odniosliśmy sukces. Ponieważ zasoby zostały zadeklarowane w pliku szablonu, możesz szybko wdrożyć zasoby na potrzeby nowych uruchomień materiałów bez konieczności ręcznego konfigurowania zasobów w witrynie Azure Portal.

Menedżer IT może zobaczyć, że twój kod Bicep staje się coraz bardziej złożony i ma zdefiniowaną coraz większą liczbę zasobów, więc zapytał, czy kod jest bardziej modularyzowany. Możesz utworzyć pojedyncze pliki Bicep, nazywane modułami, dla różnych części wdrożenia. Główny szablon Bicep może odwoływać się do tych modułów. W tle moduły są transpilowane w jeden szablon JSON na potrzeby wdrożenia.

Moduły są również sposobem na jeszcze większe wielokrotne użycie kodu Bicep. Możesz mieć jeden moduł Bicep używany przez wiele innych szablonów Bicep.

Często trzeba również emitować dane wyjściowe z modułów i szablonów Bicep. Dane wyjściowe to sposób, w jaki kod Bicep wysyła dane z powrotem do osoby lub dowolnego innego użytkownika, który rozpoczął wdrożenie. Przyjrzyjmy się najpierw danych wyjściowych.

Uwaga

Polecenia w tej lekcji są wyświetlane w celu zilustrowania pojęć. Nie uruchamiaj jeszcze poleceń. Będziesz ćwiczyć to, czego nauczysz się tutaj wkrótce.

Dane wyjściowe

Użytkownik może ręcznie wdrożyć szablony Bicep lub wdrożyć go w jakimś zautomatyzowanym procesie wydawania. W obu przypadkach często istnieją pewne dane z szablonu, które należy wysłać z powrotem do każdego lub dowolnego użytkownika wykonującego wdrożenie szablonu.

Oto kilka przykładowych scenariuszy, w których może być konieczne pobranie informacji z wdrożenia szablonu:

• Utworzysz szablon Bicep, który wdraża maszynę wirtualną i musisz uzyskać publiczny adres IP, aby można było połączyć się z maszyną za pomocą protokołu SSH.
• Utworzysz szablon Bicep, który akceptuje zestaw parametrów, takich jak nazwa środowiska i nazwa aplikacji. Szablon używa wyrażenia, aby nazwać aplikację usługi aplikacja systemu Azure Service, którą wdraża. Musisz wyświetlić nazwę aplikacji, która została wdrożona, aby można było użyć jej w potoku wdrażania w celu opublikowania plików binarnych aplikacji.

W tych scenariuszach można użyć danych wyjściowych. Aby zdefiniować dane wyjściowe w szablonie Bicep, użyj słowa kluczowego output w następujący sposób:

output appServiceAppName string = appServiceAppName

Definicja danych wyjściowych zawiera kilka kluczowych części:

• Słowo output kluczowe informuje Bicep, że definiujesz dane wyjściowe.
• appServiceAppName to nazwa danych wyjściowych. Gdy ktoś pomyślnie wdroży szablon, wartości wyjściowe zawierają określoną nazwę, aby uzyskać dostęp do oczekiwanych wartości.
• string jest typem danych wyjściowych. Dane wyjściowe Bicep obsługują te same typy co parametry.
• Dla każdego danych wyjściowych należy określić wartość. W przeciwieństwie do parametrów dane wyjściowe zawsze muszą mieć wartości. Wartości wyjściowe mogą być wyrażeniami, odwołaniami do parametrów lub zmiennych albo właściwościami zasobów wdrożonych w pliku.

Napiwek

Dane wyjściowe mogą używać tych samych nazw co zmienne i parametry. Ta konwencja może być przydatna, jeśli utworzysz złożone wyrażenie w zmiennej do użycia w zasobach szablonu, a także musisz uwidocznić wartość zmiennej jako dane wyjściowe.

Oto kolejny przykład danych wyjściowych. Ta wartość będzie miała ustawioną na w pełni kwalifikowaną nazwę domeny (FQDN) zasobu publicznego adresu IP.

output ipFqdn string = publicIPAddress.properties.dnsSettings.fqdn

Napiwek

Spróbuj użyć właściwości zasobu jako danych wyjściowych, a nie założeń dotyczących zachowania zasobów. Jeśli na przykład musisz mieć dane wyjściowe adresu URL aplikacji usługi App Service, użyj właściwości aplikacji defaultHostName zamiast utworzyć ciąg dla adresu URL samodzielnie. Czasami te założenia nie są prawidłowe w różnych środowiskach lub sposób, w jaki zasób działa, więc bezpieczniej jest mieć zasób informujący o własnych właściwościach.

Uwaga

Nie twórz danych wyjściowych dla wartości wpisów tajnych, takich jak parametry połączenia lub klucze. Każda osoba mająca dostęp do grupy zasobów może odczytywać dane wyjściowe z szablonów. Istnieją inne podejścia, których można użyć do uzyskania dostępu do tajnych właściwości zasobów, które omówimy w późniejszym module.

Definiowanie modułu

Moduły Bicep umożliwiają organizowanie i ponowne używanie kodu Bicep przez utworzenie mniejszych jednostek, które można skomponować w szablon. Dowolny szablon Bicep może być używany jako moduł przez inny szablon. W tym module szkoleniowym utworzono szablony Bicep. Oznacza to, że już utworzono pliki, które mogą być używane jako moduły Bicep!

Załóżmy, że masz szablon Bicep, który wdraża zasoby aplikacji, bazy danych i sieci dla rozwiązania A. Ten szablon można podzielić na trzy moduły, z których każdy koncentruje się na własnym zestawie zasobów. Dodatkową zaletą jest ponowne użycie modułów w innych szablonach dla innych rozwiązań. dlatego podczas tworzenia szablonu dla rozwiązania B, który ma podobne wymagania sieciowe do rozwiązania A, można ponownie użyć modułu sieciowego.

Jeśli chcesz, aby szablon zawierał odwołanie do pliku modułu, użyj słowa kluczowego module . Definicja modułu wygląda podobnie do deklaracji zasobu, ale zamiast dołączać typ zasobu i wersję interfejsu API, użyjesz nazwy pliku modułu:

module myModule 'modules/mymodule.bicep' = {
  name: 'MyModule'
  params: {
    location: location
  }
}

Przyjrzyjmy się bliżej niektórym kluczowym częściom tej definicji modułu:

• Słowo module kluczowe informuje Bicep, że chcesz użyć innego pliku Bicep jako modułu.
• Podobnie jak zasoby, moduły potrzebują symbolicznej nazwy , takiej jak myModule. Nazwa symboliczna będzie używana podczas odwoływania się do danych wyjściowych modułu w innych częściach szablonu.
• modules/mymodule.bicep to ścieżka do pliku modułu względem pliku szablonu. Pamiętaj, że plik modułu jest tylko zwykłym plikiem Bicep.
• Podobnie jak zasoby, name właściwość jest obowiązkowa. Platforma Azure używa nazwy modułu, ponieważ tworzy oddzielne wdrożenie dla każdego modułu w pliku szablonu. Te wdrożenia mają nazwy, których można użyć do ich identyfikacji.
• Możesz określić dowolne parametry modułu przy użyciu słowa kluczowego params . Po ustawieniu wartości każdego parametru w szablonie można użyć wyrażeń, parametrów szablonu, zmiennych, właściwości zasobów wdrożonych w szablonie i danych wyjściowych z innych modułów. Bicep automatycznie zrozumie zależności między zasobami.

Moduły i dane wyjściowe

Podobnie jak w przypadku szablonów moduły Bicep mogą definiować dane wyjściowe. Wspólne jest łączenie modułów w ramach szablonu. W takim przypadku dane wyjściowe z jednego modułu mogą być parametrem dla innego modułu. Za pomocą modułów i danych wyjściowych można tworzyć zaawansowane i wielokrotnego użytku pliki Bicep.

Projektowanie modułów

Dobry moduł Bicep jest zgodny z pewnymi kluczowymi zasadami:

• Moduł powinien mieć jasny cel. Moduły umożliwiają zdefiniowanie wszystkich zasobów związanych z określoną częścią rozwiązania. Możesz na przykład utworzyć moduł zawierający wszystkie zasoby używane do monitorowania aplikacji. Możesz również użyć modułu, aby zdefiniować zestaw zasobów, które należą do siebie, podobnie jak wszystkie serwery bazy danych i bazy danych.

• Nie umieszczaj każdego zasobu we własnym module. Nie należy tworzyć oddzielnego modułu dla każdego wdrażanego zasobu. Jeśli masz zasób, który ma wiele złożonych właściwości, warto umieścić ten zasób we własnym module, ale ogólnie jest lepiej, aby moduły łączyły wiele zasobów.

• Moduł powinien mieć jasne parametry i dane wyjściowe, które mają sens. Rozważmy przeznaczenie modułu. Zastanów się, czy moduł powinien manipulować wartościami parametrów, czy też szablon nadrzędny powinien go obsłużyć, a następnie przekazać pojedynczą wartość do modułu. Podobnie pomyśl o danych wyjściowych, które powinien zwrócić moduł, i upewnij się, że są one przydatne dla szablonów, które będą używać modułu.

• Moduł powinien być jak najbardziej samodzielny. Jeśli moduł musi użyć zmiennej do zdefiniowania części modułu, zmienna powinna być ogólnie uwzględniona w pliku modułu, a nie w szablonie nadrzędnym.

• Moduł nie powinien zwracać wpisów tajnych. Podobnie jak w przypadku szablonów, nie twórz danych wyjściowych modułu dla wartości wpisów tajnych, takich jak parametry połączenia lub klucze.