Terraform'тан CloudFormation'ка которулду - жана өкүндү

Инфраструктураны кайталануучу текст форматында код катары көрсөтүү чычкандар менен ойноону талап кылбаган системалар үчүн эң жөнөкөй эң жакшы тажрыйба. Бул практиканын аты бар - Инфраструктура код катары, жана буга чейин аны ишке ашыруу үчүн эки популярдуу куралдар бар, айрыкча AWS: Terraform и Cloud Formation.

Terraform'тан CloudFormation'ка которулду - жана өкүндү
Terraform жана CloudFormation менен тажрыйбаны салыштыруу

Келгенге чейин Twitch (ал Amazon Jr.) Мен иштедим бир стартапта жана үч жыл бою Terraform колдонгон. Жаңы жерде мен Terraformду бүт күчүм менен колдондум, андан кийин компания Amazon-дун бардыгына, анын ичинде CloudFormation-га өтүүнү түрттү. Мен экөөнө тең мыкты тажрыйбаларды тырышчаактык менен иштеп чыктым жана эки куралды тең өтө татаал, жалпы уюмдагы иш процесстеринде колдондум. Кийинчерээк, Терраформдан CloudFormationге өтүүнүн кесепеттерин ойлонгондон кийин, мен Terraform уюм үчүн эң жакшы тандоо экенине ынандым.

Terraform Horrible

Бета программалык камсыздоо

Terraform 1.0 версиясын чыгара элек, бул аны колдонбоо үчүн жакшы себеп. Мен биринчи жолу өзүм аракет кылып көргөндөн бери бир топ өзгөрдү, бирок ошондо terraform apply көбүнчө бир нече жаңыртуулардан кийин же бир нече жыл колдонуудан кийин бузулуп калат. Мен "азыр баары башкача" деп айтаар элем, бирок... баары ушундай дейт окшойт, туурабы? Мурунку версияларга туура келбеген өзгөртүүлөр бар, бирок алар ылайыктуу, ал тургай ресурстук дүкөндөрдүн синтаксиси жана абстракциялары азыр бизге керектүү нерседей сезилет. Аспап чындап жакшырып калды окшойт, бирок... :-0

Башка жагынан алганда, AWS артка шайкештикти сактоо менен жакшы иш жасады. Бул, балким, алардын кызматтары көбүнчө уюмдун ичинде кылдат текшерилип, андан кийин гана аталышы өзгөртүлүп, жарыяланат. Ошентип, "алар катуу аракет кылышты" - бул кемчилик. AWS сыяктуу ар түрдүү жана татаал система үчүн API'лер менен артка карай шайкештикти сактоо абдан кыйын. Кеңири колдонулуп жаткан коомдук API'лерди кармап турууга аргасыз болгон адам ушунча жылдар бою муну жасоо канчалык кыйын экенин түшүнүшү керек. Бирок CloudFormation жүрүм-туруму, менин эсимде, жылдар бою эч качан өзгөргөн жок.

Буту менен таанышыңыз... бул ок

Менин билишимче, ресурсту жок кылгыла аутсайдер CF стекиңизден CloudFormation стек мүмкүн эмес. Терраформ менен да ушундай. Бул сиздин стекиңизге болгон ресурстарды импорттоого мүмкүндүк берет. Функцияны укмуштуу деп айтууга болот, бирок чоң күч менен чоң жоопкерчилик келет. Сиз жөн гана стекке ресурс кошушуңуз керек жана стекиңиз менен иштеп жатканыңызда бул ресурсту жок кыла же өзгөртө албайсыз. Бир күнү ал тескери натыйжа берди. Бир күнү Twitchде кимдир бирөө кокустан башка бирөөнүн AWS коопсуздук тобун өзүнүн Terraform стекине эч кандай бузукулуксуз импорттоп алган. Мен бир нече буйруктарды киргиздим жана... коопсуздук тобу (кирүүчү трафик менен бирге) жок болду.

Terraform Great

Толук эмес абалдан калыбына келтирүү

