В нашата компания протича процес на въвеждане на SRE екипа. Започнах от страната на разработката. В хода на процеса ми дойдоха мисли и прозрения, с които искам да споделя с другите разработчици. В тази статия размишлявам за това, какво се случва, как се случва и как всички ние можем да живеем с това напред.
Продължение на серия статии, написани вдъхновени от презентации на нашето вътрешно събитие. :
2. Инфраструктура като код. (Тук сте)
3. Генериране на Typescript контракти по C# модели. (В процес на работа…)
4. Въведение в алгоритъма на консенсуса Raft. (В процес на работа…)
…
Решихме да създадем SRE екип, реализирайки идеите на . Набрахме програмисти от собствените си разработчици и ги изпратихме да се обучават за няколко месеца.
Пред екипа стояха следните учебни задачи:
- Да опишат нашата инфраструктура, която по-голямата част е в Microsoft Azure, под формата на код (Terraform и всичко около него).
- Да научат разработчиците да работят с инфраструктура.
- Да подготвят разработчиците за дежурства.
Въвеждаме понятието Инфраструктура като код.
В обичайната модел на света (класическо администриране) знанията за инфраструктурата се намират на две места:
- Или под формата на знания в главите на експертите.
- Или тези данни се намират на някакви устройства, част от които знаят експертите. Но не е сигурно, че човек отстрани (в случай, че целият ни екип изведнъж умре) може да разбере как работи системата. На машината може да има много сведения: достъпи, cron jobs, подготвен (виж ) диск и просто безкраен списък на това, което може да се случи. Трудно е да се разбере какво всъщност става.
В и двата случая попадаме в капан, ставаме зависими:
- или от човек, който е смъртен, подложен на болести, влюбвания, промени в настроението и просто елементарни напускания;
- или от физически работеща машина, която също може да падне, да бъде открадната, да създава изненади и неудобства.
Съответно, решението е, че в идеалния случай всичко трябва да бъде преведено в четим, поддържан, качествено написан код.
По този начин инфраструктурата като код (Infrastructure as Code – IaC) представлява описание на цялата налична инфраструктура във вид на код, както и свързаните средства за работа с него и изграждане на реалната инфраструктура от него.
Защо да превеждаме всичко в кодХората не са машини. Те не могат да запомнят всичко. Реакцията на човек и машина е различна. Всичко автоматизирано потенциално работи по-бързо от всичко, което прави човекът. Най-важното е да имаме едно основно източник на истина (single source of truth).
Откъде идват новите SRE инженериИ така, решихме да привлечем нови SRE инженери, но откъде да ги вземем? Книга с правилните отвори () ни казва: от разработчиците. Те работят с код, а вие стигате до идеалното състояние.
Търсихме ги много и дълго на пазара на труда извън нашата компания. Но сме принудени да признаем, че не намерихме нито един, който да отговаря на нашите изисквания. Наложи се да се поразровим сред своите.
Проблеми на Infrastructure as Code
Сега нека погледнем примери как инфраструктурата може да бъде внедрена в код. Кодът е добре написан, качествен, с коментари и отстъпления.
Пример на код от Terraforma.
Пример на код от Ansible.
Господа, но ако всичко беше толкова просто! Ние сме в реалния свят, а той винаги е готов да ви изненада, да предостави изненади и проблеми. И тук не липсват.
1. Първият проблем е, че в повечето случаи IaC е някакъв DSL.
А DSL, от своя страна, е описание на структурата. По-точно на това, което трябва да имате: Json, Yaml, модификации от някои големи компании, които са създали свой DSL (в Terraform се използва HCL).
Проблемът е, че в него лесно могат да липсват тъй познатите ни неща като:
- променливи;
- условия;
- някъде липсват коментари, например, в Json, по подразбиране те не са предвидени;
- функции;
- и това е още преди да спомена за такива високоуровневи неща, като класове, наследяване и изцяло подобни.
2. Вторият проблем на такъв код е, че често е хетерогенна среда. Обикновено вие работите с C#, т.е. с един език, един стек, една екосистема. А тук имате огромно разнообразие от технологии.
Напълно реална ситуация е, когато бяш с питон стартира процес, в който се подава Json. Вие го анализирате, след това друг генератор генерира още 30 файла. За всичко това входящите променливи идват от Azure Key Vault, които са извлечени чрез плугин за drone.io, написан на Go, и тези променливи минават през yaml, генериран от шаблонизатора jsonnet. Доста е сложно да имате строго добре описан код, когато имате толкова разнообразна среда.
Традиционното разработване в рамките на една задача върви с един език. Тук обаче работим с голямо количество езици.
3. Третият проблем – е инструментариумът.. Свикнали сме с готини редактори (Ms Visual Studio, Jetbrains Rider), които всичко правят вместо нас. И дори, ако сгрешим, те ще ни кажат, че не сме прави. Изглежда, че това е нормално и естествено.
Но наблизо има VSCode, в който има някакви плъгини, които се инсталират, поддържат или не поддържат. Излезли са нови версии и те не са били поддържани. Обикновеният преход към реализацията на функция (дори и да съществува) става сложен и нетривиален проблем. Обикновеното преименуване на променлива – това е заменяне в проект от десетина файла. Ще имате късмет, ако той замени точно това, което трябва. Има, разбира се, някакво синтактично оцветяване, има автозавършване, някъде има форматиране (въпреки че при мен в terraform на Windows не тръгна).
В момента на написването на статията още не е пуснат за поддръжка на версия 0.12, въпреки че тя е вече 3 месеца на разположение.
Дойде време да забравите за…
- Отстраняване на грешки.
- Инструмент за рефакторинг.
- Авто завършване.
- Откриване на грешки при компилация.
Смешно е, но това увеличава времето за разработка и увеличава броя на грешките, които неизбежно се появяват.
Най-страшното е, че сме принудени да мислим не за това как да проектираме, разпределим файловете по папки, да декомпозираме, да направим кода поддържан, четим и така нататък, а за това как правилно да напиша тая команда, защото я написах неправилно.
Като начинаещ се опитвате да проучите terraform, а IDE изобщо не ви помага в това. Когато има документация – влизате, гледате. Но ако влизате в нов език за програмиране, IDE би ви подсказала, че има такъв тип, а такъв тип няма. Най-малкото на ниво int или string. Това често е полезно.
А какво стане с тестовете?
Вие питате: „Какво стана с тестовете, господа програмисти?“ Сериозните хора тестват всичко в продукция, и то е твърдо. Ето пример за юнит тест за Terraform модул от сайта .
Те имат добра документация. Microsoft винаги ми е харесвала с подхода си към документацията и обучението. Но не е нужно да бъдеш чичо Боб, за да разбереш, че тук не е перфектният код. Обърнете внимание на валидирането, изнесено вдясно.
Проблемът с юнит теста е, че можем да проверим коректността на Jsonа на изхода. Пуснах 5 параметри, получих Json, който е 2000 реда. Мога да анализирам какво се случва, да валидирам тестовия резултат…
Трудно е да се анализира Json в Go. А трябва да пишем в Go, защото Terraform на Go е добра практика – тествате на езика, на който пишете. Самата организация на кода е много слаба. Въпреки това, това е най-добрата библиотека за тестване.
Самият Microsoft пише своите модули, тествуйки ги по този начин. Разбира се, това е с отворен код. Всичко, за което говоря, можете да дойдете и да поправите. Мога да засядам и за седмица всичко да бъде поправено, да отворя плъгини за VS код, Terraform, да направя плъгин за Rider. Може би да напиша няколко анализатора, да добавя линтери, да контрибутирам библиотека за тестване. Всичко мога да направя. Но не с това трябва да се занимавам.
Най-добри практики за Инфраструктура като код
Продължаваме. Ако в IaC няма тестове, IDE и инструментите са слаби, поне трябва да има най-добрите практики. Аз просто отидох в Google Analytics и направих сравнение на две търсения: Terraform най-добри практики и C# най-добри практики.
Какво виждаме? Безмилостна статистика не в наша полза. По отношение на количеството материал – положението е същото. В C# разработката просто сме потопени в материали, имаме свръх добри практики, книги, написани от експерти, и също така книжки, написани от други експерти, които критикуват тези книги. Море от официална документация, статии, обучителни курсове, сега има и отворен код.
Относно заявката за IaC: тук вие опитвате да съберете информация на парчета от презентации на хайлоад или HashiConf, от официалната документация и многобройни проблеми в GitHub. Как да се разпределят тези модули, какво да се прави с тях? Изглежда, че това е истински проблем… Има общност, господа, в която на всеки въпрос ще получите 10 коментара в GitHub. Но не е точно така.
За съжаление, в момента експертите едва започват да се появяват. Все още са много малко. А самото общество е на ниво зародиш.
Накъде върви всичко това и какво да правим
Можеш да оставиш всичко и да се върнеш обратно на C#, в света на райдера. Но не. Защо изобщо би започнал с това, ако не за да намериш решение. По-долу представям моите субективни изводи. Можеш да спориш с мен в коментарите, ще е интересно.
Лично аз залагам на няколко неща:
- Развитието в тази сфера се случва много бързо. Представям график на запитванията по DevOps.
Може би темата е нашумяла, но самият факт, че сферата расте, вдъхва определена надежда.Ако нещо расте толкова бързо, непременно ще се появят умни хора, които ще кажат как да се прави и как да не се прави. Увеличението на популярността води до това, че може би някой най-накрая ще отдели време да напише плъгин за jsonnet за vscode, който ще позволява да се преминава към реализиране на функция, вместо да я търсиш чрез ctrl+shift+f. Когато всичко се развива, се появяват повече материали. Същият изход на книга от Google за SRE е отличен пример за това.
- Съществуват разработени методики и практики в обичайната разработка, които можем успешно да прилагаме и тук. Да, има нюанси с тестването и хетерогенната среда, недостатъчно инструменти, но е натрупан огромен брой практики, които могат да бъдат полезни и да помогнат.
Банален пример: съвместна работа чрез pair programming. Тя значително помага да се разбере. Когато имаш до себе си колега, който също се опитва да разбере нещо, заедно ще го разберете по-добре.
Разбирането как се прави рефакторинг помага дори и в такава ситуация да го извършиш. Тоест, можеш да промениш не всичко наведнъж, а да смениш имената, след това да промениш разположението, после може би да отделиш някаква част, ох, ето тук не стигат коментарите.
Заключение
Въпреки че моите размисли могат да изглеждат песимистични, с надежда гледам в бъдещето и искрено се надявам, че у нас (и у вас) всичко ще се получи.
Следва второ част на статията. В нея ще разкажа как опитахме да прилагаме практики на гъвкава разработка, за да подобрим нашия процес на обучение и работа с инфраструктура.
Източник: habr.com
