Infrastruktura jako kod i TDD

Infrastruktura jako kod mówi nam, abyśmy używali narzędzi automatyzujących twoje kompilacje. Świetny. Narzędzia takie jak ansible , szef kuchni , marionetka , stos soli i inne popychają nas do pisania o tym, jak wygląda infrastruktura, przy jednoczesnym usuwaniu różnic.

W stosie soli te bity nazywane są stanami . Jeśli stan nie odpowiada rzeczywistości, narzędzie to dla nas rozwiąże. Innymi słowy - piszemy test na naszą infrastrukturę, a jeśli test się nie powiedzie, narzędzie samodzielnie go naprawi. Przynajmniej taki jest pomysł.

XP uczy nas korzystania z TDD, a pytanie brzmi, czy dotyczy to infrastruktury? Oprzyrządowanie to sugeruje.

Mogę sobie wyobrazić kilka rodzajów testów, które mogą być bardzo przydatne.

Piszemy testy dymu, które są dołączone do wdrożonej usługi, aby zapewnić, że kompleksowa usługa działa i działa zgodnie z oczekiwaniami. Byłoby to wywołanie API lub / i sprawdzenie systemu, aby upewnić się, że to, co właśnie wdrożyliśmy, działa. Wiele z tych funkcji może być objętych tymi samymi stanami, ponieważ narzędzia takie jak ansible mają stany zapewniające działanie usługi.

Istnieje projekt Molekuła, która pozwala na uruchamianie poszczególnych ról (jak ansible wywołuje swoje stany) przeciwko dokerowi lub innemu tymczasowemu silnikowi wirtualizacji. To zmusza do rozdzielenia ról i pozwala na wykonywanie ich w oderwaniu od podręcznika podczas pracy nad nimi. Testy najczęściej pozwalają na kpowanie ze zmiennych, z którymi rola ma współpracować. Inne przykłady wydają się jednak duplikacją silnika ansible (twierdzenie, że plik należy do użytkownika ...).

ThoughtWorks tech radar teraz chwali narzędzi takich jak Inspec , serverspec lub Goss za sprawdzenie, czy serwer spełnia specyfikację. Ale piszemy specyfikację, prawda?

Czy jest sens w dalszym testowaniu infrastruktury, jeśli opisujemy infrastrukturę w stanach / rolach? Mogę podejrzewać, że staje się to bardziej wymagane w większych organizacjach, w których jeden zespół zapewnia specyfikację, a inne poniżej, lub jeśli istnieje duży zestaw ról, być może chcesz uruchomić ich podzbiór i uzyskać korzyści z testów? Próbuję zrozumieć, dlaczego napisałbyś test, gdybyś mógł mieć rolę / stan dla tego samego pytania.

Krótko mówiąc, widzę dwie kategorie testów dla twojej infrastruktury: 1) czy ma wszystko, czego potrzebujesz do uruchomienia aplikacji i 2) nie ma żadnych zbędnych rzeczy.

Przede wszystkim możesz traktować pakiet testowy swojego oprogramowania jako rodzaj „meta testu” dla swojej infrastruktury. Tak długo, jak tworzysz infrastrukturę od podstaw dla każdego uruchomienia testowego, a pakiet testowy działa całkowicie na tej infrastrukturze (tzn. Nie korzysta z usług zewnętrznych), fakt, że cały pakiet jest zielony, oznacza, że ​​twoja skodyfikowana infrastruktura jest wystarczająca .

Po drugie, szczególnie z punktu widzenia bezpieczeństwa, możesz pisać testy na swojej infrastrukturze. To znaczy, jeśli jedną częścią infrastruktury jest maszyna wirtualna z systemem Linux, możesz napisać test, który skanuje port w tej maszynie wirtualnej, aby upewnić się, że nie ma otwartych portów niezamierzonych, które mogły zostać zainstalowane przez niezamierzony apt-get installefekt uboczny . Lub możesz napisać testy, które sprawdzają, czy nieoczekiwane pliki zostały zmienione po zakończeniu właściwego pakietu testów. Lub możesz sprawdzić dane pswyjściowe swoich maszyn wirtualnych lub kontenerów Docker pod kątem nieoczekiwanych procesów i zbudować białe listy itp., A tym samym uzyskać automatyczne powiadomienie, jeśli jakiś pakiet innej firmy zmieni się w nieudokumentowany (lub niezauważony sposób) w pewnym uaktualnieniu.

Te dwa typy testów są w pewnym sensie podobne do tego, co i tak zrobiłbyś w klasycznych ustawieniach operacyjnych, tj. Hartowanie serwerów i sprawdzanie włamań, unikanie pełnego zasobu zasobów i tym podobne.