Кээде CloudFormation бир абалдан экинчисине толугу менен өтө албай калат. Ошол эле учурда мурункусуна кайтууга аракет кылат. Бул дайыма эле ишке аша бербегени өкүнүчтүү. Кийинчерээк эмне болгонун оңдоо абдан коркунучтуу болушу мүмкүн - CloudFormation анын хакерликке кабылып жатканына сүйүнөрүн эч качан биле албайсыз - аны оңдоо үчүн да. Мурунку абалга кайтуу мүмкүнбү же жокпу, ал чындап эле кантип аныктоону билбейт жана демейки боюнча, кереметти күтүп саат бою илип кетет.

Terraform, экинчи жагынан, ийгиликсиз өтүүдөн бир топ жакшыраак калыбына келет жана өркүндөтүлгөн мүчүлүштүктөрдү оңдоо куралдарын сунуштайт.

Документтин абалына өзгөртүүлөр айкыныраак

«Макул, жүк балансы, сен өзгөрүп жатасың. Бирок кантип?"

—сарсанаа инженер, «кабыл алуу» кнопкасын басууга даяр.

Кээде CloudFormation стекиндеги жүк баланстоочу менен кээ бир манипуляцияларды жасашым керек, мисалы, порт номерин кошуу же коопсуздук тобун өзгөртүү. ClouFormation начар өзгөрүүлөрдү көрсөтөт. Мен, төөнөгүчтөр жана ийнелер боюнча, мен керектүү эч нерсени өчүрбөгөнүмдү жана керексиз эч нерсе кошпогондугума ынануу үчүн yaml файлын он жолу текшерем.

Terraform бул жагынан алда канча ачык. Кээде ал өтө тунук (окуу: тажатма). Бактыга жараша, акыркы версия өзгөрүүлөрдүн жакшыртылган дисплейин камтыйт, ошондуктан сиз азыр эмне өзгөрүп жатканын так көрө аласыз.

ийкемдүүлүк

Программаны артка жазыңыз.

Ачык айтканда, узак мөөнөттүү программалык камсыздоонун эң маанилүү өзгөчөлүгү – бул өзгөрүүлөргө ыңгайлашуу. Ар кандай программалык камсыздоону артка жазыңыз. Мен көбүнчө каталарды "жөнөкөй" кызматты колдонуп, анан баарын бир CloudFormation же Terraform стекине тыгып баштадым. Анан, албетте, бир нече ай өткөндөн кийин, мен баарын туура эмес түшүнгөнүм ачыкка чыкты жана кызмат чындыгында жөнөкөй эмес! Эми мен кандайдыр бир жол менен чоң стекти кичинекей компоненттерге бөлүшүм керек. CloudFormation менен иштегениңизде, муну алгач учурдагы стекти кайра түзүү менен гана жасоого болот, мен муну өзүмдүн маалымат базаларым менен жасабайм. Terraform, экинчи жагынан, стекти бөлүп, аны түшүнүктүүраак майда бөлүктөргө бөлүүгө мүмкүндүк берди.

Gitтеги модулдар

Terraform кодун бир нече стек аркылуу бөлүшүү CloudFormation кодун бөлүшүүгө караганда алда канча оңой. Terraform менен сиз кодуңузду git репозиторийине салып, ага семантикалык версияны башкаруу аркылуу кире аласыз. Бул репозиторийге кирүү мүмкүнчүлүгү бар адам бөлүшүлгөн кодду кайра колдоно алат. CloudFormation эквиваленти S3, бирок анын бирдей артыкчылыктары жок жана S3 пайдасына gitтен баш тартууга эч кандай себеп жок.

Уюм өсүп, жалпы стектерди бөлүшүү жөндөмдүүлүгү критикалык деңгээлге жетти. Terraform мунун бардыгын оңой жана табигый кылат, ал эми CloudFormation сизди ушул сыяктуу бир нерсеге ээ боло элегиңизден секирип өтүүгө мажбурлайт.

Операциялар код катары

"Келгиле, аны скрипт кылалы жана макул."

—Терраформ велосипедин ойлоп тапкандан 3 жыл мурун инженер.

Программалык камсыздоону иштеп чыгууга келгенде, Go же Java программасы жөн гана код эмес.

Terraform'тан CloudFormation'ка которулду - жана өкүндү
Код катары код

Ал жерде иштеген инфраструктура да бар.

Terraform'тан CloudFormation'ка которулду - жана өкүндү
Инфраструктура код катары

