Infrastruktura jako kod i TDD


11

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.

Odpowiedzi:


6

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.


Więc po pewnym czasie to właśnie postawiłem. Części wykonywane przez ansible nie są testowane same z siebie, ale skutki uboczne tych akcji są testowane przy użyciu goss. Na przykład RPM jest instalowany (ansible), a następnie testowany, czy oczekiwany plik domyślny jest zainstalowany, czy usługa działa i nasłuchuje określonego portu. Nie chcę automatycznie naprawiać takiego problemu, ale otrzymuję powiadomienie i zatrzymuję postęp. Jasne, że Ansible może przetestować system również dla Ciebie, po prostu musisz o tym wyraźnie powiedzieć, ale w naszym przypadku używamy gossdo testowania zachowania usługi w kontenerze
JackLeo

1

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.


Czy tak samo myślisz o tym, czy SSH (lub cokolwiek innego) jest włączony na określonym porcie niestandardowym, który jest analizowany z zewnętrznego pliku konfiguracyjnego? To nie spoczywa na testowanych urządzeniach, to nowatorska logika.
Jon Lauridsen,

1
Powinien być częścią IaaC, jeśli to obsługuje. Jeśli nie - ta dyskusja tak naprawdę nie ma zastosowania. Tak, to może przesuwać się w to, ile rzeczy może pokryć IaaC, ale to inna dyskusja.
Dan Cornilescu,

1
Zakładam również, że nie znajdujemy się w kontekście, w którym wymagane są kontrole redundantne - w niektórych przypadkach mogą być wymagane kontrole redundantne oparte na zupełnie innych ścieżkach kodu, a nawet infrastruktury.
Dan Cornilescu,

1

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


1
Byłoby co najmniej grzeczne, aby dodać komentarz z głosowaniem w dół, nie sądzisz, że głosujesz w dół? Zwłaszcza w przypadku tego rodzaju pytań, w których debata może być bardzo pouczająca lub nawet konstruktywna.
Pier

Zakładam, że ton twojej odpowiedzi, który jest dość agresywny dla wszystkich, którzy brali udział w tym pytaniu, dodał, że nie podałeś żadnego odniesienia z własnego przykładu ani nie opisałeś żadnej zaobserwowanej usterki, która była przyczyną odrzucającego. W końcu mówisz to samo, co mówią inne odpowiedzi, przeprowadzaj testy dymu w swoim systemie administracyjnym, aby upewnić się, że system działa poprawnie, co robi większość systemów, ponosząc awarię, jeśli nie mogą zsynchronizować systemu w pożądanym stanie. Jeśli chodzi o twoją edycję, zwykle scalanie odbywa się po wdrożeniu na etapie i upewnieniu się, że testy dymu przeszły
pomyślnie

Zdecydowanie nie zamierzałem być agresywny, nie używam tutaj mojego języka natibve (to chyba oczywiste :)).
Pier

Możemy to omówić na czacie DevOps, jeśli chcesz, myślę, że widziałem tę prezentację lub podobną na imprezie devoxx kilka lat temu. Nie zgadzam się z wywołaniem tego testu jednostkowego, to są bardziej testy funkcjonalne.
Tensibai

Ktoś z mojego zespołu programistów powiedział mi to samo, że to nie był test jednostkowy, nie jestem programistą, więc mogę się mylić, nazywając ten test jednostkowy, zdecydowanie
Pier

1

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!

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.