Олон хүмүүс Terraform-ийг өдөр тутмын ажилдаа мэддэг, ашигладаг боловч түүний шилдэг туршлагууд хараахан бүрдээгүй байна. Баг бүр өөрийн гэсэн арга барил, арга барилыг бий болгох ёстой.
Таны дэд бүтэц маш энгийнээр эхэлдэг: цөөн нөөц + цөөн тооны хөгжүүлэгчид. Цаг хугацаа өнгөрөхөд энэ нь янз бүрийн чиглэлд ургадаг. Та нөөцүүдийг Terraform модулиудад бүлэглэх, кодыг хавтас болгон зохион байгуулах арга замыг хайж байна уу, өөр юу буруу байж болох вэ? (алдартай сүүлчийн үгс)
Цаг хугацаа өнгөрч, таны дэд бүтэц таны шинэ тэжээвэр амьтан мэт санагдаж байна, гэхдээ яагаад? Та дэд бүтцэд үл ойлгогдох өөрчлөлтүүдийн талаар санаа зовж, дэд бүтэц, кодонд хүрэхээс айдаг - үүний үр дүнд та шинэ функцийг хойшлуулах эсвэл чанарыг бууруулдаг ...
Гурван жилийн турш Github дээр AWS-д зориулсан Terraform нийгэмлэгийн модулиудын цуглуулгыг удирдаж, Terraform-ийг үйлдвэрлэлд удаан хугацаагаар засварласны дараа Антон Бабенко өөрийн туршлагаасаа хуваалцахад бэлэн байна: TF модулийг ирээдүйд гэмтээхгүйн тулд хэрхэн бичих талаар.
Ярилцлагын төгсгөлд оролцогчид Terraform дахь нөөцийн удирдлагын зарчмууд, Terraform дахь модулиудтай холбоотой шилдэг туршлагууд болон дэд бүтцийн менежменттэй холбоотой зарим тасралтгүй интеграцийн зарчмуудыг илүү сайн мэддэг байх болно.
Disclaimer: Энэ тайлан нь 2018 оны 2-р сарын 0.11-2 оны 2-р сарын XNUMX-ны өдөр гэдгийг би тэмдэглэж байна. Тайлан дээр хэлэлцсэн Terraform XNUMX хувилбарыг дэмжихээ больсон. Сүүлийн XNUMX жилийн хугацаанд маш олон шинэчлэл, сайжруулалт, өөрчлөлтүүдийг агуулсан XNUMX шинэ хувилбар гарсан. Үүнд анхаарлаа хандуулж, баримт бичгийг шалгана уу.
Ашигласан материал:
- +
- — автоматаар форматлах код ба баримт бичиг
- - Terraform модулиудын генератор (WIP)
- - Визуал диаграммаас Terraform код үүсгэгч (WIP)
- www.terraform-best-practices.com
- (Шинэ нийтлэлүүд миний хувийн вэбсайт www.antonbabenko.com/ дээр байгаа)
- @antonbabenko - Твиттер, мөн олон янзын Slacks
Намайг Антон Бабенко гэдэг. Та нарын зарим нь миний бичсэн кодыг ашигласан байх. Би одоо энэ талаар урьд өмнөхөөсөө илүү итгэлтэйгээр ярих болно, учир нь надад статистик мэдээлэл бий.
Би Terraform дээр ажилладаг бөгөөд 2015 оноос хойш Terraform болон Amazon-той холбоотой олон тооны нээлттэй эхийн төслүүдэд идэвхтэй оролцож, хувь нэмрээ оруулсаар ирсэн.
Түүнээс хойш би үүнийг сонирхолтой хэлбэрээр оруулах хангалттай код бичсэн. Тэгээд би одоо энэ талаар танд хэлэхийг хичээх болно.
Би Terraform-тэй ажиллах нарийн төвөгтэй байдал, онцлогуудын талаар ярих болно. Гэхдээ энэ нь үнэхээр HighLoad-ийн сэдэв биш юм. Тэгээд одоо та яагаад гэдгийг ойлгох болно.
Цаг хугацаа өнгөрөхөд би Terraform модулиудыг бичиж эхэлсэн. Хэрэглэгчид асуулт бичсэн, би дахин бичсэн. Дараа нь би кодыг урьдчилан гүйцэтгэх дэгээ ашиглан форматлахын тулд янз бүрийн хэрэгслүүд бичсэн.
Олон сонирхолтой төслүүд байсан. Би код үүсгэх дуртай, учир нь би компьютер надад болон програмистад илүү их ажил хийх дуртай, тиймээс би одоогоор визуал диаграммаас Terraform код үүсгэгч дээр ажиллаж байна. Магадгүй та нарын зарим нь тэднийг харсан байх. Эдгээр нь сумтай сайхан хайрцагнууд юм. Хэрэв та "Экспорт" товчийг дараад бүгдийг нь код болгон авах боломжтой бол маш сайн гэж бодож байна.
Би Украинаас ирсэн. Би Норвегид олон жил амьдарсан.
Мөн миний нэрийг мэддэг, олон нийтийн сүлжээнээс олдог хүмүүсээс энэхүү тайлангийн мэдээллийг цуглуулсан. Би бараг үргэлж ижил хочтой байдаг.
Миний дурьдсанчлан, би Terraform AWS модулиудын гол засварлагч бөгөөд GitHub дээрх хамгийн том агуулахуудын нэг бөгөөд бид VPC, Autoscaling, RDS зэрэг хамгийн нийтлэг ажлуудад зориулагдсан модулиудыг байршуулдаг.
Таны одоо сонссон зүйл бол хамгийн энгийн зүйл юм. Хэрэв та Terraform гэж юу болохыг ойлгож байгаа гэдэгтээ эргэлзэж байвал өөр газар цагаа өнгөрөөсөн нь дээр. Энд маш олон техникийн нэр томъёо байх болно. Тэгээд тайлангийн түвшинг хамгийн өндөр гэж зарлахаас буцсангүй. Энэ нь би олон тайлбаргүйгээр бүх боломжит нэр томъёог ашиглан ярьж чадна гэсэн үг юм.
Terraform нь 2014 онд дэд бүтцийг код болгон бичих, төлөвлөх, удирдах боломжийг олгодог хэрэгсэл хэлбэрээр гарч ирсэн. Энд байгаа гол ойлголт бол "дэд бүтэц нь код" юм.
Миний хэлсэнчлэн бүх бичиг баримт бичигдсэн байна . Ихэнх хүмүүс энэ сайтын талаар мэдэж, баримт бичгийг уншсан гэж найдаж байна. Хэрэв тийм бол та зөв газартаа байна.
Энгийн Terraform тохиргооны файл иймэрхүү харагдах бөгөөд бид эхлээд зарим хувьсагчийг тодорхойлдог.
Энэ тохиолдолд бид "aws_region"-ыг тодорхойлно.
Дараа нь бид ямар нөөц бий болгохыг хүсч байгаагаа тайлбарлана.
Бид хамаарал болон үйлчилгээ үзүүлэгчийг ачаалахын тулд зарим тушаалуудыг, ялангуяа "terraform init"-ийг ажиллуулдаг.
Заасан тохиргоо нь бидний үүсгэсэн нөөцтэй тохирч байгаа эсэхийг шалгахын тулд бид "terraform application" командыг ажиллуулдаг. Бид өмнө нь юу ч бүтээгээгүй тул Terraform бидэнд эдгээр нөөцийг бий болгохыг уриалж байна.
Бид үүнийг баталж байна. Тиймээс бид далайн дун гэж нэрлэгддэг хувин үүсгэдэг.
Мөн ижил төстэй хэд хэдэн хэрэгслүүд байдаг. Amazon ашигладаг та нарын ихэнх нь AWS CloudFormation эсвэл Google Cloud Deployment Manager эсвэл Azure Resource Manager-ийг мэддэг. Тэдгээр нь тус бүрдээ эдгээр олон нийтийн үүлэн үйлчилгээ үзүүлэгч бүрийн нөөцийг удирдах өөрийн гэсэн хэрэглүүртэй байдаг. Terraform нь 100 гаруй үйлчилгээ үзүүлэгчийг удирдах боломжийг олгодог тул ялангуяа ашигтай байдаг. (Илүү дэлгэрэнгүй мэдээллийг )
Терраформын анхнаасаа зорьж ирсэн зорилго:
- Terraform нь нөөцийг нэг талаас харах боломжийг олгодог.
- Орчин үеийн бүх платформыг дэмжих боломжийг танд олгоно.
- Terraform нь анхнаасаа дэд бүтцийг аюулгүй, урьдчилан таамаглах боломжтой өөрчлөх боломжийг олгодог хэрэгсэл болгон зохион бүтээсэн.
2014 онд "урьдчилан таамаглах боломжтой" гэдэг үг энэ нөхцөлд маш ер бусын сонсогдов.
Terraform бол бүх нийтийн хэрэгсэл юм. Хэрэв танд API байгаа бол та бүх зүйлийг хянах боломжтой.
- Та 120 гаруй үйлчилгээ үзүүлэгчийг ашиглан хүссэн бүхнээ удирдах боломжтой.
- Жишээлбэл, та Terraform ашиглан GitHub репозитор руу хандах хандалтыг тайлбарлаж болно.
- Та Jira-д алдаа үүсгэж, хааж болно.
- Та New Relic хэмжигдэхүүнийг удирдах боломжтой.
- Хэрэв та үнэхээр хүсвэл dropbox-д файл үүсгэж болно.
Үүнийг Go-д тайлбарлаж болох нээлттэй API-тай Terraform үйлчилгээ үзүүлэгч ашиглан хийж болно.
Өмнөх слайдууд дээр үзүүлсэн шиг бид Terraform-г ашиглаж эхэлсэн, сайт дээрх зарим баримт бичгийг уншиж, зарим видео үзэж, main.tf бичиж эхэлсэн гэж бодъё.
Бүх зүйл сайхан байна, танд VPC үүсгэх файл байна.
Хэрэв та VPC үүсгэхийг хүсвэл ойролцоогоор эдгээр 12 мөрийг зааж өгнө үү. Та аль бүс нутагт үүсгэх, IP хаягийн аль cidr_block ашиглахаа тайлбарлана уу. Тэгээд л болоо.
Мэдээжийн хэрэг, төсөл аажмаар өсөх болно.
Мөн та тэнд олон шинэ зүйлийг нэмж оруулах болно: нөөцүүд, мэдээллийн эх сурвалжууд, та шинэ үйлчилгээ үзүүлэгчидтэй нэгдэх болно, гэнэт та Terraform ашиглан GitHub акаунтынхаа хэрэглэгчдийг удирдахыг хүсэх болно. Та өөр зүйл ашиглахыг хүсэж магадгүй юм. DNS үйлчилгээ үзүүлэгчид, бүх зүйлийг хөндлөн гарга. Terraform нь үүнийг хялбар болгодог.
Дараах жишээг харцгаая.
Та VPC-ийнхээ нөөцийг интернетэд нэвтрэхийг хүсч байгаа тул аажмаар internet_gateway-г нэмнэ үү. Энэ бол сайн санаа юм.
Үр дүн нь энэ main.tf:
Энэ бол main.tf-ийн дээд хэсэг юм.
Энэ бол main.tf-ийн доод хэсэг юм.
Дараа нь та дэд сүлжээ нэмнэ. Та NAT гарц, маршрут, чиглүүлэлтийн хүснэгт болон бусад олон дэд сүлжээг нэмэхийг хүсвэл 38 мөр биш, харин ойролцоогоор 200-300 мөр байх болно.
Энэ нь таны main.tf файл аажмаар нэмэгдэж байна. Ихэнхдээ хүмүүс бүгдийг нэг файлд оруулдаг. main.tf дээр 10-20 Kb гарч ирнэ. 10-20 Kb нь текстийн агуулга гэж төсөөлөөд үз дээ. Мөн бүх зүйл бүх зүйлтэй холбоотой байдаг. Энэ нь аажмаар ажиллахад хэцүү болж байна. 10-20 Kb нь сайн хэрэглэгчийн тохиолдол, заримдаа илүү байдаг. Хүмүүс үүнийг үргэлж муу гэж боддоггүй.
Энгийн програмчлалын нэгэн адил, жишээлбэл, дэд бүтцийг код болгон ашигладаггүй тул бид янз бүрийн анги, багц, модуль, бүлэглэлийг ашигладаг. Terraform нь танд ижил төстэй зүйлийг хийх боломжийг олгодог.
- Код нэмэгдэж байна.
- Нөөц хоорондын хамаарал ч нэмэгдэж байна.
Мөн бидэнд маш их хэрэгцээ байна. Бид цаашид ингэж амьдрах боломжгүй гэдгээ ойлгож байна. Манай код асар том болж байна. 10-20 Kb нь мэдээжийн хэрэг тийм ч том биш, гэхдээ бид зөвхөн сүлжээний стекийн тухай ярьж байна, өөрөөр хэлбэл та зөвхөн сүлжээний нөөцийг нэмсэн. Бид 100 Кб-ыг хялбархан нэхэх боломжтой Application Load Balancer, deployment ES кластер, Kubernetes гэх мэтийн талаар яриагүй байна. Хэрэв та энэ бүгдийг бичвэл Terraform нь Terraform модулиудыг хангадаг гэдгийг тун удахгүй мэдэх болно.
Terraform модулиуд нь бүлгээр удирддаг бие даасан Terraform тохиргоо юм. Энэ бол Terraform модулиудын талаар мэдэх ёстой зүйл юм. Тэд огт ухаалаг биш, ямар нэг зүйлээс шалтгаалж нарийн төвөгтэй холболт хийхийг зөвшөөрдөггүй. Энэ бүхэн хөгжүүлэгчдийн мөрөн дээр унадаг. Энэ бол таны аль хэдийн бичсэн Terraform тохиргооны нэг төрөл юм. Та үүнийг зүгээр л бүлэг гэж нэрлэж болно.
Тиймээс бид 10-20-30 Кб кодоо хэрхэн оновчтой болгохыг ойлгохыг хичээж байна. Бид зарим модулиудыг ашиглах хэрэгтэйг аажмаар ойлгож байна.
Таны тааралддаг модулиудын эхний төрөл бол нөөцийн модулиуд юм. Тэд танай дэд бүтэц юуны тухай, ямар бизнес эрхэлдэг, хаана, ямар нөхцөл байдалтай байгааг ойлгохгүй байна. Эдгээр нь миний нээлттэй эх сурвалжийн нийгэмлэгтэй хамтран удирддаг модулиуд бөгөөд бид танай дэд бүтцийн хамгийн анхны барилгын блок болгон дэвшүүлж байна.
Нөөцийн модулийн жишээ.
Бид нөөцийн модулийг дуудахдаа түүний агуулгыг аль замаас ачаалахыг зааж өгдөг.
Бид ямар хувилбарыг татаж авахыг хүсч байгаагаа зааж өгнө.
Бид тэнд олон маргааныг дамжуулдаг. Тэгээд л болоо. Энэ модулийг ашиглах үед бидний мэдэх ёстой зүйл бол энэ юм.
Хамгийн сүүлийн хувилбарыг ашиглавал бүх зүйл тогтвортой байна гэж олон хүн боддог. Гэхдээ үгүй. Дэд бүтэц нь хувилбартай байх ёстой бөгөөд бид энэ эсвэл өөр бүрэлдэхүүн хэсгийг аль хувилбарт байрлуулсан бэ гэдгийг тодорхой хариулах ёстой.
Энэ модулийн дотор байгаа код энд байна. Аюулгүй байдлын бүлгийн модуль. Энд гүйлгэх нь 640-р мөрөнд очно. Амазон дахь аюулгүй байдлын нөөцийг боломжит бүх тохиргоонд бий болгох нь маш энгийн ажил биш юм. Аюулгүй байдлын бүлгийг үүсгээд түүнд ямар дүрмийг дамжуулахыг хэлэх нь хангалтгүй юм. Энэ нь маш энгийн байх болно. Амазон дотор сая сая өөр хязгаарлалт байдаг. Жишээлбэл, хэрэв та ашигладаг бол VPC төгсгөлийн цэг, угтвар жагсаалт, төрөл бүрийн API мөн энэ бүгдийг бусад бүх зүйлтэй хослуулахыг оролддог бол Terraform танд үүнийг хийхийг зөвшөөрдөггүй. Мөн Amazon API ч үүнийг зөвшөөрдөггүй. Тиймээс бид энэ бүх аймшигт логикийг модульд нууж, хэрэглэгчийн кодыг яг ийм харагдах байдлаар өгөх хэрэгтэй.
Дотор нь хэрхэн хийгдсэнийг хэрэглэгч мэдэх шаардлагагүй.
Нөөцийн модулиудаас бүрдэх хоёр дахь төрлийн модулиуд нь таны бизнест илүү хамааралтай асуудлуудыг аль хэдийн шийддэг. Ихэнхдээ энэ нь Terraform-ийн өргөтгөл болж, шошго, компанийн стандартын хувьд хатуу утгыг тогтоодог газар юм. Та мөн Terraform танд одоогоор ашиглахыг зөвшөөрөхгүй байгаа функцуудыг нэмж болно. Энэ яг одоо. Одоо өнгөрсөн үеийн зүйл болох гэж буй 0.11 хувилбар. Гэсэн хэдий ч урьдчилсан боловсруулагч, jsonnet, cookiecutter болон бусад олон зүйл нь бүрэн хэмжээний ажилд ашиглах ёстой туслах механизм юм.
Дараа нь би үүний зарим жишээг харуулах болно.
Дэд бүтцийн модулийг яг ижил аргаар дууддаг.
Контентыг хаанаас татаж авах эх сурвалжийг зааж өгсөн болно.
Энэ модульд олон тооны утгыг дамжуулж, дамжуулдаг.
Дараа нь энэ модулийн дотор хэд хэдэн нөөцийн модулийг VPC эсвэл Аппликешн ачааллыг тэнцвэржүүлэгч үүсгэх, аюулгүй байдлын бүлэг эсвэл уян харимхай контейнер үйлчилгээний кластер үүсгэх зорилгоор дууддаг.
Хоёр төрлийн модуль байдаг. Энэ тайланд миний бүлэглэсэн мэдээллийн ихэнх нь баримт бичигт бичигдээгүй тул үүнийг ойлгох нь чухал юм.
Яг одоо Terraform дахь баримт бичиг нь нэлээд асуудалтай байгаа тул эдгээр функцууд байгаа тул та тэдгээрийг ашиглаж болно. Гэхдээ тэр эдгээр функцийг хэрхэн ашиглах, яагаад ашиглах нь дээр вэ гэдгийг хэлээгүй. Тиймээс маш олон хүмүүс амьдрах боломжгүй зүйлийг бичдэг.
Дараа нь эдгээр модулиудыг хэрхэн бичихийг харцгаая. Дараа нь бид тэдгээрийг хэрхэн дуудах, кодтой хэрхэн ажиллахыг харах болно.
Terraform Бүртгэл -
Зөвлөмж №0 бол нөөцийн модулиудыг бичихгүй байх явдал юм. Эдгээр модулиудын ихэнх нь танд зориулагдсан болно. Миний хэлсэнчлэн эдгээр нь нээлттэй эх сурвалж, таны бизнесийн логикийг агуулаагүй, IP хаяг, нууц үг гэх мэт хатуу кодгүй байна. Модуль нь маш уян хатан байдаг. Тэгээд аль хэдийн бичигдсэн байх магадлалтай. Амазоны нөөцөд зориулсан олон модуль байдаг. 650 орчим. Тэгээд ихэнх нь чанартай.
Энэ жишээн дээр хэн нэгэн тан дээр ирээд “Би мэдээллийн санг удирдах чадвартай болмоор байна. Би мэдээллийн сан үүсгэхийн тулд модуль үүсгэ." Тухайн хүн Amazon эсвэл Terraform-ийн хэрэгжилтийн нарийн ширийнийг мэдэхгүй. Тэр зүгээр л: "Би MSSQL-г удирдахыг хүсч байна." Энэ нь манай модулийг дуудаж, хөдөлгүүрийн төрлийг тэнд дамжуулж, цагийн бүсийг зааж өгнө гэсэн үг юм.
Мөн бид энэ модулийн дотор хоёр өөр эх үүсвэрийг бий болгоно гэдгийг хүн мэдэхгүй байх ёстой: нэг нь MSSQL-д, хоёр дахь нь бусад бүх зүйлд зориулагдсан, учир нь зөвхөн Terraform 0.11 дээр цагийн бүсийн утгыг нэмэлт болгон зааж өгөх боломжгүй.
Мөн энэ модулиас гарахад хүн зүгээр л хаягийг хүлээн авах боломжтой болно. Энэ бүхнийг дотооддоо ямар мэдээллийн сангаас, ямар нөөцөөс бүтээж байгааг тэр мэдэхгүй. Энэ бол далдлах маш чухал элемент юм. Энэ нь зөвхөн нээлттэй эх сурвалжид нээлттэй байгаа модулиудад төдийгүй таны төсөл, баг дотор бичих модулиудад хамаарна.
Энэ бол хоёр дахь аргумент бөгөөд хэрэв та Терраформыг хэсэг хугацаанд ашиглаж байгаа бол маш чухал юм. Та өөрийн бүх Terraform модулиудыг өөрийн компанид байрлуулах агуулахтай. Цаг хугацаа өнгөрөхөд энэ төсөл нэг эсвэл хоёр мегабайт хүртэл өсөх нь хэвийн үзэгдэл юм. Энэ зүгээр.
Гэхдээ асуудал бол Terraform эдгээр модулиудыг хэрхэн дууддаг вэ? Жишээлбэл, хэрэв та хэрэглэгч бүрийг үүсгэхийн тулд модуль руу залгавал Terraform эхлээд хадгалах газрыг бүхэлд нь ачаалж, дараа нь тухайн модуль байрладаг хавтас руу шилжинэ. Ингэснээр та нэг мегабайтыг татаж авах болно. Хэрэв та 100 эсвэл 200 хэрэглэгчийг удирдаж байгаа бол 100 эсвэл 200 мегабайтыг татаж аваад дараа нь тэр хавтас руу орно. Мэдээжийн хэрэг та "Terraform init" дээр дарах бүртээ олон зүйлийг татаж авахыг хүсэхгүй байна.
Энэ асуудлыг шийдэх хоёр арга бий. Эхнийх нь харьцангуй замыг ашиглах явдал юм. Ингэснээр та хавтас нь дотоод (./) гэдгийг кодонд зааж өгнө. Та ямар нэгэн зүйлийг эхлүүлэхээсээ өмнө энэ агуулахын Git клоныг дотооддоо хийдэг. Ингэснээр та үүнийг нэг удаа хийх болно.
Мэдээжийн хэрэг маш олон сул тал бий. Жишээлбэл, та хувилбарыг ашиглах боломжгүй. Энэ нь заримдаа амьдрахад хэцүү байдаг.
Хоёр дахь шийдэл. Хэрэв танд маш олон дэд модуль байгаа бөгөөд танд аль хэдийн тодорхой шугам хоолой байгаа бол монорепозитороос олон төрлийн багцуудыг цуглуулж, S3 руу байршуулах боломжийг олгодог MBT төсөл байдаг. Энэ бол маш сайн арга юм. Тиймээс iam-user-1.0.0.zip файл нь ердөө 1 Кб жинтэй байх болно, учир нь энэ нөөцийг үүсгэх код нь маш бага юм. Мөн энэ нь илүү хурдан ажиллах болно.
Модулиудад юу ашиглах боломжгүй талаар ярилцъя.
Яагаад модулиудад ийм муу зүйл байдаг вэ? Хамгийн муу зүйл бол хэрэглэгч гэж таамаглах явдал юм. Хэрэглэгчийг өөр өөр хүмүүс ашиглаж болох үйлчилгээ үзүүлэгчийн баталгаажуулалтын сонголт гэж үзье. Жишээлбэл, бид бүгдээрээ дүрээ өөртөө шингээх болно. Энэ нь Терраформ энэ үүргийг гүйцэтгэх болно гэсэн үг юм. Дараа нь энэ дүрээрээ бусад үйлдлүүдийг хийх болно.
Муу нь гэвэл Вася Amazon-той нэг аргаар, жишээлбэл, өгөгдмөл орчны хувьсагчийг ашиглан холбогдох дуртай бол Петя нууц газар хадгалсан хуваалцсан түлхүүрээ ашиглах дуртай бол та хоёуланг нь зааж өгөх боломжгүй. Терраформ. Тэд зовлон зүдгүүрийг мэдрэхгүйн тулд модульд энэ блокыг зааж өгөх шаардлагагүй болно. Үүнийг илүү өндөр түвшинд зааж өгөх ёстой. Өөрөөр хэлбэл, бидэнд нөөцийн модуль, дэд бүтцийн модуль, дээр нь найрлага бий. Үүнийг илүү өндөр газар зааж өгөх ёстой.
Хоёр дахь муу зүйл бол тэжээгч юм. Энд муу зүйл тийм ч өчүүхэн биш, учир нь хэрэв та код бичээд энэ нь танд тохирсон бол энэ нь ажиллаж байгаа бол яагаад үүнийг өөрчлөх хэрэгтэй гэж бодож магадгүй юм.
Хамгийн муу нь та энэ ханган нийлүүлэгчийг хэзээ эхлүүлэхийг тэр бүр хянаж чаддаггүй. Хоёрдугаарт, та aws ec2 гэж юу гэсэн үг болохыг хянахгүй, өөрөөр хэлбэл бид одоо Линукс эсвэл Windows-ийн тухай ярьж байна уу. Тиймээс та өөр өөр үйлдлийн системүүд эсвэл өөр өөр хэрэглэгчийн тохиолдлуудад адилхан ажиллах зүйлийг бичиж болохгүй.
Албан ёсны баримт бичигт мөн дурдсан хамгийн нийтлэг жишээ бол хэрэв та aws_instance гэж бичээд олон тооны аргументуудыг зааж өгвөл тэнд "local-exec" провайдерийг зааж өгөөд ansible-ээ ажиллуулбал буруудах зүйлгүй болно. тоглоомын ном.
Үнэн хэрэгтээ, тийм ээ, үүнд буруу зүйл байхгүй. Гэхдээ удахгүй та энэ local-exec зүйл, жишээлбэл launch_configuration-д байхгүй гэдгийг ойлгох болно.
Мөн та launch_configuration-г ашиглаж, нэг жишээнээс автоматаар масштаблах бүлэг үүсгэхийг хүсвэл launch_configuration-д "provisioner" гэсэн ойлголт байхгүй болно. "Хэрэглэгчийн өгөгдөл" гэсэн ойлголт байдаг.
Тиймээс илүү түгээмэл шийдэл бол хэрэглэгчийн өгөгдлийг ашиглах явдал юм. Энэ нь инстанц асаалттай үед эсвэл автомат масштабын бүлэг нь энэхүү launch_configuration-г ашиглах үед тухайн жишээн дээр эсвэл ижил хэрэглэгчийн өгөгдөлд ажиллах болно.
Хэрэв та нийлүүлэгчийг ажиллуулахыг хүсэж байгаа бол, энэ нь наалт хийх бүрэлдэхүүн хэсэг учраас нэг нөөц бий болсон үед та провайдер, тушаалаа ажиллуулах хэрэгтэй. Ийм нөхцөл байдал зөндөө байдаг.
Үүний хамгийн зөв нөөцийг null_resource гэж нэрлэдэг. Null_resource нь хэзээ ч бүтээгддэггүй хуурамч нөөц юм. Энэ нь юунд ч хүрдэггүй, API байхгүй, автоматаар масштаблахгүй. Гэхдээ энэ нь командыг хэзээ ажиллуулахыг хянах боломжийг олгодог. Энэ тохиолдолд командыг үүсгэх үед ажиллуулна.
холбоос
Хэд хэдэн шинж тэмдэг байдаг. Би бүх шинж тэмдгүүдийг нарийвчлан үзэхгүй. Энэ тухай нийтлэл бий. Гэхдээ хэрэв та Terraform-тэй ажиллаж байсан эсвэл бусад хүмүүсийн модулийг ашигласан бол нээлттэй эхийн ихэнх код шиг олон модулийг хүмүүс өөрсдийн хэрэгцээнд зориулж бичдэг болохыг анзаарсан байх. Нэг хүн бичээд асуудлаа шийдчихлээ. Би үүнийг GitHub-д гацсан, амьд үлдээгээрэй. Энэ нь амьдрах болно, гэхдээ тэнд ямар ч баримт бичиг, жишээ байхгүй бол хэн ч үүнийг ашиглахгүй. Хэрэв танд тодорхой даалгавараас арай илүү зүйлийг шийдэх боломж байхгүй бол хэн ч үүнийг ашиглахгүй. Хэрэглэгчээ алдах маш олон арга бий.
Хүмүүс ашиглахын тулд ямар нэг зүйл бичихийг хүсч байвал эдгээр тэмдгүүдийг дагаж мөрдөхийг зөвлөж байна.
Эдгээр нь:
- Баримт бичиг ба жишээнүүд.
- Бүрэн ажиллагаатай.
- Боломжит өгөгдмөл.
- Цэвэр код.
- Тестүүд.
Туршилтууд нь бичихэд нэлээд хэцүү байдаг тул өөр нөхцөл байдал юм. Би баримт бичиг, жишээнд илүү итгэдэг.
Тиймээс бид модулиудыг хэрхэн бичих талаар авч үзсэн. Хоёр аргумент байна. Эхнийх нь хамгийн чухал нь та чадах юм бол бичихгүй байх, учир нь олон хүмүүс чамаас өмнө эдгээр ажлыг аль хэдийн хийсэн байдаг. Хоёрдугаарт, хэрэв та шийдсэн хэвээр байгаа бол модуль болон провайдеруудад үйлчилгээ үзүүлэгчийг ашиглахгүй байхыг хичээгээрэй.
Энэ бол баримт бичгийн саарал хэсэг юм. Та одоо бодож байж магадгүй: “Ямар нэг зүйл тодорхойгүй байна. Итгэлгүй байна." Гэхдээ бид зургаан сарын дараа харах болно.
Одоо эдгээр модулиудыг хэрхэн дуудах талаар ярилцъя.
Бидний код цаг хугацааны явцад өсдөг гэдгийг бид ойлгож байна. Бидэнд нэг файл байхгүй, 20 файл байна. Тэд бүгд нэг хавтсанд байна. Эсвэл таван хавтас байж болно. Магадгүй бид ямар нэгэн байдлаар тэдгээрийг бүс нутгаар, зарим бүрэлдэхүүн хэсгүүдээр нь задалж эхэлж байгаа байх. Дараа нь бид одоо синхрончлол, зохион байгуулалтын зарим эхлэлтэй байгааг ойлгож байна. Өөрөөр хэлбэл, хэрэв бид сүлжээний нөөцийг өөрчилбөл юу хийх ёстой, үлдсэн нөөцөө юу хийх ёстой, эдгээр хамаарлыг хэрхэн үүсгэх гэх мэтийг ойлгох ёстой.
Хоёр туйл байдаг. Эхний экстрим бол бүгд нэг дор байдаг. Бидэнд нэг мастер файл байна. Одоогийн байдлаар энэ нь Terraform вэбсайт дээрх албан ёсны шилдэг туршлага байсан.
Гэтэл одоо больчихсон, хассан гэж бичээд байна. Цаг хугацаа өнгөрөхөд Терраформ нийгэмлэг энэ нь хамгийн сайн туршлагаас хол байгааг ойлгосон, учир нь хүмүүс уг төслийг янз бүрийн аргаар ашиглаж эхэлсэн. Мөн асуудал бий. Жишээлбэл, бид бүх хамаарлыг нэг дор жагсаахад. Бид "Terraform plan" дээр дарах тохиолдол байдаг бөгөөд Terraform нь бүх нөөцийн төлөвийг шинэчлэх хүртэл маш их цаг хугацаа өнгөрөх болно.
Маш их цаг бол жишээлбэл, 5 минут. Зарим хүмүүсийн хувьд энэ бол маш их хугацаа юм. 15 минут зарцуулсан тохиолдлуудыг би харсан. AWS API нь нөөц бүрийн төлөв байдалд юу болж байгааг олж мэдэхийн тулд 15 минут зарцуулсан. Энэ бол маш том газар нутаг юм.
Мэдээжийн хэрэг, та ямар нэг зүйлийг нэг газар өөрчлөхийг хүсч, 15 минут хүлээхэд холбогдох асуудал гарч ирэх бөгөөд энэ нь танд зарим өөрчлөлтийн зургийг өгөх болно. Та нулимж, "Тийм" гэж бичээд ямар нэг зүйл буруу болсон. Энэ бол маш бодит жишээ юм. Terraform таныг асуудлаас хамгаалах гэж оролддоггүй. Өөрөөр хэлбэл, хүссэн зүйлээ бичнэ үү. Асуудал гарах болно - таны асуудал. Хэдийгээр Terraform 0.11 нь танд ямар нэгэн байдлаар туслахыг оролдохгүй байна. 0.12-т "Вася, чи үүнийг үнэхээр хүсч байна, чи ухаан орж чадах уу?" гэж хэлэх боломжтой сонирхолтой газрууд байдаг.
Хоёрдахь арга бол энэ талбайг багасгах, өөрөөр хэлбэл нэг газраас ирсэн дуудлага өөр газраас бага холбогдож болно.
Ганц асуудал бол та илүү олон код бичих хэрэгтэй, өөрөөр хэлбэл та олон тооны файлд хувьсагчдыг дүрсэлж, үүнийг шинэчлэх хэрэгтэй. Зарим хүмүүс үүнд дургүй байдаг. Энэ бол миний хувьд хэвийн зүйл. Зарим хүмүүс "Яагаад үүнийг өөр газар бичээд байгаа юм бэ, би бүгдийг нэг дор байрлуулна" гэж боддог. Энэ нь боломжтой, гэхдээ энэ нь хоёр дахь туйл юм.
Энэ бүхэн хэн нэг газар амьдардаг вэ? Нэг, хоёр, гурван хүн, өөрөөр хэлбэл хэн нэгэн үүнийг ашиглаж байна.
Мөн нэг бүрэлдэхүүн хэсэг, нэг блок эсвэл нэг дэд бүтцийн модулийг хэн дууддаг вэ? Таваас долоон хүн. Энэ сайхан байна.
Хамгийн түгээмэл хариулт бол дунд нь хаа нэгтээ байдаг. Хэрэв төсөл том бол ямар ч шийдэл тохирохгүй, бүх зүйл бүтдэггүй тул та хольцтой болно. Аль аль нь давуу талтай гэдгийг ойлгож байгаа бол үүнд буруудах зүйл байхгүй.
Хэрэв VPC стек дээр ямар нэг зүйл өөрчлөгдсөн бөгөөд та эдгээр өөрчлөлтийг EC2-д хэрэгжүүлэхийг хүсвэл, өөрөөр хэлбэл, та шинэ дэд сүлжээтэй болсон тул автоматаар масштаблах бүлгийг шинэчлэхийг хүссэн бол би энэ төрлийн хамаарлыг зохицуулах гэж нэрлэдэг. Зарим шийдэл байдаг: хэн юу ашигладаг вэ?
Би ямар шийдэл байгааг санал болгож чадна. Та ид шидийг хийхийн тулд Terraform ашиглаж болно, эсвэл Terraform ашиглахын тулд makefile ашиглаж болно. Тэнд ямар нэг зүйл өөрчлөгдсөн бол эндээс ажиллуулж болно.
Энэ шийдвэр танд хэр таалагдаж байна вэ? Энэ гайхалтай шийдэл гэдэгт хэн нэгэн итгэх үү? Би инээмсэглэлийг харлаа, эргэлзээ төрж байсан бололтой.
Мэдээжийн хэрэг, үүнийг гэртээ бүү оролдоорой. Terraform-ийг хэзээ ч Terraform-аас ажиллуулахаар төлөвлөөгүй.
Нэгэн тайланд тэд надад "Үгүй ээ, энэ ажиллахгүй" гэж хэлсэн. Гол нь энэ нь ажиллах ёсгүй юм. Хэдийгээр та Terraform-аас Terraform-ийг ажиллуулж, дараа нь Terraform-ийг эхлүүлэх нь үнэхээр гайхалтай харагдаж байгаа ч та үүнийг хийх ёсгүй. Terraform үргэлж маш амархан эхлэх ёстой.
Хэрэв танд ямар нэг зүйл нэг газар өөрчлөгдсөн үед дуудлагын зохион байгуулалт хэрэгтэй бол Terragrunt байна.
Terragrunt нь Terraform-ийн нэмэлт хэрэгсэл бөгөөд дэд бүтцийн модулиудын дуудлагыг зохицуулах, зохицуулах боломжийг олгодог.
Ердийн Terraform тохиргооны файл иймэрхүү харагдаж байна.
Та аль модулийг дуудахыг хүсч байгаагаа зааж өгнө үү.
Модульд ямар хамаарал байдаг вэ?
Мөн энэ модуль ямар аргументуудыг хүлээн авдаг вэ. Энэ бол Террагрунтын талаар мэдэх бүх зүйл юм.
Баримт бичиг тэнд байгаа бөгөөд GitHub дээр 1 одтой. Гэхдээ ихэнх тохиолдолд энэ нь таны мэдэх ёстой зүйл юм. Үүнийг Terraform-тай дөнгөж ажиллаж эхэлж буй компаниудад хэрэгжүүлэхэд маш хялбар байдаг.
Тиймээс найрал хөгжим бол Террагрунт юм. Өөр сонголтууд байдаг.
Одоо кодтой хэрхэн ажиллах талаар ярилцъя.
Хэрэв та коддоо шинэ функц нэмэх шаардлагатай бол ихэнх тохиолдолд энэ нь хялбар байдаг. Та шинэ эх сурвалж бичиж байна, бүх зүйл энгийн.
Хэрэв танд урьдчилж үүсгэсэн эх сурвалж байгаа бол, жишээ нь та AWS данс нээсний дараа Terraform-ийн талаар мэдсэн бөгөөд өөрт байгаа нөөцөө ашиглахыг хүсч байвал модулийг ийм байдлаар өргөтгөх нь зүйтэй. энэ нь байгаа нөөцийг ашиглахыг дэмждэг.
Мөн блокийн нөөцийг ашиглан шинэ нөөц бий болгохыг дэмжсэн.
Гаралт дээр бид ашигласан зүйлээс хамааран гаралтын id-г буцаана.
Terraform 0.11-ийн хоёр дахь маш чухал асуудал бол жагсаалттай ажиллах явдал юм.
Хэцүү зүйл бол хэрэв бид ийм хэрэглэгчдийн жагсаалттай бол.
Мөн бид блокийн нөөц ашиглан эдгээр хэрэглэгчдийг үүсгэх үед бүх зүйл хэвийн болно. Бид бүхэл бүтэн жагсаалтыг үзэж, тус бүрдээ файл үүсгэдэг. Бүх зүйл сайхан байна. Дараа нь жишээ нь дунд байгаа user3-ыг эндээс хасах хэрэгтэй, дараа нь индекс өөрчлөгдөх тул түүний дараа үүссэн бүх нөөцийг дахин үүсгэх болно.
Төлөв орчинд жагсаалттай ажиллах. Төрийн орчин гэж юу вэ? Энэ нөөцийг бий болгоход шинэ үнэ цэнэ бий болдог нөхцөл байдал юм. Жишээлбэл, AWS хандалтын түлхүүр эсвэл AWS нууц түлхүүр, өөрөөр хэлбэл бид хэрэглэгч үүсгэх үед шинэ хандалт эсвэл нууц түлхүүр хүлээн авдаг. Мөн бид хэрэглэгчийг устгах бүрт энэ хэрэглэгч шинэ түлхүүртэй болно. Гэхдээ энэ бол фэн шуй биш, учир нь хэн нэгэн багаас гарах бүрт түүнд шинэ хэрэглэгч үүсгэвэл хэрэглэгч бидэнтэй найзлахыг хүсэхгүй.
Энэ бол шийдэл юм. Энэ бол Jsonnet дээр бичигдсэн код юм. Jsonnet бол Google-ийн загварчлалын хэл юм.
Энэ тушаал нь энэ загварыг хүлээн зөвшөөрөх боломжийг олгодог бөгөөд гаралт болгон таны загварт нийцүүлэн хийгдсэн json файлыг буцаана.
Загвар нь иймэрхүү харагдаж байна.
Terraform нь HCL болон Json хоёртой ижил аргаар ажиллах боломжийг олгодог тул хэрэв та Json үүсгэх чадвартай бол үүнийг Terraform руу шилжүүлж болно. .tf.json өргөтгөлтэй файлыг амжилттай татаж авах болно.
Тэгээд бид үүнтэй ердийнхөөрөө ажилладаг: terraform init, terramorm хэрэглэнэ. Мөн бид хоёр хэрэглэгчийг бий болгодог.
Одоо хэн нэгэн багийг орхихоос айхгүй. Бид зүгээр л json файлыг засах болно. Вася Пупкин явсан, Петя Пяточкин үлдсэн. Петя Пяточкин шинэ түлхүүр авахгүй.
Terraform-ийг бусад хэрэгслүүдтэй нэгтгэх нь үнэхээр Terraform-ийн ажил биш юм. Terraform нь нөөцийг бий болгох платформ болгон бүтээгдсэн, тэгээд л болоо. Дараа нь гарч ирэх бүх зүйл бол Терраформын санаа зовох зүйл биш юм. Тэгээд тэнд нэхэх шаардлагагүй. Танд хэрэгтэй бүхнийг хийдэг Ansible байдаг.
Гэхдээ бид Terraform-ийг сунгаж, ямар нэгэн зүйл дууссаны дараа зарим тушаалыг дуудахыг хүсэх үед нөхцөл байдал үүсдэг.
Эхний арга. Бид энэ тушаалыг бичих гаралтыг үүсгэдэг.
Дараа нь бид бүрхүүлийн terraform гаралтаас энэ тушаалыг дуудаж, хүссэн утгыг зааж өгнө. Тиймээс команд нь орлуулсан бүх утгуудаар гүйцэтгэгдэнэ. Энэ нь маш тухтай байдаг.
Хоёр дахь арга зам. Энэ нь манай дэд бүтцийн өөрчлөлтөөс хамааран null_resource-ийн хэрэглээ юм. Зарим нөөцийн ID өөрчлөгдвөл бид ижил local-exe-г дуудаж болно.
Мэдээжийн хэрэг, энэ бүхэн цаасан дээр жигд байна, учир нь Амазон бусад бүх нийтийн үйлчилгээ үзүүлэгчдийн нэгэн адил өөрийн гэсэн олон тооны зах зээлтэй байдаг.
Хамгийн нийтлэг давуу тал бол та AWS данс нээхдээ аль бүс нутгийг ашиглах нь чухал байдаг; энэ функц тэнд идэвхжсэн үү; магадгүй та 2013 оны XNUMX-р сарын дараа нээсэн байх; Магадгүй та VPC гэх мэт стандартыг ашиглаж байгаа байх. Олон хязгаарлалтууд байдаг. Амазон тэднийг баримт бичгийн туршид тараасан.
Цөөн хэдэн зүйлээс зайлсхийхийг зөвлөж байна.
Эхлэхийн тулд Terraform төлөвлөгөө эсвэл Terraform CLI доторх бүх нууц бус маргаанаас зайлсхий. Энэ бүгдийг tfvars файл эсвэл орчны хувьсагч руу оруулж болно.
Гэхдээ та энэ шидэт тушаалыг бүхэлд нь цээжлэх шаардлагагүй. Terraform төлөвлөгөө - var, бид унтраах. Эхний хувьсагч нь var, хоёр дахь хувьсагч нь var, гурав дахь, дөрөв дэх хувьсагч. Миний байнга ашигладаг код болох дэд бүтцийн хамгийн чухал зарчим бол кодыг хараад л би тэнд юу, ямар төлөвт, ямар үнэлэмжтэй байгааг тодорхой ойлгох ёстой. Тиймээс би баримт бичгийг унших эсвэл Васягаас манай кластерийг үүсгэхдээ ямар параметр ашигласан талаар асуух шаардлагагүй. Би зүгээр л орчинтой таарч тохирох tfvars өргөтгөлтэй файлыг нээж, тэнд байгаа бүх зүйлийг харах хэрэгтэй.
Мөн хамрах хүрээг багасгахын тулд зорилтот аргументуудыг бүү ашигла. Үүний тулд жижиг дэд бүтцийн модулиудыг ашиглах нь илүү хялбар байдаг.
Мөн параллелизмыг хязгаарлаж, нэмэгдүүлэх шаардлагагүй. Хэрэв надад 150 нөөц байгаа бөгөөд би Amazon параллелизмыг анхдагч 10-аас 100 болгон нэмэгдүүлэхийг хүсч байвал ямар нэг зүйл буруу болж магадгүй юм. Эсвэл одоо зүгээр байж болох ч Амазон таныг хэт олон дуудлага хийж байна гэж хэлэхэд танд асуудал гарах болно.
Terraform эдгээр асуудлуудын ихэнхийг дахин эхлүүлэхийг оролдох боловч та бараг юу ч хүрэхгүй. Parallelism=1 нь AWS API эсвэл Terraform үйлчилгээ үзүүлэгчийн дотор ямар нэгэн алдаа гарсан тохиолдолд ашиглах чухал зүйл юм. Дараа нь та параллелизм = 1 гэж зааж өгөх хэрэгтэй бөгөөд Terraform нэг дуудлагыг, дараа нь хоёр дахь, гурав дахь дуудлагыг дуустал хүлээнэ үү. Тэр тэднийг нэг нэгээр нь хөөргөх болно.
Хүмүүс надаас “Яагаад би Terraform ажлын талбарыг муу гэж боддог вэ?” гэж асуудаг. Дэд бүтцийг код гэдэг зарчим нь ямар дэд бүтэц бий болсон, ямар үнэлэмжтэй байгааг харах явдал гэж би боддог.
Ажлын талбарыг хэрэглэгчид үүсгээгүй. Энэ нь хэрэглэгчид Terraform ажлын талбаргүйгээр бид амьдарч чадахгүй гэж GitHub-д бичсэн гэсэн үг биш юм. Үгүй тийм биш. Terraform Enterprise бол арилжааны шийдэл юм. HashiCorp-ийн Terraform нь бидэнд ажлын талбар хэрэгтэй гэж шийдсэн тул бид үүнийг файлаар хассан. Би үүнийг тусдаа хавтсанд хийх нь илүү хялбар байдаг. Дараа нь арай илүү файлууд байх болно, гэхдээ энэ нь илүү тодорхой болно.
Кодтой хэрхэн ажиллах вэ? Үнэндээ жагсаалттай ажиллах нь цорын ганц зовлон юм. Мөн Terraform-ыг хялбархан аваарай. Энэ нь таны төлөө бүх зүйлийг гайхалтайгаар хийх зүйл биш юм. Баримт бичигт бичигдсэн бүх зүйлийг тэнд шахах шаардлагагүй.
Илтгэлийн сэдвийг "ирээдүйд зориулж" бичсэн. Би энэ талаар маш товч ярина. Ирээдүйд энэ нь 0.12 удахгүй гарах болно гэсэн үг юм.
0.12 бол олон тонн шинэ зүйл юм. Хэрэв та ердийн програмчлалаас гаралтай бол бүх төрлийн динамик блок, гогцоо, зөв ба нөхцөлт харьцуулах үйлдлүүдийг орхиж, зүүн ба баруун талыг нэгэн зэрэг тооцдоггүй, гэхдээ нөхцөл байдлаас хамааран. Та үүнийг маш их санаж байна, тиймээс 0.12 нь үүнийг шийдэх болно.
Гэхдээ! Хэрэв та бэлэн модулиуд болон гуравдагч талын шийдлүүдийг ашиглан бага, илүү хялбар бичвэл 0.12 гарч ирээд бүх зүйлийг засах болно гэж хүлээх шаардлагагүй болно.
Мэдээлэл өгсөнд баярлалаа! Та дэд бүтцийг код болгон ярьж, тестийн талаар нэг үг хэлсэн. Модульд тест хийх шаардлагатай юу? Энэ хэний хариуцлага вэ? Би өөрөө бичих шаардлагатай юу эсвэл модулиудын үүрэг хариуцлага уу?
Ирэх жил бид бүх зүйлийг туршиж үзэхээр шийдсэн тайлангуудаар дүүрэн байх болно. Юуг шалгах вэ гэдэг хамгийн том асуулт. Өөр өөр үйлчилгээ үзүүлэгчээс маш их хамааралтай, маш олон хязгаарлалт байдаг. Та бид хоёр ярилцаж байгаад "Надад шалгалт хэрэгтэй байна" гэж хэлэхэд би: "Чи юу шалгах вэ?" Та бүс нутагтаа шалгуулна гэсэн. Дараа нь би энэ нь манай бүс нутагт ажиллахгүй байна гэж хэлж байна. Өөрөөр хэлбэл, бид үүн дээр санал нийлэх боломжгүй болно. Тэр ч бүү хэл техникийн олон асуудал байгаа. Өөрөөр хэлбэл, эдгээр тестүүдийг хэрхэн бичих вэ, ингэснээр тэдгээр нь хангалттай байх болно.
Би энэ сэдвийг идэвхтэй судалж байна, өөрөөр хэлбэл таны бичсэн дэд бүтцэд үндэслэн тестийг хэрхэн автоматаар үүсгэх вэ. Өөрөөр хэлбэл, хэрэв та энэ кодыг бичсэн бол би үүнийг ажиллуулах хэрэгтэй, үүний үндсэн дээр би тест үүсгэж болно.
нь Terraform-ийн интеграцийн тест бичих боломжийг олгодог хамгийн түгээмэл номын сангуудын нэг юм. Энэ бол туслах хэрэгслүүдийн нэг юм. Би DSL төрлийг илүүд үздэг, жишээ нь, rspec.
Антон, тайланд баярлалаа! Намайг Валерий гэдэг. Би жаахан философийн асуулт асууя. Болзолтоор хангалт, байршуулалт гэж байна. Хангамж нь миний дэд бүтцийг бий болгодог, байршуулахдаа бид үүнийг хэрэгтэй зүйлээр дүүргэдэг, тухайлбал, сервер, программ гэх мэт. Мөн Terraform нь бэлтгэл хийхэд илүү зориулагдсан, Ansible нь байршуулалтад илүү зориулагдсан байдаг, учир нь Ansible нь бас физик дэд бүтцэд зориулагдсан байдаг. nginx, Postgres-ийг суулгах боломжийг танд олгоно. Гэхдээ үүнтэй зэрэгцэн Ansible нь жишээлбэл Amazon эсвэл Google-ийн нөөцийг ашиглахыг зөвшөөрдөг бололтой. Гэхдээ Terraform нь модулиудыг ашиглан зарим програм хангамжийг байрлуулах боломжийг олгодог. Таны бодлоор Terraform болон Ansible хоёрын хооронд ямар нэгэн хил хязгаар байдаг уу, хаана, юуг ашиглах нь дээр вэ? Эсвэл, жишээ нь, Ansible аль хэдийн хог болсон гэж та бодож байна уу, та Terraform-ыг бүх зүйлд ашиглахыг хичээх ёстой юу?
Сайн асуулт, Валерий. 2014 оноос хойш Terraform нь зориулалтын хувьд өөрчлөгдөөгүй гэдэгт би итгэдэг. Дэд бүтцийн төлөө бүтээгдсэн, дэд бүтцийнхээ төлөө үхсэн. Бидэнд Ansible-ийн тохиргооны менежмент хэрэгтэй байсан бөгөөд байх болно. Асуудал нь launch_configuration дотор хэрэглэгчийн өгөгдөл байгаа явдал юм. Эндээс та Ansible гэх мэтийг татдаг. Энэ бол миний хамгийн дуртай стандарт ялгаа юм.
Хэрэв бид үзэсгэлэнтэй дэд бүтцийн талаар ярьж байгаа бол энэ зургийг цуглуулдаг Packer гэх мэт хэрэгслүүд байдаг. Дараа нь Terraform өгөгдлийн эх сурвалжийг ашиглан энэ зургийг олж, эхлүүлэх_тохиргоог шинэчилнэ. Өөрөөр хэлбэл, ийм байдлаар дамжуулах хоолой нь бид эхлээд Tracker-ыг татаж, дараа нь Terraform-ыг татдаг. Хэрэв бүтээгдсэн бол шинэ өөрчлөлт гарна.
Сайн уу? Мэдээлэл өгсөнд баярлалаа! Намайг Миша гэдэг, RBS компани. Та нөөц үүсгэхдээ provisioner-ээр дамжуулан Ansible руу залгаж болно. Ansible нь мөн динамик тооллого гэж нэрлэгддэг сэдэвтэй. Та эхлээд Terraform руу залгаж, дараа нь мужаас нөөц авч, гүйцэтгэх Ansible руу залгаж болно. Юу нь дээр вэ?
Хүмүүс хоёуланг нь адилхан амжилттай ашигладаг. Хэрэв бид автоматаар масштаблах бүлгийн тухай ярихгүй бол Ansible дахь динамик тооллого нь тохиромжтой зүйл юм шиг санагдаж байна. Учир нь автомат масштабын бүлэгт бид эхлүүлэх_тохиргоо гэж нэрлэгддэг өөрийн хэрэгсэлтэй болсон. launch_configuration-д бид шинэ нөөц үүсгэх үед эхлүүлэх шаардлагатай бүх зүйлийг бүртгэдэг. Тиймээс Amazon-ийн хувьд динамик тооллого ашиглах, Terraform ts файлыг унших нь миний бодлоор хэт их хэрэг болно. Хэрэв та "автомат масштабын бүлэг" гэсэн ойлголт байхгүй бусад хэрэгслийг ашигладаг бол, жишээлбэл, DigitalOcean эсвэл автоматаар масштаблах бүлэг байхгүй өөр үйлчилгээ үзүүлэгчийг ашигладаг бол та API-г гараар татах, IP хаягийг олох, үүсгэх шаардлагатай болно. динамик бараа материалын файл бөгөөд Ansible аль хэдийн түүгээр тэнүүчлэх болно. Өөрөөр хэлбэл, Amazon-ийн хувьд launch_configuration, бусад бүх зүйлд динамик бараа материал байдаг.
Эх сурвалж: www.habr.com