W naszej firmie trwa proces onboardingu zespołu SRE. Zaczynałem tę przygodę od strony programowania. W trakcie tego procesu miałem przemyślenia i spostrzeżenia, którymi chciałbym podzielić się z innymi programistami. W tym artykule-refleksji mówię o tym, co się dzieje, jak to się dzieje i jak wszyscy powinni sobie z tym radzić w przyszłości.
Ciąg dalszy serii artykułów napisanych na podstawie wystąpień na naszym wewnętrznym wydarzeniu. :
2. Infrastructure as code. (Jesteś tutaj)
3. Generacja kontraktów Typescript na podstawie modeli C#. (W trakcie…)
4. Wprowadzenie do algorytmu konsensusu Raft. (W trakcie…)
…
Postanowiliśmy stworzyć zespół SRE, wcielając idee . Zatrudniliśmy programistów z naszego zespołu i wysłaliśmy ich na kilka miesięcy na szkolenie.
Przed zespołem stanęły następujące zadania edukacyjne:
- Opisać naszą infrastrukturę, która w przeważającej części znajduje się w Microsoft Azure, w formie kodu (Terraform i wszystko, co z tym związane).
- Nauczyć programistów pracy z infrastrukturą.
- Przygotować programistów do dyżurów.
Wprowadzamy pojęcie Infrastructure as code
W klasycznym modelu świata (klasycznym administracji) wiedza o infrastrukturze znajduje się w dwóch miejscach:
- Albo w głowach ekspertów.
- Albo te informacje znajdują się na różnych maszynach, z których część zna tylko ekspert. Ale nie ma pewności, że osoba z zewnątrz (w przypadku, gdyby nasz zespół nagle umarł) zdoła zrozumieć, co i jak działa. Na maszynie może być wiele informacji: dostępów, cron jobów, podmontowanego (zobacz ) dysku i po prostu nieskończony wykaz tego, co może się dziać. Ciężko jest zrozumieć, co w rzeczywistości się dzieje.
W obu przypadkach znajdujemy się w pułapce, stając się zależnymi:
- albo od człowieka, który jest śmiertelny, podatny na choroby, zakochania, wahania nastroju, a także po prostu na banalne zwolnienia;
- albo od fizycznie działającej maszyny, która również może się zepsuć, zostać skradziona, stwarzać niespodzianki i niewygody.
Naturalnie nasuwa się rozwiązanie, aby w idealnym świecie wszystko przekuć w kod zrozumiały dla ludzi, łatwy do utrzymania i dobrze napisany.
Tak więc infrastruktura jako kod (Infrastructure as Code – IaC) to opis całej istniejącej infrastruktury w postaci kodu oraz towarzyszące narzędzia do pracy z nim i przekształcania go w rzeczywistą infrastrukturę.
Dlaczego warto wszystko zamieniać na kodLudzie to nie maszyny. Nie mogą zapamiętać wszystkiego. Reakcja człowieka i maszyny jest różna. Wszystko, co jest zautomatyzowane, zazwyczaj działa szybciej niż to, co robi człowiek. Najważniejsze to mieć jedno źródło prawdy (single source of truth).
Skąd biorą się nowi inżynierowie SREZdecydowaliśmy się na zatrudnienie nowych inżynierów SRE, ale skąd ich wziąć? Książka z poprawnymi odpowiedziami () mówi: od programistów. Pracują z kodem, a ty osiągasz idealny stan.
Dużo szukaliśmy ich na rynku pracy poza naszą firmą. Ale musimy przyznać, że nie znaleźliśmy żadnego, który spełniałby nasze wymagania. Musieliśmy rozejrzeć się wśród własnych zasobów.
Problemy infrastruktury jako kod
Teraz przyjrzyjmy się przykładom, jak infrastruktura może być zakodowana. Kod powinien być dobrze napisany, jakościowy, z komentarzami i wcięciami.
Przykład kodu z Terraform.
Przykład kodu z Ansible.
Szanowni Państwo, ale gdyby to było takie proste! Jesteśmy w rzeczywistym świecie, a on zawsze jest gotowy zaskoczyć was, dostarczyć niespodzianek, problemów. Tutaj również ich nie brakuje.
1. Pierwszy problem polega na tym, że w większości przypadków IaC to jakiś DSL.
A DSL z kolei to opis struktury. Dokładniej mówiąc, tego, co powinieneś mieć: Json, Yaml, modyfikacje od różnych dużych firm, które wymyśliły swoje DSL (w Terraformie używa się HCL).
Problem w tym, że mogą w nim łatwo brakować takich znanych nam elementów jak:
- zmienne;
- warunki;
- gdzieś brakuje komentarzy, na przykład w Json, domyślnie ich nie przewidziano;
- funkcje;
- a to jeszcze nie mówię o takich rzeczach na wyższym poziomie jak klasy, dziedziczenie i inne tego typu.
2. Drugi problem tego kodu – najczęściej jest to heterogeniczne środowisko.. Zwykle siedzisz i pracujesz w C#, czyli z jednym językiem, jednym stosie, jedną ekosystemą. A tu masz ogromną różnorodność technologii.
Całkowicie realna sytuacja, kiedy bash z Pythonem uruchamia jakiś proces, do którego podtykany jest Json. Analizujesz go, a potem jakiś generator wydaje jeszcze 30 plików. Wszystkie te dane wejściowe pochodzą z Azure Key Vault, które są pobierane przez wtyczkę do drone.io, napisaną w Go, a te zmienne przechodzą przez yaml, który powstał w wyniku generacji z silnika szablonów jsonnet. Dosyć trudno mieć ściśle opisany kod, gdy masz tak różnorodne środowisko.
Tradycyjny rozwój w ramach jednego zadania odbywa się w jednym języku. Tutaj pracujemy natomiast z wieloma językami.
3. Trzeci problem – to narzędzia.. Przywykliśmy do świetnych edytorów (Ms Visual Studio, Jetbrains Rider), które wszystko za nas robią. I nawet, jeśli popełnimy błąd, one powiedzą, że to nie tak. Wygląda na to, że to normalne i naturalne.
Ale gdzieś obok jest VSCode, w którym są jakieś wtyczki, które w jakiś sposób się instalują, są wspierane albo nie. Wyszły nowe wersje, a ich nie wsparto. Banale przejście do implementacji funkcji (nawet jeśli taka istnieje) staje się trudnym i nietrywialnym problemem. Prosta zmiana nazwy zmiennej – to zamiana w projekcie z dziesiątek plików. Może się uda, jeśli zrobi to, co trzeba. Oczywiście niektóre miejsca mają podświetlanie, jest automatyczne uzupełnianie, gdzieś jest formatowanie (chociaż u mnie w Terraformie na Windowsie nie zadziałało).
W momencie pisania artykułu jeszcze nie wydano wsparcia dla wersji 0.12, chociaż została już wydana od 3 miesięcy.
Nadszedł czas, aby zapomnieć o…
- Debugowaniu.
- Narzędziu do refaktoryzacji.
- Automatycznym uzupełnianiu.
- Wykrywaniu błędów przy kompilacji.
Śmieszne, ale to wydłuża czas pracy nad projektem i zwiększa liczbę błędów, które są nieuchronne.
Najgorsze jest to, że zmuszeni jesteśmy myśleć nie o tym, jak zaprojektować, uporządkować pliki w folderach, dekomponować, uczynić kod czytelnym i tak dalej, ale o tym, jak poprawnie napisać tę komendę, ponieważ jakoś ją źle napisałem.
Jako nowicjusz próbujesz zgłębić Terraform, a IDE w tym wcale Ci nie pomaga. Gdy jest dokumentacja – wchodzisz, patrzysz. Ale gdybyś uczył się nowego języka programowania, to IDE podpowiedziałoby, że istnieje taki typ, a tamtego nie ma. Przynajmniej na poziomie int lub string. To często bywa przydatne.
A co z testami?
Zadajecie pytanie: „A co z testami, panowie programiści?” Poważni goście testują wszystko na produkcji, i to ostro. Oto przykład testu jednostkowego dla modułu Terraform ze strony. .
Mają dobrą dokumentację. Microsoft zawsze mi się podobał swoim podejściem do dokumentacji i szkoleń. Ale nie trzeba być wujkiem Bobem, żeby zrozumieć, że kod tutaj nie jest idealny. Zwróć uwagę na walidację, która została przeniesiona w prawo.
Problem z testem jednostkowym polega na tym, że możemy sprawdzić poprawność JSON-a na wyjściu. Wprowadziłem 5 parametrów, a otrzymałem 2000-liniową porcję JSON-a. Mogę przeanalizować, co się tutaj dzieje, walidować wynik testu…
Trudno jest analizować JSON w Go. A trzeba pisać w Go, ponieważ Terraform w Go to dobra praktyka testowania w tym języku, w którym piszesz. Organizacja kodu jest bardzo słaba. Mimo to, to najlepsza biblioteka do testowania.
Sami Microsoft piszą swoje moduły, testując je w ten sposób. Oczywiście, jest to Open Source. Wszystko, o czym mówię, możesz przyjść i naprawić. Mogę usiąść i w tydzień wszystko naprawić, otworzyć źródła wtyczek VS Code, Terraform, stworzyć plugin dla Ride, może napisać kilka analizatorów, podłączyć lintery, wnieść wkład do biblioteki testowej. Mogę wszystko zrobić. Ale nie o to powinienem się zajmować.
Najlepsze praktyki Infrastructure as Code
Jedziemy dalej. Jeśli w IaC nie ma testów, IDE i narzędzia są słabe, to powinny być przynajmniej najlepsze praktyki. Po prostu poszedłem na Google Analytics i przeprowadziłem porównanie dwóch zapytań: Terraform best practices i C# best practices.
Co widzimy? Bezwzględną statystykę nie na naszą korzyść. Pod względem ilości materiałów – sytuacja jest ta sama. W rozwoju C# po prostu toną w materiałach, mamy super najlepsze praktyki, są książki napisane przez ekspertów oraz książki pisane przez innych ekspertów, które krytykują te pierwsze. Mnóstwo oficjalnej dokumentacji, artykułów, kursów, a teraz jeszcze open source development.
Jeśli chodzi o zapytanie dotyczące IaC: tu próbujesz zbierać informacje z wykładów high-load lub HashiConf, z oficjalnej dokumentacji i licznych problemów na GitHubie. Jak w ogóle rozdzielać te moduły, co z nimi robić? Wydaje się, że to prawdziwy problem… Jest przecież społeczność, panowie, w której na każde pytanie dostaniesz 10 komentarzy na GitHubie. Ale to nie jest pewne.
Niestety, na chwilę obecną eksperci dopiero zaczynają się pojawiać. Jest ich jeszcze zbyt mało. A całe community pozostaje na etapie wczesnym.
Dokąd to wszystko zmierza i co robić
Można wszystko rzucić i wrócić do C#, w świat rideg'a. Ale nie. Dlaczego w ogóle miałbyś się tym zajmować, jeśli nie po to, by znaleźć rozwiązanie. Poniżej przedstawiam moje subiektywne wnioski. Możesz ze mną polemizować w komentarzach, będzie ciekawie.
Osobiście stawiam na kilka rzeczy:
- Rozwój w tej dziedzinie postępuje bardzo szybko. Podaję wykres zapytań dotyczących DevOps.
Może to kontrowersyjny temat, ale sam fakt, że ta dziedzina rośnie, daje pewną nadzieję.Jeśli coś rozwija się tak szybko, to na pewno pojawią się mądrzy ludzie, którzy powiedzą, jak to robić, a jak nie. Wzrost popularności prowadzi do tego, że ktoś w końcu znajdzie czas, aby dopisać wtyczkę do jsonnet dla vscode, która pozwoli przechodzić do implementacji funkcji, a nie szukać jej przez ctrl+shift+f. Kiedy wszystko się rozwija, pojawia się więcej materiałów. To samo wydanie książki od Google o SRE jest świetnym tego przykładem.
- Są opracowane metody i praktyki w zwykłym programowaniu, które możemy z powodzeniem zastosować tutaj. Tak, są pewne szczegóły związane z testowaniem i heterogennym środowiskiem, niedostateczne narzędzia, ale zgromadzono ogromną liczbę praktyk, które mogą być przydatne i pomocne.
Banalny przykład: praca zespołowa przez pair programming. To bardzo pomaga w zrozumieniu. Kiedy masz obok siebie sąsiada, który też stara się coś zrozumieć, razem zrozumiecie lepiej.
Zrozumienie, jak przeprowadza się refaktoryzację, pomaga nawet w takiej sytuacji ją wykonać. To znaczy, że możesz nie zmieniać wszystkiego na raz, ale najpierw zmienić nazewnictwo, potem lokalizację, może wyodrębnić jakąś część, o, a tutaj brakuje komentarzy.
Podsumowanie
Mimo że moje rozważania mogą wydawać się pesymistyczne, z nadzieją patrzę w przyszłość i szczerze mam nadzieję, że nam (i wam) się uda.
Wkrótce przygotuję drugą część artykułu. W niej opowiem o tym, jak próbowaliśmy zastosować praktyki zwinnego programowania, aby poprawić nasz proces uczenia się i pracę z infrastrukturą.
Źródło: habr.com
