Дэд бүтцийг дахин давтагдах текст хэлбэрээр код болгон харуулах нь хулганатай тоглох шаардлагагүй системүүдийн хувьд хамгийн сайн арга юм. Энэ дасгал нь нэртэй байдаг - , ба одоогоор үүнийг хэрэгжүүлэх хоёр алдартай хэрэгсэл байна, ялангуяа AWS: и .
Terraform болон CloudFormation-ийн туршлагыг харьцуулах
Ирэхээс өмнө (тэр бол ) Би ажилласан болон гурван жилийн турш Terraform ашигласан. Шинэ газарт би Terraform-ийг бүх хүч чадлаараа ашигласан бөгөөд дараа нь компани CloudFormation гэх мэт бүх Amazon руу шилжсэн. Би аль алиных нь шилдэг туршлагыг хичээнгүйлэн хөгжүүлж, байгууллагын хэмжээнд маш нарийн төвөгтэй ажлын урсгалд хоёуланг нь ашигласан. Хожим нь Terraform-аас CloudFormation руу шилжихийн үр дагаврыг тунгаан бодож үзсэний эцэст Terraform бол байгууллагын хувьд хамгийн сайн сонголт байж магадгүй гэдэгт итгэлтэй болсон.
Терраформ Аймшигтай
Бета програм хангамж
Terraform 1.0 хувилбарыг хараахан гаргаагүй байгаа нь үүнийг ашиглахгүй байх сайн шалтгаан юм. Би өөрөө анх туршиж үзсэнээс хойш маш их өөрчлөгдсөн, гэхдээ тэр үед terraform apply ихэвчлэн хэд хэдэн шинэчлэлт хийсний дараа эсвэл хэдхэн жилийн турш ашигласны дараа эвдэрдэг. "Одоо бүх зүйл өөр болсон" гэж би хэлэх байсан, гэхдээ ... хүн бүр ингэж хэлдэг бололтой, тийм үү? Өмнөх хувилбаруудтай нийцэхгүй байгаа өөрчлөлтүүд байгаа хэдий ч тэдгээр нь тохиромжтой, тэр ч байтугай нөөцийн дэлгүүрүүдийн синтакс, хийсвэрлэл нь одоо бидэнд хэрэгтэй зүйл болсон юм шиг санагдаж байна. Энэ хэрэгсэл үнэхээр сайжирсан бололтой, гэхдээ... :-0
Нөгөөтэйгүүр, AWS нь хоцрогдсон нийцтэй байдлыг хадгалахын тулд сайн ажил хийсэн. Энэ нь тэдний үйлчилгээг ихэвчлэн байгууллага дотроо сайтар шалгаж, дараа нь нэрийг нь өөрчилснөөр нийтлүүлдэгтэй холбоотой байх. Тиймээс "тэд их хичээсэн" гэдэг нь дутуу илэрхийлэл юм. AWS шиг олон янз, нарийн төвөгтэй системд API-уудтай хоцрогдсон нийцтэй байдлыг хадгалах нь үнэхээр хэцүү байдаг. Олон жилийн турш өргөн хэрэглэгддэг олон нийтийн API-г хадгалах шаардлагатай болсон хэн бүхэн үүнийг хийх нь хичнээн хэцүү болохыг ойлгох ёстой. Гэхдээ миний санах ойд CloudFormation-ийн зан байдал олон жилийн туршид хэзээ ч өөрчлөгдөөгүй.
Хөлтэй уулз... энэ бол сум юм
Миний мэдэж байгаагаар нөөцийг устга гадны хүн Таны CF стекээс CloudFormation стек хийх боломжгүй. Терраформын хувьд ч мөн адил. Энэ нь танд байгаа нөөцийг стек рүүгээ оруулах боломжийг олгодог. Энэ функцийг гайхалтай гэж хэлж болно, гэхдээ агуу хүч нь асар их үүрэг хариуцлагатай байдаг. Та стек дээр нөөц нэмэхэд л хангалттай бөгөөд та стектэйгээ ажиллаж байхдаа энэ нөөцийг устгах эсвэл өөрчлөх боломжгүй. Нэг л өдөр энэ нь эргээд хариу үйлдэл үзүүлэв. Twitch дээр нэгэн өдөр хэн нэгэн өөр хэн нэгний AWS аюулгүй байдлын бүлгийг өөрийн Terraform стек рүү санамсаргүйгээр оруулж ирсэн. Би хэд хэдэн тушаал оруулаад ... хамгаалалтын бүлэг (орж ирж буй урсгалтай хамт) алга болсон.
Терраформ гайхалтай
Бүрэн бус төлөв байдлаас сэргээх
Заримдаа CloudFormation нь нэг төлөвөөс нөгөөд бүрэн шилжиж чадахгүй. Үүний зэрэгцээ тэрээр өмнөх рүүгээ буцахыг хичээх болно. Энэ нь үргэлж боломжгүй байдаг нь харамсалтай. Дараа нь юу болсныг дибаг хийх нь үнэхээр аймшигтай байж болох юм - CloudFormation нь хакердаж байгаадаа баяртай байх эсэхийг та хэзээ ч мэдэхгүй - зүгээр л засахын тулд ч гэсэн. Өмнөх байдалдаа буцаж очих боломжтой эсэхээс үл хамааран тэр хэрхэн яаж тодорхойлохоо мэдэхгүй байгаа бөгөөд анхдагч байдлаар гайхамшгийг хүлээж олон цагаар унтдаг.
Нөгөө талаар Terraform нь бүтэлгүйтсэн шилжилтийн дараа илүү сайн сэргэх хандлагатай бөгөөд дибаг хийх дэвшилтэт хэрэгслүүдийг санал болгодог.
Баримт бичгийн төлөвт илүү тодорхой өөрчлөлт орно
“За, ачаалал тэнцвэржүүлэгч, чи өөрчлөгдөж байна. Гэхдээ яаж?"
-санаа зовсон инженер "зөвшөөрөх" товчийг дарахад бэлэн байна.
Заримдаа би CloudFormation стек дэх ачааллын тэнцвэржүүлэгчийг ашиглан портын дугаар нэмэх эсвэл хамгаалалтын бүлгийг өөрчлөх зэрэг зарим үйлдэл хийх шаардлагатай болдог. ClouFormation нь өөрчлөлтийг муу харуулдаг. Би зүү болон зүү дээр yaml файлыг арван удаа дахин шалгаж, шаардлагатай зүйлээ устгаагүй, шаардлагагүй зүйл нэмээгүй эсэхийг шалгаарай.
Терраформ энэ тал дээр илүү ил тод байдаг. Заримдаа тэр хэтэрхий ил тод байдаг (унш: уйтгартай). Аз болоход, хамгийн сүүлийн хувилбар нь өөрчлөлтийн сайжруулсан дэлгэцийг агуулдаг бөгөөд ингэснээр та яг юу өөрчлөгдөж байгааг харах боломжтой болсон.
Уян хатан байдал
Програм хангамжийг буцааж бичих.
Шулуухан хэлэхэд урт хугацааны програм хангамжийн хамгийн чухал шинж чанар нь өөрчлөлтөд дасан зохицох чадвар юм. Аливаа програм хангамжийг буцааж бичнэ үү. Ихэнх тохиолдолд би "энгийн" үйлчилгээг ашиглаж, дараа нь бүх зүйлийг нэг 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 сервер эсвэл мониторинг хийх дотоод Графана хяналтын самбар байгаа байх. Infra as Code-ийг өөр өөр шалтгаанаар сонгосон бөгөөд тус бүр нь програм хангамжтай холбоотой бүх зүйлд адилхан чухал юм.
Намайг Twitch-д ажиллаж байх үед бид Amazon-ийн холимог суулгагдсан болон AWS системүүдийн үйлчилгээг хурдасгасан. Бид олон бичил үйлчилгээг цуцалж, дэмжиж, үйл ажиллагааны зардлыг нэмэгдүүлсэн. Хэлэлцүүлэг дараах байдлаар өрнөсөн.
- Я: Хараал ид, энэ бол нэг микро үйлчилгээг overclock хийх олон дохио юм. Би AWS данс үүсгэхийн тулд энэ хогийг ашиглах хэрэгтэй болно (бид 2 данс руу орсон бичил үйлчилгээ), дараа нь анхааруулга тохируулах, энэ нь кодын хадгалах газар, энэ нь имэйлийн жагсаалтад зориулагдсан, дараа нь энэ...
- Тэргүүлэх: За ингээд скрипт биччихье.
- Я: За, гэхдээ скрипт өөрөө өөрчлөгдөх болно. Бидэнд Amazon-ийн эдгээр бүх суулгацууд шинэчлэгдсэн эсэхийг шалгах арга хэрэгтэй болно.
- Тэргүүлэх: Сайхан сонсогдож байна. Мөн бид үүнд зориулж скрипт бичих болно.
- Я: Агуу их! Мөн скрипт нь параметрүүдийг тохируулах шаардлагатай хэвээр байх болно. Тэр тэднийг хүлээж авах уу?
- Тэргүүлэх: Тэр явсан газраа аваач!
- Я: Процесс өөрчлөгдөж магадгүй бөгөөд хойшлогдсон нийцтэй байдал алдагдах болно. Зарим төрлийн семантик хувилбарын хяналт шаардлагатай болно.
- Тэргүүлэх: Сайхан санаа!
- Я: Хэрэгслийг хэрэглэгчийн интерфейс дотор гараар өөрчлөх боломжтой. Үүнийг шалгаж, засах арга бидэнд хэрэгтэй болно.
...3 жилийн дараа:
- Тэргүүлэх: Тэгээд бид terraform авсан.
Түүхийн ёс суртахуун нь: та ч гэсэн Амазон дахь бүх зүйлд толгой эргэм, та AWS-аас өөр ямар нэг зүйлийг ашигласаар байгаа бөгөөд эдгээр үйлчилгээ нь тухайн төлөвийг синхрончлолд байлгахын тулд тохиргооны хэл ашигладаг төлөвтэй байна.
CloudFormation lambda ба git модулиуд terraform
lambda бол CloudFormation-ийн захиалгат логик асуудлыг шийдэх шийдэл юм. Ламбдагаар та чадна буюу . Энэ арга нь Terraform-ийн git модулиудын семантик хувилбарт байхгүй нэмэлт нарийн төвөгтэй байдлыг танилцуулж байна. Миний хувьд хамгийн тулгамдсан асуудал бол эдгээр бүх хэрэглэгчийн ламбда (мөн эдгээр нь олон арван AWS дансууд) зөвшөөрлийг удирдах явдал байв. Өөр нэг чухал асуудал бол "Тахиа эсвэл өндөг юу хамгийн түрүүнд ирсэн бэ?" гэсэн асуудал байсан: энэ нь ламбда кодтой холбоотой байв. Энэ функц нь өөрөө дэд бүтэц, код бөгөөд өөрөө хяналт, шинэчлэлт хийх шаардлагатай. Авс дахь эцсийн хадаас нь ламбда кодын өөрчлөлтийг семантикаар шинэчлэхэд бэрхшээлтэй байсан; Бид мөн шууд командгүйгээр стекийн үйлдлүүд гүйлтийн хооронд өөрчлөгдөхгүй байхыг баталгаажуулах шаардлагатай болсон.
Би нэг удаа сонгодог ачаалал тэнцвэржүүлэгчээр Elastic Beanstalk орчинд зориулсан канар суулгацыг бий болгохыг хүсч байснаа санаж байна. Хийх хамгийн хялбар зүйл бол үйлдвэрлэлийн орчны хажууд ГЗ-ийн хоёр дахь байршуулалтыг хийх бөгөөд үүнийг нэг алхам урагшлуулна: автомат масштабтай канар байршуулах бүлгийг үйлдвэрлэлийн орчинд байршуулах LB-тэй хослуулах. Тэгээд Terraform ашигладаг болохоор , энэ нь Terraform дээр 4 нэмэлт мөр код шаардах болно. CloudFormation-д харьцуулж болохуйц шийдэл байгаа эсэхийг асуухад тэд намайг Terraform кодын 4 мөр муутай ямар нэг зүйлийн төлөө байршуулах хоолой болон бүх зүйл бүхий git репозиторыг зааж өгсөн.
Энэ нь шилжилт хөдөлгөөнийг илүү сайн илрүүлдэг
Бодит байдал нь хүлээлттэй нийцэж байгаа эсэхийг шалгаарай.
Энэ нь бодит байдал нь хүлээлттэй нийцэж байгаа эсэхийг баталгаажуулахад тусалдаг тул кодын функцийн хувьд маш хүчирхэг үйлдэл юм. Энэ нь CloudFormation болон Terraform хоёуланд нь боломжтой. Гэвч үйлдвэрлэлийн стек өсөхийн хэрээр CloudFormation-д дрейф хайх нь улам олон хуурамч илрүүлэлтийг бий болгосон.
Terraform-ийн тусламжтайгаар та шилжилт хөдөлгөөнийг илрүүлэх илүү дэвшилтэт дэгээтэй болно. Жишээлбэл, та тушаалыг оруулна уу Хэрэв та өөрийн бүхэл бүтэн ECS байршуулалтад гарсан өөрчлөлтийг үл тоомсорлохгүйгээр тодорхой даалгаврын тодорхойлолтод гарсан өөрчлөлтийг үл тоомсорлохыг хүсвэл шууд ECS даалгаврын тодорхойлолтод оруулна уу.
CDK ба CloudFormation-ийн ирээдүй
CloudFormation-ийг дэд бүтцийн өргөн хүрээнд удирдахад хэцүү байдаг. Эдгээр бэрхшээлүүдийн ихэнх нь хүлээн зөвшөөрөгдсөн бөгөөд хэрэгсэлд ийм зүйл хэрэгтэй , кодын үүлэн дэд бүтцийг тодорхойлж, AWS CloudFormation-ээр дамжуулан ажиллуулах хүрээ. aws-cdk-ийн ирээдүй юу болохыг харах нь сонирхолтой байх болно, гэхдээ Terraform-ийн бусад давуу талуудтай өрсөлдөхөд хэцүү байх болно; CloudFormation-ийг шинэчлэхийн тулд дэлхийн хэмжээнд өөрчлөлт оруулах шаардлагатай болно.
Ингэснээр Terraform урмыг хугалахгүй
Энэ бол "текст хэлбэрээр" биш "код хэлбэрээр дэд бүтэц" юм.
Terraform-ийн талаархи анхны сэтгэгдэл надад маш муу байсан. Би зүгээр л арга барилаа ойлгоогүй гэж бодож байна. Бараг бүх инженерүүд үүнийг хүссэн дэд бүтцэд хувиргах шаардлагатай текст формат гэж өөрийн эрхгүй ойлгодог. ИНГЭЖ БОЛОХГҮЙ.
Сайн програм хангамж хөгжүүлэх үнэн зөв ойлголтууд Terraform-д бас хамаатай.
Би Terraform дээр сайн кодыг бий болгохын тулд хэрэгжүүлсэн олон туршлагыг үл тоомсорлож байгааг харсан. Та сайн програмист болохын тулд олон жил суралцсан. Та Terraform-тэй ажиллаж байгаа учраас энэ туршлагаас бүү татгалз. Сайн програм хангамж хөгжүүлэх үнэн зөв ойлголт нь Terraform-д хамаатай.
Кодыг хэрхэн баримтжуулж болохгүй вэ?
Би ямар ч баримт бичиггүй асар том Terraform стекүүдийг харсан. Та ямар ч баримт бичиггүйгээр хэрхэн хуудсанд код бичих вэ? Таныг тайлбарласан баримт бичгийг нэмнэ үү код Terraform ("код" гэсэн үгийг онцолсон), энэ хэсэг яагаад ийм чухал вэ, мөн та юу хийдэг вэ.
Нэгэн цагт нэг том үндсэн() функц байсан үйлчилгээг бид хэрхэн ашиглах вэ?
Би маш нарийн төвөгтэй Terraform стекүүдийг нэг модуль хэлбэрээр харуулсан. Бид яагаад ийм байдлаар програм хангамжийг байрлуулж болохгүй гэж? Бид яагаад том функцүүдийг жижиг хэсгүүдэд хуваадаг вэ? Үүнтэй ижил хариултууд Terraform-д хамаарна. Хэрэв таны модуль хэтэрхий том бол та үүнийг жижиг модулиудад хуваах хэрэгтэй.
Танай компани номын сан ашигладаггүй юу?
Инженерүүд Terraform ашиглан шинэ төсөл боловсруулж, бусад төслийн асар том хэсгүүдийг өөрсдийнхөө төсөл рүү тэнэг байдлаар хуулж, дараа нь ажиллаж эхлэх хүртлээ тэдэнтэй хэрхэн харьцаж байсныг би харсан. Та компанидаа "байлдааны" кодтой ийм байдлаар ажиллах уу? Бид зөвхөн номын санг ашигладаггүй. Тиймээ гэхдээ зарчмын хувьд дундын номын сангүй бид хаана байна?!
Та PEP8 эсвэл gofmt ашигладаггүй юу?
Ихэнх хэлүүд стандарт, хүлээн зөвшөөрөгдсөн форматын схемтэй байдаг. Python дээр энэ нь PEP8 юм. In Go - gofmt. Terraform өөрийн гэсэн онцлогтой: terraform fmt. Эрүүл мэндийнхээ төлөө үүнийг сайхан өнгөрүүлээрэй!
Та JavaScript мэдэхгүй байж React ашиглах уу?
Terraform модулиуд нь таны бий болгосон нарийн төвөгтэй дэд бүтцийн зарим хэсгийг хялбарчлах боломжтой боловч энэ нь та үүнийг огт хийх боломжгүй гэсэн үг биш юм. Та нөөцийг ойлгохгүйгээр Терраформыг зөв ашиглахыг хүсч байна уу? Та үхэх болно: цаг хугацаа өнгөрөх болно, та хэзээ ч Терраформыг эзэмшихгүй.
Та singletons эсвэл dependency injection-ээр кодлож байна уу?
Dependency injection нь програм хангамж хөгжүүлэхэд хүлээн зөвшөөрөгдсөн шилдэг туршлага бөгөөд синглтоноос илүүд үздэг. Энэ нь Terraform-д хэр ашигтай вэ? Би алсын төлөвөөс хамаардаг Terraform модулиудыг харсан. Алсын төлөвийг олж авах модулиудыг бичихийн оронд параметрүүдийг авдаг модулийг бич. Дараа нь эдгээр параметрүүдийг модульд дамжуулна.
Танай номын сангууд арван зүйлийг сайн хийдэг үү, эсвэл нэг зүйлийг сайн хийдэг үү?
Хамгийн сайн ажилладаг номын сан бол маш сайн хийдэг нэг даалгавар дээр төвлөрдөг номын сан юм. Бүх зүйлийг нэг дор хийхийг оролддог том Terraform модулиудыг бичихийн оронд тэдгээрийн нэг зүйлийг сайн хийдэг хэсгүүдийг бүтээ. Дараа нь шаардлагатай бол тэдгээрийг нэгтгэнэ.
Хэрхэн хоцрогдсон нийцтэй байдалгүйгээр номын санд өөрчлөлт оруулах вэ?
Энгийн номын сан шиг нийтлэг Terraform модуль нь ямар нэгэн байдлаар өөрчлөлтүүдийг буцаахгүйгээр хэрэглэгчдэд мэдээлэх шаардлагатай. Эдгээр өөрчлөлтүүд номын санд тохиолдоход ядаргаатай байдаг ба Terraform модулиудад үл нийцэх өөрчлөлтүүд хийгдсэнтэй адил ядаргаатай байдаг. Terraform модулиудыг ашиглахдаа git tags болон semver ашиглахыг зөвлөж байна.
Танай үйлдвэрлэлийн үйлчилгээ зөөврийн компьютер дээрээ эсвэл дата төвд ажиллаж байна уу?
Hashicorp зэрэг хэрэгслүүдтэй өөрийн terraform ажиллуулах. Эдгээр төвлөрсөн үйлчилгээ нь газарзүйн өөрчлөлтийг удирдах, аудит хийх, батлахад хялбар болгодог.
Та тест бичдэггүй юм уу?
Инженерүүд кодыг турших шаардлагатайг хүлээн зөвшөөрдөг ч Terraform-тэй ажиллахдаа туршилт хийхээ мартдаг. Дэд бүтцийн хувьд энэ нь урвасан мөчүүдээр дүүрэн байдаг. Миний зөвлөгөө бол CI/CD-ийн үед тест хийхэд зөв байрлуулж болох модулиудыг ашиглан стекүүдийг "турших" эсвэл "жишээг бий болгох" явдал юм.
Терраформ ба микро үйлчилгээ
Микро үйлчилгээний компаниудын амьдрал, үхэл нь микро үйлчилгээний шинэ ажлын хэсгүүдийн хурд, шинэчлэл, тасалдал зэргээс шалтгаална.
Микро үйлчилгээний архитектуртай холбоотой хамгийн түгээмэл сөрөг тал бөгөөд үүнийг арилгах боломжгүй нь код биш харин ажилтай холбоотой байдаг. Хэрэв та Terraform-ийг зөвхөн микро үйлчилгээний архитектурын дэд бүтцийн талыг автоматжуулах арга гэж бодож байвал системийн жинхэнэ ашиг тусыг алдаж байна гэсэн үг. Одоо аль хэдийн болсон .
Эх сурвалж: www.habr.com