Nasza firma jest w trakcie onboardingu zespołu SRE. Wszedłem w tę całą historię od strony deweloperskiej. W trakcie tego procesu wpadłem na przemyślenia i spostrzeżenia, którymi chcę się podzielić z innymi programistami. W tym artykule omawiam, co się dzieje, jak się dzieje i jak każdy może nadal z tym żyć.
Kontynuacja cyklu artykułów napisanych na podstawie wystąpień na naszym wewnętrznym wydarzeniu :
2. Infrastruktura jako kod. (Jesteś tutaj)
3. Generowanie kontraktów TypeScript z wykorzystaniem modeli C#. (W trakcie...)
4. Wprowadzenie do algorytmu konsensusu Raft. (W trakcie...)
...
Postanowiliśmy stworzyć zespół SRE, wdrażający pomysły . Rekrutowali programistów spośród własnych programistów i wysyłali ich na kilkumiesięczne szkolenie.
Zespół miał następujące zadania szkoleniowe:
- Opisz naszą infrastrukturę, która jest głównie na Microsoft Azure w formie kodu (Terraform i wszystko dookoła).
- Naucz programistów, jak pracować z infrastrukturą.
- Przygotuj programistów do obowiązków.
Wprowadzamy koncepcję infrastruktury jako kodu
W typowym modelu świata (administracja klasyczna) wiedza o infrastrukturze zlokalizowana jest w dwóch miejscach:
- Albo w formie wiedzy w głowach ekspertów.
- Lub te informacje znajdują się na niektórych maszynach do pisania, z których niektóre są znane ekspertom. Ale nie jest faktem, że osoba z zewnątrz (na wypadek nagłej śmierci całego naszego zespołu) będzie w stanie dowiedzieć się, co i jak działa. Na maszynie może znajdować się wiele informacji: akcesoria, cronjobs, zastraszenie (patrz. ) dysku i po prostu niekończąca się lista tego, co może się wydarzyć. Trudno zrozumieć, co się naprawdę dzieje.
W obu przypadkach wpadamy w pułapkę uzależnienia:
- lub od osoby śmiertelnej, podatnej na choroby, zakochania, wahania nastroju i po prostu banalne zwolnienia;
- lub z fizycznie pracującej maszyny, która również spada, zostaje skradziona i powoduje niespodzianki i niedogodności.
Jest rzeczą oczywistą, że w idealnym przypadku wszystko powinno zostać przetłumaczone na czytelny dla człowieka, łatwy w utrzymaniu i dobrze napisany kod.
Zatem infrastruktura jako kod (Incfastructure as Code - IaC) to opis całej istniejącej infrastruktury w postaci kodu, a także związanych z nią narzędzi do pracy z nią i wdrażania z niej prawdziwej infrastruktury.
Po co tłumaczyć wszystko na kod?Ludzie to nie maszyny. Nie są w stanie wszystkiego zapamiętać. Reakcja człowieka i maszyny jest inna. Wszystko, co jest zautomatyzowane, jest potencjalnie szybsze niż wszystko, co robi człowiek. Najważniejsze jest jedno źródło prawdy.
Skąd pochodzą nowi inżynierowie SRE?Postanowiliśmy więc zatrudnić nowych inżynierów SRE, tylko skąd ich wziąć? Książka z poprawnymi odpowiedziami () mówi nam: od programistów. W końcu pracują z kodem i osiągasz stan idealny.
Długo szukaliśmy ich na rynku personalnym poza naszą firmą. Musimy jednak przyznać, że nie znaleźliśmy nikogo, kto odpowiadałby naszym prośbom. Musiałem szukać wśród swoich ludzi.
Problemy Infrastruktura jako kod
Przyjrzyjmy się teraz przykładom, jak infrastrukturę można zakodować na stałe w kodzie. Kod jest dobrze napisany, wysokiej jakości, z komentarzami i wcięciami.
Przykładowy kod z Terraformy.
Przykładowy kod z Ansible.
Panowie, gdyby to było takie proste! Jesteśmy w prawdziwym świecie, który zawsze jest gotowy Cię zaskoczyć, przedstawić niespodzianki i problemy. Tutaj też nie może się bez nich obejść.
1. Pierwszy problem polega na tym, że w większości przypadków IaC to coś w rodzaju dsl.
A DSL to z kolei opis struktury. Dokładniej, co powinieneś mieć: Json, Yaml, modyfikacje kilku dużych firm, które wymyśliły własne dsl (w terraformie używany jest HCL).
Problem w tym, że łatwo może nie zawierać tak znanych rzeczy, jak:
- zmienne;
- warunki;
- gdzieś nie ma komentarzy, np. w Jsonie, domyślnie ich nie ma;
- Funkcje;
- i nawet nie mówię o tak ważnych sprawach, jak klasy, dziedziczenie i tak dalej.
2. Drugi problem z takim kodem polega na tym, że najczęściej jest to środowisko heterogeniczne. Zwykle siedzisz i pracujesz z C#, tj. z jednym językiem, jednym stosem, jednym ekosystemem. A tutaj masz ogromną różnorodność technologii.
Jest to bardzo realna sytuacja, gdy bash z Pythonem uruchamia jakiś proces, do którego wstawiany jest Json. Analizujesz to, a następnie jakiś inny generator tworzy kolejne 30 plików. Do tego wszystkiego z Azure Key Vault odbierane są zmienne wejściowe, które ściągane są w całość przez napisaną w Go wtyczkę do drone.io i te zmienne przechodzą przez yaml, który powstał w wyniku generacji z silnika szablonów jsonnet. Trudno jest mieć ściśle opisany kod, gdy masz tak zróżnicowane środowisko.
Tradycyjny rozwój w ramach jednego zadania wiąże się z jednym językiem. Tutaj pracujemy z dużą liczbą języków.
3. Trzecim problemem jest strojenie. Jesteśmy przyzwyczajeni do fajnych redaktorów (Ms Visual Studio, Jetbrains Rider), którzy robią wszystko za nas. A nawet jeśli jesteśmy głupi, powiedzą, że się mylimy. Wydaje się to normalne i naturalne.
Ale gdzieś w pobliżu znajduje się VSCode, w którym znajduje się kilka wtyczek, które w jakiś sposób są zainstalowane, obsługiwane lub nieobsługiwane. Pojawiły się nowe wersje, które nie były obsługiwane. Banalne przejście do implementacji funkcji (nawet jeśli istnieje) staje się problemem złożonym i nietrywialnym. Prosta zmiana nazwy zmiennej polega na jej odtworzeniu w projekcie kilkunastu plików. Będziesz miał szczęście, jeśli umieści to, czego potrzebujesz. Oczywiście tu i ówdzie jest podświetlenie, jest autouzupełnianie, gdzieś jest formatowanie (chociaż u mnie to nie działało w terraformie na Windowsie).
W momencie pisania tego tekstu nie zostały jeszcze wydane do obsługi wersji 0.12, mimo że są wydawane od 3 miesięcy.
Pora zapomnieć o...
- Debugowanie.
- Narzędzie do refaktoryzacji.
- Automatyczne uzupełnianie.
- Wykrywanie błędów podczas kompilacji.
To zabawne, ale wydłuża to również czas programowania i zwiększa liczbę nieuniknionych błędów.
Najgorsze jest to, że jesteśmy zmuszeni myśleć nie o tym, jak zaprojektować, uporządkować pliki w foldery, rozłożyć, sprawić, aby kod był łatwy w utrzymaniu, czytelny itd., ale o tym, jak poprawnie napisać to polecenie, bo jakoś źle to napisałem .
Jako początkujący próbujesz nauczyć się terraform, a IDE w ogóle ci nie pomaga. Jeśli jest dokumentacja, wejdź i poszukaj. Ale jeśli wprowadzasz nowy język programowania, IDE powie ci, że istnieje taki typ, ale czegoś takiego nie ma. Przynajmniej na poziomie int lub string. Jest to często przydatne.
A co z testami?
Pytacie: „A co z testami, panowie programiści?” Poważni goście testują wszystko na produkcji i jest to trudne. Oto przykład testu jednostkowego modułu terraform ze strony internetowej .
Mają dobrą dokumentację. Zawsze lubiłem Microsoft za podejście do dokumentacji i szkoleń. Ale nie musisz być wujkiem Bobem, żeby zrozumieć, że nie jest to doskonały kod. Zwróć uwagę na walidację po prawej stronie.
Problem z testem jednostkowym polega na tym, że ty i ja możemy sprawdzić poprawność wyniku Jsona. Dorzuciłem 5 parametrów i dostałem obrus Json z 2000 liniami. Mogę przeanalizować, co się tutaj dzieje, potwierdzić wynik testu...
Trudno jest analizować Json w Go. A pisać trzeba w Go, bo terraform w Go to dobra praktyka do testowania w języku, w którym piszesz. Organizacja samego kodu jest bardzo słaba. Jednocześnie jest to najlepsza biblioteka do testowania.
Microsoft sam pisze swoje moduły, testując je w ten sposób. Oczywiście, że jest to oprogramowanie Open Source. Wszystko o czym mówię, możesz przyjechać i naprawić. Mogę usiąść i naprawić wszystko w tydzień, wtyczki kodu VS typu open source, terraformy, stworzyć wtyczkę dla jeźdźca. Może napisz kilka analizatorów, dodaj linters, udostępnij bibliotekę do testowania. Mogę zrobić wszystko. Ale nie to powinnam robić.
Najlepsze praktyki Infrastruktura jako kod
Przejdźmy dalej. Jeśli nie ma testów w IaC, IDE i tuning są złe, to powinny istnieć przynajmniej najlepsze praktyki. Właśnie poszedłem do Google Analytics i porównałem dwa zapytania: najlepsze praktyki Terraform i najlepsze praktyki C#.
Co widzimy? Bezlitosne statystyki nie są na naszą korzyść. Ilość materiału jest taka sama. Jeśli chodzi o programowanie w języku C#, jesteśmy po prostu zawaleni materiałami, mamy super najlepsze praktyki, istnieją książki pisane przez ekspertów, a także książki pisane na książkach przez innych ekspertów, którzy je krytykują. Morze oficjalnej dokumentacji, artykułów, szkoleń, a teraz także rozwoju open source.
Jeśli chodzi o żądanie IaC: tutaj próbujesz krok po kroku zbierać informacje z raportów highload lub HashiConf, z oficjalnej dokumentacji i licznych problemów na Githubie. Jak w ogóle dystrybuować te moduły, co z nimi zrobić? Wygląda na to, że to realny problem... Istnieje społeczność, panowie, gdzie na każde pytanie dostaniecie 10 komentarzy na Githubie. Ale to nie jest dokładnie.
Niestety, w tym momencie eksperci dopiero zaczynają się pojawiać. Jest ich na razie za mało. A sama społeczność spędza czas na podstawowym poziomie.
Dokąd to wszystko zmierza i co robić
Możesz rzucić wszystko i wrócić do C#, do świata jeźdźców. Ale nie. Po co w ogóle zawracałeś sobie tym głowę, skoro nie możesz znaleźć rozwiązania. Poniżej przedstawiam moje subiektywne wnioski. Możesz się ze mną kłócić w komentarzach, będzie ciekawie.
Osobiście stawiam na kilka rzeczy:
- Rozwój w tej dziedzinie następuje bardzo szybko. Oto harmonogram żądań dla DevOps.
Temat może i szumny, ale sam fakt, że kula rośnie daje pewną nadzieję.Jeśli coś tak szybko rośnie, to na pewno pojawią się mądrzy ludzie, którzy powiedzą Ci, co robić, a czego nie. Wzrost popularności powoduje, że może komuś uda się w końcu dodać wtyczkę do jsonnet dla vscode, która pozwoli przejść do implementacji funkcji, zamiast szukać jej poprzez ctrl+shift+f. W miarę rozwoju sytuacji pojawia się więcej materiałów. Wydanie przez Google książki o SRE jest tego doskonałym przykładem.
- Istnieją rozwinięte techniki i praktyki w zakresie konwencjonalnego rozwoju, które możemy z powodzeniem zastosować tutaj. Tak, istnieją niuanse związane z testowaniem i heterogenicznym środowiskiem, niewystarczającym narzędziem, ale zgromadzono ogromną liczbę praktyk, które mogą być przydatne i pomocne.
Banalny przykład: współpraca poprzez programowanie w parach. Rozpracowanie tego bardzo pomaga. Kiedy masz w pobliżu sąsiada, który również próbuje coś zrozumieć, razem zrozumiecie lepiej.
Zrozumienie, w jaki sposób przeprowadzana jest refaktoryzacja, pomaga ją przeprowadzić nawet w takiej sytuacji. Oznacza to, że nie możesz zmienić wszystkiego na raz, ale zmienić nazewnictwo, następnie zmienić lokalizację, a następnie możesz wyróżnić jakąś część, och, ale tutaj nie ma wystarczającej liczby komentarzy.
wniosek
Pomimo tego, że moje rozumowanie może wydawać się pesymistyczne, patrzę w przyszłość z nadzieją i szczerą nadzieją, że wszystko się ułoży dla nas (i Was).
W następnej kolejności przygotowywana jest druga część artykułu. Opowiem w nim o tym, jak próbowaliśmy zastosować zwinne praktyki programistyczne, aby ulepszyć nasz proces uczenia się i pracę z infrastrukturą.
Źródło: www.habr.com