Jak testować infrastrukturę chmurową?

18 marca, 2021 Sebastian Kowalski

Coraz więcej serwisów jest hostowanych po stronie dostawców chmurowych. Wynika to z wielu korzyści, które daje przeniesienie infrastruktury do chmury, na przykład optymalizacja kosztów, skalowalność, elastyczność, łatwiejsze utrzymanie systemu  i możliwość szybszego wprowadzania w nim zmian.

Jednak w przypadku dużych systemów, ze skomplikowaną architekturą, pojawia się dodatkowe wyzwanie. Wszystkie elementy muszą być dobrze skonfigurowane, aby serwis działał poprawnie. Jak zatem sprawdzić, czy kluczowe ustawienia są właściwe?

Z pomocą przychodzą testy infrastruktury.

 

Czym jest testowanie infrastruktury chmurowej?

 

Testowanie infrastruktury jest to niefunkcjonalny rodzaj testów, który polega na porównaniu konkretnych wartości i parametrów dla zasobów serwisu z wartościami oczekiwanymi. Należy do testów niefunkcjonalnych, ponieważ sprawdza działanie systemu, a nie konkretnych funkcji.

Możesz na przykład upewnić się, czy rozmiar instancji jest odpowiedni dla danego środowiska, czy masz poprawnie skonfigurowany backup bazy danych w regionie zastępczym, czy alarmy są wywoływane odpowiednimi wydarzeniami lub, czy role tworzone w systemie nie mają zbyt szerokich uprawnień. Jeśli sprawdzisz, że tego typu konfiguracja jest ustawiona poprawnie, dowiesz się, czy na przykład nie płacisz za dużo za przewymiarowane instancje. W skrajnej sytuacji wykryjesz defekt, który będzie decydował o (nie)stabilności i/lub bezpieczeństwie systemu.

 

Dlaczego warto testować infrastrukturę?

Testy infrastruktury są dodatkowym elementem, dzięki któremu zwiększysz prawdopodobieństwo, że system zadziała. Oczywiście sprawdzenie samej konfiguracji środowiska nie wystarczy i nie zastąpi innych rodzajów i poziomów testów. Pomoże Ci jednak wykryć błędy, które są niewidoczne z punktu widzenia testów funkcjonalnych, na przykład wspomniany wyżej backup bazy danych w regionie zastępczym.

Dodatkowo, testy infrastruktury możesz, a nawet powinieneś automatyzować. Przy wykorzystaniu parametryzacji możesz je wykonywać na różnych środowiskach, opierając się na raz dodanej implementacji. Jeśli wykorzystasz do tego odpowiednie narzędzia, to możesz równocześnie dokumentować aktualne wymagania dotyczące środowisk. Zwolni Cię to z dodatkowych obowiązków utrzymywania „papierowych” wymagań dla systemu (np. na projektowym confluence’ie), które przeważnie szybko stają się nieaktualne.

 

 

Jak testowanie infrastruktury wpisuje się w proces QA?

 

Testy infrastruktury są testami niefunkcjonalnymi, dlatego nie wpisują się bezpośrednio w piramidę testów. Dla przypomnienia, piramida testów opisuje organizację różnych poziomów testów funkcjonalnych pod względem ich ilości na poszczególnych poziomach. Więcej o piramidzie testów przeczytasz tutaj.  I chociaż testowanie infrastruktury jest poza piramidą testów, to warto wykonywać takie testy tuż po wdrożeniu serwisów na środowisko, przed testami integracyjnymi i systemowymi. Dzięki temu oszczędzisz czas w przypadku problemów z infrastrukturą. Zamiast wykonywać kosztowne testy z wyższych poziomów piramidy, od razu dowiesz się, że musisz w pierwszej kolejności poprawić konfigurację środowiska.

Obrazuje to poniższy schemat:

 

Jak widzisz, jest to również dołożenie kolejnego elementu w całym procesie, natomiast automatyczne testy infrastruktury dla „gotowego” (wdrożonego) środowiska wykonują się bardzo szybko, zatem nie powinno to znacząco wydłużyć czasu wykonania całego pipeline’a.

 

 

Sposoby testowania infrastruktury chmurowej

 

Najprostszym, a jednocześnie najbardziej zawodnym sposobem, jest manualne sprawdzenie stanu zasobów środowiska po deploymencie. Ludzkie oko może nie wychwycić wszystkich błędów, dlatego opieranie się tylko na tej metodzie nie jest najlepszym pomysłem. Na szczęście istnieje sporo narzędzi umożliwiających weryfikację stanu infrastruktury.

Można je podzielić na dwa typy:

– narzędzia tworzące osobną przestrzeń roboczą (kopię aktualnego środowiska), na której są wykonywane testy infrastruktury

– narzędzia, które operacje wykonują na wskazanym środowisku, bez tworzenia jego dodatkowej kopii.

 

