У нас у кампаніі ідзе працэс онбордынгу SRE-каманды. Я зайшоў ва ўсю гэтую гісторыю з боку распрацоўкі. У працэсе ў мяне з'явіліся думкі і інсайты, якімі я хачу падзяліцца з іншымі распрацоўшчыкамі. У гэтым артыкуле-разважанні я кажу пра тое, што адбываецца, як адбываецца, і як усім далей з гэтым жыць.
Працяг серыі артыкулаў, напісаных па матывах выступленняў на нашым унутраным мерапрыемстве :
2. Infrastructure as code. (You are here)
3. Генерацыя Typescript кантрактаў па c# мадэлям. (In progress…)
4. Увядзенне ў алгарытм кансэнсусу Raft. (In progress…)
...
Мы вырашылі зрабіць каманду SRE, увасобіўшы ідэі . Набралі праграмістаў са сваіх жа распрацоўшчыкаў і адправілі іх навучацца на некалькі месяцаў.
Перад камандай стаялі наступныя навучальныя задачы:
- Апісаць нашу інфраструктуру, якая па большай частцы ў Microsoft Azure у выглядзе кода (Terraform і ўсё, што каля).
- Навучыць распрацоўшчыкаў рабоце з інфраструктурай.
- Падрыхтаваць распрацоўшчыкаў да дзяжурстваў.
Уводзім паняцце Infrastructure as code
У звычайнай мадэлі свету (класічным адміністраванні) веды аб інфраструктуры знаходзяцца ў двух месцах:
- Або ў выглядзе ведаў у галовах экспертаў.
- Або гэтыя звесткі знаходзяцца на нейкіх машынках, частка з якіх ведаюць эксперты. Але не факт, што чалавек са боку (у выпадку, калі ўся наша каманда раптам памрэ) зможа разабрацца, што і як працуе. На машыне можа быць шмат звестак: аксэсы, кранджобы, падмаўчаны (гл. ) дыск і проста бясконцы спіс таго, што можа адбывацца. Па ёй цяжка зразумець, што ў рэальнасці адбываецца.
У абодвух выпадках мы апыняемся ў пастцы, становячыся залежнымі:
- альбо ад чалавека, які смяротны, схільны хваробам, закаханасцям, перападам настрою і проста банальным звальненням;
- альбо ад фізічна працавальнай машыны, якая таксама падае, крадзецца, падае нечаканасці і нязручнасці.
Само сабой напрошваецца рашэнне, што ў ідэале ўсё трэба перавесці ў чалавекачытальны, які падтрымліваецца, якасна напісаны код.
Такім чынам інфраструктура як код (Incfastructure as Code - IaC) - гэта апісанне ўсёй наяўнай інфраструктуры ў выглядзе кода, а таксама спадарожныя сродкі па працы з ім і ўвасабленні з яго ж рэальнай інфраструктуры.
Навошта пераводзіць усё ў кодЛюдзі - не машыны. Яны не могуць запомніць усё. Рэакцыя ў чалавека і машыны розная. Усё аўтаматызаванае патэнцыйна працуе хутчэй, чым усё, што робіць чалавек. Самае галоўнае - гэта адна крыніца праўды (single source of truth).
Адкуль бяруцца новыя SRE-інжынерыТакім чынам, мы вырашылі падлучыць новых SRE-інжынераў, але адкуль іх браць? Кніжка з правільнымі адказамі () кажа нам: з распрацоўшчыкаў. Бо яны працуюць з кодам, а вы дасягаеце ідэальнага стану.
Мы шмат і доўга шукалі іх на кадравым рынку за межамі нашай кампаніі. Але вымушаныя прызнаць, што не знайшлі ніводнага пад нашыя запыты. Прыйшлося пашарсціць сярод сваіх.
Праблемы Infrastructure as code
Цяпер давайце паглядзім прыклады таго, як інфраструктура можа быць зашыта ў код. Код добра напісаны, якасна, з каментамі і водступамі.
Прыклад кода з Terraforma.
Прыклад кода з Ansible.
Спадары, але калі б усё было так проста! Мы ж з вамі ў рэальным свеце, а ён заўсёды гатовы здзівіць вас, паднесці сюрпрызы, праблемы. Не абыходзіцца без іх і тут.
1. Першая праблема складаецца ў тым, што ў большасці выпадкаў IaC - гэта нейкі dsl.
А DSL, у сваю чаргу, - гэта апісанне структуры. Дакладней таго, што ў цябе павінна быць: Json, Yaml, мадыфікацыі ад нейкіх буйных кампаній, якія прыдумалі свой dsl (у тэраформе выкарыстоўваецца HCL).
Бяда ў тым, што ў ім можа лёгка не быць такіх звыклых нам рэчаў як:
- зменныя;
- умовы;
- дзесьці няма каментароў, напрыклад, у Json, па дэфолце іх не прадугледжана;
- функцыі;
- і гэта я яшчэ не кажу пра такія высокаўзроўневыя рэчы, як класы, атрыманне ў спадчыну і ўсё такое.
2. Другая праблема такога кода - часцей за ўсё гэта гетэрагеннае асяроддзе. Звычайна вы сядзіце і працуеце з C#, г.зн. з адной мовай, адным стэкам, адной экасістэмай. А тут у вас вялізная разнастайнасць тэхналогій.
Цалкам рэальная сітуацыя, калі Баш з пітонам запускае нейкі працэс, у які падсоўваецца Json. Вы яго аналізуеце, потым яшчэ нейкі генератар выдае яшчэ 30 файлаў. Для ўсяго гэтага паступаюць уваходныя зменныя з Azure Key Vault, якія сцягнутыя плагінам да drone.io, напісаным на Go, і зменныя гэтыя праходзяць праз yaml, які атрымаўся ў выніку генерацыі з шаблонизатора jsonnet. Даволі складана мець строга добра апісаны код, калі ў вас настолькі разнастайнае асяроддзе.
Традыцыйная распрацоўка ў рамках адной задачы ідзе з адной мовай. Тутака ж мы працуем з вялікай колькасцю моў.
3. Трэцяя праблема - гэта тулінг. Мы абвыклі да крутых рэдактараў (Ms Visual Studio, Jetbrains Rider), якія ўсё робяць за нас. І нават, калі мы затупілі, яны скажуць, што мы не правы. Здаецца, што гэта нармальна і натуральна.
Але дзесьці побач ёсць VSCode, у якім ёсць нейкія плагіны, якія неяк ставяцца, падтрымліваюцца ці не падтрымліваюцца. Выйшлі новыя версіі, і іх не падтрымалі. Банальны пераход да імплементацыі функцыі (нават калі яна ёсць) становіцца складанай і нетрывіяльнай праблемай. Просты рэнейм зменнай - гэта рэплейс у праекце з дзясятка файлаў. Пашанцуе, калі ён тое, што трэба зарэплейсіць. Ёсць, вядома, дзе-нідзе падсвятленне, ёсць аўтакомплішн, дзесьці ёсць фарматынг (праўда ў мяне ў тэраформе на віндзе не завёўся).
На момант напісання артыкула яшчэ не выпусцілі для падтрымкі версіі 0.12, хаця яна зарэлізавана ўжо як 3 месяцы.
Нетутэйша час забыцца аб…
- Адладка.
- Refactoring tool.
- Auto completion.
- Выяўленні памылак пры кампіляцыі.
Смешна, але гэта ж павялічвае час на распрацоўку і павялічвае колькасць памылак, якія непазбежна адбываюцца.
Самае страшнае, што мы вымушаныя думаць не пра тое, як спраектаваць, раскласці файлікі па татачках, дэкампазіраваць, зрабіць падтрымліваным, чытаным і гэтак далей код, а пра тое, як бы мне карэктна напісаць гэтую каманду, таму што я яе неяк няправільна напісаў. .
Як пачатковец вы спрабуеце спазнаць тэраформ, а IDE вам у гэтым ніколькі не дапамагае. Калі ёсць дакументацыя - зайшлі, паглядзелі. Але калі б вы заязджалі ў новую мову праграмавання, то IDE падказала б, што ёсць такі тып, а такога не. Прынамсі, на ўзроўні int ці string. Гэта часта бывае карысным.
А як жа тэсты?
Вы спытаеце: "Як жа тэсты, спадары праграмісты?" Сур'ёзныя хлопцы тэсціруюць усё на продзе, і гэта жорстка. Вось прыклад юнітэста для тэраформ-модуля з сайта .
У іх добрая дакумэнтацыя. Microsoft мне заўсёды падабаліся сваім падыходам да дакументацыі і навучанні. Але не трэба быць дзядзькам Бобам, каб зразумець, што тут не ідэальны код. Звярніце ўвагу на валідацыю, вынесеную направа.
Праблема unit-тэсту ў тым, што мы з вамі можам праверыць карэктнасць Jsonа на вынахадзе. Я кінуў 5 параметраў, мне выдалася анучка Json на 2000 радкоў. Я магу прааналізаваць, што тут адбываецца, validate test result…
Складана аналізаваць Json у Go. А трэба пісаць у Go, таму што тэраформ на Go – гэта добрая практыка таго, што тэстуеш у той мове, у якой ты пішаш. Сама арганізацыя кода вельмі слабая. Пры гэтым – гэта лепшая бібліятэка для тэсціравання.
Сам Microsoft піша свае модулі, тэсціруючы іх такім спосабам. Канешне, гэта Open Source. Усё, пра што я кажу вы можаце прыйсці і паправіць. Я магу сесці і за тыдзень усё паправіць, заапенсорсіць убудовы VS-кода, тэраформ, зрабіць убудову для райдэра. Можа быць, напісаць парачку аналізатараў, прыкруціць лінтэры, законтрыб'юціць бібліятэку для тэставання. Усё магу зрабіць. Але я не гэтым мушу займацца.
Лепшыя практыкі Infrastructure as code
Едзем далей. Калі ў IaC няма тэстаў, дрэнна з IDE і тулінгам, то павінны быць хаця б лепшыя практыкі. Я проста пайшоў у гугл-аналітыку і правёў параўнанне двух пошукавых запытаў: Terraform best practices і c# best practices.
Што мы бачым? Бязлітасную статыстыку не на нашу карысць. Па колькасці матэрыялу - тое ж самае. У C# распрацоўцы мы проста купаемся ў матэрыялах, у нас ёсць звышлепшыя практыкі, ёсць кнігі напісаныя экспертамі, а таксама кніжкі, напісаныя на кніжкі іншымі экспертамі, якія крытыкуюць тыя кніжкі. Мора афіцыйнай дакументацыі, артыкулаў, якія навучаюць курсаў, зараз яшчэ і open source распрацоўка.
Што тычыцца запыту па IaC: тут вы па макулінках спрабуеце сабраць інфу з дакладаў хайлаада або HashiConf, з афіцыйнай дакументацыі і шматлікіх issue на гітхабе. Як увогуле гэтыя модулі раскідваць, што з імі рабіць? Здаецца, што гэта рэальная праблема… Ёсць жа кам'юніці, спадары, дзе на любое пытанне табе дадуць 10 каментаў на гітхабе. Але гэта не дакладна.
Нажаль, у дадзены момант часу эксперты толькі пачынаюць з'яўляцца. Пакуль іх замала. А само кам'юніці боўтаецца на ўзроўні зародкаў.
Куды ўсё гэта рухаецца і што рабіць
Можна ўсё кінуць і пайсці назад на C#, у свет райдэра. Але не. Навошта вы ўвогуле сталі б гэтым займацца, калі не знайсці рашэнне. Далей я прыводжу свае суб'ектыўныя высновы. Можаце паспрачацца са мной у каментарах, будзе цікава.
Асабіста я стаўлю на некалькі рэчаў:
- Развіццё ў гэтай сферы адбываецца вельмі хутка. Прыводжу графік запытаў па DevOps.
Можа быць тэма хайпавая, але сам факт таго, што сфера расце, усяляе некаторую надзею.Калі нешта расце настолькі хутка, дык абавязкова з'явяцца разумныя людзі, якія скажуць як трэба рабіць, а як не трэба. Павелічэнне папулярнасці вядзе да таго, што можа ў кагосьці будзе час дапісаць нарэшце плягін да jsonnet для vscode, які дазволіць пераходзіць да імплементацыі функцыі, а не шукаць яе праз ctrl+shift+f. Калі ўсё разьвіваецца, зьяўляецца больш матэрыялаў. Тое ж выйсце кнігі ад гугла пра SRE выдатны таму прыклад.
- Ёсць распрацаваныя методыкі і практыкі ў звычайнай распрацоўцы, якія мы можам паспяхова прымяняць тут. Так, ёсць нюансы з тэставаннем і гетэрагенным асяроддзем, недастатковы тулінг, але назапашана велізарная колькасць практык, якія могуць спатрэбіцца і дапамагчы.
Банальны прыклад: сумесная праца праз pair programming. Ён моцна дапамагае разабрацца. Калі ў цябе ёсць побач сусед, які таксама нешта спрабуе зразумець, разам вы зразумееце лепей.
Разуменне таго, як робіцца рэфакторынг дапамагае нават у такой сітуацыі вырабляць яго. Гэта значыць, ты можаш памяняць не ўсё адразу, а памяняць нэймінг, потым памяняць размяшчэнне, потым можа вылучыць нейкую частку, ой, а тут не хапае каментароў.
Заключэнне
Нягледзячы на тое, што мае развагі могуць здацца песімістычнымі, я з надзеяй гляджу ў будучыню і шчыра спадзяюся, што ў нас (і ў вас) усё атрымаецца.
Следам рыхтуецца другая частка артыкула. У ёй я раскажу пра тое, як мы паспрабавалі прымяняць практыкі гнуткай распрацоўкі, каб палепшыць наш працэс навучання і працу з інфраструктурай.
Крыніца: habr.com