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

Нашата компанија е во процес на вклучување на тим SRE. Дојдов во целата оваа приказна од развојната страна. Во тој процес, дојдов до мисли и сознанија кои сакам да ги споделам со други програмери. Во оваа статија за размислување зборувам за тоа што се случува, како се случува и како секој може да продолжи да живее со тоа.

Продолжение на серијата написи напишани врз основа на говори на нашиот внатрешен настан DevForum:

1. Шредингерова мачка без кутија: проблемот на консензус во дистрибуираните системи.
2. Инфраструктура како код. (Ти си тука)
3. Генерирање на договори Typescript користејќи C# модели. (Во тек...)
4. Вовед во алгоритмот за консензус Raft. (Во тек...)
...

Решивме да создадеме тим на SRE, спроведувајќи ги идеите google sre. Тие регрутираа програмери од нивните сопствени програмери и ги испратија да тренираат неколку месеци.

Тимот ги имаше следните задачи за обука:

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

Го воведуваме концептот на Инфраструктура како код

Во вообичаениот модел на светот (класична администрација), знаењето за инфраструктурата се наоѓа на две места:

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

Во двата случаи, се наоѓаме себеси заробени да станеме зависни:

• или од личност која е смртна, подложна на болест, заљубување, промени во расположението и едноставно банални отпуштања;
• или од физичка работна машина, која исто така паѓа, се краде и претставува изненадувања и непријатности.

Се подразбира дека идеално сè треба да се преведе во читлив, одржуван, добро напишан код.

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

Зошто да се преведе сè во код?Луѓето не се машини. Тие не можат да се сетат на сè. Реакцијата на човекот и машината е различна. Сè што е автоматизирано е потенцијално побрзо од сè што е направено од човек. Најважно е единствен извор на вистината.

Од каде доаѓаат новите инженери на SRE?Значи, решивме да вработиме нови инженери SRE, но од каде да ги набавиме? Резервирајте со точни одговори (Google SRE Book) ни кажува: од програмерите. На крајот на краиштата, тие работат со кодот, а вие ја постигнувате идеалната состојба.

Долго време баравме многу за нив на пазарот за персонал надвор од нашата компанија. Но, мора да признаеме дека не најдовме некој што одговара на нашите барања. Морав да барам меѓу сопствениот народ.

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

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

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

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

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

1. Првиот проблем е што во повеќето случаи IaC е некој вид на dsl.

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

Проблемот е што лесно може да не содржи такви познати работи како што се:

• променливи;
• Услови;
• некаде нема коментари, на пример, во Json, стандардно тие не се обезбедени;
• функции;
• а јас дури и не зборувам за такви работи на високо ниво како што се класи, наследство и сето тоа.

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

Многу е реална ситуација кога баш со 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 или стринг. Ова е често корисно.

Што е со тестовите?

Вие прашувате: „Што е со тестовите, господа програмери? Сериозните момци тестираат сè на производство, и тоа е тешко. Еве еден пример на единица тест за тераформски модул од веб-локацијата Мајкрософт.

Имаат добра документација. Отсекогаш ми се допаѓал Мајкрософт за неговиот пристап кон документацијата и обуката. Но, не треба да сте чичко Боб за да разберете дека ова не е совршен код. Забележете ја валидацијата надесно.

Проблемот со единица тест е тоа што вие и јас можеме да ја провериме исправноста на излезот Json. Фрлив во 5 параметри и ми дадоа Јсон крпа со 2000 линии. Можам да анализирам што се случува овде, да го потврдам резултатот од тестот...

Тешко е да се анализира Json во Go. И треба да пишувате во Go, бидејќи terraform in Go е добра практика за тестирање на јазикот на кој пишувате. Организацијата на самиот код е многу слаба. Во исто време, ова е најдобрата библиотека за тестирање.

Самиот Мајкрософт ги пишува своите модули, тестирајќи ги на овој начин. Се разбира, тоа е со отворен код. Сè за што зборувам, можете да дојдете и да поправите. Можам да седнам и да поправам сè за една недела, додатоци со отворен код VS код, тераформи, да направам додаток за возачот. Можеби напишете неколку анализатори, додадете линтери, придонесете библиотека за тестирање. Можам се. Но, тоа не е она што треба да го правам.

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

Ајде да продолжиме. Ако нема тестови во IaC, IDE и подесувањето се лоши, тогаш барем треба да има најдобри практики. Штотуку отидов на Google Analytics и споредив две прашања за пребарување: Terraform најдобри практики и c# најдобри практики.

Што гледаме? Немилосрдната статистика не ни оди во прилог. Количината на материјалот е иста. Во развојот на C#, едноставно сме преплавени со материјали, имаме супер-најдобри практики, има книги напишани од експерти, а исто така и книги напишани на книги од други експерти кои ги критикуваат тие книги. Море од официјална документација, статии, курсеви за обука, а сега и развој со отворен код.

Што се однесува до барањето за IaC: овде се обидувате да собирате информации малку по малку од извештаите на highload или HashiConf, од официјалната документација и бројни проблеми на Github. Како да се дистрибуираат овие модули воопшто, што да се прави со нив? Се чини дека ова е вистински проблем... Постои заедница, господа, каде за секое прашање ќе ви бидат дадени 10 коментари на Github. Но, тоа не е точно.

За жал, во овој момент на време, експертите само што почнуваат да се појавуваат. Досега ги има премалку. А самата заедница се дружи на рудиментарно ниво.

Каде оди сето ова и што да се прави

Можете да испуштите сè и да се вратите на C#, во светот на возачот. Но не. Зошто воопшто би се мачеле да го направите ова ако не можете да најдете решение. Подолу ги прикажувам моите субјективни заклучоци. Можете да се расправате со мене во коментарите, ќе биде интересно.

Лично, се обложувам на неколку работи:

1. Развојот во оваа област се случува многу брзо. Еве распоред на барања за DevOps.

   
   
   Можеби темата е возбуда, но самиот факт дека сферата расте, дава некаква надеж.

   Ако нешто расте толку брзо, тогаш дефинитивно ќе се појават паметни луѓе кои ќе ви кажат што да правите, а што не. Зголемувањето на популарноста води до фактот дека можеби некој ќе има време конечно да додаде додаток на jsonnet за vscode, што ќе ви овозможи да продолжите да ја имплементирате функцијата, наместо да ја барате преку ctrl+shift+f. Како што се развиваат работите, се појавуваат повеќе материјали. Издавањето книга од Google за SRE е одличен пример за ова.

2. Развиени се техники и практики во конвенционалниот развој кои можеме успешно да ги примениме овде. Да, има нијанси со тестирање и хетерогено опкружување, недоволно алатки, но се акумулирани огромен број практики кои можат да бидат корисни и корисни.

   Тривијален пример: соработка преку програмирање во парови. Многу помага да се сфати. Кога имате сосед во близина кој исто така се обидува да разбере нешто, заедно ќе разберете подобро.

   Разбирањето како се прави рефакторирањето помага да се спроведе дури и во таква ситуација. Односно, не можете да промените сè одеднаш, туку да го промените името, потоа да ја смените локацијата, потоа да означите некој дел, ох, но тука нема доволно коментари.

Заклучок

И покрај фактот дека моето размислување може да изгледа песимистичко, јас гледам во иднината со надеж и искрено се надевам дека сè ќе успее кај нас (и вас).

Во продолжение се подготвува вториот дел од статијата. Во него, ќе зборувам за тоа како се обидовме да користиме практики за агилен развој за да го подобриме нашиот процес на учење и да работиме со инфраструктура.

Извор: www.habr.com