Na końcu przebieg testu dla tych dwóch typów wygląda podobnie, czyli pobierane są wartości aktualnych parametrów i porównywane z oczekiwaniami. Natomiast to, czy zechcesz stworzyć dodatkową przestrzeń roboczą, zależy od podejścia i procesu zdefiniowanego w konkretnym projekcie.

 

 

Case study

 

A w jaki sposób podeszliśmy do testowania infrastruktury w rzeczywistym projekcie? I czego nauczyliśmy się w trakcie?

Najpierw musieliśmy wybrać odpowiednie narzędzie.

Ponieważ klient korzysta z infrastruktury AWS, najważniejsze było znalezienie narzędzia, które wspiera właśnie tego cloud providera. Zależało nam też na dobrej dokumentacji, aby sprawnie używać narzędzia w konkretnych przypadkach. Ponadto, nie chcieliśmy równolegle tworzyć dodatkowych przestrzeni roboczych jedynie w celu wykonania testów infrastruktury, ponieważ taka opcja była już dostępna w ramach zdefiniowanego w projekcie procesu dla pozostałych rodzajów testów, zatem zwiększyłoby to niepotrzebnie koszty.

Te wymagania spełniał Inspec, który jest open source’owym narzędziem wspierającym nie tylko serwisy AWS, ale również Azure oraz GCP. Umożliwia on pobranie aktualnie ustawionych parametrów serwisów chmurowych, które następnie możemy porównać z oczekiwaniami za pomocą asercji i matcherów. Pozwoliło nam to na sprawdzenie stanu naszego serwisu: czy jest dobrze skonfigurowany, czy nowe zmiany, które wprowadzamy, nie spowodują problemów z tym, co już do tej pory działało.

Wykorzystując Inspec’a wymagania infrastruktury dla konkretnych środowisk możemy utrzymywać w formie JSON, np.:

 

 

 

 

Które po wczytaniu mogą być sprawdzane w następujący sposób:

 

 

Dzięki temu Inspec potwierdza, że wartości z pliku JSON dla konkretnych elementów pokrywają się z tym co jest aktualnie ustawione w zdeployowanym systemie.

 

Niestety, z czasem okazało się, że Inspec już nam nie wystarcza.

 

Dlaczego? Największym problemem była implementacja testów z wykorzystaniem języka Ruby, gdzie zarówno serwis jak i wszystkie pozostałe rodzaje i poziomy testów były implementowane za pomocą Pythona. Dodatkowo niektóre z ustawień systemu które chcieliśmy sprawdzać nie były wspierane domyślnie przez Inspec’a. Z tego względu z czasem zaczęliśmy wprowadzać własne rozwiązanie z wykorzystaniem bibliotek Pythona – Boto3 oraz Behave. Boto3 służy do komunikacji z serwisami AWS i pobiera aktualne wartości parametrów, które następnie możemy porównać z oczekiwaniami. Natomiast Behave pozwala na zastosowanie procesu BDD (Behavioral Driven Development) i wykorzystanie języka Gherkin do opisu wymagań dotyczących infrastruktury.

Przykładowa definicja z wykorzystaniem Gherkina może wyglądać w ten sposób:

 

 

 

Natomiast wykorzystanie tych wartości i ich porównanie z tym co aktualnie jest zdeployowane na środowisku może wyglądać tak:

 

 

 

Zastosowanie tych narzędzi wymagało większej ilości pracy i przygotowania struktury na etapie zmiany narzędzia, natomiast w dłuższej perspektywie zmiana się opłaciła. Po pierwsze, wszystkie testy są pisane w Pythonie oraz Boto3, który wspiera więcej parametrów w porównaniu do Inspeca. Oprócz tego dostajemy darmową dokumentację infrastruktury, która zawsze odpowiada temu, co rzeczywiście jest zdeployowane na środowiskach. Dzięki temu nie musimy się martwić o utrzymywanie statycznych dokumentów.

 

Obejrzyj case study TUTAJ.

 

Lessons learned, czyli czego się nauczyliśmy.

 

Testy infrastruktury, choć nie zastąpią nam pozostałych rodzajów testów, ale są bardzo ważne dla prawidłowego działania systemu. Docelowo pozwolą zaoszczędzić czas i pieniądze na wypadek problemów z infrastrukturą.

Pamiętaj jednak, aby już na początku projektu (zwłaszcza dużego) rozważnie wybrać narzędzie do testów infrastruktury. InSpec oraz inne narzędzia, mają wiele zalet, ale niestety mają swoje ograniczenia i mogą być niewystarczające do niektórych projektów, o czym zresztą przekonaliśmy się w zespole. W przyszłości wymagania mogą się zmienić, dlatego narzędzie łatwiejsze nie zawsze będzie dobrym wyborem. Lepiej zainwestować czas na dobre sprawdzenie dostępnych opcji, żeby w przyszłości uniknąć problematycznych i często kosztownych, zmian.

 

Praca tester automatyczny tester manualny

 

Najnowsze wpisy