Stosowanie najlepszych rozwiązań przy użyciu modułu zestawu narzędzi do testowania

  • 5 min

Podczas tworzenia szablonów usługi Azure Resource Manager (szablonów usługi ARM) istnieją sposoby, aby ułatwić tworzenie prawidłowych szablonów i dostarczanie zaleceń w celu poprawy ich jakości. Więc jakie są te rekomendacje i dlaczego mogą być korzystne dla Twojego szablonu?

Istnieją zalecenia dotyczące różnych poziomów: wszystko, od parametrów i zmiennych, do zaleceń, które mają zastosowanie do zasobów. Spróbujmy spojrzeć na dane rekomendacje z wysokiego poziomu i zobaczmy, co można zyskać stosując się do nich:

  • Łatwość konserwacji Podczas opracowywania szablonu, od tworzenia go po raz pierwszy po jego aktualizację, utrzymanie porządku z czasem staje się wyzwaniem. Wraz ze wzrostem szablonu wykonaj parametry i zmienne. Ważne jest, aby zrozumieć, do czego służy każda z nich i jak należy ich odpowiednio używać.

    Wyobraź sobie scenariusz, w którym parametr jest źle nazwany i masz trudności z zrozumieniem, co robi. Możesz też użyć zakodowanej na stałe wartości, w której nie należy, a gdy coś się zmieni, usługi platformy Azure spadną. Wszystkie te problemy przyczyniają się do obciążenia konieczności zrozumienia i późniejszego odrzucenia tego, co patrzysz. Zachowanie dyscypliny podczas nadawania nazw elementom i utrzymanie czystości może pomóc w ograniczeniu skutków tych scenariuszy.

  • Poprawność Możesz spróbować nazwać wszystko we właściwy sposób, ale może być po prostu zbyt wiele reguł, aby śledzić. Takie sytuacje wymagają narzędzia, które przypomina o wszystkich tych przepisach i przepisach, i wymusza je.

  • Elastyczność Upewnij się, że szablony są wystarczająco elastyczne, aby można było z nich korzystać w dowolnym środowisku. Jeśli szablony nie są poprawnie sparametryzowane, mogą one nie być możliwe do ponownego użycia.

  • Rozszerzalność. Czasami chcesz dodać własne rekomendacje. Twoja firma lub zespół może mieć własne reguły wymuszania.

Uwaga

Sprawdzanie kodu pod kątem tego rodzaju zaleceń jest czasami nazywane linting.

Zestaw narzędzi do testowania szablonu usługi ARM

Użycie narzędzia do testowania jest dobrym pomysłem, ponieważ pozwala skupić się na tworzeniu, wiedząc, że narzędzie znajdzie wszystkie problemy i ulepszy szablony. Istnieje takie narzędzie: zestaw narzędzi do testowania szablonu usługi ARM, czasami nazywany arm-TTK. Rozwiązuje ono powyższe problemy, przeprowadzając serię testów. Testy są podzielone na następujące kategorie:

  • Weryfikowanie intencji użytkownika. Ta kategoria sprawdza, czy wszystkie zadeklarowane zmienne i parametry są używane oraz wyświetla ostrzeżenia, jeśli nie są.
  • Stosowanie rozwiązań z zakresu bezpieczeństwa Innym ważnym aspektem jest zapewnienie, że z szablonu nie zostaną zwrócone żadne poufne dane, jak na przykład wpisy tajne interfejsu API.
  • Korzystanie z odpowiednich konstrukcji językowych. Należy używać konstrukcji językowych lub funkcji pomocniczych, aby nie polegać na wartościach zakodowanych na stałe.

Uwaga

Są to rekomendacje, a nie wymagania. Jednak zdecydowanie zachęcamy do ich wykonania.

Instalowanie narzędzia

To narzędzie jest modułem programu PowerShell. Aby móc go uruchomić, należy wykonać następujące kroki:

  1. Zainstaluj program PowerShell. To zadanie jest wykonywane inaczej w zależności od tego, czy korzystasz z systemu Linux, Mac czy Windows.
  2. Pobierz moduł. Moduł jest hostowany w repozytorium GitHub. Możesz pobrać go z tego miejsca lub za pośrednictwem polecenia git clone.
  3. Zaimportuj moduł. Ten krok to tylko jednowierszowa instrukcja, która zostanie wprowadzona do sesji programu PowerShell, co spowoduje udostępnienie poleceń usługi ARM-TTK.

Zobaczysz, jak to zrobić w następnej lekcji. Po zainstalowaniu narzędzia możesz przystąpić do uruchamiania testów w szablonie.

Uruchamianie testów

Uruchomienie testów obejmuje wywołanie modułu z odpowiednimi parametrami. -TemplatePath jest obowiązkowym parametrem, który oczekuje ciągu wskazującego lokalizację pliku szablonu wdrożenia. Nazwa pliku szablonu musi mieć format azuredeploy.json lub maintemplate.json. Typowy przebieg testu może więc wyglądać podobnie do następującego polecenia:

Test-AzTemplate -TemplatePath path/to/template

Narzędzie testuje plik szablonu, a także testuje wszystkie pliki szablonów w tym samym katalogu i jego podfolderach.

Typowe dane wyjściowe z przebiegu testu mogą wyglądać następująco:

[+] adminUsername Should Not Be A Literal (24 ms)
[+] apiVersions Should Be Recent (18 ms)
[+] artifacts parameter (16 ms)
[+] DeploymentTemplate Schema Is Correct (17 ms)
[+] IDs Should Be Derived From ResourceIDs (15 ms)
[-] Location Should Not Be Hardcoded (41 ms)
     azuredeploy.json must use the location parameter, not resourceGroup().location (except when used as a default value in the main template)

Pomyślne testy są kodowane w kolorze zielonym i są poprzedzone prefiksem [+]. Testy nieudane są kodowane na czerwono z prefiksem [-].

Konfigurowanie przebiegu testu za pomocą parametrów testu

Do tej pory pokazano, jak dołączenie parametru -TemplatePath jest obowiązkowe podczas uruchamiania narzędzia. Dane narzędzie akceptuje również parametry opcjonalne. Te parametry umożliwiają uruchamianie określonych plików lub określonych testów. Użycie tych parametrów zapewnia bardziej szczegółową kontrolę podczas tworzenia, jak i debugowania szablonów.

Parametr -File służy do uruchamiania określonego pliku. Parametr -Test umożliwia określenie scenariusza testowego do uruchomienia.

Parametry można używać na następujące sposoby:

  • Uruchamianie testów dla pojedynczego pliku. Może być konieczne uruchomienie testów tylko dla pojedynczego pliku, nad którym aktualnie pracujesz. Przyczyną jest możliwość łatwiejszego skoncentrowania się na tworzeniu tego określonego pliku szablonu. Dodatkową korzyścią jest to, że dane wyjściowe będą zawierać mniej szumów i pokazywać tylko interesujące Cię elementy. Używając parametru -File ze ścieżką do pliku (w tym nazwy pliku), można uruchomić testy tylko w tym pliku.

    Ważne

    Parametr nadal oczekuje , że plik azuredeploy.json lub maintemplate.json będzie istnieć w określonej lokalizacji.

  • Uruchamianie pojedynczego typu testu dla wszystkich plików. Czasami warto uruchomić pojedynczy typ testu, aby upewnić się, że spełniasz kryteria tylko dla tego scenariusza. To zadanie można wykonać przy użyciu parametru -Test. Parametr oczekuje pełnej nazwy testu w cudzysłowie; na przykład Zasoby powinny mieć lokalizację.