Бирок ал кайдан? Аны кантип көзөмөлдөө керек? Сиздин кодуңуз кайда жашайт? Иштеп чыгуучуларга кирүү уруксаты керекпи?

Terraform'тан CloudFormation'ка которулду - жана өкүндү
Операциялар код катары

Программалык камсыздоону иштеп чыгуучу болуу жөн гана код жазууну билдирбейт.

AWS жалгыз эмес: балким, сиз башка провайдерлерди колдоносуз. SignalFx, PagerDuty же Github. Балким, сизде CI/CD үчүн ички Jenkins сервери же мониторинг жүргүзүү үчүн ички Grafana панели бардыр. Infra as Code ар кандай себептерден улам тандалып алынат жана алардын ар бири программалык камсыздоого тиешелүү бардык нерселер үчүн бирдей маанилүү.

Мен Twitchте иштегенде, биз Amazon'дун аралаш камтылган жана AWS тутумдарынын ичиндеги кызматтарды тездеттик. Биз көптөгөн микросервистерди токтотуп, колдоого алып, операциялык чыгымдарды көбөйттүк. Талкуулар мындайча өттү:

  • Я: Каргыш тийсин, бул бир микросервисти ашыкча кылуу үчүн көп жаңсоолор. Мен бул таштандыны AWS каттоо эсебин түзүү үчүн колдонушум керек (биз 2 аккаунтка кирдик микросервис), анда бул эскертүүлөрдү орнотуу үчүн, бул код репозиторий үчүн, бул электрондук почта тизмеси үчүн, анан бул...
  • коргошун: Келгиле, аны скрипт кылалы жана макул.
  • Я: Макул, бирок сценарийдин өзү өзгөрөт. Бул камтылган Amazon гизмостарынын баары жаңыртылганын текшерүүнүн бир жолу болушу керек.
  • коргошун: Жакшы болчудай. Жана биз бул үчүн сценарий жазабыз.
  • Я: Абдан жакшы! Жана скрипт дагы деле параметрлерди коюшу керек болот. Ал аларды кабыл алабы?
  • коргошун: Барган жерине жеткирсин!
  • Я: Процесс өзгөрүшү мүмкүн жана артка шайкештик жоголот. Семантикалык версияны башкаруунун кандайдыр бир түрү талап кылынат.
  • коргошун: Мыкты ой!
  • Я: Куралдар колдонуучу интерфейсинин ичинде кол менен өзгөртүлүшү мүмкүн. Муну текшерип, оңдоонун жолу керек.

…3 жылдан кийин:

  • коргошун: Жана биз терраформа алдык.

Окуянын моралдык мааниси: сен болсо да Amazon бардык нерсеге баш ийет, сиз дагы эле AWS'тен эмес нерсени колдонуп жатасыз жана бул кызматтарда ошол абалды синхрондоштуруу үчүн конфигурация тилин колдонгон абал бар.

CloudFormation lambda vs git модулдары terraform

lambda - бул CloudFormation'тун жеке логика маселесин чечүү. Ламбда менен болот макросторду түзүү же колдонуучу булагы. Бул ыкма Terraformдун git модулдарынын семантикалык версиясында жок кошумча татаалдыктарды киргизет. Мен үчүн эң актуалдуу маселе бул колдонуучунун бардык ламбдаларына уруксаттарды башкаруу болду (жана булар ондогон AWS эсептери). Дагы бир маанилүү маселе "биринчи болуп эмне болду, тоокпу же жумурткабы?" Бул функциянын өзү инфраструктура жана код жана анын өзү мониторинг жана жаңыртууларды талап кылат. Табыттагы акыркы мык - ламбда кодунун өзгөрүүлөрүн семантикалык жактан жаңыртуудагы кыйынчылык; биз ошондой эле түз буйруксуз стек аракеттеринин чуркоо ортосунда өзгөрбөшүнө ынанышыбыз керек болчу.