IMHO raczej nie ma potrzeby pisać testów TDD dla elementów całkowicie objętych specyfikacją stanu IaaC. Oznacza to, że skuteczność IaaC jest wątpliwa - dlaczego miałbyś z niej korzystać, jeśli tak?

Spojrzenie na to z innego, perspektywicznego IaaC (jeśli jest właściwie wykonane) obejmuje możliwości przetestowane i uznane za działające niezawodnie. Co czyni go atrakcyjnym i sprawia, że ​​pisanie testów dopasowania TDD jest zbędne.

Na przykład konfiguracja IaaC określająca system z zainstalowanym SSH zawiera już niezawodne sprawdzanie poprawności instalacji SSH, a jeśli nie, mechanizmy prawidłowej instalacji. Co powoduje, że test TDD sprawdza, czy SSH jest zainstalowany redundantny. Jeśli twoja konfiguracja IaaC określa również, że sshd ma zostać uruchomiony i nasłuchuje na określonym porcie, wówczas testy TDD dla sshd działającego i nasłuchującego na odpowiednim porcie również byłyby zbędne.

Zauważ, że moja odpowiedź nie dotyczy TDD ani żadnego innego rodzaju testu, który sprawdza, czy twoja konfiguracja IaaC jako całość pasuje do określonego celu. Jest to ważne i może być stosowane w testach TDD, CI lub podobnych podczas opracowywania specyfikacji IaaC - uważam, że odpowiedź @ AnoE ma zastosowanie w takim przypadku.

Wygląda na to, że wszyscy tutaj zakładają, że narzędzie IAC zawsze działa zgodnie z oczekiwaniami, ale mogę stwierdzić (z własnego doświadczenia), że nie zawsze tak jest, w przeciwnym razie test jednostkowy byłby w rzeczywistości bezużyteczny.

Pamiętam zdjęcie zatytułowane „Uruchomiono instrukcję Ansible, wszystko jest w porządku” z płonącym budynkiem w tle ...

Uruchamianie stanu deklaratywnego i utrzymywanie serwera w tym stanie deklarowanym to dwie różne rzeczy z mojego punktu widzenia i przynajmniej doświadczenia.

Szerokie i heterogeniczne środowisko, rozproszone na wiele DC, osiągalne przez sieć publiczną itp. Istnieje wiele powodów, dla których nie można zastosować stanu, w całości lub w części.

Z tych wszystkich powodów jest miejsce na test jednostkowy, który pozwala uzyskać migawkę aktualnego stanu serwera, który znowu może różnić się od stanu docelowego.

Powiedziałbym więc, że tak, testy jednostkowe są przydatne nawet w środowisku zarządzanym przez IAC.

EDYTOWAĆ

A co z regresją strony deweloperskiej bazy kodu IaC? więc wprowadzasz zmiany w kodzie w gałęzi deweloperskiej i łączysz go z gałęzią prod, mając nadzieję, że nie wszystko zepsujesz? Testy jednostkowe są tak cenne i zwykle proste do wdrożenia. Nie rozumiem, dlaczego kodować bez tej funkcji.

Odniesienie (po francusku przepraszam za to): https://fr.slideshare.net/logilab/testinfra-pyconfr-2017

Z mojego doświadczenia wynika, że ​​jedną z głównych różnic między deweloperami a operacjami są „duże obciążenia w czasie wykonywania”. Instalowanie pakietów w dużej mierze zależy od repozytoriów, sieci lub prawidłowych kluczy lub, powiedzmy, tworzenia nowego serwera w chmurze - zależy to od zasobów dostawcy.

Jeśli chodzi o obsługę administracyjną serwerów, nawet jeśli nie zmieniłeś kodu obsługi, twój obraz będzie ważny przez większość czasu, ale czasem nie. Myślę więc, że testowanie jest naprawdę niezbędne do zapewnienia działających obrazów.

Jeśli przejdziesz poza pojedyncze serwery, sytuacja stanie się jeszcze gorsza ... jak przetestujesz osiągalność w całych konfiguracjach sieciowych? W tym rozdzielczość DNS, routing i zapora ogniowa? Nawet jeśli interfejs API twoich dostawców IaaC działa zgodnie z oczekiwaniami (widziałem problemy z przewodami w tym obszarze), naprawdę lubię TDD w tym przypadku.

Ponieważ nie znalazłem żadnych narzędzi testujących w tym obszarze, napisaliśmy je w wolnym czasie: https://github.com/DomainDrivenArchitecture/dda-serverspec-crate

Myślę więc, że TDD jest naprawdę ważne w świecie DevOps!