Инфраструктурата като код: първо запознанство

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

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

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

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

Отборът имаше следните тренировъчни задачи:

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

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

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

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

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

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

От само себе си се разбира, че в идеалния случай всичко трябва да бъде преведено в четим от човека, поддържаем, добре написан код.

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

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

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

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

Проблеми Инфраструктура като код

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

Примерен код от Terraforma.

Примерен код от Ansible.

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

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

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

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

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

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

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

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

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

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

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

Време е да забравите за...

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

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

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

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

Ами тестовете?

Питате: „Ами тестовете, господа програмисти?“ Сериозните момчета тестват всичко в производството и е трудно. Ето пример за единичен тест за тераформиран модул от уебсайта Microsoft.

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

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

Трудно е да се анализира Json в Go. И трябва да пишете на Go, защото terraform в Go е добра практика за тестване на езика, на който пишете. Организацията на самия код е много слаба. В същото време това е най-добрата библиотека за тестване.

Самият Microsoft пише своите модули, като ги тества по този начин. Разбира се, че е с отворен код. Всичко, за което говоря, можете да дойдете и да го оправите. Мога да седна и да поправя всичко за една седмица, плъгини за VS код с отворен код, тераформи, да направя плъгин за ездача. Може би да напиша няколко анализатора, да добавя линтери, да допринеса с библиотека за тестване. Мога всичко. Но не трябва да правя това.

Най-добри практики Инфраструктурата като код

Да продължим. Ако няма тестове в IaC, IDE и настройката са лоши, тогава трябва да има поне най-добри практики. Току-що отидох в Google Analytics и сравних две заявки за търсене: Terraform най-добри практики и c# най-добри практики.

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

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

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

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

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

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

1. Развитието в тази област се случва много бързо. Ето график на заявките за DevOps.

   
   
   Темата може да е хайп, но самият факт, че сферата се разраства, дава известна надежда.

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

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

   Тривиален пример: сътрудничество чрез програмиране по двойки. Помага много да го разбера. Когато имате съсед наблизо, който също се опитва да разбере нещо, заедно ще разберете по-добре.

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

Заключение

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

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

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