Биздин компания SRE командасын ишке киргизүү процессинде. Мен бул окуяга өнүгүү тараптан келдим. Бул процессте мен башка иштеп чыгуучулар менен бөлүшкүм келген ойлор жана түшүнүктөр менен келдим. Бул рефлексия макаласында мен эмне болуп жатканы, ал кандай болуп жатканы жана ар бир адам аны менен кантип жашай берери жөнүндө сүйлөшөм.
Биздин ички иш-чарабызда сүйлөгөн сөзүнүн негизинде жазылган макалалар сериясынын уландысы :
2. Инфраструктура код катары. (Сен бул жерде)
3. C# моделдерин колдонуу менен Typescript келишимдерин түзүү. (Прогрессте...)
4. Raft консенсус алгоритмине киришүү. (Прогрессте...)
...
Биз идеяларды ишке ашыруу менен SRE командасын түзүүнү чечтик . Алар өздөрүнүн иштеп чыгуучуларынын арасынан программисттерди жалдап, бир нече айга окууга жөнөтүштү.
Командада төмөнкүдөй машыгуу милдеттери болгон:
- Биздин инфраструктурабызды сүрөттөп бериңиз, ал көбүнчө Microsoft Azure'де код түрүндө (Terraform жана анын айланасындагы бардык нерселер).
- Иштеп чыгуучуларга инфраструктура менен иштөөнү үйрөтүңүз.
- Иштеп чыгуучуларды кызматка даярдоо.
Инфраструктура түшүнүгүн код катары киргизебиз
Кадимки дүйнөнүн моделинде (классикалык башкаруу), инфраструктура жөнүндө билим эки жерде жайгашкан:
- Же эксперттердин башындагы билим түрүндө.
- Же бул маалымат кээ бир машинкаларда, алардын айрымдары адистерге белгилүү. Бирок сырттан келген адам (эгерде биздин команда күтүлбөгөн жерден өлүп калса) эмне иштээрин жана кандай иштээрин аныктай ала тургандыгы чындык эмес. Машинада көп маалымат болушу мүмкүн: аксессуарлар, кронжобдор, коркутуу (кара. ) диск жана эмне болушу мүмкүн чексиз тизмеси. Чынында эмне болуп жатканын түшүнүү кыйын.
Эки учурда тең биз көз каранды болуп калабыз:
- же өлүмгө дуушар болгон, ооруга дуушар болгон, сүйүүгө кабылган, маанайы өзгөргөн жана жөн эле баналдык жумуштан кеткен адамдан;
- же физикалык жактан иштеген машинадан, ал да кулап, уурдалып, күтүлбөгөн жана ыңгайсыздыктарды жаратат.
Идеалында бардыгы адам окуй турган, сактай турган, жакшы жазылган кодго которулушу керек экени айтпаса да түшүнүктүү.
Ошентип, инфраструктура код катары (Incfastructure as Code - IaC) - бул код түрүндөгү бардык болгон инфраструктуранын сыпаттамасы, ошондой эле аны менен иштөө жана андан реалдуу инфраструктураны ишке ашыруу үчүн тиешелүү куралдар.
Эмне үчүн баарын кодго которуу керек?Адамдар машина эмес. Алар баарын эстей алышпайт. Адам менен машинанын реакциясы ар башка. Автоматташтырылган нерселердин баары адам жасаган бардык нерседен тезирээк болот. Эң негизгиси чындыктын бир булагы.
Жаңы SRE инженерлери кайдан келишет?Ошентип, биз жаңы SRE инженерлерин жалдоону чечтик, бирок аларды кайдан алуу керек? Туура жооптору бар китеп () бизге мындай дейт: иштеп чыгуучулардан. Анткени, алар код менен иштешет, сиз идеалдуу абалга жетесиз.
Биз аларды компаниябыздан тышкары кадрлар рыногунда көп издедик. Бирок мойнубузга алышыбыз керек, биз өтүнүчүбүзгө ылайыктуу эч кимди таба алган жокпуз. Мен өз элимдин арасынан издөөгө туура келди.
Проблемалар Инфраструктура код катары
Эми инфраструктураны кодго кантип катуу коддосо болорун мисалдарды карап көрөлү. Код жакшы жазылган, жогорку сапатта, комментарийлер жана чегинүүлөр менен.
Терраформадан мисал коду.
Ansibleден үлгү коду.
Мырзалар, ушунча жөнөкөй болсо кана! Биз чыныгы дүйнөдөбүз жана ал ар дайым сизди таң калтырууга, сюрприздерди жана көйгөйлөрдү тартуулоого даяр. Аларсыз бул жерде да болбойт.
1. Биринчи маселе, көпчүлүк учурларда IaC кандайдыр бир dsl болуп саналат.
Ал эми DSL, өз кезегинде, структуранын сүрөттөлүшү болуп саналат. Тагыраак айтканда, сизде эмне болушу керек: Json, Yaml, кээ бир ири компаниялардын модификациялары, алар өздөрүнүн dsl менен (HCL terraform колдонулат).
Кыйынчылык, ал оңой эле тааныш нерселерди камтыбайт:
- өзгөрмөлөр;
- шарттар;
- бир жерде комментарийлер жок, мисалы, Джсондо, демейки боюнча алар берилбейт;
- функциялар;
- жана мен класстар, мурас жана башка нерселер сыяктуу жогорку деңгээлдеги нерселер жөнүндө сөз кылбайм.
2. Мындай коддун экинчи көйгөйү - бул көбүнчө гетерогендүү чөйрө. Адатта сиз C# менен отуруп иштейсиз, б.а. бир тил, бир стек, бир экосистема менен. Ал эми бул жерде сизде көптөгөн технологиялар бар.
Python менен bash Json киргизилген процессти баштаганда бул абдан реалдуу жагдай. Сиз аны талдайсыз, анан башка генератор дагы 30 файлды чыгарат. Мунун бардыгы үчүн киргизүү өзгөрмөлөрү Azure Key Vault'дан алынат, алар Go'до жазылган drone.io плагини аркылуу бириктирилет жана бул өзгөрмөлөр jsonnet шаблон кыймылдаткычынан генерациялоонун натыйжасында түзүлгөн yaml аркылуу өтөт. Ушунчалык ар түрдүү чөйрөдө так сүрөттөлгөн кодго ээ болуу өтө кыйын.
Бир милдеттин алкагындагы салттуу өнүгүү бир тил менен келет. Бул жерде биз көптөгөн тилдер менен иштейбиз.
3. Үчүнчү маселе – тюнинг. Биз үчүн бардыгын жасаган редакторлорду (Ms Visual Studio, Jetbrains Rider) муздатууга көнүп калганбыз. А биз келесоо болсок да жаңылабыз деп айтышат. Бул нормалдуу жана табигый көрүнөт.
Бирок жакын жерде VSCode бар, анда кандайдыр бир жол менен орнотулган, колдоого алынган же колдоого алынбаган плагиндер бар. Жаңы версиялар чыгып, колдоого алынган эмес. Функцияны ишке ашырууга баналдык өтүү (ал бар болсо да) татаал жана маанилүү эмес маселеге айланат. Жөнөкөй өзгөрмөнүн атын өзгөртүү - бул ондогон файлдардын долбоорундагы кайталоо. Эгер ал сизге керектүү нерсени жайгаштырса, сиз бактылуу болосуз. Албетте, бул жерде жана бул жерде арткы жарыктандыруу бар, автоматтык түрдө бүтүрүү бар, бир жерде форматтоо бар (бирок бул мен үчүн Windows'тун терраформасында иштеген жок).
Бул жазуу учурунда 0.12 версиясын колдоо үчүн азырынча чыга элек, бирок ал 3 ай бою чыгарылган.
Унутууга убакыт келди...
- Мүчүлүштүктөрдү оңдоо.
- Рефакторинг куралы.
- Авто бүтүрүү.
- Компиляция учурунда каталарды аныктоо.
Бул күлкүлүү, бирок бул иштеп чыгуу убактысын көбөйтөт жана сөзсүз түрдө пайда болгон каталардын санын көбөйтөт.
Эң жаманы, биз кантип долбоорлоо, файлдарды папкаларга иретке келтирүү, ыдыратуу, кодду сактоого, окула турган кылуу ж. .
Баштоочу катары сиз терраформаларды үйрөнүүгө аракет кылып жатасыз жана IDE сизге такыр жардам бербейт. Документтери болгондо кирип карагыла. Бирок, эгер сиз жаңы программалоо тилине кирип жаткан болсоңуз, IDE сизге мындай түрү бар экенин айтат, бирок андай нерсе жок. Жок дегенде int же сап деңгээлинде. Бул көбүнчө пайдалуу.
Тесттер жөнүндө эмне айтууга болот?
Сиз: "Тесттер жөнүндө эмне айтууга болот, мырзалар, программисттер?" Олуттуу жигиттер бардыгын өндүрүштө сынашат жана бул кыйын. Бул жерде веб-сайттан терраформ модулу үчүн бирдик сынагынын мисалы келтирилген .
Алардын жакшы документтери бар. Мага Microsoftтун документацияга жана окутууга болгон мамилеси ар дайым жакты. Бирок бул кемчиликсиз код эмес экенин түшүнүү үчүн Боб байке болуунун кереги жок. Оң жактагы текшерүүнү белгилеңиз.
Бирдик сынагынын көйгөйү сиз жана мен Json чыгаруунун тууралыгын текшере алабыз. Мен 5 параметрди ыргытып, 2000 сызыктан турган Json бут кийимин беришти. Мен бул жерде эмне болуп жатканын талдап, тесттин жыйынтыгын ырастай алам...
Go'до Джсонду талдоо кыйын. Ал эми Go тилинде жазышыңыз керек, анткени Go in terraform - бул сиз жазган тилде тестирлөө үчүн жакшы практика. Кодекстин өзүн уюштуруу абдан начар. Ошол эле учурда, бул тестирлөө үчүн мыкты китепкана болуп саналат.
Microsoft өзү модулдарын жазат, аларды ушундай жол менен сынайт. Албетте, бул Open Source. Мен айтып жаткан нерселердин баары келип, оңдосо болот. Мен отуруп алып, бир жуманын ичинде бардыгын оңдой алам, ачык булак VS коду плагиндери, терраформалар, чабандес үчүн плагин жасай алам. Балким, бир-эки анализатор жазып, линтерлерди кошуп, тестирлөө үчүн китепкананы кошо аласыз. Мен баарын кыла алам. Бирок бул мен кылышым керек эмес.
Мыкты тажрыйбалар Инфраструктура код катары
Келгиле, уланталы. Эгерде IaCда тесттер жок болсо, IDE жана тюнинг начар болсо, анда жок дегенде мыкты тажрыйбалар болушу керек. Мен жаңы эле Google Analyticsке кирип, эки издөө сурамын салыштырдым: Terraform мыкты тажрыйбалары жана C# мыкты тажрыйбалары.
Биз эмнени көрүп жатабыз? Ырайымсыз статистика биздин пайдабызга эмес. Материалдын көлөмү бирдей. C# иштеп чыгууда биз жөн эле материалдарга толгонбуз, бизде супер-мыкты тажрыйбалар бар, эксперттер жазган китептер, ошондой эле ал китептерди сындаган башка эксперттердин китептери боюнча жазылган китептер бар. Расмий документтердин, макалалардын, окуу курстарынын деңизи, ошондой эле ачык булактарды иштеп чыгуу.
IaC сурамына келсек: бул жерде сиз жогорку жүктөөдөн же HashiConf отчетторунан, расмий документтерден жана Githubдагы көптөгөн маселелерден аз-аздан маалыматты чогултууга аракет кылып жатасыз. Бул модулдарды жалпысынан кантип бөлүштүрсө болот, алар менен эмне кылуу керек? Бул чыныгы көйгөй окшойт... Коомчулук бар, мырзалар, ар кандай сурооңузга Githubда 10 комментарий берилет. Бирок так эмес.
Тилекке каршы, азыркы учурда эксперттер жаңыдан чыга баштады. Азырынча алардын саны өтө аз. Ал эми коомчулук өзү жөнөкөй деңгээлде асылып жатат.
Мунун баары кайда баратат жана эмне кылуу керек
Сиз баарын таштап, кайра C#, чабандестер дүйнөсүнө бара аласыз. Бирок жок. Эгер чечим таба албасаңыз, эмне үчүн убара болосуз? Төмөндө мен өзүмдүн субъективдүү тыянактарымды келтирем. Комментарийлерде мени менен талашсаңыз болот, бул кызыктуу болот.
Жеке мен бир нече нерсеге коем:
- Бул тармакта өнүгүү абдан тез жүрүп жатат. Бул жерде DevOps үчүн сурамдардын графиги.
Тема дүрбөлөңгө түшүшү мүмкүн, бирок чөйрөнүн өсүп баратканынын өзү кандайдыр бир үмүт берет.Эгер бир нерсе ушунчалык тез өсүп кетсе, анда сөзсүз түрдө акылдуу адамдар пайда болот, алар сизге эмне кылууну жана эмнени кылбоо керектигин айтышат. Популярдуулуктун өсүшү, балким, кимдир бирөө ctrl+shift+f аркылуу издөөнүн ордуна, функцияны ишке ашырууга өтүүгө мүмкүндүк берүүчү vscode үчүн jsonnet плагинин акырында кошууга үлгүрүшүнө алып келет. нерселер өнүгүп, көбүрөөк материалдар пайда болот. Google'дан SRE жөнүндө китептин чыгышы буга эң сонун мисал.
- Кадимки өнүгүүдө биз бул жерде ийгиликтүү колдоно ала турган өнүккөн техникалар жана тажрыйбалар бар. Ооба, тестирлөөнүн нюанстары жана гетерогендүү чөйрө, шаймандардын жетишсиздиги бар, бирок пайдалуу жана пайдалуу боло турган көптөгөн тажрыйбалар топтолгон.
Маанилүү мисал: жуп программалоо аркылуу кызматташуу. Аны түшүнүүгө көп жардам берет. Жаныңызда бир нерсени түшүнүүгө аракет кылган кошунаңыз болсо, чогуу жакшыраак түшүнөсүз.
Рефакторинг кантип жүргүзүлөрүн түшүнүү аны ушундай кырдаалда да жүргүзүүгө жардам берет. Башкача айтканда, бардыгын бир заматта өзгөртө албайсыз, бирок атын өзгөртүңүз, анан жайгашкан жериңизди өзгөртүңүз, анан кандайдыр бир бөлүгүн бөлүп көрсөңүз болот, оо, бирок бул жерде комментарийлер жетишсиз.
жыйынтыктоо
Менин ой жүгүртүүм пессимисттик көрүнгөнүнө карабастан, мен келечекке үмүт менен карайм жана бардыгы биз үчүн (жана сиз) үчүн жакшы болот деп чын жүрөктөн үмүттөнөм.
Кийинки макаланын экинчи бөлүгү даярдалууда. Анда мен окуу процессибизди жана инфраструктура менен иштөөнү жакшыртуу үчүн agile өнүктүрүү тажрыйбаларын кантип колдонууга аракет кылганыбыз жөнүндө сүйлөшөм.
Source: www.habr.com