Testowanie zasobów po wdrożeniu

6 min

Sprawdzając i wyświetlając podgląd wdrożenia Bicep, udało Ci się mieć pewność, że pliki Bicep zostaną pomyślnie wdrożone. Ale wdrożenie nie jest całą historią. Po zakończeniu wdrażania warto również sprawdzić, czy wdrożenie działa zgodnie z oczekiwaniami.

W tej lekcji poznasz testy, które można uruchomić po zakończeniu wdrażania. Dowiesz się również o wycofywaniu wdrożenia, jeśli wszystko nie okaże się zgodnie z oczekiwaniami.

Uruchamianie testów weryfikacyjnych kompilacji i testów ujemnych

Podczas definiowania zasobów w pliku Bicep twoim celem nie jest tylko tworzenie zasobów na platformie Azure. Jest to dostarczanie wartości do organizacji przy jednoczesnym spełnieniu wymagań organizacji. Podczas weryfikowania i wyświetlania podglądu plików Bicep zyskujesz pewność, że definicje zasobów są prawidłowe, ale niekoniecznie wiesz, że zasoby rzeczywiście będą robić to, co chcesz.

Załóżmy na przykład, że wdrażasz nowy serwer logiczny usługi Azure SQL przy użyciu potoku wdrażania Bicep. Definicja Bicep dla serwera jest prawidłowa, dlatego przekazuje etapy linter i walidacji wstępnej. Polecenie analizy co-jeżeli pokazuje, że serwer zostanie utworzony, co można oczekiwać. Wdrożenie zakończy się również pomyślnie. Jednak na końcu procesu wdrażania nadal może nie być uruchomiony serwer bazy danych, który jest gotowy do użycia. Przyczyny mogą obejmować:

Nie skonfigurowano reguł zapory, aby zezwolić na ruch sieciowy do serwera.
Włączono uwierzytelnianie microsoft Entra na serwerze, jeśli nie powinno być możliwe lub na odwrót.

Nawet w przypadku wdrażania podstawowych plików Bicep warto rozważyć, w jaki sposób można sprawdzić, czy wdrażane zasoby działają faktycznie i spełniają wymagania. Oto przykłady zastosowania tej zasady:

Podczas wdrażania witryny internetowej spróbuj uzyskać dostęp do aplikacji internetowej z potoku. Sprawdź, czy potok łączy się z witryną internetową pomyślnie i otrzymuje prawidłowy kod odpowiedzi.
Podczas wdrażania sieci dostarczania zawartości (CDN) spróbuj nawiązać połączenie z zasobem za pośrednictwem sieci CDN. Sprawdź, czy potok łączy się z usługą CDN pomyślnie i otrzymuje prawidłowy kod odpowiedzi.

Te testy są czasami nazywane testami weryfikacyjnymi kompilacji infrastruktury. Testowanie weryfikacyjne kompilacji to prosta forma testowania przeznaczona do wykrywania poważnych problemów we wdrożeniu.

Uwaga

Niektóre zasoby platformy Azure nie są łatwe do uzyskania z agenta potoku hostowanego przez firmę Microsoft. Może być konieczne rozważenie użycia własnego agenta do uruchamiania etapów testu weryfikacyjnego kompilacji, jeśli wymagają one dostępu do zasobów za pośrednictwem sieci prywatnych.

Dobrym pomysłem jest również przeprowadzenie negatywnych testów. Testy negatywne pomagają potwierdzić, że zasoby nie mają niepożądanego zachowania. Na przykład podczas wdrażania maszyny wirtualnej warto używać usługi Azure Bastion do bezpiecznego łączenia się z maszyną wirtualną. Możesz dodać do potoku test ujemny, aby sprawdzić, czy nie można nawiązać połączenia z maszyną wirtualną bezpośrednio przy użyciu połączenia pulpitu zdalnego lub protokołu SSH.

Ważne

Celem tych testów nie jest sprawdzenie, czy Bicep prawidłowo wdrożył zasoby. Przy użyciu Bicep przyjmujesz założenie, że wdroży zasoby określone w plikach Bicep. Zamiast tego celem jest sprawdzenie, czy zdefiniowane zasoby będą działać w danej sytuacji i spełnić wymagania.

Uruchamianie testów z usługi Azure Pipelines

Istnieje wiele sposobów uruchamiania testów w potoku. W tym module użyjemy narzędzia Pester, które jest narzędziem typu open source, które uruchamia testy napisane za pomocą programu PowerShell. Możesz użyć innej platformy testów, a nawet wybrać uruchamianie testów bez narzędzia testowego. Na przykład innym narzędziem testowym, które należy wziąć pod uwagę, jest psRule dla platformy Azure, które obejmuje wstępnie utworzone reguły i testy dla platformy Azure. Może ona uruchamiać walidację szablonów, a także uruchamiać testy względem wdrożonych zasobów platformy Azure. Połączymy się z elementem PSRule w podsumowaniu.

W przypadku korzystania z obsługiwanej platformy testowej usługa Azure Pipelines rozumie wyniki każdego testu. Wyświetla wyniki testu wraz z informacjami o przebiegu potoku i śledzi historię każdego testu w czasie. W następnym ćwiczeniu zobaczysz, jak można używać usługi Azure Pipelines z testami weryfikacyjnymi kompilacji infrastruktury.

Przekazywanie danych między krokami i etapami