Эсимде, бир жолу классикалык жүк баланстоочу менен Elastic Beanstalk чөйрөсү үчүн канареяны түзгүм келген. Эң оңой нерсе, өндүрүш чөйрөсүнүн жанында EB үчүн экинчи жайгаштырууну жасоо, аны бир кадам алдыга жылдыруу: авто-масштабдуу канарларды жайылтуу тобун өндүрүш чөйрөсүндө LB жайылтуу тобу менен айкалыштыруу. Жана Terraform колдонгондон бери Корутунду катары ASG beantalk, бул үчүн Terraform ичинде 4 кошумча код саптары талап кылынат. Мен CloudFormationде салыштырууга боло турган чечим барбы деп сураганымда, алар мени жайылтуу түтүктөрү бар бүтүндөй гит репозиторийине көрсөтүштү, мунун баары Terraform кодунун начар 4 саптары жасай ала турган нерсе үчүн.

Ал дрейфти жакшыраак аныктайт

Чындык күтүүлөргө дал келээрин текшериңиз.

Дрифт аныктоо коду өзгөчөлүгү катары абдан күчтүү операциялар болуп саналат, анткени ал реалдуулук күтүүлөргө дал келүүгө жардам берет. Бул CloudFormation жана Terraform менен да жеткиликтүү. Бирок өндүрүш стекти өскөн сайын, CloudFormation'да дрейфти издөө уламдан-улам жалган аныктоолорду жаратты.

Terraform менен сизде дрейфти аныктоо үчүн алда канча өркүндөтүлгөн илгичтер бар. Мисалы, сиз буйрук киргизесиз өзгөртүүлөр_эгер ECS тапшырмасынын аныктамасында түздөн-түз ECS тапшырмасынын аныктамасында.

CDK жана CloudFormation келечеги

CloudFormation чоң, кайчылаш инфраструктуралык масштабда башкаруу кыйын. Бул кыйынчылыктардын көбү таанылат жана курал сыяктуу нерселер керек aws-cdk, коддо булут инфраструктурасын аныктоо жана аны AWS CloudFormation аркылуу иштетүү үчүн негиз. Келечекте aws-cdk эмне болорун көрүү кызыктуу болот, бирок Terraformдун башка күчтүү жактары менен атаандашуу кыйынга турат; CloudFormation жаңыртуу үчүн глобалдык өзгөртүүлөр талап кылынат.

Ошентип, Terraform көңүлүн калтырбайт

Бул "текст катары" эмес, "код катары инфраструктура".

Терраформ боюнча менин биринчи таасирим абдан жаман болду. Мен жөн гана мамилени түшүнгөн жокмун деп ойлойм. Дээрлик бардык инженерлер аны каалаган инфраструктурага айландыруу керек болгон текст форматы катары кабыл алышат. УШУНДАЙ КЫЛБА.

Жакшы программалык камсыздоону иштеп чыгуунун чындыктары Terraform үчүн да тиешелүү.

Терраформда жакшы кодду түзүү үчүн кабыл алынган көптөгөн практикаларды көрдүм. Сиз жакшы программист болуу үчүн көп жылдар бою окугансыз. Терраформ менен иштеп жатканыңыз үчүн бул тажрыйбадан баш тартпаңыз. Жакшы программалык камсыздоону иштеп чыгуунун чындыктары Terraform үчүн колдонулат.

Кантип код документтештирилбейт?

Мен эч кандай документтери жок чоң Terraform стектерин көрдүм. Кодду кантип барактарга жаза аласыз - такыр документсиз? Сизди түшүндүргөн документтерди кошуңуз коду Terraform ("код" сөзүнө басым жасоо), бул бөлүм эмне үчүн абдан маанилүү жана сиз эмне кыласыз.

Бир кездеги чоң негизги() функция болгон кызматтарды кантип орното алабыз?

Мен бир модуль катары берилген абдан татаал Terraform стектерин көрдүм. Эмне үчүн биз программалык камсыздоону ушундай жол менен жайгаштырбайбыз? Эмне үчүн биз чоң функцияларды кичинесинен бөлөбүз? Ошол эле жооптор Terraform үчүн колдонулат. Эгерде сиздин модулуңуз өтө чоң болсо, анда сиз аны кичинекей модулдарга бөлүшүңүз керек.

Сиздин компания китепканаларды колдонбойбу?

Мен инженерлер Terraform аркылуу жаңы долбоорду кантип ойлоп таап, башка долбоорлордун чоң бөлүктөрүн өздөрүнө акылсыз түрдө көчүрүп, анан ал иштей баштаганга чейин алар менен аралашып жүргөнүн көрдүм. Сиз компанияңызда "согуштук" код менен ушундай иштейсизби? Биз жөн эле китепканаларды колдонбойбуз. Ооба, баары китепкана болуш керек эмес, бирок принципиалдуу түрдө жалпы китепканалары жок биз кайдабыз?!

