Дэд бүтцийг давтагдах текст хэлбэрээр код хэлбэрээр дүрслэх нь хулганы товчлуурыг дарах шаардлагагүй системүүдийн хувьд энгийн хамгийн сайн дадал юм. Энэ дадал нь ... гэж нэрлэгддэг болсон. , одоогоор үүнийг хийх хоёр алдартай хэрэгсэл байдаг, ялангуяа AWS дээр: и .
Terraform болон CloudFormation-тай хийсэн туршлагаа харьцуулж байна
Нэгдэхээс өмнө (тэр бол ) Би ажилласан Би Terraform-ыг гурван жил орчим ашигласан. Шинэ ажил дээрээ би Terraform-ыг өргөнөөр ашигласан боловч дараа нь компани намайг CloudFormation зэрэг Amazon маягийн бүх зүйл рүү шилжихэд түлхэц болсон. Би хоёуланд нь зориулсан шилдэг туршлагуудыг хичээнгүйлэн боловсруулж, байгууллага даяарх маш нарийн төвөгтэй ажлын урсгалд хоёр хэрэгслийг ашигласан. Хожим нь Terraform-оос CloudFormation руу шилжих үр дагаврыг сайтар бодож үзсэний дараа би Terraform нь байгууллагын хувьд илүү сайн сонголт байх гэдэгт итгэсэн.
Терраформ аймшигтай юм
Програм хангамжийн бета хувилбар
Terraform одоогоор 1.0 хувилбарт хүрээгүй байгаа нь үүнийг ашиглахгүй байх сайн шалтгаан юм. Анх туршиж үзсэнээс хойш их өөрчлөгдсөн, гэхдээ тэр үед terraform apply Энэ нь хэд хэдэн удаа шинэчлэгдсэний дараа эсвэл хэдэн жилийн дараа л эвдэрдэг байсан. Би "одоо бүх зүйл өөр болсон" гэж хэлэх байсан ч... хүн бүр тэгж хэлдэг, тийм үү? Өмнөх хувилбаруудтай нийцэхгүй өөрчлөлтүүд байгаа ч тэдгээр нь тохиромжтой бөгөөд нөөцийн хадгалалтын синтакс болон хийсвэрлэлүүд одоо яг тохирсон юм шиг санагдаж байна. Хэрэгсэл сайжирсан бололтой, гэхдээ... :-0
Нөгөөтэйгүүр, AWS нь арын нийцтэй байдлыг хадгалах тал дээр сайн ажилласан. Энэ нь тэдний үйлчилгээг нэрийг нь өөрчилж, олон нийтэд хүргэхээс өмнө дотооддоо сайтар шалгадагтай холбоотой байж болох юм. Тиймээс "сайн хийлээ" гэдэг нь дутуу үнэлэлт юм. AWS шиг олон хувьсагчтай, нарийн төвөгтэй API-ийн хувьд арын нийцтэй байдлыг хадгалах нь маш хэцүү байдаг. AWS шиг өргөн хэрэглэгддэг олон нийтийн API-г хадгалах шаардлагатай болсон хэн бүхэн олон жилийн турш үүнийг хийхэд хичнээн хэцүү болохыг ойлгох ёстой. Гэсэн хэдий ч миний мэдэж байгаагаар CloudFormation-ийн зан байдал олон жилийн турш хэзээ ч өөрчлөгдөөгүй.
Хөлтэй нь таар... энэ бол сум.
Миний мэдэхийн нөөцийг устгана уу гадны хүн Өөрийн CF стекээс одоо байгаа CloudFormation нөөцийг импортлох боломжгүй юм. Terraform нь үүнтэй төстэй. Энэ нь танд одоо байгаа нөөцийг стек рүүгээ импортлох боломжийг олгодог. Энэ функц нь үнэхээр гайхалтай боловч агуу хүч чадалтай хамт агуу хариуцлага ирдэг. Та стек дээрээ нөөц нэмсний дараа стектэйгээ ажиллаж байхдаа үүнийг устгах эсвэл өөрчлөх боломжгүй. Энэ нь нэг удаа эсрэгээрээ үр дүнгээ өгсөн. Twitch дээрх хэн нэгэн ямар ч хорон санаагүйгээр санамсаргүйгээр өөр хэн нэгний AWS аюулгүй байдлын бүлгийг өөрийн Terraform стек рүүгээ импортолсон. Тэд хэд хэдэн команд оруулсан бөгөөд ... аюулгүй байдлын бүлэг (ирж буй урсгалын хамт) алга болсон.
Агуу Терраформ
Бүрэн бус төлөв байдлаас сэргэх
Заримдаа CloudFormation нь нэг төлөвөөс нөгөө төлөв рүү бүрэн шилжиж чаддаггүй. Энэ нь өмнөх төлөв рүүгээ буцахыг оролдох болно. Харамсалтай нь энэ нь үргэлж боломжтой байдаггүй. Үүссэн замбараагүй байдлыг засах нь жаахан аймшигтай байж болно - CloudFormation нь хакердуулахад баяртай байх эсэхийг та хэзээ ч мэдэхгүй, хэдийгээр энэ нь зөвхөн засвар хийх зорилгоор байсан ч гэсэн. Энэ нь мөн өмнөх төлөв рүүгээ буцаж чадах эсэхийг нарийн тодорхойлж чадахгүй бөгөөд анхдагчаар хэдэн цагийн турш гайхамшгийг хүлээж гацдаг.
Нөгөөтэйгүүр, Terraform нь бүтэлгүйтсэн шилжилтийг илүү уян хатан сэргээх хандлагатай бөгөөд өргөн хүрээтэй дибаг хийх хэрэгслүүдийг санал болгодог.
Баримт бичгийн төлөвт илүү тодорхой өөрчлөлтүүд
"За, ачааллын тэнцвэржүүлэгч, чи солигдож байна. Гэхдээ яаж?"
—санаа зовсон инженер, зөвшөөрөх товчийг дарахад бэлэн байв.
Заримдаа би CloudFormation стек дэх ачааллын тэнцвэржүүлэгчийг тохируулах шаардлагатай болдог - жишээлбэл, портын дугаар нэмэх эсвэл аюулгүй байдлын бүлгийг өөрчлөх. CloudFormation нь өөрчлөлтийг тийм ч тодорхой харуулдаггүй. Би шаардлагатай зүйлийг устгаагүй эсвэл шаардлагагүй зүйл нэмээгүй эсэхээ шалгахын тулд YAML файлыг арав дахин дахин давхар шалгадаг.
Terraform энэ тал дээр илүү ил тод болсон. Заримдаа бүр хэтэрхий ил тод байдаг (унших нь: ядаргаатай). Аз болоход, хамгийн сүүлийн хувилбарт сайжруулсан өөрчлөлтийн тайлан багтсан бөгөөд одоо та юу өөрчлөгдөж байгааг тодорхой харж чадна.
Уян хатан байдал
Програм хангамжийг урвуу дарааллаар бичих.
Шуудхан хэлэхэд, урт хугацааны програм хангамжийн хамгийн чухал ялгарах онцлог нь өөрчлөлтөд дасан зохицох чадвар юм. Аливаа програм хангамжийг урвуу байдлаар бич. Миний хамгийн том алдаа бол "энгийн" үйлчилгээг аваад дараа нь бүгдийг нь нэг CloudFormation эсвэл Terraform стек болгон чихэхийг оролдох явдал байв. Мэдээжийн хэрэг, хэдэн сарын дараа би бүгдийг нь буруу хийсэн нь тогтоогдсон бөгөөд үйлчилгээ нь үнэндээ энгийн биш байсан! Тиймээс би том стекийг ямар нэгэн байдлаар жижиг бүрэлдэхүүн хэсгүүдэд хуваах шаардлагатай болсон. CloudFormation-ийн тусламжтайгаар үүнийг зөвхөн одоо байгаа стекийг дахин бүтээх замаар л хийж болно, би үүнийг өгөгдлийн сантайгаа хийдэггүй. Нөгөөтэйгүүр, Terraform нь надад стекийг задлан шинжилж, илүү удирдахад хялбар жижиг хэсгүүдэд хуваах боломжийг олгосон.
Git дахь модулиуд
Terraform кодыг олон стек дээр хуваалцах нь CloudFormation-той хуваалцахаас хамаагүй хялбар юм. Terraform-ын тусламжтайгаар та кодыг git репозиторт байрлуулж, семантик хувилбарын хяналтыг ашиглан хандах боломжтой. Энэ репозиторт хандах эрхтэй хэн ч гэсэн хуваалцсан кодыг дахин ашиглах боломжтой. CloudFormation-ийн эквивалент нь S3 боловч энэ нь ижил давуу талыг санал болгодоггүй бөгөөд S3-ийн оронд git-ийг орхих шалтгаан байхгүй.
Байгууллага өргөжин тэлж, нийтлэг стекүүдийг хуваалцах чадвар чухал түвшинд хүрсэн. Terraform үүнийг хялбар бөгөөд байгалийн болгодог бол CloudFormation нь иймэрхүү зүйлийг ажиллуулахын тулд маш их бэрхшээлийг даван туулах шаардлагатай болдог.
Код хэлбэрээр үйлдлүүд
"Бид зохиолоо бичнэ, тэгээд л болоо."
—Терраформын дугуйг дахин зохион бүтээхээс 3 жилийн өмнө инженер байсан.
Програм хангамж хөгжүүлэх тухайд гэвэл Go эсвэл Java програм нь зүгээр л код бичихээс илүү зүйл юм.
Код болгон кодлох
Мөн түүний үйл ажиллагаа явуулдаг дэд бүтэц бий.
Дэд бүтэц нь код
Гэхдээ энэ хаанаас гаралтай вэ? Та үүнийг хэрхэн хянадаг вэ? Таны код хаана байдаг вэ? Хөгжүүлэгчид үүнд хандах зөвшөөрөл авах шаардлагатай юу?
Код хэлбэрээр үйлдлүүд
Програм хангамж хөгжүүлэгч байх нь зүгээр л код бичихээс илүү зүйл юм.
AWS нь цорын ганц сонголт биш: та SignalFx, PagerDuty, эсвэл Github гэх мэт бусад үйлчилгээ үзүүлэгчдийг ашиглах магадлалтай. Магадгүй танд CI/CD-д зориулсан дотоод Jenkins сервер эсвэл хяналт хийх дотоод Grafana хяналтын самбар байгаа байх. Хүмүүс янз бүрийн шалтгааны улмаас Infra-г код болгон сонгодог бөгөөд эдгээр нь бүгд програм хангамжтай холбоотой аливаа зүйлд адилхан чухал юм.
Би Twitch дээр ажиллаж байхдаа бид суулгагдсан системүүд болон Amazon-ы AWS системүүдийн холимог үйлчилгээг хурдасгаж байсан. Бид олон тооны бичил үйлчилгээг гаргаж, засвар үйлчилгээ хийж, үйл ажиллагааны зардлыг нэмэгдүүлж байсан. Яриа иймэрхүү өрнөдөг байсан:
- Я: Чөтгөр гэж, нэг микросервисийг ажиллуулж эхлэхэд их ажил болно. Би үүнийг ашиглан AWS бүртгэл үүсгэх хэрэгтэй болно (бид хоёр бүртгэл үүсгэх гэж байсан) бичил үйлчилгээ), дараа нь энэ нь мэдэгдэл тохируулахад, энэ нь код хадгалах санд, энэ нь имэйл жагсаалтад, мөн энэ нь...
- Хар тугалга: Зохиол бичье, тэгээд л болоо.
- ЯЗа, гэхдээ скрипт өөрөө өөрчлөгдөх болно. Эдгээр бүх суулгагдсан Amazon зүйлс шинэчлэгдсэн эсэхийг шалгах арга бидэнд хэрэгтэй болно.
- Хар тугалгаСайхан сонсогдож байна. Бид үүнд зориулж зохиол бичих болно.
- ЯМаш сайн! Гэхдээ скриптэд параметрүүд хэрэгтэй хэвээр байх болов уу. Тэдгээрийг хүлээн авах уу?
- Хар тугалга: Тийм ээ, тэр үүнийг хүлээн зөвшөөрөх болно, тэр өөр юу хийж чадах билээ!
- ЯЭнэ үйл явц өөрчлөгдөж, урвуу нийцтэй байдал алдагдаж магадгүй. Ямар нэгэн семантик хувилбарын хяналт шаардлагатай болно.
- Хар тугалга: Гайхалтай санаа байна!
- ЯХэрэгслийг хэрэглэгчийн интерфэйс дотор гараар өөрчилж болно. Үүнийг шалгаж, засах арга бидэнд хэрэгтэй болно.
...3 жилийн дараа:
- Хар тугалга: Бид терраформтой болсон.
Түүхийн ёс суртахуун бол: хэдийгээр та ч гэсэн Амазонтой холбоотой бүх зүйл миний чихэнд хүртэл, та AWS биш зүйлийг ашигласаар байгаа бөгөөд эдгээр үйлчилгээнүүд нь тухайн төлөвийг синхрончлохын тулд тохиргооны хэлийг ашигладаг төлөвтэй байна.
CloudFormation Lambda болон Terraform Git модулиуд
Lambda бол CloudFormation-ийн өөрчлөн тохируулсан логикийн асуудлыг шийдэх шийдэл юм. Lambda-ийн тусламжтайгаар та ... хийж чадна буюу Энэ арга нь Terraform-ын git модулиудын семантик хувилбарт байдаггүй нэмэлт нарийн төвөгтэй байдлыг авчирдаг. Миний хувьд хамгийн тулгамдсан асуудал бол эдгээр бүх хэрэглэгчийн ламбдагийн зөвшөөрлийг удирдах явдал байсан (энэ нь олон арван AWS бүртгэлийг хамардаг). Өөр нэг, илүү тулгамдсан асуудал бол тахиа эсвэл өндөгний асуудал байсан: энэ нь ламбда кодтой холбоотой байв. Ламбда функц нь өөрөө дэд бүтэц болон кодын аль аль нь бөгөөд өөрөө хяналт, шинэчлэлт шаарддаг. Авсны сүүлчийн хадаас нь ламбда кодын өөрчлөлтийг семантик байдлаар шинэчлэхэд бэрхшээлтэй байсан; Би мөн стекийн үйлдлүүд шууд тушаалгүйгээр ажиллах хооронд өөрчлөгдөхгүй байхыг баталгаажуулах шаардлагатай болсон.
Би нэгэн цагт сонгодог ачааллын тэнцвэржүүлэгчтэй Elastic Beanstalk орчинд зориулсан канар байршуулалтыг үүсгэхийг хүсч байснаа санаж байна. Хамгийн хялбар арга бол үйлдвэрлэлийн орчны хажууд EB-д зориулж хоёр дахь байршуулалтыг үүсгэх бөгөөд нэг алхам урагшлах явдал юм: автомат масштабтай канар байршуулалтын бүлгийг LB байршуулалттай үйлдвэрлэлийн орчинд нэгтгэх. Terraform нь ашигладаг тул , энэ нь Terraform дээр дөрвөн нэмэлт мөр код шаардах болно. CloudFormation дээр үүнтэй төстэй шийдэл байгаа эсэхийг асуухад надад байршуулах хоолойтой бүхэл бүтэн git репозиторыг зааж өгсөн бөгөөд энэ бүхэн нь Terraform кодын ердөө дөрвөн мөр юу хийж чадахын тулд юм.
Энэ нь шилжилтийг илүү сайн илрүүлдэг
Бодит байдал хүлээлттэй давхцаж байгаа эсэхийг шалгаарай.
Код хэлбэрээр үйлдлүүд нь бодит байдал хүлээлттэй нийцэж байгаа эсэхийг баталгаажуулахад тусалдаг тул маш хүчирхэг функц юм. Энэ нь CloudFormation болон Terraform хоёуланд нь боломжтой. Гэхдээ үйлдвэрлэлийн стек өсөхийн хэрээр CloudFormation дахь дрифт илрүүлэлт нь улам бүр олон хуурамч эерэг үр дүнг өгч байв.
Terraform-той бол та дрифт илрүүлэх илүү дэвшилтэт амьдралын мөчлөгийн дэгээтэй болно. Жишээлбэл, та дараах тушаалыг өгч болно Хэрэв та ECS-ийн бүхэл бүтэн байршуулалтын өөрчлөлтийг үл тоомсорлолгүйгээр тодорхой даалгаврын тодорхойлолт дахь өөрчлөлтийг үл тоомсорлохыг хүсвэл ECS даалгаврын тодорхойлолтод шууд оруулна уу.
CDK болон Үүлэн формацийн ирээдүй
Үүлэн формацийг өргөн хүрээтэй, дэд бүтцийн хооронд удирдахад хэцүү байдаг. Эдгээр бэрхшээлүүдийн олонх нь хүлээн зөвшөөрөгдсөн бөгөөд хэрэгсэл нь дараах функцуудыг шаарддаг. , код доторх үүлэн дэд бүтцийг тодорхойлж, AWS CloudFormation-ээр дамжуулан гүйцэтгэх хүрээ. aws-cdk-ийн ирээдүйд юу болохыг харах сонирхолтой байх болно, гэхдээ Terraform-ийн бусад давуу талуудтай өрсөлдөхөд бэрхшээлтэй байх болно; CloudFormation-ийг ижил түвшинд хүргэхийн тулд томоохон өөрчлөлт шаардлагатай болно.
Terraform-д сэтгэл дундуур байхаас зайлсхийхийн тулд
Энэ бол "код хэлбэрээр дэд бүтэц" болохоос "текст хэлбэрээр" биш юм.
Terraform-ын талаарх анхны сэтгэгдэл маань нэлээд муу байсан. Би зүгээр л энэ аргыг буруу ойлгосон байх гэж бодож байна. Бараг бүх инженерүүд үүнийг хүссэн дэд бүтэц болгон хувиргах шаардлагатай текст формат гэж анхандаа ойлгодог. ИНГЭЖ БИШ.
Сайн програм хангамж хөгжүүлэлтийн үнэнүүд нь Terraform-д ч хамаатай.
Terraform дээр сайн код бичих олон шилдэг туршлагыг үл тоомсорлож байгааг би харсан. Та сайн программист болохын тулд олон жилийг зарцуулсан. Зөвхөн Terraform дээр ажиллаж байгаа гээд энэ туршлагыг бүү хая. Сайн програм хангамж хөгжүүлэх үнэн нь Terraform-д ч хамаатай.
Кодыг хэрхэн баримтжуулж болохгүй вэ?
Би ямар ч баримт бичиггүй асар том Terraform стекүүдтэй таарсан. Ямар ч баримт бичиггүйгээр хуудсууд дээр код хэрхэн бичих вэ? Өөрийнхөө талаар тайлбарласан баримт бичгийг нэмнэ үү код Terraform (энд "код" гэдэг үгийг онцолсон), энэ хэсэг яагаад чухал болох, та юу хийдэг вэ.
Нэгэн цагт нэг том main() функц байсан үйлчилгээг хэрхэн байршуулах вэ?
Би нэг модуль хэлбэрээр танилцуулсан маш нарийн төвөгтэй Terraform стекүүдтэй таарсан. Бид яагаад ийм програм хангамжийг байршуулдаггүй юм бэ? Бид яагаад том функцуудыг жижиг функцүүд болгон хуваадаг вэ? Үүнтэй ижил хариултууд Terraform-д хамаарна. Хэрэв таны модуль хэтэрхий том бол та үүнийг жижиг модуль болгон хуваах хэрэгтэй.
Танай компани номын сан ашигладаггүй юм уу?
Би инженерүүд Terraform ашиглан шинэ төсөл хэрэгжүүлэхдээ бусад төслүүдээс асар том хэсгүүдийг өөрсдийн төслүүд рүү хуулж буулгаад, дараа нь ажиллаж эхлэх хүртэл нь тэдгээрийг өөрчилж байхыг харсан. Танай компанид үйлдвэрлэлийн кодоор үүнийг хийх үү? Бид номын сангуудыг ямар нэгэн шалтгаанаар ашигладаг. Тийм ээ, тийм үү? гэхдээ зарчмын хувьд нийтийн номын сангүйгээр бид хаана байх байсан бэ?!
Та PEP8 эсвэл gofmt ашигладаггүй юм уу?
Ихэнх хэлнүүд стандарт, хүлээн зөвшөөрөгдсөн форматлах схемтэй байдаг. Python хэл дээр энэ нь PEP8. Go хэл дээр энэ нь gofmt. Terraform нь өөрийн гэсэн хэлбэртэй байдаг: terraform fmtТаалан соёрхоно уу!
Та JavaScript мэдэхгүй байж React ашиглах уу?
Terraform модулиуд нь таны барьж буй нарийн төвөгтэй дэд бүтцийн зарим хэсгийг хялбарчилж болох ч энэ нь та үүнийг бүрэн үл тоомсорлож болно гэсэн үг биш юм. Нөөцийг ойлголгүйгээр Terraform-ыг зөв ашиглахыг хүсч байна уу? Та сүйрэх болно: цаг хугацаа өнгөрөх болно, гэхдээ та Terraform-ыг хэзээ ч эзэмшиж чадахгүй хэвээр байх болно.
Та синглтон эсвэл хамаарлын тарилга ашиглан код бичдэг үү?
Хамаарлын тарилга нь програм хангамж хөгжүүлэх хамгийн сайн туршлага бөгөөд ганц бие хувилбаруудаас илүүд үздэг. Энэ нь Terraform-д хэрхэн хамаарах вэ? Би алсын төлөвөөс хамааралтай Terraform модулиудыг харсан. Алсын төлөвийг авчирдаг модулиудыг бичихийн оронд параметрүүдийг авдаг модуль бич. Дараа нь эдгээр параметрүүдийг модуль руу дамжуул.
Танай номын сангууд арван зүйлийг сайн хийдэг үү эсвэл нэг зүйлийг маш сайн хийдэг үү?
Нэг даалгаварт анхаарлаа төвлөрүүлж, онцгой сайн хийдэг сангууд хамгийн сайн ажилладаг. Бүх зүйлийг нэг дор хийхийг оролддог том Terraform модулиудыг бичихийн оронд тэдгээрийг нэг зүйлийг сайн хийдэг хэсгүүдэд нэгтгэ. Дараа нь шаардлагатай бол нэгтгэ.
Буцах нийцтэй байдалгүйгээр номын сангуудад хэрхэн өөрчлөлт оруулах вэ?
Ердийн номын сангийн нэгэн адил хуваалцсан Terraform модуль нь хэрэглэгчдэд ямар нэгэн байдлаар буцаад нийцэхгүй өөрчлөлтүүдийн талаар мэдэгдэх шаардлагатай байдаг. Ийм өөрчлөлтүүд номын санд гарахад төвөгтэй байдаг бөгөөд Terraform модулиудад буцаад нийцэхгүй өөрчлөлтүүд гарахад ч мөн адил төвөгтэй байдаг. Terraform модулиудыг ашиглахдаа git tags болон semver ашиглахыг зөвлөж байна.
Үйлдвэрлэлийн үйлчилгээ таны зөөврийн компьютер дээр ажиллаж байна уу эсвэл дата төвд ажиллаж байна уу?
Hashicorp нь дараах хэрэгслүүдтэй таны Terraform-ыг ажиллуулах. Эдгээр төвлөрсөн үйлчилгээнүүд нь Terraform-ын өөрчлөлтийг удирдах, аудит хийх, батлахад хялбар болгодог.
Чи шалгалт бичдэггүй юм уу?
Инженерүүд кодыг шалгах шаардлагатай гэдгийг хүлээн зөвшөөрдөг ч Terraform-той ажиллахдаа үүнийг хийхээ ихэвчлэн мартдаг. Энэ нь дэд бүтцийн хувьд төвөгтэй асуудлуудад хүргэж болзошгүй юм. Би CI/CD-ийн үед баталгаажуулалтад зохих ёсоор байрлуулж болох модулиудыг ашиглан стекийн "турших" эсвэл "дээж үүсгэх"-ийг зөвлөж байна.
Терраформ болон микросервисүүд
Микросервис компаниудын амьдрал, үхэл нь шинэ микросервисийн ажлын стекүүдийн хурд, инноваци, тасалдалаас хамаарна.
Микросервис архитектурын хамгийн түгээмэл сөрөг тал нь шийдэгдээгүй хэвээр байгаа бөгөөд энэ нь кодтой холбоотой биш, харин ажилтай холбоотой юм. Хэрэв та Terraform-ийг зөвхөн микросервис архитектурын дэд бүтцийн талыг автоматжуулах арга гэж үзвэл энэ системийн жинхэнэ ашиг тусыг алдаж байна гэсэн үг юм. .
Эх сурвалж: www.habr.com
