Infrastructure as code: първа среща

В нашата компания тече процес на онбординг на SRE екипа. Аз влязох в цялата история от страна на разработката. В процеса ми се появиха мисли и прозрения, които искам да споделя с другите разработчици. В тази статия-разсъждение говоря за това, което се случва, как се случва и как всички да живеят с него по-нататък.

Продължение на серия статии, написани вдъхновени от изказвания на нашето вътрешно събитие DevForum:

1. Котката на Шрьодингер без кутия: проблемът с консенсуса в разпределените системи.
2. Инфраструктурата като код. (Тук сте)
3. Генериране на TypeScript договори по C# модели. (В ход…)
4. Въведение в алгоритъма за консенсус Raft. (В ход…)
…

Решихме да създадем SRE екип, реализирайки идеите google sre. Набрахме програмисти от нашите разработчици и ги изпратихме да се обучават за няколко месеца.

Пред екипа стояха следните учебни задачи:

• Да опишем нашата инфраструктура, която предимно е в Microsoft Azure, под формата на код (Terraform и всичко около него).
• Да обучим разработчиците да работят с инфраструктурата.
• Да подготвим разработчиците за дежурства.

Въвеждаме понятието Инфраструктура като код

В обичайната модел на света (класическото администриране) знанията за инфраструктурата се намират на две места:

1. или под формата на знания в главите на експертите.
2. Или тези сведения се намират на някакви машини, част от които експертите познават. Но не е факт, че човек отстрани (в случай че целият ни екип изведнъж умре) ще може да разбере какво и как работи. На машината могат да бъдат много сведения: достъпи, кронджобове, подмонтиран(пвд. disk mounting) диск и просто безкраен списък с това, което може да се случи. Трудно е да се разбере какво наистина се случва.

И в двата случая попадаме в капан, ставайки зависими:

• или от човек, който е смъртен, подлежащ на болести, влюбвания, колебания в настроението и просто банални уволнения;
• или от физически работеща машина, която също се проваля, краде се, носи неочакваности и неудобства.

Съответно, решението е очевидно, че идеално всичко трябва да бъде преведено в четим, поддържан, качествено написан код.

Така инфраструктурата като код (Infrastructure as Code – IaC) е описание на цялата налична инфраструктура под формата на код, а също и съпътстващите инструменти за работа с него и реализацията на самата инфраструктура.

Защо да превеждаме всичко в кодХората не са машини. Те не могат да запомнят всичко. Реакцията на човека и машината е различна. Всичко, което е автоматизирано, потенциално работи по-бързо от всичко, което прави човекът. Най-важното е – единен източник на истина (single source of truth).

Откъде идват новите SRE инжинериИ така, решихме да ангажираме нови SRE инжинери, но откъде да ги намерим? Книгата с правилните отговори (Google SRE Book) ни казва: от разработчиците. В крайна сметка те работят с код, а вие постигате идеалното състояние.

Дълго и упорито ги търсихме на трудовия пазар извън нашата компания. Но трябва да признаем, че не намерихме нито един по нашите критерии. Наложи се да се поровим сред собствените си.

Проблемите с Infrastructure as Code

Сега да разгледаме примери за това как инфраструктурата може да бъде вградена в код. Кодът е добре написан, качествен, с коментари и отстъпи.

Пример за код от Terraform.

Пример за код от Ansible.

Господа, но ако всичко беше толкова просто! Ние сме в реалния свят, който винаги е готов да ви изненада, да ви поднесе изненади и проблеми. И тук не минава без тях.

1. Първият проблем е, че в повечето случаи IaC е някакъв DSL.

А DSL, от своя страна, е описание на структурата. По-точно, какво трябва да имате: JSON, YAML, модификации от някои големи компании, които са създали техния DSL (в Terraform се използва HCL).

Проблемът е, че в него може лесно да няма такива познати неща като:

• променливи;
• условия;
• някъде няма коментари, например, в JSON по подразбиране те не са предвидени;
• функции;
• и това е без да споменавам такива високо нива неща като класове, наследяване и всичко такова.

2. Вторият проблем на този код е, че по-често това е хетерогенна среда. Обикновено седите и работите с C#, т.е. с един език, един стек, една екосистема. А тук имате огромно разнообразие от технологии.

Напълно реална ситуация е, когато bash с python стартира процес, в който се вмъква Json. Вие го анализирате, след това някакъв генератор генерира още 30 файла. За всичко това постъпват входни променливи от Azure Key Vault, които са изтеглени от плъгин за drone.io, написан на Go, и тези променливи преминават през yaml, генериран от шаблонизатора jsonnet. Доста сложно е да имате строго описан код, когато средата ви е толкова разнообразна.

Традиционната разработка по една задача се извършва с един език. Тук обаче работим с голямо количество езици.

3. Третият проблем е инструментариумът. Свикнали сме с страхотни редактори (Ms Visual Studio, Jetbrains Rider), които правят всичко вместо нас. И дори ако направим грешка, те ще ни кажат, че не сме прави. Изглежда, че това е нормално и естествено.

Но някъде наблизо има VSCode, в който има някакви плъгини, които се инсталират, поддържат или не поддържат. Излезли са нови версии, и те не са поддържани. Простото преминаване към имплементация на функция (дори ако я има) става сложен и нетривиален проблем. Простото преименуване на променлива е заменена в проекта в десетки файлове. Ще се радвате, ако тя замени точно това, което трябва. Разбира се, на места има подсветка, автозавършване, на места има форматиране (въпреки че при мен в терраформ на Windows не работеше).