PEP8 же gofmt колдонбойсузбу?

Көпчүлүк тилдерде стандарттуу, кабыл алынган форматтоо схемасы бар. Pythonдо бул PEP8. In Go - gofmt. Terraform өзүнө таандык: terraform fmt. Ден соолук үчүн колдонуңуз!

Сиз JavaScript билбей туруп React колдоносузбу?

Terraform модулдары сиз түзгөн татаал инфраструктуранын кээ бир бөлүгүн жөнөкөйлөштүрө алат, бирок бул сиз аны такыр иштете албайсыз дегенди билдирбейт. Терраформды ресурстарды түшүнбөстөн туура колдонгуңуз келеби? Сиз өлдүңүз: убакыт өтөт, жана сиз Терраформды эч качан өздөштүрбөйсүз.

Сиз синглтондор же көз карандылык инъекциясы менен коддоп жатасызбы?

Көз карандылык инъекциясы программалык камсыздоону иштеп чыгуу үчүн таанылган эң мыкты тажрыйба болуп саналат жана синглтондордон артык. Бул Terraform'до канчалык пайдалуу? Мен алыскы абалдан көз каранды Terraform модулдарын көрдүм. Алыскы абалды калыбына келтирүүчү модулдарды жазуунун ордуна, параметрлерди алган модулду жазыңыз. Анан бул параметрлерди модулга өткөрүңүз.

Сиздин китепканаңыз он нерсени жакшы аткарабы же бир нерсе жакшыбы?

Эң жакшы иштеген китепканалар - бул алар абдан жакшы аткарган бир тапшырмага көңүл бурган китепканалар. Баарын бир эле учурда жасоого аракет кылган чоң Terraform модулдарын жазуунун ордуна, алардын бир нерсени жакшы аткарган бөлүктөрүн түзүңүз. Анан керек болсо, аларды бириктирет.

Артка шайкештиксиз китепканаларга кантип өзгөртүүлөрдү киргизесиз?

Кадимки китепкана сыяктуу жалпы Terraform модулу кандайдыр бир жол менен колдонуучуларга артка шайкеш келбей, өзгөрүүлөрдү жеткирүүсү керек. Бул өзгөртүүлөр китепканаларда болгондо тажатма жана Terraform модулдарына артка шайкеш келбеген өзгөртүүлөр киргизилгенде тажатма. Terraform модулдарын колдонууда git тегдерин жана semverди колдонуу сунушталат.

Сиздин өндүрүш кызматыңыз ноутбукуңуздабы же маалымат борборундабы?

Hashicorp сыяктуу куралдар бар терраформдуу булут терраформаңызды иштетүү үчүн. Бул борборлоштурулган кызматтар башкарууну, текшерүүнү жана терраформадагы өзгөрүүлөрдү бекитүүнү жеңилдетет.

Тест жазбайсыңбы?

Инженерлер кодду текшерүү керек экенин түшүнүшөт, бирок алар Terraform менен иштөөдө тестирлөө жөнүндө унутуп коюшат. Инфраструктура үчүн бул чыккынчылык учурларга толгон. Менин кеңешим - CI/CD учурунда тестирлөө үчүн туура жайгаштырыла турган модулдарды колдонуп, стектерди "сыноо" же "мисалы түзүү".

Терраформ жана микросервис

Микросервис компанияларынын жашоосу жана өлүмү жаңы микросервистин жумушчу стектеринин ылдамдыгына, инновациясына жана үзгүлтүккө жараша болот.

Микросервис архитектуралары менен байланышкан эң кеңири таралган терс аспект жана аны жок кылууга болбойт, кодго эмес, ишке байланыштуу. Эгер сиз Terraformду микросервис архитектурасынын инфраструктуралык жагын гана автоматташтыруунун бир жолу деп ойлосоңуз, анда сиз системанын чыныгы артыкчылыктарын колдон чыгарып жатасыз. Азыр болду баары код сыяктуу.

Source: www.habr.com

Комментарий кошуу