Po podzieleniu potoku na wiele etapów każda z nich ponosi własną odpowiedzialność, czasami trzeba przekazywać dane między tymi etapami. Na przykład jeden etap może utworzyć zasób platformy Azure, z którego musi pracować inny etap. Aby móc przekazywać dane, drugi etap musi znać nazwę utworzonego zasobu. Na przykład etap testu weryfikacyjnego kompilacji musi uzyskać dostęp do zasobów wdrożonych przez etap wdrażania.

Plik Bicep wdraża zasoby, aby mógł uzyskać dostęp do właściwości zasobu i opublikować je jako dane wyjściowe wdrożenia. Dostęp do danych wyjściowych wdrożenia można uzyskać w potoku. W usłudze Azure Pipelines istnieje specjalna składnia umożliwiająca publikowanie zmiennych w celu udostępnienia ich na różnych etapach.

Najpierw musisz opublikować zmienną wyjściową dla etapu potoku. Aby wyświetlić zmienną, napiszesz specjalnie sformatowany ciąg do dziennika potoku, który usługa Azure Pipelines wie, jak zrozumieć. W poniższym przykładzie zmienna o nazwie myVariable jest ustawiona na wartość myValue:

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Usługa Azure Pipelines odczytuje i interpretuje ciąg z dziennika potoku i udostępnia wartość zmiennej jako dane wyjściowe. Tę wartość można połączyć z większą wyjątkiem skryptów, aby opublikować wartość danych wyjściowych wdrożenia Bicep jako zmienną wyjściową dla etapu potoku. Zobaczysz, jak wykonać ten skrypt w następnym ćwiczeniu.

Po drugie, musisz udostępnić zmienną zadaniu etapu testu weryfikacyjnego kompilacji. Zdefiniujesz zmienną dla zadania i użyjesz innego specjalnie sformatowanego ciągu YAML:

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

Teraz wszystkie kroki w zadaniu testu weryfikacyjnego kompilacji mogą uzyskiwać dostęp do wartości podobnej myVariable do dowolnej innej zmiennej przy użyciu składni $(myVariable). Użyjesz zmiennej w następnym ćwiczeniu.

Inne typy testów

Testy funkcjonalne i testy integracji są często używane do sprawdzania, czy wdrożone zasoby działają zgodnie z oczekiwaniami. Na przykład test integracji może połączyć się z witryną internetową i przesłać testową transakcję, a następnie poczekać, aby potwierdzić, że transakcja zakończy się pomyślnie. Korzystając z testów integracji, możesz przetestować rozwiązanie kompilowane przez zespół wraz z infrastrukturą, na której jest uruchomiona. W przyszłym module zobaczysz, jak można dodać te typy testów do potoku.

Istnieje również możliwość uruchamiania innych typów testów z potoku wdrażania, w tym testów wydajnościowych i testów penetracyjnych zabezpieczeń. Te testy wykraczają poza zakres tego modułu, ale mogą one dodać wartość do zautomatyzowanego procesu wdrażania.

Wycofywanie lub wycofywanie

Załóżmy, że potok pomyślnie wdraża zasoby, ale testy kończą się niepowodzeniem. Co należy zrobić?

Wcześniej w tym module przedstawiono, że usługa Azure Pipelines umożliwia tworzenie etapów wycofywania, które są uruchamiane po awarii poprzedniego etapu. Za pomocą tego podejścia można utworzyć etap wycofywania, gdy etap testu zgłasza nieoczekiwany wynik. Możesz również ręcznie wycofać zmiany lub ponownie uruchomić cały potok, jeśli uważasz, że awaria była spowodowana tymczasowym problemem, który został rozwiązany.

Uwaga

Po przesłaniu wdrożenia do usługi Azure Resource Manager możesz zażądać, aby usługa Resource Manager automatycznie ponownie uruchomić ostatnie pomyślne wdrożenie, jeśli zakończy się niepowodzeniem. W tym celu należy użyć kroku interfejsu wiersza polecenia platformy Azure w celu wdrożenia pliku i dodać --rollback-on-error parametr podczas przesyłania wdrożenia przy użyciu az deployment group create polecenia .

Często trudno jest wypracować kroki, które powinien wykonać etap wycofywania. Ogólnie rzecz biorąc, wdrożenia Bicep są złożone i nie jest łatwe do wycofywania zmian. Szczególnie trudno jest wycofać wdrożenie, gdy wdrożenie zawiera inne składniki.

Załóżmy na przykład, że potok wdraża plik Bicep definiujący bazę danych Azure SQL Database, a następnie dodaje dane do bazy danych. Czy po wycofaniu wdrożenia dane powinny zostać usunięte? Czy baza danych powinna zostać również usunięta? Trudno przewidzieć, jak każda awaria i każde wycofanie mogą mieć wpływ na uruchomione środowisko.

Z tego powodu wiele organizacji preferuje wycofywanie, co oznacza, że szybko naprawią przyczynę awarii, a następnie ponownie wdróż. Tworząc wysokiej jakości zautomatyzowany proces wdrażania i postępując zgodnie ze wszystkimi najlepszymi rozwiązaniami poznanym w tych ścieżkach szkoleniowych, będziesz w stanie szybko rozwiązać problemy i ponownie wdrożyć pliki Bicep przy zachowaniu wysokiej jakości.

Napiwek