Terraform хөгжүүлэгчид AWS дэд бүтэцтэй ажиллахад тохиромжтой шилдэг туршлагуудыг санал болгодог бололтой. Зөвхөн нэг нюанс байна. Цаг хугацаа өнгөрөх тусам орчны тоо нэмэгдэж, тус бүр өөрийн гэсэн онцлогтой. Програмын стекийн бараг хуулбар хөрш зэргэлдээ бүс нутагт гарч ирдэг. Мөн Terraform кодыг шинэ шаардлагын дагуу сайтар хуулж, засах эсвэл цасан ширхгийг хийх шаардлагатай.
Том болон урт төслүүд дээр эмх замбараагүй байдал, гар ажиллагаатай тэмцэхийн тулд Терраформ дахь хэв маягийн тухай миний тайлан.
Видео:
Би 40 настай, би IT салбарт 20 жил ажиллаж байна. Би Ixtens компанид 12 жил ажиллаж байна. Бид цахим худалдаанд суурилсан хөгжлийн чиглэлээр ажилладаг. Мөн би DevOps дадлага хийж 5 жил болж байна.
Миний түүх нууцыг задруулахгүй байх гэрээний ард нуугдаж, нэрийг нь хэлэхгүй компанид төсөл хэрэгжүүлж байсан туршлагаа ярих болно.
Төслийн цар хүрээг ойлгохын тулд слайд дээрх тоонуудыг зааж өгсөн болно. Дараа нь миний хэлэх бүх зүйл Амазонтой холбоотой.
Би 4 жилийн өмнө энэ төсөлд хамрагдсан. Төсөл томорсон учраас дэд бүтцийн шинэчлэл эрчимтэй явагдаж байсан. Мөн ашигласан хэв маяг нь тохирохгүй болсон. Төслийн төлөвлөсөн бүх өсөлтийг харгалзан шинэ зүйл гаргах шаардлагатай байв.
Өчигдөр Додо пиццанд болсон явдлыг бидэнд хэлсэн Матвейд баярлалаа. Энэ бол 4 жилийн өмнө энд болсон явдал юм.
Хөгжүүлэгчид ирээд дэд бүтцийн код хийж эхэлсэн.
Үүнийг шаардсан хамгийн тодорхой шалтгаан бол зах зээлд гаргах цаг хугацаа байсан. DevOps багийг нэвтрүүлэх явцад саад тотгор учруулахгүй байхыг баталгаажуулах шаардлагатай байв. Мөн бусад зүйлсийн дунд Terraform болон Puppet-ийг хамгийн эхний түвшинд ашигласан.
Terraform бол HashiCorp-ийн нээлттэй эхийн төсөл юм. Энэ юу болохыг ч мэдэхгүй хүмүүст зориулж дараагийн хэдэн слайд.
Дэд бүтцийг код гэдэг нь бид дэд бүтцээ тайлбарлаж, зарим роботоос бидний тодорхойлсон нөөцийг хүлээн авахыг хүсч болно гэсэн үг юм.
Жишээлбэл, бидэнд виртуал машин хэрэгтэй. Бид хэд хэдэн шаардлагатай параметрүүдийг тайлбарлаж, нэмэх болно.
Үүний дараа бид консол дээр Amazon руу нэвтрэх эрхийг тохируулах болно. Мөн бид Terraform төлөвлөгөөг асуух болно. Terraform төлөвлөгөө: "За, бид таны нөөцөд зориулж эдгээр зүйлийг хийж чадна" гэж хэлэх болно. Мөн дор хаяж нэг нөөц нэмэгдэх болно. Мөн ямар ч өөрчлөлт гарахгүй.
Та бүх зүйлд сэтгэл хангалуун байгаа бол Terraform-аас өргөдөл гаргахыг хүсэх ба Terraform танд зориулж жишээ үүсгэх бөгөөд та үүлэн дээрээ виртуал машин хүлээн авах болно.
Цаашид манай төсөл хөгжиж байна. Бид тэнд зарим өөрчлөлтүүдийг нэмж байна. Бид илүү олон жишээ асууж, бид 53 оруулгыг нэмнэ.
Мөн бид давтаж байна. Төлөвлөөч. Ямар өөрчлөлт хийхээр төлөвлөж байгааг бид харж байна. Бид өргөдөл гаргана. Ингээд л манай дэд бүтэц хөгжиж байна.
Terraform нь төрийн файлууд гэж нэрлэгддэг зүйлийг ашигладаг. Өөрөөр хэлбэл, Амазон руу орж буй бүх өөрчлөлтүүд таны тодорхойлсон нөөц бүрд Амазон дээр үүсгэгдсэн холбогдох нөөцүүд байгаа файлд хадгалагдана. Тиймээс, нөөцийн тодорхойлолт өөрчлөгдөхөд Терраформ Amazon-д яг юу өөрчлөх ёстойг мэддэг.
Эдгээр төлөвийн файлууд нь зөвхөн файлууд байсан. Бид тэднийг Гитэд хадгалсан нь туйлын тохиромжгүй байсан. Хэн нэгэн өөрчлөлт хийхээ үргэлж мартдаг байсан бөгөөд олон зөрчилдөөн үүссэн.
Одоо backend ашиглах боломжтой болсон, өөрөөр хэлбэл Terraform нь төрийн файлыг аль хувинд, ямар товчлуураар хадгалахыг зааж өгсөн болно. Мөн Terraform өөрөө энэ төлөвийн файлыг авч, бүх ид шидийг хийж, эцсийн үр дүнг буцааж өгөх болно.
Манай дэд бүтэц хөгжиж байна. Энд бидний код байна. Одоо бид зөвхөн виртуал машин бүтээхийг хүсэхгүй байгаа бөгөөд бид туршилтын орчинтой болохыг хүсч байна.
Terraform нь модуль гэх мэт зүйлийг үүсгэх, өөрөөр хэлбэл зарим хавтсанд ижил зүйлийг дүрслэх боломжийг олгодог.
Жишээлбэл, тест хийхдээ энэ модулийг дуудаж, Terraform application-г модуль дээрээ хэрэгжүүлсэнтэй ижил зүйлийг аваарай. Туршилтын хувьд энэ код байх болно.
Үйлдвэрлэлийн хувьд бид тэнд зарим өөрчлөлтийг илгээж болно, учир нь туршилт хийхэд бидэнд том инстанцууд хэрэггүй; үйлдвэрлэлд том инстанцууд зүгээр л хэрэгтэй байдаг.
Тэгээд би төсөлдөө буцаж очих болно. Энэ бол хэцүү ажил байсан, төлөвлөсөн дэд бүтэц нь маш том байсан. Энэ кодыг засвар үйлчилгээ хийдэг хүмүүст ч, өөрчлөлт хийдэг хүмүүст ч тохиромжтой байхын тулд бүх кодыг ямар нэгэн байдлаар байрлуулах шаардлагатай байв. Мөн ямар ч хөгжүүлэгч өөрийн платформын хэсэгт шаардлагатай дэд бүтцийг засах боломжтой гэж төлөвлөж байсан.
Хэрэв танд том төсөл байгаа бол бүх дэд бүтцийг хэдэн жижиг хэсэг болгон хувааж, хэсэг бүрийг тусад нь хавтсанд тайлбарлах нь утга учиртай бол энэ нь HashiCorp-аас санал болгосон лавлах мод юм.
Өргөн хүрээний нөөцийн номын сантай тул та туршилт, үйлдвэрлэлд ойролцоогоор ижил зүйлийг дуудаж болно.
Манай тохиолдолд энэ нь тийм ч тохиромжтой биш байсан, учир нь хөгжүүлэгчид эсвэл тест хийхэд зориулсан тестийн стекийг ямар нэгэн байдлаар хялбархан авах шаардлагатай байв. Гэхдээ би фолдеруудыг үзэж, шаардлагатай дарааллаар нь ашиглахыг хүсээгүй бөгөөд мэдээллийн сан нэмэгдэж, дараа нь энэ мэдээллийн санг ашигладаг жишээ өсөх вий гэж санаа зовохгүй байсан. Тиймээс бүх туршилтыг нэг хавтсаас эхлүүлсэн. Тэнд ижил модулиудыг дуудсан боловч бүх зүйлийг нэг гүйлтээр хийсэн.
Terraform нь бүх хамаарлыг хариуцдаг. Мөн энэ нь үргэлж нөөцүүдийг дарааллаар нь үүсгэдэг бөгөөд ингэснээр та IP хаягийг, жишээлбэл, шинээр үүсгэсэн жишээнээс авч, route53 бичлэгт энэ IP хаягийг авах боломжтой.
Үүнээс гадна платформ нь маш том юм. Туршилтын стекийг нэг цаг, 8 цаг ч гэсэн ажиллуулах нь нэлээд үнэтэй ажил юм.
Мөн бид энэ асуудлыг автоматжуулсан. Мөн Женкинсийн ажил бидэнд стекийг ажиллуулах боломжийг олгосон. Үүний дотор хөгжүүлэгчийн туршиж үзэхийг хүсч буй өөрчлөлтүүдтэй татах хүсэлтийг эхлүүлэх, шаардлагатай бүх сонголт, бүрэлдэхүүн хэсэг, хэмжээсийг зааж өгөх шаардлагатай байв. Хэрэв тэр гүйцэтгэлийн тест хийхийг хүсч байвал илүү олон тохиолдол авч болно. Хэрэв тэр ямар нэгэн маягт нээгдсэн эсэхийг шалгах шаардлагатай бол тэр хөдөлмөрийн хөлсний доод хэмжээгээр эхэлж болно. Мөн кластер хэрэгтэй эсэхийг зааж өгнө үү гэх мэт.
Дараа нь Женкинс Terraform хавтас дахь кодыг бага зэрэг өөрчилсөн бүрхүүлийн скриптийг түлхсэн. Би шаардлагагүй файлуудыг устгаж, шаардлагатай файлуудыг нэмсэн. Дараа нь нэг удаагийн Terraform-ийг түрхэхэд стек боссон.
Дараа нь миний орохыг хүсэхгүй байгаа бусад алхмууд байсан.
Туршилтын хувьд үйлдвэрлэлээс арай илүү сонголт шаардлагатай байсан тул бид модулиудын хуулбарыг хийх шаардлагатай болсон тул эдгээр хуулбаруудад зөвхөн туршилт хийхэд шаардлагатай функцуудыг нэмж оруулах боломжтой болсон.
Туршилтын явцад би эцэст нь үйлдвэрлэлд орох эдгээр өөрчлөлтүүдийг туршихыг хүссэн юм. Гэвч үнэн хэрэгтээ нэг зүйлийг туршиж үзсэн, арай өөр зүйл үйлдвэрлэлд ашигласан. Үйлдвэрлэлд бүх өөрчлөлтийг үйл ажиллагааны баг хэрэгжүүлсэн загварт бага зэрэг завсарлага гарсан. Заримдаа туршилтаас үйлдвэрлэл рүү шилжих ёстой байсан өөрчлөлтүүд өөр хувилбарт үлдсэн байдаг.
Нэмж дурдахад ийм асуудал гарсан тул шинэ үйлчилгээ нэмэгдсэн нь аль хэдийн байгаа үйлчилгээнээс арай өөр байв. Одоо байгаа модулийг өөрчлөхийн оронд бид түүний хуулбарыг хийж, шаардлагатай өөрчлөлтүүдийг оруулах шаардлагатай болсон.
Үндсэндээ Terraform бол жинхэнэ хэл биш юм. Энэ бол тунхаглал юм. Хэрэв бид ямар нэг зүйлийг зарлах шаардлагатай бол бид үүнийг зарладаг. Мөн энэ бүхэн ажилладаг.
Хэзээ нэгэн цагт миний татах хүсэлтүүдийн нэг нь яригдаж байхад манай нэг хамт олон цасан ширхгийг үүсгэх шаардлагагүй гэж хэлсэн. Тэр юу гэсэн үг вэ гэж би гайхлаа. Дэлхий дээр хоёр ижил цасан ширхгүүд байдаггүй, бүгд өөр өөр байдаг гэсэн шинжлэх ухааны баримт байдаг. Үүнийг сонссон даруйдаа би Terraform кодын бүрэн жинг мэдэрсэн. Учир нь хувилбараас хувилбар руу шилжих шаардлагатай үед Terraform нь гинжин хэлхээний өөрчлөлтийг таслах шаардлагатай байсан, өөрөөр хэлбэл код нь дараагийн хувилбарт тохирохгүй болсон. Мөн бид дэд бүтцийг Terraform-ийн дараагийн хувилбарт хүргэхийн тулд дэд бүтцийн файлуудын бараг тал хувийг хамарсан татах хүсэлт гаргах шаардлагатай болсон.
Ийм цасан ширхгүүд гарч ирсний дараа бидний бүх Terraform кодууд том, том овоо цас болж хувирав.
Үйл ажиллагаанаас гадуур байгаа гадны хөгжүүлэгчийн хувьд энэ нь түүнд тийм ч чухал биш, учир нь тэр татах хүсэлт гаргасан тул түүний нөөц эхэлсэн. Энэ бол түүний санаа зовох зүйл биш юм. Бүх зүйл хэвийн байгаа эсэхийг шалгадаг DevOps баг эдгээр бүх өөрчлөлтийг хийх шаардлагатай. Нэмэлт цасан ширхэг бүрээр эдгээр өөрчлөлтийн өртөг маш их өссөн.
Семинарт сууж буй оюутан самбар дээр шохойгоор хоёр төгс дугуй зурсан түүх бий. Багш нь луужингүйгээр яаж ийм жигд зурж чадсаныг гайхаж байна. Оюутан: "Маш энгийн, би армид хоёр жил мах бутлуурын машин эргүүлсэн" гэж хариулав.
Мөн би энэ төсөлд оролцсон дөрвөн жилийн хугацаанд би Терраформыг хоёр жил орчим хийж байна. Мэдээжийн хэрэг, надад Terraform кодыг хэрхэн хялбарчлах, програмчлалын хэл шиг ажиллах, энэ кодыг шинэчилж байх ёстой хөгжүүлэгчдийн ачааллыг бууруулах талаар зарим нэг заль мэх, зөвлөгөө байна.
Миний эхлүүлэхийг хүсч буй хамгийн эхний зүйл бол Symlinks юм. Terraform нь олон дахин давтагдах кодтой байдаг. Жишээлбэл, бид дэд бүтцийг бий болгох бараг бүх цэг дээр үйлчилгээ үзүүлэгч рүү залгах нь ижил байдаг. Үүнийг тусдаа хавтсанд хийх нь логик юм. Мөн хаана ч үйлчилгээ үзүүлэгч энэ файлд Symlinks хийх шаардлагатай.
Жишээлбэл, үйлдвэрлэлд та зарим гадаад Amazon данс руу нэвтрэх эрхийг авах боломжийг олгодог assum role-г ашигладаг. Нэг файлыг өөрчилснөөр нөөцийн модны үлдсэн бүх файлууд шаардлагатай эрхүүдийг авах бөгөөд Terraform нь Amazon-ийн аль сегмент рүү нэвтрэхийг мэддэг болно.
Symlinks хаана бүтэлгүйтдэг вэ? Миний хэлсэнчлэн Terraform-д төрийн файлууд байдаг. Мөн тэд маш их дажгүй. Гэхдээ гол зүйл бол Terraform нь хамгийн түрүүнд арын хэсгийг эхлүүлдэг. Мөн тэрээр эдгээр параметрүүдэд ямар ч хувьсагчийг ашиглах боломжгүй, тэдгээрийг үргэлж текстээр бичих ёстой.
Үүний үр дүнд хэн нэгэн шинэ эх сурвалж үүсгэх үед тэр кодын зарим хэсгийг бусад хавтаснаас хуулж авдаг. Мөн тэр түлхүүр эсвэл хувинтай алдаа гаргаж магадгүй юм. Жишээлбэл, тэрээр хамгаалагдсан хязгаарлагдмал орчинд хамгаалагдсан хязгаарлагдмал орчинд хийдэг зүйл хийж, дараа нь үйлдвэрлэлд хийдэг. Тиймээс үйлдвэрлэлд байгаа хувин нь хамгаалагдсан хязгаарлагдмал орчинд ашиглагдах болно. Мэдээжийн хэрэг, тэд үүнийг хурдан олох болно. Үүнийг ямар нэгэн байдлаар засах боломжтой, гэхдээ энэ нь цаг хугацаа, тодорхой хэмжээгээр нөөцийг дэмий үрж байна.
Бид дараа нь юу хийж чадах вэ? Terraform-тэй ажиллахын өмнө та үүнийг эхлүүлэх хэрэгтэй. Эхлэх үед Terraform бүх залгаасуудыг татаж авдаг. Хэзээ нэгэн цагт тэд цул бүтэцээс илүү микро үйлчилгээний архитектур руу хуваагдсан. Мөн та үргэлж Terraform init-ийг хийх хэрэгтэй бөгөөд ингэснээр бүх модулиуд, бүх залгаасуудыг татаж авдаг.
Мөн та эхлээд бүх хувьсагчдыг авч болох бүрхүүлийн скриптийг ашиглаж болно. Бүрхүүлийн скрипт нь ямар ч байдлаар хязгаарлагдахгүй. Хоёрдугаарт, замууд. Хэрэв бид хадгалах газарт байгаа замыг төрийн файлын түлхүүр болгон үргэлж ашигладаг бол үүний дагуу энд байгаа алдаа арилна.
Би өгөгдлийг хаанаас авч болох вэ? JSON файл. Terraform нь зөвхөн hcl (HashiCorp тохиргооны хэл) дээр төдийгүй JSON дээр дэд бүтцийг бичих боломжийг олгодог.
JSON нь бүрхүүлийн скриптээс уншихад хялбар байдаг. Үүний дагуу та хувинтай тохиргооны файлыг хаа нэг газар байрлуулж болно. Мөн энэ хувиныг Terraform код болон бүрхүүлийн скриптэд хоёуланг нь ашиглан эхлүүлнэ үү.
Терраформд зориулж хувинтай байх нь яагаад чухал вэ? Учир нь алсын төлөвийн файлууд гэж байдаг. Өөрөөр хэлбэл, би Амазон руу "Жишгээ өсгөнө үү" гэж хэлэхийн тулд зарим нөөцийг цуглуулахдаа олон шаардлагатай параметрүүдийг зааж өгөх хэрэгтэй болно.
Мөн эдгээр таниулбарууд өөр хавтсанд хадгалагддаг. Тэгээд би очоод: "Terraform, яг тэр нөөцийн улсын файл руу гүйж, надад эдгээр таниулбаруудыг аваарай" гэж хэлж чадна. Тиймээс янз бүрийн бүс нутаг эсвэл хүрээлэн буй орчны хооронд тодорхой нэгдэл гарч ирдэг.
Алсын төлөвийн файлыг ашиглах нь үргэлж боломжгүй байдаг. Жишээлбэл, та өөрийн гараар VPC үүсгэсэн. Мөн VPC-г үүсгэдэг Terraform код нь маш олон янзын VPC-г үүсгэдэг бөгөөд энэ нь маш их цаг хугацаа шаардагдах бөгөөд та нэгийг нөгөөд тохируулах шаардлагатай тул та дараах заль мэхийг ашиглаж болно.
Өөрөөр хэлбэл, модулийг VPC болгож, танигчийг өгөх мэт санагдах боловч үнэндээ яг ижил жишээ үүсгэхэд ашиглаж болох хатуу кодлогдсон утгууд бүхий файл байдаг.
Төрийн файлыг үүлэн дээр хадгалах нь үргэлж шаардлагагүй байдаг. Жишээлбэл, модулиудыг туршихдаа та арын төгсгөлийн тохиргоог ашиглаж болох бөгөөд энэ нь туршилтын үед файлыг зүгээр л дискэнд хадгалах болно.
Одоо туршилтын талаар бага зэрэг. Та Terraform дээр юу туршиж болох вэ? Магадгүй маш их зүйл боломжтой, гэхдээ би энэ 4 зүйлийн талаар ярих болно.
HashiCorp нь Terraform кодыг хэрхэн форматлах талаар ойлголттой байдаг. Мөн Terraform fmt нь энэ итгэл үнэмшлийн дагуу засварласан кодыг форматлах боломжийг олгодог. Үүний дагуу тест нь формат нь HashiCorp-ийн гэрээсэлсэнтэй тохирч байгаа эсэхийг шалгах ёстой бөгөөд ингэснээр хаалтны байршлыг өөрчлөх шаардлагагүй болно.
Дараагийнх нь Terraform validate. Энэ нь бүх хаалт хосолсон эсэхээс үл хамааран синтаксийг шалгахаас өөр зүйл хийдэггүй. Энд юу чухал вэ? Манай дэд бүтэц маш өргөн цар хүрээтэй. Үүнд маш олон янзын аавууд байдаг. Мөн тус бүрт та Terraform validate-г ажиллуулах хэрэгтэй.
Үүний дагуу туршилтыг хурдасгахын тулд бид олон процессыг зэрэгцээ ашиглан зэрэгцээ ажиллуулдаг.
Зэрэгцээ гэдэг их дажгүй зүйл, үүнийг ашигла.
Гэхдээ Terraform-ийг эхлүүлэх болгондоо HashiCorp руу очиж “Хамгийн сүүлийн үеийн залгаасуудын хувилбарууд юу вэ? Мөн миний кэшэд байгаа залгаас нь зөв үү эсвэл буруу юу?" Мөн энэ нь алхам тутамд удааширч байв.
Хэрэв та Terraform-д залгаасууд хаана байгааг хэлвэл Terraform: "За, энэ нь магадгүй тэнд байгаа хамгийн сүүлийн үеийн зүйл байх. Би хаашаа ч явахгүй, би тэр даруй таны Terraform кодыг шалгаж эхэлнэ."
Фолдерыг шаардлагатай залгаасуудаар дүүргэхийн тулд бид маш энгийн Terraform кодтой бөгөөд үүнийг эхлүүлэхэд л хангалттай. Энд мэдээжийн хэрэг, таны кодонд ямар нэгэн байдлаар оролцдог бүх үйлчилгээ үзүүлэгчийг зааж өгөх хэрэгтэй, эс тэгвээс Terraform: "Би тодорхой үйлчилгээ үзүүлэгчийг мэдэхгүй, учир нь энэ нь кэшэд байхгүй" гэж хэлэх болно.
Дараагийнх нь Terraform төлөвлөгөө юм. Миний хэлсэнчлэн хөгжил бол мөчлөгтэй. Бид кодонд өөрчлөлт оруулдаг. Дараа нь дэд бүтцэд ямар өөрчлөлт хийхээр төлөвлөж байгааг олж мэдэх хэрэгтэй.
Дэд бүтэц нь маш том бол та нэг модулийг өөрчилж, туршилтын орчин эсвэл тодорхой бүс нутгийг засч, хөрш зэргэлдээх хэсгийг нь эвдэж болно. Тиймээс Терраформын төлөвлөгөөг бүхэлд нь дэд бүтцэд зориулж хийж, ямар өөрчлөлт хийхээр төлөвлөж байгааг харуулах ёстой.
Та үүнийг ухаалаг хийж чадна. Жишээлбэл, бид хамаарлыг шийддэг Python скрипт бичсэн. Юу өөрчлөгдсөнөөс хамааран: Terraform модуль эсвэл зүгээр л тодорхой бүрэлдэхүүн хэсэг, энэ нь бүх хамааралтай хавтаснуудын төлөвлөгөөг гаргадаг.
Терраформын төлөвлөгөөг хүсэлтийн дагуу хийх ёстой. Наад зах нь бид үүнийг хийдэг.
Мэдээжийн хэрэг, өөрчлөлт, амлалт болгонд туршилт хийх нь сайн хэрэг, гэхдээ төлөвлөгөө бол нэлээд үнэтэй зүйл юм. Мөн татах хүсэлтэд бид "Надад төлөвлөгөөгөө өгөөч" гэж хэлдэг. Робот эхэлнэ. Мөн таны өөрчлөлтөөс хүлээгдэж буй бүх төлөвлөгөөг комментоор илгээх эсвэл хавсаргана.
Төлөвлөгөө бол нэлээд үнэтэй зүйл юм. Терраформ Амазон руу очоод “Энэ тохиолдол байсаар байна уу? Энэ автомат масштаб яг ижил параметртэй юу?" Үүнийг хурдасгахын тулд та refresh=false гэх мэт параметрийг ашиглаж болно. Энэ нь Terraform S3-аас төлөвийг татаж авна гэсэн үг юм. Мөн энэ муж нь Амазонд байгаа зүйлтэй яг таарна гэдэгт итгэх болно.
Ийм Terraform төлөвлөгөө нь илүү хурдан явагддаг, гэхдээ муж нь таны дэд бүтцэд тохирсон байх ёстой, өөрөөр хэлбэл хаа нэгтээ, хэзээ нэгэн цагт Terraform-ийн шинэчлэлт эхлэх ёстой. Terraform refresh яг үүнийг хийдэг: төлөв нь бодит дэд бүтцэд байгаа зүйлтэй таарч байна.
Мөн аюулгүй байдлын талаар ярих хэрэгтэй. Эндээс л бид эхлэх ёстой байсан. Та Terraform болон Terraform нь дэд бүтцээрээ ажиллаж байгаа газарт эмзэг байдал бий. Өөрөөр хэлбэл, та үндсэндээ кодыг гүйцэтгэж байна. Хэрэв татах хүсэлт нь ямар нэгэн хортой код агуулсан бол хэт их хандалттай дэд бүтэц дээр ажиллах боломжтой. Тиймээс Terraform төлөвлөгөөг хаана ажиллуулахаа болгоомжтой байгаарай.
Миний ярихыг хүсч буй дараагийн зүйл бол хэрэглэгчийн мэдээллийн тест юм.
Хэрэглэгчийн өгөгдөл гэж юу вэ? Амазон дээр бид жишээ үүсгэх үед жишээний хамт тодорхой захидал илгээж болно - meta data. Жишээ эхлэх үед ихэвчлэн cloud init нь эдгээр тохиолдлуудад үргэлж байдаг. Cloud init энэ захидлыг уншаад: "За, өнөөдөр би ачаалал тэнцвэржүүлэгч байна." Мөн эдгээр гэрээний дагуу тэрээр зарим үйлдлийг гүйцэтгэдэг.
Гэвч харамсалтай нь бид Terraform төлөвлөгөө болон Terraform-ийг хэрэгжүүлэхэд хэрэглэгчийн өгөгдөл нь ийм бөөн тоо мэт харагдана. Өөрөөр хэлбэл, тэр зүгээр л танд хэш илгээдэг. Төлөвлөгөөнөөс таны харж болох зүйл бол ямар нэгэн өөрчлөлт гарах эсэх эсвэл хэш нь хэвээр үлдэх эсэх юм.
Хэрэв та үүнийг анхаарч үзэхгүй бол зарим эвдэрсэн текст файл Amazon дээр, жинхэнэ дэд бүтцэд орж магадгүй юм.
Эсвэл гүйцэтгэх үед та бүхэл бүтэн дэд бүтцийг биш, харин зөвхөн загварыг зааж өгч болно. Код дээр "Энэ загварыг миний дэлгэцэн дээр харуулна уу" гэж хэлээрэй. Үүний үр дүнд та өөрийн өгөгдөл Amazon дээр хэрхэн харагдахыг хэвлэх боломжтой.
Өөр нэг сонголт бол хэрэглэгчийн өгөгдлийг үүсгэхийн тулд модулийг ашиглах явдал юм. Та энэ модулийг ашиглах болно. Та диск дээрх файлыг хүлээн авна. Үүнийг лавлагаатай харьцуул. Тиймээс, хэрэв хэн нэгэн залуу хэрэглэгчийн өгөгдлийг бага зэрэг засахаар шийдсэн бол таны тест "За, энд тэнд зарим өөрчлөлтүүд байна - энэ бол хэвийн зүйл" гэж хэлэх болно.
Миний ярихыг хүсч буй дараагийн зүйл бол Automate Terraform application.
Мэдээжийн хэрэг, Terraform-ийг автомат горимд ашиглах нь үнэхээр аймшигтай, учир нь тэнд ямар өөрчлөлтүүд гарч ирснийг, тэдгээр нь амьд дэд бүтцэд ямар их хор хөнөөл учруулж болохыг хэн мэдэх билээ.
Туршилтын орчны хувьд энэ бүхэн хэвийн үзэгдэл юм. Өөрөөр хэлбэл, туршилтын орчинг бүрдүүлдэг ажил бол бүх хөгжүүлэгчдэд хэрэгтэй зүйл юм. "Бүх зүйл миний төлөө ажилласан" гэх мэт илэрхийлэл нь инээдтэй меме биш, харин тухайн хүн андуурч, стек босгож, энэ стек дээр зарим туршилт хийж байсныг нотолж байна. Тэгээд тэр тэнд бүх зүйл сайн байгаа эсэхийг шалгаад "За, миний гаргаж байгаа кодыг шалгасан" гэж хэлэв.
Үйлдвэрлэл, хамгаалагдсан хязгаарлагдмал орчин болон бизнесийн хувьд илүү чухал орчинд та зарим нөөцийг хэсэгчлэн аюулгүйгээр ашиглаж болно, учир нь энэ нь хэн нэгний үхэлд хүргэхгүй. Үүнд: автомат масштабын бүлгүүд, хамгаалалтын бүлгүүд, үүрэг, route53, жагсаалт нь нэлээд том байж болно. Гэхдээ юу болж байгааг анхааралтай ажиглаж, автоматжуулсан програмын тайланг уншина уу.
Хэрэглэх нь аюултай эсвэл аймшигтай тохиолдолд, жишээлбэл, хэрэв эдгээр нь мэдээллийн баазын зарим байнгын нөөц юм бол дэд бүтцийн зарим хэсэгт хэрэгжээгүй өөрчлөлтүүд байгаа гэсэн тайланг хүлээн авна уу. Инженер хяналтан дор өргөдөл гаргах ажлыг эхлүүлдэг эсвэл консолоосоо хийдэг.
Амазон-д хамгаалалтыг дуусгах гэх мэт зүйл байдаг. Мөн энэ нь зарим тохиолдолд танд шаардлагагүй өөрчлөлтөөс хамгаалж чадна. Өөрөөр хэлбэл, Терраформ Амазон руу очоод: "Би энэ жишээг устгах хэрэгтэй, өөр нэгийг хийх хэрэгтэй." Амазон хэлэхдээ: "Уучлаарай, өнөөдөр биш. Бид төгсгөлийн хамгаалалттай."
Мөн бялуу дээрх мөстөлт нь кодыг оновчтой болгох явдал юм. Бид Terraform кодтой ажиллахдаа модульд маш олон тооны параметрүүдийг дамжуулах ёстой. Эдгээр нь зарим төрлийн нөөцийг бий болгоход шаардлагатай параметрүүд юм. Мөн код нь модулиас модулиар, модулиас модулиар дамжих шаардлагатай параметрүүдийн том жагсаалт болж хувирдаг, ялангуяа модулиудыг үүрлэсэн тохиолдолд.
Мөн уншихад маш хэцүү байдаг. Үүнийг хянан үзэх нь маш хэцүү байдаг. Ихэнхдээ зарим параметрүүдийг хянаж үздэг бөгөөд тэдгээр нь яг хэрэгтэй зүйл биш юм. Үүнийг дараа нь засахад цаг хугацаа, мөнгө зарцуулдаг.
Тиймээс би ийм зүйлийг тодорхой утгын модыг агуулсан цогц параметр болгон ашиглахыг санал болгож байна. Өөрөөр хэлбэл, танд ямар нэгэн орчинд байхыг хүсч буй бүх үнэт зүйлсийг агуулсан хавтас хэрэгтэй болно.
Мөн энэ модулийг дуудсанаар та нэг нийтлэг модульд, өөрөөр хэлбэл бүхэл бүтэн дэд бүтцэд адилхан ажилладаг нийтлэг модульд үүсгэгдсэн модыг авч болно.
Энэ модульд та орон нутгийнхан шиг Terraform-ийн сүүлийн үеийн функцийг ашиглан зарим тооцоолол хийх боломжтой. Дараа нь нэг гаралтаар массив хэш гэх мэт нарийн төвөгтэй параметрүүдийг өгнө.
Энд миний хамгийн сайн олдворууд дууссан. Би Колумбын тухай түүхийг ярихыг хүсч байна. Тэрээр Энэтхэгийг нээх экспедицид мөнгө хайж байхдаа (тэр үед бодож байсан шиг) хэн ч түүнд итгээгүй бөгөөд тэд үүнийг боломжгүй гэж үзсэн. Дараа нь тэр: "Өндөг унахгүй эсэхийг шалгаарай." Бүх банкирууд, маш баян, магадгүй ухаалаг хүмүүс өндөгийг ямар нэгэн байдлаар байрлуулахыг оролдсон бөгөөд энэ нь унасаар байв. Дараа нь Колумб өндөгийг аваад бага зэрэг дарав. Бүрхүүл нь үрчийж, өндөг нь хөдөлгөөнгүй байв. Тэд: "Өө, энэ хэтэрхий амархан!" Колумб хариуд нь: "Тийм ээ, энэ нь хэтэрхий энгийн. Намайг Энэтхэгийг нээхэд бүгд энэ худалдааны замыг ашиглах болно."
Миний сая хэлсэн зүйл бол маш энгийн бөгөөд өчүүхэн зүйл байх. Мөн та тэдгээрийн талаар суралцаж, ашиглаж эхлэхэд бүх зүйл дарааллаар нь явагдана. Тиймээс давуу талыг ашигла. Хэрэв эдгээр нь таны хувьд хэвийн зүйл бол ядаж өндөг унахгүйн тулд яаж байрлуулахаа мэддэг.
Үүнд:
- Цасан ширхгүүдээс зайлсхийхийг хичээ. Цасан ширхгүүд бага байх тусам томоохон дэд бүтцээ өөрчлөхөд шаардагдах нөөц бага байх болно.
- Тогтмол өөрчлөлтүүд. Өөрөөр хэлбэл, кодонд зарим өөрчлөлт гарсан тохиолдолд та дэд бүтцээ эдгээр өөрчлөлтөд аль болох хурдан нийцүүлэх хэрэгтэй. Хоёр, гурван сарын дараа хэн нэгэн Elasticsearch-ийг үзэхээр ирж, Terraform төлөвлөгөө гаргаад, түүний төсөөлөөгүй өөрчлөлтүүд гарч ирэх нөхцөл байдал байж болохгүй. Мөн бүх зүйлийг цэгцлэхийн тулд маш их цаг хугацаа шаардагдана.
- Туршилт ба автоматжуулалт. Таны код тест, функцээр бүрхэгдсэн байх тусам та бүх зүйлийг зөв хийж байгаа гэдэгтээ илүү итгэлтэй болно. Мөн автомат хүргэлт нь таны итгэлийг хэд дахин нэмэгдүүлнэ.
- Туршилтын болон үйлдвэрлэлийн орчны код нь бараг ижил байх ёстой. Практикт, учир нь үйлдвэрлэл арай өөр хэвээр байгаа бөгөөд туршилтын орчноос давж гарах зарим нюансууд хэвээр байх болно. Гэсэн хэдий ч нэмэх эсвэл хасах нь үүнийг баталгаажуулж болно.
- Хэрэв танд маш олон Terraform код байгаа бөгөөд энэ кодыг шинэчлэхэд маш их цаг зарцуулдаг бол дахин засварлаж, сайн хэлбэрт оруулахад хэзээ ч оройтдоггүй.
- Өөрчлөгдөх боломжгүй дэд бүтэц. AMI хүргэлтийн хуваарийн дагуу.
- Танд олон оруулга байгаа бөгөөд тэдгээрийг тогтмол дарааллаар байлгахыг хүсч байгаа үед route53-ын бүтэц.
- API хурдны хязгаарлалттай тэмцэж байна. Энэ үед Амазон "Болоо, би өөр хүсэлтийг хүлээж авах боломжгүй, түр хүлээнэ үү" гэж хэлсэн. Мөн оффисын тал нь дэд бүтцээ эхлүүлэх хүртэл хүлээж байна.
- Толбо тохиолдлууд. Амазон бол хямдхан арга хэмжээ биш бөгөөд толбо нь танд маш их мөнгө хэмнэх боломжийг олгодог. Тэнд та энэ тухай бүхэл бүтэн тайланг хэлж болно.
- Аюулгүй байдал болон IAM үүрэг.
- Алдагдсан нөөцийг хайж олоход Амазонд үл мэдэгдэх гарал үүсэлтэй тохиолдлууд байвал тэд мөнгө иддэг. Хэдийгээр жишээ нь сард 100-150 долларын үнэтэй байсан ч энэ нь жилд 1 доллараас илүү байна. Ийм нөөцийг олох нь ашигтай бизнес юм.
- Мөн нөөцлөгдсөн тохиолдлууд.
Энэ бол миний хувьд. Terraform маш гоё, та үүнийг ашигладаг. Баярлалаа!
Асуултууд
Мэдээлэл өгсөнд баярлалаа! Таны төлөвийн файл S3-д байгаа, гэхдээ энэ төлөвийн файлыг хэд хэдэн хүн аваад өргөжүүлэхийг оролдох асуудлыг яаж шийдэх вэ?
Юуны өмнө бид яарахгүй байна. Хоёрдугаарт, бид зарим кодын хэсэг дээр ажиллаж байгаа гэж мэдээлдэг тугнууд байдаг. Өөрөөр хэлбэл, дэд бүтэц нь маш том боловч энэ нь хэн нэгэн ямар нэг зүйлийг байнга ашигладаг гэсэн үг биш юм. Идэвхтэй үе байх үед энэ нь асуудал байсан; бид төлөвийн файлуудыг Git-д хадгалсан. Энэ нь чухал байсан, эс тэгвээс хэн нэгэн улсын файл хийх байсан тул бүх зүйл үргэлжлэхийн тулд бид тэдгээрийг гараар нэгтгэх шаардлагатай болсон. Одоо бол тийм асуудал байхгүй. Ерөнхийдөө Terraform энэ асуудлыг шийдсэн. Хэрэв ямар нэг зүйл байнга өөрчлөгдөж байвал таны хэлсэн зүйлд саад болох түгжээг ашиглаж болно.
Та нээлттэй эх сурвалж эсвэл аж ахуйн нэгж ашиглаж байна уу?
Аж ахуйн нэгж байхгүй, өөрөөр хэлбэл та очиж үнэгүй татаж авах боломжтой бүх зүйл.
Намайг Станислав гэдэг. Би жижиг нэмэлт оруулахыг хүссэн. Та жишээг устгах боломжгүй болгох боломжийг олгодог Амазоны функцийн талаар ярьсан. Энэ нь бас Terraform-д байдаг; Life Second блок дээр та өөрчлөлтийг хориглох эсвэл устгахыг хориглохыг зааж өгч болно.
Цаг хугацаа хязгаарлагдмал байсан. Сайн цэг.
Би бас хоёр зүйл асуух гэсэн юм. Эхлээд та туршилтын талаар ярьсан. Та ямар нэгэн туршилтын хэрэгсэл ашигласан уу? Би Test Kitchen залгаасын талаар сонссон. Магадгүй өөр зүйл байгаа байх. Мөн би орон нутгийн үнэт зүйлсийн талаар асуумаар байна. Эдгээр нь оролтын хувьсагчдаас юугаараа ялгаатай вэ? Яагаад би ямар нэг зүйлийг зөвхөн Орон нутгийн утгуудаар дамжуулан параметрчилж болохгүй гэж? Би энэ сэдвийг олох гэж оролдсон боловч ямар нэгэн байдлаар би өөрөө үүнийг олж чадаагүй.
Бид энэ өрөөний гадна илүү дэлгэрэнгүй ярилцаж болно. Манай туршилтын хэрэгслүүд бүрэн өөрөө хийгдсэн байдаг. Тэнд шалгах зүйл алга. Ерөнхийдөө автоматжуулсан туршилтууд нь хаа нэгтээ дэд бүтцийг авч, хэвийн байгаа эсэхийг шалгаад, дэд бүтэц сайн хэвээр байгаа гэсэн тайлангаар бүгдийг устгах сонголтууд байдаг. Туршилтын стекийг өдөр бүр ажиллуулдаг тул бидэнд ийм зүйл байхгүй. Тэгээд л хангалттай. Тэгээд ямар нэг зүйл эвдэрч эхэлбэл бид өөр газар шалгахгүйгээр эвдэрч эхэлнэ.
Орон нутгийн үнэт зүйлсийн талаар яриагаа өрөөний гадна үргэлжлүүлье.
Сайн уу? Мэдээлэл өгсөнд баярлалаа! Маш мэдээлэл сайтай. Та дэд бүтцийг тодорхойлох олон төрлийн кодтой гэж хэлсэн. Та энэ кодыг үүсгэх талаар бодож үзсэн үү?
Гайхалтай асуулт, баярлалаа! Гол нь бид дэд бүтцийг код болгон ашиглахдаа кодыг хараад тухайн кодын ард ямар дэд бүтэц байгааг ойлгодог гэж үздэг. Хэрэв код үүсгэсэн бол тэнд ямар дэд бүтэц байгааг ойлгохын тулд ямар код үүсэхийг төсөөлөх хэрэгтэй. Нэг бол бид код үүсгэж, түүнийгээ биелүүлж, үндсэндээ ижил зүйл тохиолддог. Ингээд бид бичсэн замаараа явсан, авсан. Дээрээс нь генераторууд биднийг хийж эхлэхэд хэсэг хугацааны дараа гарч ирсэн. Мөн өөрчлөхөд аль хэдийн оройтсон байсан.
Та jsonnet-ийн талаар сонссон уу?
Үгүй
Хараач, энэ бол маш сайхан зүйл юм. Та үүнийг хэрэглэж, өгөгдлийн бүтцийг үүсгэж болох тодорхой тохиолдлыг би харж байна.
Сахлын машин онигоонд гардаг шиг генераторууд байвал сайн байдаг. Энэ нь эхний удаад царай нь өөр, гэхдээ дараа нь хүн бүр ижил царайтай байдаг. Генераторууд маш сайн ажилладаг. Гэвч харамсалтай нь бидний царай арай өөр. Энэ бол асуудал.
Зүгээр л хар. Баярлалаа!
Намайг Максим, би Сбербанкнаас ирсэн. Та Terraform-ийг програмчлалын хэлтэй дүйцэхүйц болгох гэж оролдож байгаа тухайгаа бага зэрэг ярилаа. Ansible ашиглах нь илүү хялбар биш гэж үү?
Эдгээр нь маш өөр зүйл юм. Та Ansible-д нөөц үүсгэж, хүүхэлдэй нь Amazon-д нөөц үүсгэж болно. Гэхдээ Terraform шууд дээшээ хурц байна.
Танд зөвхөн Амазон бий юу?
Бидэнд зөвхөн Амазон байдаг гэсэн үг биш. Манайд бараг зөвхөн Амазон бий. Гэхдээ гол онцлог нь Терраформ санаж байна. Ansible дээр та: "Надад 5 тохиолдол өгөөч" гэж хэлбэл энэ нь дээшлэх бөгөөд дараа нь та: "Одоо надад 3 тохиолдол хэрэгтэй байна" гэж хэлэх болно. Терраформ: "За, би 2 ална" гэж хэлэх ба Ансибл: "За, танд 3 байна" гэж хэлэх болно. Нийт 8.
Сайн уу? Мэдээлэл өгсөнд баярлалаа! Терраформын тухай сонсох нь маш сонирхолтой байсан. Би Terraform нь тогтвортой хувилбаргүй хэвээр байгаа талаар нэн даруй жижиг тайлбар хэлмээр байна, тиймээс Terraform-д маш болгоомжтой хандаарай.
Оройн хоолны сайн халбага. Өөрөөр хэлбэл, хэрэв танд шийдэл хэрэгтэй бол заримдаа та тогтворгүй гэх мэт зүйлийг хойшлуулдаг, гэхдээ энэ нь ажиллаж, бидэнд тусалсан.
Асуулт нь ийм байна. Та Remote backend ашигладаг, S 3 ашигладаг. Яагаад албан ёсны backend ашигладаггүй юм бэ?
Албан тушаалтан уу?
Терраформ үүл.
Тэр хэзээ гарч ирсэн бэ?
4 сарын өмнө.
Хэрэв энэ нь 4 жилийн өмнө гарч ирсэн бол би таны асуултанд хариулах байсан байх.
Аль хэдийн суулгасан функц, түгжээ байгаа бөгөөд та төрийн файлыг хадгалах боломжтой. Үүнийг нэг туршаад. Гэхдээ би үүнийг бас туршиж үзээгүй.
Бид өндөр хурдтай явж байгаа том галт тэргээр явж байна. Та хэдхэн машин аваад хаячихаж болохгүй.
Цасан ширхгийн тухай ярилаа, яагаад салбараа ашиглаагүй юм бэ? Яагаад ийм байдлаар болоогүй юм бэ?
Бидний арга барил бол бүхэл бүтэн дэд бүтэц нэг агуулахад байдаг. Terraform, Puppet, үүнтэй ямар нэгэн байдлаар холбоотой бүх скриптүүд бүгд нэг агуулахад байдаг. Ингэснээр бид нэмэлт өөрчлөлтүүдийг ар араасаа туршиж байгаа эсэхийг баталгаажуулж чадна. Хэрэв энэ нь олон салбар байсан бол ийм төслийг хадгалах нь бараг боломжгүй юм. Зургаан сар өнгөрч, тэд маш их зөрж, энэ нь зүгээр л нэг төрлийн шийтгэл юм. Рефактор хийхээс өмнө би үүнээс зугтахыг хүссэн юм.
Тэгэхээр энэ нь ажиллахгүй байна уу?
Энэ огт ажиллахгүй байна.
Салбараас би хавтас слайдыг хайчилж авлаа. Өөрөөр хэлбэл, хэрэв та туршилтын стек бүрт үүнийг хийвэл, жишээлбэл, А баг өөрийн гэсэн хавтастай, В баг өөрийн гэсэн хавтастай бол энэ нь бас ажиллахгүй. Бид хүн бүрт тохирсон уян хатан туршилтын орчны нэгдсэн кодыг бүтээсэн. Өөрөөр хэлбэл, бид нэг кодоор үйлчилсэн.
Сайн уу? Намайг Юра гэдэг! Мэдээлэл өгсөнд баярлалаа! Модулиудын талаархи асуулт. Та модулиудыг ашиглаж байна гэж хэлж байна. Нэг модульд өөр хүний өөрчлөлттэй нийцэхгүй өөрчлөлт хийсэн бол та асуудлыг хэрхэн шийдвэрлэх вэ? Та ямар нэгэн байдлаар модулиудыг хувилбар болгож байна уу эсвэл хоёр шаардлагыг хангахын тулд wunderwaffle авчрахыг оролдож байна уу?
Энэ бол цасны том асуудал юм. Ямар нэгэн гэм зэмгүй өөрчлөлт нь дэд бүтцийн зарим хэсгийг эвдэж болзошгүй үед бид ийм зовлонг амсдаг. Мөн энэ нь удаан хугацааны дараа л мэдэгдэхүйц байх болно.
Энэ нь шийдэгдээгүй байгаа гэсэн үг үү?
Та бүх нийтийн модулиуд хийдэг. Цасан ширхгээс зайлсхий. Тэгээд бүх зүйл бүтнэ. Мэдээллийн хоёрдугаар хагаст үүнээс хэрхэн сэргийлэх тухай өгүүлнэ.
Сайн уу? Мэдээлэл өгсөнд баярлалаа! Би тодруулмаар байна. Хөшигний ард миний ирсэн том овоо байсан. Хүүхэлдэй болон дүрийн хуваарилалтыг хэрхэн нэгтгэсэн бэ?
Хэрэглэгчийн өгөгдөл.
Энэ нь та зүгээр л файлыг нулимж, ямар нэгэн байдлаар гүйцэтгэх үү?
Хэрэглэгчийн өгөгдөл нь тэмдэглэл юм, өөрөөр хэлбэл бид зургийг клон болгоход Демон тэнд босч, өөрийгөө хэн болохыг олж мэдэхийг хичээж, ачааллын тэнцвэржүүлэгч гэсэн тэмдэглэлийг уншдаг.
Өөрөөр хэлбэл, энэ нь ямар нэгэн байдлаар өгөгдсөн тусдаа үйл явц мөн үү?
Бид үүнийг зохион бүтээгээгүй. Бид үүнийг ашигладаг.
Сайн уу? Надад Хэрэглэгчийн мэдээллийн талаар асуулт байна. Тэнд асуудал байгаа, хэн нэгэн буруу газар руу юм явуулж магадгүй гэж та хэлсэн. Хэрэглэгчийн өгөгдөл гэж юу болохыг үргэлж тодорхой байлгахын тулд хэрэглэгчийн өгөгдлийг ижил Git-д хадгалах ямар нэг арга бий юу?
Бид загвараас хэрэглэгчийн өгөгдлийг үүсгэдэг. Өөрөөр хэлбэл тэнд тодорхой тооны хувьсагчийг ашигладаг. Мөн Terraform нь эцсийн үр дүнг гаргадаг. Тиймээс, та зүгээр л загвар руу хараад юу болохыг хэлж болохгүй, учир нь бүх асуудал нь хөгжүүлэгч энэ хувьсагч дахь мөрийг дамжуулж байна гэж бодож байгаатай холбоотой боловч массив тэнд ашиглагддаг. Тэгээд тэр - бам бид хоёр - ийм, тийм, дараагийн мөр, тэгээд бүх зүйл тасарлаа. Хэрэв энэ нь шинэ нөөц бөгөөд хүн үүнийг аваад ямар нэг зүйл ажиллахгүй байгааг харвал энэ нь хурдан шийдэгддэг. Хэрэв энэ автомат масштабын бүлэг шинэчлэгдсэн бол хэзээ нэгэн цагт автомат масштабын бүлгийн тохиолдлууд солигдож эхэлнэ. Тэгээд bang, ямар нэг зүйл ажиллахгүй байна. Өвдөж байна.
Ганц шийдэл нь сорилт болж таарч байна?
Тийм ээ, та асуудлыг харж байна, та тэнд туршилтын алхмуудыг нэмнэ үү. Өөрөөр хэлбэл, гаралтыг бас шалгаж болно. Энэ нь тийм ч тохиромжтой биш байж магадгүй, гэхдээ та бас зарим тэмдэглэгээ хийж болно - Хэрэглэгчийн өгөгдлийг энд хавсаргасан эсэхийг шалгаарай.
Намайг Тимур гэдэг. Терраформыг хэрхэн зөв зохион байгуулах тухай тайлангууд байгаа нь үнэхээр гайхалтай.
Би ч эхлээгүй байна.
Дараагийн чуулганд магадгүй гэж бодож байна. Надад энгийн асуулт байна. Та яагаад утгыг tfvar ашиглахын оронд тусдаа модуль дээр хатуу кодлож байгаа юм бэ, өөрөөр хэлбэл утгууд нь яагаад tfvar-аас илүү байдаг вэ?
Өөрөөр хэлбэл, би энд бичих ёстой (слайд: Production/environment/settings.tf): domain = variable, domain vpcnetwork, variable vpcnetwork болон stvars – би ижил зүйлийг авч болох уу?
Энэ бол бидний хийдэг зүйл юм. Жишээлбэл, бид тохиргооны эх үүсвэрийн модулийг хэлнэ.
Үндсэндээ энэ бол ийм tfvars юм. Tfvars нь туршилтын орчинд маш тохиромжтой. Надад том жишээнүүдийн хувьд tfvars байна, жижиг тохиолдолд. Тэгээд би нэг файлыг хавтас руу шидэв. Тэгээд би хүссэн зүйлээ авсан. Дэд бүтцээ хумихдаа бид бүх зүйлийг шууд харж, ойлгох боломжтой байгаасай гэж хүсдэг. Тиймээс та эндээс харж, дараа нь tfvars-ыг харах хэрэгтэй болж байна.
Бүх зүйл нэг дор байх боломжтой юу?
Тийм ээ, tfvars нь танд нэг кодтой байх үед юм. Мөн энэ нь өөр өөр нюанс бүхий хэд хэдэн өөр газар хэрэглэгддэг. Тэгээд tfvar шидээд нюансаа авна. Мөн бид хамгийн цэвэр хэлбэрээрээ код шиг дэд бүтэц юм. Би хараад ойлгосон.
Сайн уу? Клоуд үйлчилгээ үзүүлэгч таны Terraform хийсэн зүйлд саад болох нөхцөл байдалтай тулгарсан уу? Бид мета өгөгдлийг засаж байна гэж бодъё. ssh товчлуурууд байдаг. Мөн Google өөрийн мета өгөгдөл болон түлхүүрээ тэнд байнга байрлуулдаг. Мөн Terraform үргэлж өөрчлөлттэй гэж бичдэг. Гүйлт болгоны дараа юу ч өөрчлөгдөөгүй байсан ч тэр энэ талбарыг одоо шинэчилнэ гэж үргэлж хэлдэг.
Түлхүүртэй, гэхдээ тийм ээ, дэд бүтцийн нэг хэсэг нь энэ зүйлд нөлөөлдөг, өөрөөр хэлбэл Terraform юу ч өөрчилж чадахгүй. Бид ч гэсэн гараараа юуг ч өөрчилж чадахгүй. Бид одоохондоо түүнтэй хамт амьдарна.
Өөрөөр хэлбэл, та ийм зүйлтэй тулгарсан, гэхдээ юу ч олж чадаагүй байна, тэр яаж үүнийг хийж, өөрөө хийдэг вэ?
Харамсалтай нь тийм.
Сайн уу? Намайг Старков Станислав гэдэг. Мэйл. ru групп. ... дээр шошго үүсгэх асуудлыг яаж шийдэх вэ, дотор нь яаж дамжуулах вэ? Миний ойлгож байгаагаар Хэрэглэгчийн датагаар дамжуулан хостын нэрийг зааж өгөх, Хүүхэлдэйг асаах уу? Мөн асуултын хоёр дахь хэсэг. Та SG-д энэ асуудлыг хэрхэн шийдэх вэ, өөрөөр хэлбэл та ижил төрлийн олон зуун тохиолдлын SG үүсгэх үед тэдгээрийн зөв нэр нь юу вэ?
Бидний хувьд маш чухал тохиолдлуудыг бид сайхан нэрлэж байна. Шаардлагагүй зүйл бол энэ нь автомат масштабтай бүлэг юм. Мөн онолын хувьд та үүнийг хадаж, шинээр авах боломжтой.
Шошготой холбоотой асуудлын хувьд ийм асуудал байхгүй, гэхдээ ийм даалгавар байдаг. Дэд бүтэц нь том бөгөөд үнэтэй учраас бид шошгыг маш их ашигладаг. Мөнгө хаашаа орж байгааг харах хэрэгтэй, тиймээс хаягууд нь юу хаашаа явсныг задлах боломжийг олгодог. Үүний дагуу маш их мөнгө шаарддаг зүйлийг хайж олоход энд зарцуулагддаг.
Өөр ямар асуулт байсан бэ?
SG олон зуун жишээ үүсгэх үед тэдгээрийг ямар нэгэн байдлаар ялгах шаардлагатай юу?
Үгүй, болохгүй. Тохиолдол бүрт надад асуудал байгаа гэж мэдээлдэг агент байдаг. Хэрэв агент мэдээлдэг бол төлөөлөгч түүний тухай мэддэг бөгөөд хамгийн багадаа түүний IP хаяг байдаг. Та аль хэдийн зугтаж болно. Хоёрдугаарт, бид Кубернетес байдаггүй Консулыг Discovery-д ашигладаг. Мөн Консул нь тухайн жишээний IP хаягийг харуулдаг.
Өөрөөр хэлбэл, та хостын нэр дээр бус IP дээр анхаарлаа төвлөрүүлж байна уу?
Хост нэрээр шилжих боломжгүй, өөрөөр хэлбэл маш олон байдаг. Instance identifiers байдаг - AE гэх мэт. Та үүнийг хаа нэгтээ олж болно, та хайлт руу хаяж болно.
Сайн уу? Terraform бол үүлэнд тохирсон сайн зүйл гэдгийг би ойлгосон.
Ганц тийм биш.
Энэ бол яг миний сонирхлыг татдаг асуулт юм. Хэрэв та бүх тохиолдлынхоо хамт Bare Metal руу нүүхээр шийдсэн бол? Ямар нэгэн асуудал гарах уу? Эсвэл энд дурдсантай ижил Ansible гэх мэт бусад бүтээгдэхүүнийг ашиглах шаардлагатай хэвээр байх уу?
Ansible бол өөр зүйлийн талаар бага зэрэг юм. Өөрөөр хэлбэл, жишээ эхлэхэд Ansible аль хэдийн ажилладаг. Мөн Terraform нь жишээ эхлэхээс өмнө ажилладаг. Нүцгэн металл руу шилжих - үгүй.
Одоо биш, гэхдээ бизнес ирээд "Алив" гэж хэлэх болно.
Өөр үүлэн рүү шилжих - тийм ээ, гэхдээ энд арай өөр арга байна. Та Terraform кодыг бага хүчин чармайлтаар өөр үүл рүү шилжүүлж болохуйц байдлаар бичих хэрэгтэй.
Эхэндээ манай дэд бүтэц бүхэлдээ агностик, өөрөөр хэлбэл ямар ч үүл тохиромжтой байх ёстой гэсэн үүрэг даалгавар өгсөн боловч хэзээ нэгэн цагт бизнес бууж өгөөд: "За, дараагийн N жилд бид хаашаа ч явахгүй, бид үйлчилгээг ашиглаж болно. Амазоноос "
Terraform нь Front-End ажлуудыг үүсгэх, PagerDuty, data doc гэх мэтийг тохируулах боломжийг олгодог. Энэ нь маш олон сүүлтэй. Тэр бараг бүх дэлхийг удирдаж чадна.
Мэдээлэл өгсөнд баярлалаа! Би бас Terraform-ийг 4 жил ашиглаж байна. Терраформ, дэд бүтэц, тунхаглалын тодорхойлолт руу жигд шилжих үе шатанд бид хэн нэгэн гараар ямар нэгэн зүйл хийж, та төлөвлөгөө гаргах гэж оролдсон нөхцөл байдалтай тулгарсан. Тэгээд надад ямар нэгэн алдаа гарсан. Ийм асуудалтай хэрхэн тэмцэж байна вэ? Жагсаалтад орсон алдагдсан нөөцийг хэрхэн олох вэ?
Гол нь гар, нүдээрээ бид тайланд ямар нэгэн хачирхалтай зүйл олж харвал тэнд юу болж байгааг шинжилдэг, эсвэл зүгээр л алдаг. Ерөнхийдөө татах хүсэлт нь нийтлэг зүйл юм.
Хэрэв алдаа гарвал буцаах уу? Та үүнийг хийхийг оролдсон уу?
Үгүй ээ, энэ бол тухайн хүн ямар нэгэн асуудал олж харсан тэр мөчид гаргасан шийдвэр юм.
Эх сурвалж: www.habr.com