Към момента на написване на статията vscode-terraform плъгин все още не е издаден за поддръжка на версия 0.12, въпреки че тя е освободена вече преди 3 месеца.

Настъпи времето да забравим за…

1. Дебъгване.
2. Инструмент за рефактуриране.
3. Автозавършване.
4. Откриване на грешки при компилация.

Смешно, но това увеличава времето за разработка и увеличава броя на неизбежните грешки.

Най-страшното е, че сме принудени да мислим не как да проектираме, да организираме файловете по папките, да декомпозиране, да създадем поддържаем и четим код, а как правилно да напиша тази команда, защото я написах неправилно.

Като начинаещ вие се опитвате да опознаете терраформ, а IDE не ви помага ни най-малко. Когато има документация – влизате, гледате. Но ако се опитвате да усвоите нов език за програмиране, IDE би подсказала, че има такъв тип, а такава структура няма. Най-малкото на ниво int или string. Това често е полезно.

А какво да кажем за тестовете?

Ще попитате: «Какво да кажем за тестовете, уважаеми програмисти?» Сериозните хора тестват всичко в продукция, и то строго. Ето пример за юнит тест за Terraform модул от сайта Microsoft.

Те имат добро документация. Microsoft винаги ми е харесвал подхода към документацията и обучението. Но не е нужно да бъдеш дядо Боб, за да разбереш, че тук не е идеалният код. Обърнете внимание на валидацията, която е преместена вдясно.

Проблемът с юнит теста е, че можем да проверим коректността на JSON на изхода. Пратих 5 параметъра и получих JSON от 2000 реда. Мога да анализирам какво се случва, да валидирам тестовия резултат…

Трудно е да се анализира JSON в Go. Но трябва да се пише на Go, защото Terraform е на Go – това е добра практика за тестване на езика, на който пишеш. Самата организация на кода е много слаба. Въпреки това – това е най-добрата библиотека за тестване.

Самият Microsoft пише своите модули, тестват ги по този начин. Разбира се, това е Open Source. Всичко, за което говоря, можете да дойдете и да поправите. Мога да седна и за седмица всичко да поправя, да open source-на плъгини за VS Code, Terraform, да направя плъгин за Rider. Може да напиша и няколко анализатора, да прикача линтери, да контрибуирам в библиотеката за тестване. Всичко мога да направя. Но не това трябва да правя.

Най-добри практики за Infrastructure as Code

Продължаваме. Ако в IaC няма тестове, IDE и инструментал не са добри, поне трябва да има най-добри практики. Просто отидох в Google Analytics и направих сравнение на две търсения: Terraform best practices и c# best practices.

Какво виждаме? Безпощадна статистика не в наша полза. По количество материал – същото. В разработката на C# просто сме затрупани с материали, имаме свръхдобри практики, имаме книги написани от експерти, а също и книги, написани на книги от други експерти, които критикуват тези книги. Огромно количество официална документация, статии, обучителни курсове, а в момента и open source разработки.

Що се отнася до търсенето по IaC: тук вие на парчета се опитвате да съберете информация от доклади на хайлоад или HashiConf, от официалната документация и многобройни проблеми в GitHub. Как всъщност да разпространявате тези модули, какво да правите с тях? Изглежда, че това е наистина проблем… Има общност, господа, където на всеки въпрос получавате 10 коментара в GitHub. Но не е сигурно.

За съжаление, в момента експертите едва започват да се появяват. Все още са твърде малко. А самата общност е на ниво начален стадий.

Къде се движи всичко това и какво да правим

Можеш да оставиш всичко и да се върнеш обратно на C#, в света на райдерите. Но не. Защо изобщо би се занимавал с това, ако не целиш да намериш решение. По-долу споделям моите субективни изводи. Можеш да спориш с мен в коментарите, ще е интересно.

Лично аз залагам на няколко неща:

1. Развитието в тази област протича много бързо. Привеждам графика на търсенията по DevOps.

   
   
   Може да е популярна тема, но фактът, че сферата расте, вселява определена надежда.

   Ако нещо расте толкова бързо, със сигурност ще се появят умни хора, които ще кажат какво да правим и какво не. Увеличаването на популярността води до факта, че може на някой да му остане време да довърши плъгин за jsonnet за vscode, който ще позволи да се премине към имплементацията на функцията, а не да я търсиш през ctrl+shift+f. Когато всичко се развива, се появяват повече материали. Същият изход на книгата от Google за SRE е отличен пример за това.

2. Има разработени методики и практики в обичайната разработка, които можем успешно да приложим и тук. Да, има нюанси с тестването и хетерогенната среда, както и недостатъчен тулинг, но е натрупано огромно количество практики, които могат да бъдат полезни.

   Банален пример: съвместна работа чрез pair programming. Това много помага за разясняване. Когато ти имаш до себе си съсед, който също се опитва да разбере нещо, заедно ще разберете по-добре.

   Разбирането на това как се прави рефакторинг, помага дори в такава ситуация да го извършваш. Тоест, можеш да не променяш всичко наведнъж, а да смениш именуването, после разположението, а може да изолираш някаква част, ох, а тук не стигат коментарите.

Заключение

Въпреки че моите размишления могат да изглеждат песимистични, аз с надежда гледам в бъдещето и искрено се надявам, че при нас (и при вас) всичко ще се получи.

Следва втора част на статията. В нея ще разкажа как опитахме да приложим практиките на гъвкавото разработване, за да подобрим нашия процес на обучение и работа с инфраструктурата.

Източник: habr.com