Ko'p odamlar Terraformni kundalik ishlarida biladilar va foydalanadilar, ammo buning eng yaxshi amaliyotlari hali shakllanmagan. Har bir jamoa o'ziga xos yondashuv va usullarni o'ylab topishi kerak.
Sizning infratuzilmangiz deyarli oson boshlanadi: bir nechta manbalar + bir nechta dasturchilar. Vaqt o'tishi bilan u har xil yo'nalishlarda o'sadi. Resurslarni Terraform modullariga guruhlash, kodlarni papkalarga tartibga solish usullarini topasizmi va yana nima noto'g'ri bo'lishi mumkin? (mashhur oxirgi so'zlar)
Vaqt o'tadi va sizning infratuzilmangiz sizning yangi uy hayvoningiz kabi his qilasiz, lekin nima uchun? Siz infratuzilmadagi tushunarsiz o'zgarishlardan xavotirdasiz, infratuzilma va kodga tegishdan qo'rqasiz - natijada siz yangi funksiyalarni kechiktirasiz yoki sifatni pasaytirasiz...
Github’da AWS uchun Terraform hamjamiyat modullari to‘plamini uch yil boshqarganidan va ishlab chiqarishda Terraform’ga uzoq muddatli xizmat ko‘rsatganidan so‘ng, Anton Babenko o‘z tajribasi bilan o‘rtoqlashishga tayyor: kelajakda zarar ko‘rmasligi uchun TF modullarini qanday yozish kerak.
Suhbat oxirida ishtirokchilar Terraform’dagi resurslarni boshqarish tamoyillari, Terraform’dagi modullar bilan bog‘liq eng yaxshi amaliyotlar va infratuzilmani boshqarish bilan bog‘liq ba’zi uzluksiz integratsiya tamoyillari bilan ko‘proq tanish bo‘ladilar.
Voz kechish: Shuni ta'kidlaymanki, bu hisobot 2018 yil noyabr oyida - 2 yil o'tdi. Hisobotda muhokama qilingan Terraform 0.11 versiyasi endi qo'llab-quvvatlanmaydi. Oxirgi 2 yil ichida ko'plab yangiliklar, yaxshilanishlar va o'zgarishlarni o'z ichiga olgan 2 ta yangi nashr chiqdi. Iltimos, bunga e'tibor bering va hujjatlarni tekshiring.
Manbalar:
- +
- — avtomatik formatlash kodi va hujjatlari
- - Terraform modullari generatori (WIP)
- - Vizual diagrammalardan terraform kod generatori (WIP)
- www.terraform-best-practices.com
- (Yangi xabarlar mening shaxsiy veb-saytimda www.antonbabenko.com/)
- @antonbabenko - Twitter va turli xil shimlar
Mening ismim Anton Babenko. Ba'zilaringiz men yozgan koddan foydalangan bo'lishi mumkin. Endi men bu haqda har qachongidan ham ishonch bilan gapiraman, chunki menda statistik ma'lumotlardan foydalanish imkoniyati bor.
Men Terraformda ishlayman va 2015 yildan beri Terraform va Amazon bilan bog'liq ko'plab ochiq manba loyihalarida faol ishtirokchi va hissa qo'shdim.
O'shandan beri men uni qiziqarli tarzda qo'yish uchun etarli kod yozdim. Va hozir bu haqda sizga aytib berishga harakat qilaman.
Men Terraform bilan ishlashning nozik tomonlari va o'ziga xosligi haqida gapiraman. Lekin bu HighLoad mavzusi emas. Va endi nima uchun tushunasiz.
Vaqt o'tishi bilan men Terraform modullarini yozishni boshladim. Foydalanuvchilar savollar yozishdi, men ularni qayta yozdim. Keyin kodni oldindan topshirilgan kanca yordamida formatlash uchun turli xil yordamchi dasturlarni yozdim va hokazo.
Ko'p qiziqarli loyihalar bor edi. Menga kod yaratish yoqadi, chunki men kompyuter men va dasturchi uchun tobora ko'proq ish qilishini yoqtiraman, shuning uchun men hozirda vizual diagrammalardan Terraform kod generatori ustida ishlayapman. Balki ba'zilaringiz ularni ko'rgandirsiz. Bu o'qlar bilan chiroyli qutilar. Agar siz "Eksport" tugmasini bossangiz va barchasini kod sifatida olsangiz, menimcha, bu juda yaxshi.
Men Ukrainadanman. Men ko'p yillardan beri Norvegiyada yashayman.
Shuningdek, ushbu hisobot uchun ma'lumotlar mening ismimni biladigan va meni ijtimoiy tarmoqlarda topadigan odamlardan to'plangan. Men deyarli har doim bir xil taxallusga egaman.
Yuqorida aytib o'tganimdek, men GitHub-dagi eng katta omborlardan biri bo'lgan Terraform AWS modullarining asosiy saqlovchisiman, bu erda biz eng keng tarqalgan vazifalar uchun modullarni joylashtiramiz: VPC, Autoscaling, RDS.
Va hozir eshitgan narsangiz eng oddiy. Agar siz Terraform nima ekanligini tushunganingizga shubha qilsangiz, vaqtingizni boshqa joyda o'tkazganingiz ma'qul. Bu erda juda ko'p texnik atamalar bo'ladi. Va men hech ikkilanmay hisobot darajasini eng yuqori deb e'lon qildim. Bu shuni anglatadiki, men ko'p tushuntirishlarsiz barcha mumkin bo'lgan atamalardan foydalanishim mumkin.
Terraform 2014 yilda infratuzilmani kod sifatida yozish, rejalashtirish va boshqarish imkonini beruvchi yordamchi dastur sifatida paydo bo'ldi. Bu erda asosiy tushuncha "infratuzilma kod sifatida".
Barcha hujjatlar, men aytganimdek, yozilgan . Umid qilamanki, ko'pchilik bu sayt haqida biladi va hujjatlarni o'qib chiqdi. Agar shunday bo'lsa, unda siz to'g'ri joydasiz.
Oddiy Terraform konfiguratsiya fayli shunday ko'rinadi, bu erda biz avval ba'zi o'zgaruvchilarni aniqlaymiz.
Bu holda biz "aws_region" ni aniqlaymiz.
Keyin biz qanday resurslarni yaratmoqchi ekanligimizni tasvirlaymiz.
Biz ba'zi buyruqlarni, xususan, bog'liqliklar va provayderlarni yuklash uchun "terraform init" ni ishga tushiramiz.
Belgilangan konfiguratsiya biz yaratgan resurslarga mos kelishini tekshirish uchun biz "terraform application" buyrug'ini ishga tushiramiz. Biz ilgari hech narsa yaratmaganimiz sababli, Terraform bizni ushbu resurslarni yaratishga undaydi.
Buni tasdiqlaymiz. Shunday qilib, biz dengiz chig'anoqlari deb ataladigan chelakni yaratamiz.
Bundan tashqari, bir nechta shunga o'xshash yordamchi dasturlar mavjud. Amazondan foydalanadigan ko'plaringiz AWS CloudFormation yoki Google Cloud Deployment Manager yoki Azure Resource Manager-ni bilishadi. Ularning har biri ushbu ommaviy bulut provayderlarining har birida resurslarni boshqarish uchun o'ziga xos dasturga ega. Terraform ayniqsa foydalidir, chunki u 100 dan ortiq provayderlarni boshqarish imkonini beradi. (Batafsil )
Terraform boshidanoq ko'zlagan maqsadlari:
- Terraform resurslarning yagona ko'rinishini taqdim etadi.
- Barcha zamonaviy platformalarni qo'llab-quvvatlash imkonini beradi.
- Terraform esa boshidanoq infratuzilmani xavfsiz va bashoratli tarzda o‘zgartirish imkonini beruvchi yordamchi dastur sifatida ishlab chiqilgan.
2014 yilda bu kontekstda "bashorat qilinadigan" so'zi juda g'ayrioddiy yangradi.
Terraform universal yordamchi dastur hisoblanadi. Agar sizda API bo'lsa, unda siz hamma narsani boshqarishingiz mumkin:
- Siz xohlagan hamma narsani boshqarish uchun 120 dan ortiq provayderlardan foydalanishingiz mumkin.
- Masalan, siz GitHub omborlariga kirishni tasvirlash uchun Terraform-dan foydalanishingiz mumkin.
- Siz hatto Jira'da xatolar yaratishingiz va yopishingiz mumkin.
- Siz New Relic ko'rsatkichlarini boshqarishingiz mumkin.
- Agar chindan ham xohlasangiz, dropbox-da fayllar yaratishingiz mumkin.
Bularning barchasiga Go'da tasvirlanishi mumkin bo'lgan ochiq APIga ega Terraform provayderlari yordamida erishiladi.
Aytaylik, biz avvalgi slaydlarda ko‘rsatganimdek, Terraform’dan foydalanishni boshladik, saytdagi hujjatlarni o‘qib chiqdik, video tomosha qildik va main.tf yozishni boshladik.
Va hamma narsa ajoyib, sizda VPC yaratadigan fayl bor.
Agar siz VPC yaratmoqchi bo'lsangiz, unda siz taxminan ushbu 12 qatorni belgilaysiz. Qaysi mintaqada yaratmoqchi ekanligingizni, qaysi IP manzillardan qaysi cidr_blokdan foydalanishni tasvirlab bering. Va tamom.
Tabiiyki, loyiha asta-sekin o'sib boradi.
Va siz u yerda bir qancha yangi narsalarni qo'shasiz: resurslar, ma'lumotlar manbalari, yangi provayderlar bilan integratsiya bo'lasiz, birdan GitHub hisobingizdagi foydalanuvchilarni boshqarish uchun Terraform-dan foydalanmoqchi bo'lasiz va hokazo. Siz turli xil narsalarni ishlatishingiz mumkin. DNS provayderlari, hamma narsani kesib o'ting. Terraform buni osonlashtiradi.
Keling, quyidagi misolni ko'rib chiqaylik.
Siz asta-sekin internet_gateway ni qo'shasiz, chunki VPC resurslaringiz internetga kirishini xohlaysiz. Bu yaxshi fikr.
Natijada bu main.tf:
Bu main.tf ning yuqori qismidir.
Bu main.tf ning pastki qismidir.
Keyin siz pastki tarmoqni qo'shasiz. NAT shlyuzlarini, marshrutlarni, marshrutlash jadvallarini va boshqa bir qator quyi tarmoqlarni qo'shmoqchi bo'lganingizda, sizda 38 qator emas, balki taxminan 200-300 qator bo'ladi.
Ya'ni main.tf faylingiz asta-sekin o'sib bormoqda. Va ko'pincha odamlar hamma narsani bitta faylga joylashtiradilar. main.tf da 10-20 Kb ko'rinadi. Tasavvur qiling-a, 10-20 Kb matn mazmuni. Va hamma narsa hamma narsaga bog'liq. Bu bilan ishlash asta-sekin qiyinlashmoqda. 10-20 Kb yaxshi foydalanuvchi holati, ba'zan ko'proq. Va odamlar buni har doim ham yomon deb o'ylamaydilar.
Oddiy dasturlashda bo'lgani kabi, ya'ni kod sifatida infratuzilma emas, biz turli sinflar, paketlar, modullar, guruhlardan foydalanishga odatlanganmiz. Terraform sizga xuddi shu narsani qilish imkonini beradi.
- Kod o'sib bormoqda.
- Resurslar o'rtasidagi bog'liqlik ham kuchaymoqda.
Va bizda katta, katta ehtiyoj bor. Biz endi bunday yashay olmasligimizni tushunamiz. Bizning kodimiz ulkan bo'lib bormoqda. 10-20 Kb, albatta, unchalik katta emas, lekin biz faqat tarmoq to'plami haqida gapiramiz, ya'ni siz faqat tarmoq resurslarini qo'shdingiz. Biz 100 Kb osongina to'qilishi mumkin bo'lgan Application Load Balancer, ES klasterini joylashtirish, Kubernetes va boshqalar haqida gapirmayapmiz. Agar siz bularning barchasini yozsangiz, tez orada Terraform Terraform modullarini taqdim etishini bilib olasiz.
Terraform modullari guruh sifatida boshqariladigan mustaqil Terraform konfiguratsiyasidir. Terraform modullari haqida bilishingiz kerak bo'lgan hamma narsa shu. Ular umuman aqlli emas, ular biror narsaga bog'liq holda hech qanday murakkab aloqalarni o'rnatishga imkon bermaydi. Bularning barchasi ishlab chiquvchilarning yelkasiga tushadi. Ya'ni, bu siz allaqachon yozgan Terraform konfiguratsiyasining bir turi. Va siz uni oddiygina guruh sifatida chaqirishingiz mumkin.
Shunday qilib, biz 10-20-30 Kb kodimizni qanday optimallashtirishimizni tushunishga harakat qilmoqdamiz. Biz asta-sekin ba'zi modullardan foydalanishimiz kerakligini tushunamiz.
Siz duch keladigan modullarning birinchi turi resurs modullaridir. Ular sizning infratuzilmangiz nima bilan bog‘liqligini, biznesingiz nima bilan bog‘liqligini, qayerda va qanday shart-sharoitlar borligini tushunishmaydi. Aynan shu modullar men ochiq kodli hamjamiyat bilan birgalikda boshqaramiz va biz infratuzilmangiz uchun dastlabki qurilish bloklari sifatida ilgari suramiz.
Resurs moduliga misol.
Resurs modulini chaqirganimizda, uning mazmunini qaysi yo'ldan yuklashimiz kerakligini aniqlaymiz.
Biz qaysi versiyani yuklab olishni xohlayotganimizni ko'rsatamiz.
Biz u erda bir qancha dalillarni o'tkazamiz. Va tamom. Ushbu moduldan foydalanganda bilishimiz kerak bo'lgan yagona narsa.
Ko'pchilik, agar ular oxirgi versiyadan foydalansa, hamma narsa barqaror bo'ladi deb o'ylaydi. Lekin yoq. Infratuzilma versiyalashtirilgan bo'lishi kerak, biz u yoki bu komponent qaysi versiyada joylashtirilganiga aniq javob berishimiz kerak.
Mana ushbu modul ichidagi kod. Xavfsizlik guruhi moduli. Bu erda varaq 640-qatorga o'tadi. Amazonda har qanday konfiguratsiyada xavfsizlik guruhi resursini yaratish juda ahamiyatsiz vazifadir. Xavfsizlik guruhini yaratish va unga qanday qoidalar o'tishini aytish kifoya emas. Bu juda oddiy bo'lardi. Amazonda millionlab turli xil cheklovlar mavjud. Misol uchun, agar siz foydalansangiz VPC so'nggi nuqtasi, prefikslar ro'yxati, turli API va bularning barchasini hamma narsa bilan birlashtirishga harakat qilsa, Terraform sizga buni qilishga ruxsat bermaydi. Amazon API ham bunga ruxsat bermaydi. Shuning uchun biz ushbu dahshatli mantiqni modulda yashirishimiz va foydalanuvchi kodini xuddi shunday ko'rinishda berishimiz kerak.
Foydalanuvchi uning ichida qanday yaratilganligini bilishi shart emas.
Resurs modullaridan tashkil topgan ikkinchi turdagi modullar allaqachon biznesingizga ko'proq mos keladigan muammolarni hal qiladi. Ko'pincha bu joy Terraform uchun kengaytma bo'lib, teglar, kompaniya standartlari uchun ba'zi qattiq qiymatlarni o'rnatadi. Shuningdek, u erda Terraform hozirda foydalanishga ruxsat bermaydigan funksiyalarni qo'shishingiz mumkin. Bu hozir. Endi o'tmishda qoladigan 0.11 versiyasi. Ammo shunga qaramay, preprotsessorlar, jsonnet, cookie-cutter va boshqa ko'plab narsalar to'liq ish uchun ishlatilishi kerak bo'lgan yordamchi mexanizmdir.
Keyinchalik men bunga ba'zi misollarni ko'rsataman.
Infratuzilma moduli aynan shu tarzda chaqiriladi.
Kontentni qaerdan yuklab olish mumkinligi ko'rsatilgan.
Ushbu modulga bir nechta qiymatlar kiritiladi va o'tkaziladi.
Keyinchalik, ushbu modul ichida VPC yoki Application Load Balancer yaratish yoki xavfsizlik guruhini yaratish yoki Elastik konteyner xizmati klasterini yaratish uchun bir qator resurs modullari chaqiriladi.
Ikki turdagi modul mavjud. Buni tushunish juda muhim, chunki men ushbu hisobotda guruhlangan ma'lumotlarning aksariyati hujjatlarda yozilmagan.
Va hozirda Terraform-dagi hujjatlar juda muammoli, chunki u faqat bu xususiyatlar mavjudligini aytadi, siz ulardan foydalanishingiz mumkin. Ammo u bu xususiyatlardan qanday foydalanish kerakligini, nima uchun ulardan foydalanish yaxshiroq ekanligini aytmaydi. Shuning uchun, juda ko'p odamlar yashay olmaydigan narsalarni yozadilar.
Keling, keyin ushbu modullarni qanday yozishni ko'rib chiqaylik. Keyin biz ularga qanday qo'ng'iroq qilishni va kod bilan qanday ishlashni ko'rib chiqamiz.
Terraform registri -
Maslahat №0 - manba modullarini yozmaslik. Ushbu modullarning aksariyati allaqachon siz uchun yozilgan. Aytganimdek, ular ochiq manba, ularda sizning biznes mantiqingiz yo'q, ularda IP manzillar, parollar va boshqalar uchun qattiq kodlangan qiymatlar yo'q. Modul juda moslashuvchan. Va, ehtimol, allaqachon yozilgan. Amazondan resurslar uchun ko'plab modullar mavjud. Taxminan 650. Va ularning aksariyati sifatli.
Ushbu misolda, kimdir sizga kelib: “Men ma'lumotlar bazasini boshqarishni xohlayman. Ma'lumotlar bazasini yaratishim uchun modul yarating." Bu odam Amazon yoki Terraformning amalga oshirish tafsilotlarini bilmaydi. U shunchaki aytadi: "Men MSSQL-ni boshqarishni xohlayman." Ya'ni, u bizning modulimizni chaqiradi, u erda vosita turini o'tkazadi va vaqt zonasini ko'rsatadi.
Va odam biz ushbu modul ichida ikki xil manba yaratishimizni bilmasligi kerak: biri MSSQL uchun, ikkinchisi hamma narsa uchun, chunki Terraform 0.11 da siz vaqt mintaqasi qiymatlarini ixtiyoriy sifatida belgilay olmaysiz.
Va ushbu moduldan chiqishda odam oddiygina manzilni olishi mumkin bo'ladi. Bularning barchasini qaysi ma'lumotlar bazasidan, qaysi manbadan yaratayotganimizni u bilmaydi. Bu yashirishning juda muhim elementi. Va bu nafaqat ochiq manbada ochiq bo'lgan modullarga, balki loyihalaringiz va jamoalaringiz ichida yozadigan modullarga ham tegishli.
Bu ikkinchi dalil bo'lib, agar siz Terraformdan bir muncha vaqt foydalanayotgan bo'lsangiz, bu juda muhim. Sizning kompaniyangiz uchun barcha Terraform modullaringizni joylashtirgan omboringiz bor. Va vaqt o'tishi bilan ushbu loyiha bir yoki ikki megabayt hajmgacha o'sishi odatiy holdir. Bu odatiy.
Ammo muammo shundaki, Terraform ushbu modullarni qanday chaqiradi. Misol uchun, agar siz har bir foydalanuvchini yaratish uchun modulga qo'ng'iroq qilsangiz, Terraform avval butun omborni yuklaydi va keyin o'sha modul joylashgan papkaga o'tadi. Shu tarzda siz har safar bir megabayt yuklab olasiz. Agar siz 100 yoki 200 foydalanuvchini boshqarsangiz, u holda siz 100 yoki 200 megabaytni yuklab olasiz va keyin o'sha papkaga o'ting. Shunday qilib, siz har safar "Terraform init" tugmasini bosganingizda bir nechta narsalarni yuklab olishni xohlamaysiz.
Bu muammoning ikkita yechimi bor. Birinchisi, nisbiy yo'llardan foydalanishdir. Shunday qilib, siz kodda jildning mahalliy (./) ekanligini ko'rsatasiz. Va biror narsani ishga tushirishdan oldin siz ushbu omborning Git klonini mahalliy sifatida qilasiz. Shu tarzda siz buni bir marta qilasiz.
Albatta, juda ko'p salbiy tomonlari bor. Misol uchun, siz versiyani ishlata olmaysiz. Va bu bilan yashash ba'zan qiyin.
Ikkinchi yechim. Agar sizda juda ko'p submodullar bo'lsa va sizda allaqachon o'rnatilgan quvur liniyasi mavjud bo'lsa, unda MBT loyihasi mavjud bo'lib, u sizga monorepozitoriyadan turli xil paketlarni to'plash va ularni S3-ga yuklash imkonini beradi. Bu juda yaxshi usul. Shunday qilib, iam-user-1.0.0.zip faylining og'irligi atigi 1 Kb bo'ladi, chunki bu resursni yaratish uchun kod juda kichik. Va u ancha tezroq ishlaydi.
Keling, modullarda nimadan foydalanish mumkin emasligi haqida gapiraylik.
Nima uchun modullarda bu yomon? Eng yomoni, foydalanuvchini qabul qilishdir. Tasavvur qiling, foydalanuvchi turli odamlar tomonidan ishlatilishi mumkin bo'lgan provayder autentifikatsiya variantidir. Masalan, biz hammamiz rolni o'zlashtiramiz. Bu Terraform bu rolni o'z zimmasiga olishini anglatadi. Va keyin bu rol bilan u boshqa harakatlarni bajaradi.
Va yomon tomoni shundaki, agar Vasya Amazonga bir yo'l bilan ulanishni yaxshi ko'rsa, masalan, standart muhit o'zgaruvchisidan foydalangan holda va Petya o'zining umumiy kalitidan foydalanishni yaxshi ko'rsa, u maxfiy joyda bo'lsa, unda ikkalasini ham ko'rsata olmaysiz. Terraform. Va ular azob chekmasliklari uchun modulda ushbu blokni ko'rsatishning hojati yo'q. Bu yuqori darajada ko'rsatilishi kerak. Ya'ni, bizda resurs moduli, infratuzilma moduli va tepada kompozitsiya mavjud. Va bu yuqoriroq joyda ko'rsatilishi kerak.
Ikkinchi yomonlik esa rizq beruvchidir. Bu erda yovuzlik unchalik ahamiyatsiz emas, chunki agar siz kod yozsangiz va u siz uchun ishlayotgan bo'lsa, unda agar u ishlayotgan bo'lsa, unda nima uchun uni o'zgartirish kerak deb o'ylashingiz mumkin.
Yomon tomoni shundaki, bu provayder qachon ishga tushirilishini har doim ham nazorat qila olmaysiz, birinchidan. Ikkinchidan, siz aws ec2 nimani anglatishini nazorat qilmaysiz, ya'ni biz hozir Linux yoki Windows haqida gapiryapmiz. Shunday qilib, siz turli xil operatsion tizimlarda yoki turli xil foydalanuvchi holatlarida bir xil ishlaydigan narsalarni yoza olmaysiz.
Rasmiy hujjatlarda ham ko'rsatilgan eng keng tarqalgan misol shundan iboratki, agar siz aws_instance ni yozsangiz va bir nechta argumentlarni ko'rsatsangiz, u erda "local-exec" provayderini ko'rsatsangiz va ansible-ni ishga tushirsangiz, buning hech qanday yomon joyi yo'q. o'yin kitobi.
Aslida, ha, buning hech qanday yomon joyi yo'q. Ammo tez orada siz bu local-exec narsasi, masalan, launch_configuration-da mavjud emasligini tushunasiz.
Agar siz launch_configuration-dan foydalansangiz va bitta misoldan avtomatik o'lchov guruhini yaratmoqchi bo'lsangiz, launch_configuration-da "provayder" tushunchasi yo'q. "Foydalanuvchi ma'lumotlari" tushunchasi mavjud.
Shuning uchun, yanada universal yechim foydalanuvchi ma'lumotlaridan foydalanishdir. Va u namunaning o'zida, misol yoqilganda yoki xuddi shu foydalanuvchi ma'lumotlarida, avtomatik o'lchov guruhi ushbu launch_configurationdan foydalanganda ishga tushiriladi.
Agar siz hali ham provayderni ishga tushirmoqchi bo'lsangiz, chunki u yopishtiruvchi komponent bo'lib, bitta resurs yaratilganda, o'sha paytda siz provayderingizni, buyrug'ingizni ishga tushirishingiz kerak. Bunday holatlar juda ko'p.
Buning uchun eng to'g'ri manba null_resource deb ataladi. Null_resource - bu hech qachon yaratilmagan soxta resurs. U hech narsaga tegmaydi, API yo'q, avtomatik o'lchov yo'q. Lekin bu buyruqni qachon ishga tushirishni boshqarish imkonini beradi. Bunday holda, buyruq yaratish vaqtida bajariladi.
aloqa
Bir nechta belgilar mavjud. Men barcha belgilarni batafsil ko'rib chiqmayman. Bu haqda maqola bor. Ammo agar siz Terraform bilan ishlagan bo'lsangiz yoki boshqa odamlarning modullaridan foydalangan bo'lsangiz, unda siz ko'p modullar, ochiq kodli kodlarning aksariyati kabi, odamlar tomonidan o'z ehtiyojlari uchun yozilganligini tez-tez payqadingiz. Bir kishi yozdi va muammosini hal qildi. Men uni GitHub-ga joylashtirdim, unga yashashga ruxsat bering. U yashaydi, lekin u erda hech qanday hujjat va misollar bo'lmasa, hech kim undan foydalanmaydi. Va agar o'ziga xos vazifadan biroz ko'proq narsani hal qilishga imkon beradigan hech qanday funksionallik bo'lmasa, unda hech kim undan foydalanmaydi. Foydalanuvchilarni yo'qotishning ko'plab usullari mavjud.
Agar siz odamlar undan foydalanishi uchun biror narsa yozmoqchi bo'lsangiz, men ushbu belgilarga amal qilishni maslahat beraman.
Ular quyidagilardir:
- Hujjatlar va misollar.
- To'liq funksionallik.
- Mantiqiy defoltlar.
- Toza kod.
- Sinovlar.
Testlar boshqa holat, chunki ularni yozish juda qiyin. Men hujjatlar va misollarga ko'proq ishonaman.
Shunday qilib, biz modullarni qanday yozishni ko'rib chiqdik. Ikkita dalil bor. Birinchisi, eng muhimi, agar imkoningiz bo'lsa, yozmang, chunki sizdan oldin bir guruh odamlar bu vazifalarni bajarishgan. Ikkinchidan, agar siz hali ham qaror qilsangiz, modullar va provayderlarda provayderlardan foydalanmaslikka harakat qiling.
Bu hujjatlarning kulrang qismi. Siz hozir shunday deb o'ylayotgandirsiz: “Biror narsa tushunarsiz. Ishonchim komil emas." Ammo olti oydan keyin ko'ramiz.
Keling, ushbu modullarni qanday chaqirish haqida gapiraylik.
Bizning kodimiz vaqt o'tishi bilan o'sib borishini tushunamiz. Bizda endi bitta fayl yo'q, bizda allaqachon 20 ta fayl bor. Ularning barchasi bitta papkada. Yoki beshta papkada. Ehtimol, biz ularni qandaydir tarzda mintaqalar, ba'zi tarkibiy qismlar bo'yicha taqsimlashni boshlayotgandirmiz. Keyin biz endi sinxronizatsiya va orkestratsiyaning ba'zi asoslari borligini tushunamiz. Ya'ni, agar biz tarmoq resurslarini o'zgartirsak, nima qilishimiz kerakligini, qolgan resurslarimiz bilan nima qilishimiz kerakligini, bu bog'liqliklarni qanday keltirib chiqarishni va hokazolarni tushunishimiz kerak.
Ikkita haddan tashqari holat mavjud. Birinchi ekstremal hammasi bittada. Bizda bitta asosiy fayl bor. Hozircha bu Terraform veb-saytidagi rasmiy eng yaxshi amaliyot edi.
Ammo endi u eskirgan va o'chirilgan deb yozilgan. Vaqt o'tishi bilan Terraform hamjamiyati bu eng yaxshi amaliyotdan yiroq ekanligini tushundi, chunki odamlar loyihadan turli yo'llar bilan foydalana boshladilar. Va muammolar bor. Misol uchun, biz barcha bog'liqliklarni bir joyda sanab o'tganimizda. "Terraform rejasi" ni bosganimizda va Terraform barcha resurslarning holatini yangilamaguncha, ko'p vaqt o'tishi mumkin bo'lgan holatlar mavjud.
Ko'p vaqt, masalan, 5 daqiqa. Ba'zilar uchun bu juda ko'p vaqt. Men 15 daqiqa davom etgan holatlarni ko'rdim. AWS API har bir resurs holati bilan nima sodir bo'layotganini aniqlash uchun 15 daqiqa vaqt sarfladi. Bu juda katta maydon.
Va, tabiiyki, biror narsani bir joyda o'zgartirmoqchi bo'lganingizda, tegishli muammo paydo bo'ladi, keyin siz 15 daqiqa kutasiz va u sizga ba'zi o'zgarishlarning tuvalini beradi. Siz tupurdingiz, "Ha" deb yozdingiz va nimadir noto'g'ri ketdi. Bu juda real misol. Terraform sizni muammolardan himoya qilishga urinmaydi. Ya'ni, xohlaganingizni yozing. Muammolar bo'ladi - sizning muammolaringiz. Terraform 0.11 sizga hech qanday yordam berishga harakat qilmasa ham. 0.12 da ba'zi qiziqarli joylar bor: "Vasya, siz buni chindan ham xohlaysizmi, o'zingizga kela olasizmi?"
Ikkinchi yo'l - bu maydonni qisqartirish, ya'ni bir joydan qo'ng'iroqlar boshqa joydan kamroq ulanishi mumkin.
Yagona muammo shundaki, siz ko'proq kod yozishingiz kerak, ya'ni ko'p sonli fayllardagi o'zgaruvchilarni tasvirlashingiz va buni yangilashingiz kerak. Ba'zilarga bu yoqmaydi. Bu men uchun normal holat. Va ba'zi odamlar shunday deb o'ylashadi: "Nega buni turli joylarda yozaman, men hammasini bir joyga qo'yaman". Bu mumkin, lekin bu ikkinchi ekstremal.
Bularning barchasi bir joyda kim yashaydi? Bir, ikki, uch kishi, ya'ni kimdir foydalanmoqda.
Va ma'lum bir komponentni, bitta blokni yoki bitta infratuzilma modulini kim chaqiradi? Besh-etti kishi. Bu ajoyib.
Eng keng tarqalgan javob - o'rtada. Agar loyiha katta bo'lsa, unda siz tez-tez hech qanday yechim mos bo'lmagan vaziyatga ega bo'lasiz va u erda hamma narsa ishlamaydi, shuning uchun siz aralashma bilan yakunlanasiz. Buning hech qanday yomon joyi yo'q, chunki ikkalasining ham afzalliklari borligini tushunsangiz.
Agar VPC stekida biror narsa o'zgargan bo'lsa va siz ushbu o'zgarishlarni EC2 ga qo'llamoqchi bo'lsangiz, ya'ni sizda yangi pastki tarmoq mavjud bo'lgani uchun avtomatik o'lchov guruhini yangilamoqchi bo'lsangiz, men bunday qaramlik orkestratsiyasini chaqiraman. Ba'zi echimlar mavjud: kim nimadan foydalanadi?
Men qanday echimlar borligini taklif qila olaman. Sehrgarlik qilish uchun Terraform-dan foydalanishingiz mumkin yoki Terraform-dan foydalanish uchun makefillardan foydalanishingiz mumkin. Va u erda biror narsa o'zgarganligini ko'ring, uni shu yerda ishga tushirishingiz mumkin.
Bu qaror sizga qanday yoqadi? Bu ajoyib yechim ekanligiga kimdir ishonadimi? Men tabassumni ko'raman, shekilli, shubhalar paydo bo'ldi.
Albatta, buni uyda sinab ko'rmang. Terraform hech qachon Terraformdan ishga tushirish uchun ishlab chiqilmagan.
Bir xabarda ular menga: "Yo'q, bu ishlamaydi", dedilar. Gap shundaki, u ishlamasligi kerak. Terraform-ni Terraform-dan va keyin Terraform-dan ishga tushirish juda ta'sirli ko'rinsa-da, buni qilmaslik kerak. Terraform har doim juda oson boshlanishi kerak.
Agar biror joyda biror narsa o'zgargan bo'lsa, qo'ng'iroqlarni orkestratsiya qilish kerak bo'lsa, u holda Terragrunt mavjud.
Terragrunt - yordamchi dastur, Terraform qo'shimchasi bo'lib, u sizga infratuzilma modullariga qo'ng'iroqlarni muvofiqlashtirish va tartibga solish imkonini beradi.
Oddiy Terraform konfiguratsiya fayli shunday ko'rinadi.
Siz qaysi modulga qo'ng'iroq qilishni xohlayotganingizni aniqlaysiz.
Modul qanday bog'liqliklarga ega?
Va bu modul qanday argumentlarni qabul qiladi. Terragrunt haqida bilish kerak bo'lgan narsa shu.
Hujjatlar mavjud va GitHubda 1 ta yulduz bor. Ammo ko'p hollarda bu siz bilishingiz kerak bo'lgan narsadir. Terraform bilan endigina ishlay boshlagan kompaniyalarda buni amalga oshirish juda oson.
Shunday qilib, orkestr - Terragrunt. Boshqa variantlar ham bor.
Endi kod bilan qanday ishlash haqida gapiraylik.
Agar siz kodingizga yangi xususiyatlar qo'shishingiz kerak bo'lsa, aksariyat hollarda bu oson. Siz yangi resurs yozyapsiz, hamma narsa oddiy.
Agar sizda oldindan yaratilgan manba bo'lsa, masalan, siz AWS hisob qaydnomasini ochganingizdan so'ng Terraform haqida bilgan bo'lsangiz va sizda mavjud bo'lgan resurslardan foydalanmoqchi bo'lsangiz, modulingizni shu tarzda kengaytirish maqsadga muvofiq bo'ladi. u mavjud resurslardan foydalanishni qo'llab-quvvatlaydi.
Va blok resursidan foydalangan holda yangi resurslarni yaratishni qo'llab-quvvatladi.
Chiqishda biz har doim nima ishlatilganiga qarab chiqish identifikatorini qaytaramiz.
Terraform 0.11 da ikkinchi juda muhim muammo ro'yxatlar bilan ishlashdir.
Qiyinchilik shundaki, agar bizda foydalanuvchilar ro'yxati mavjud bo'lsa.
Va biz ushbu foydalanuvchilarni blokli resurs yordamida yaratganimizda, hamma narsa yaxshi bo'ladi. Biz butun ro'yxatni ko'rib chiqamiz, har biri uchun fayl yaratamiz. Hammasi yaxshi. Va keyin, masalan, o'rtada joylashgan user3 ni bu yerdan olib tashlash kerak, keyin undan keyin yaratilgan barcha resurslar qayta yaratiladi, chunki indeks o'zgaradi.
Holatli muhitda ro'yxatlar bilan ishlash. Davlat muhiti nima? Bu resurs yaratilganda yangi qiymat yaratiladigan holat. Masalan, AWS kirish kaliti yoki AWS maxfiy kaliti, ya'ni foydalanuvchi yaratganimizda biz yangi kirish yoki maxfiy kalitni olamiz. Va har safar foydalanuvchini o'chirib tashlaganimizda, bu foydalanuvchi yangi kalitga ega bo'ladi. Ammo bu feng shui emas, chunki har safar kimdir jamoani tark etganda unga yangi foydalanuvchi yaratsak, foydalanuvchi biz bilan do'st bo'lishni xohlamaydi.
Bu yechim. Bu Jsonnet-da yozilgan kod. Jsonnet — Google tomonidan ishlab chiqarilgan shablon tili.
Ushbu buyruq sizga ushbu shablonni qabul qilish imkonini beradi va natijada shabloningizga muvofiq yaratilgan json faylini qaytaradi.
Shakl shunday ko'rinadi.
Terraform sizga HCL va Json bilan bir xil tarzda ishlash imkonini beradi, shuning uchun agar sizda Json yaratish qobiliyati bo'lsa, uni Terraformga o'tkazishingiz mumkin. .tf.json kengaytmali fayl muvaffaqiyatli yuklab olinadi.
Va keyin biz odatdagidek u bilan ishlaymiz: terraform init, terramorm qo'llaniladi. Va biz ikkita foydalanuvchi yaratamiz.
Endi jamoadan kimdir ketsa qo'rqmaymiz. Biz faqat json faylini tahrir qilamiz. Vasya Pupkin ketdi, Petya Pyatochkin qoldi. Petya Pyatochkin yangi kalitni olmaydi.
Terraformni boshqa vositalar bilan integratsiya qilish Terraformning ishi emas. Terraform resurslarni yaratish platformasi sifatida yaratilgan va bu ham. Keyinchalik paydo bo'ladigan hamma narsa Terraformni tashvishga solmaydi. Va u erda uni to'qishning hojati yo'q. Ansible bor, u sizga kerak bo'lgan hamma narsani bajaradi.
Ammo biz Terraformni kengaytirmoqchi bo'lganimizda va biror narsa tugagandan so'ng ba'zi buyruqlarni chaqirmoqchi bo'lganimizda vaziyatlar yuzaga keladi.
Birinchi yo'l. Biz ushbu buyruqni yozadigan chiqishni yaratamiz.
Va keyin biz bu buyruqni qobiq terraformi chiqishidan chaqiramiz va kerakli qiymatni belgilaymiz. Shunday qilib, buyruq barcha almashtirilgan qiymatlar bilan bajariladi. Bu juda qulay.
Ikkinchi yo'l. Bu bizning infratuzilmamizdagi o'zgarishlarga qarab null_resource dan foydalanish. Ba'zi manbalarning identifikatori o'zgarishi bilan biz xuddi shu local-exe faylini chaqirishimiz mumkin.
Tabiiyki, bularning barchasi qog'ozda silliq, chunki Amazon, boshqa barcha davlat provayderlari singari, o'zining bir qator chekka holatlariga ega.
Eng tez-tez uchragan holat shundan iboratki, siz AWS hisobini ochganingizda qaysi hududlardan foydalanganingiz muhim; u yerda bu funksiya yoqilganmi; ehtimol siz uni 2013 yil dekabridan keyin ochgansiz; ehtimol siz VPC va hokazolarda sukut bo'yicha foydalanayotgandirsiz. Ko'p cheklovlar mavjud. Va Amazon ularni hujjatlar bo'ylab tarqatdi.
Men qochishni tavsiya qiladigan bir nechta narsa bor.
Boshlash uchun Terraform rejasi yoki Terraform CLI ichidagi barcha maxfiy bo'lmagan dalillardan qoching. Bularning barchasini tfvars fayliga yoki muhit o'zgaruvchisiga qo'yish mumkin.
Ammo bu sehrli buyruqni yodlab olishingiz shart emas. Terraform rejasi - bor va biz boramiz. Birinchi o'zgaruvchi - var, ikkinchi o'zgaruvchi - var, uchinchi, to'rtinchi. Kod sifatida men tez-tez foydalanadigan infratuzilmaning eng muhim printsipi shundan iboratki, kodni ko'rib chiqish orqali men u erda nima, qaysi holatda va qanday qadriyatlar bilan joylashtirilganligini aniq tushunishim kerak. Va shuning uchun men hujjatlarni o'qishim yoki Vasyadan bizning klasterimizni yaratishda qanday parametrlardan foydalanganligini so'rashim shart emas. Men shunchaki tfvars kengaytmali faylni ochishim kerak, bu ko'pincha muhitga mos keladi va u erda hamma narsani ko'rib chiqing.
Bundan tashqari, qamrovni qisqartirish uchun maqsadli argumentlardan foydalanmang. Buning uchun kichik infratuzilma modullaridan foydalanish ancha oson.
Bundan tashqari, parallellikni cheklash va oshirishning hojati yo'q. Agar menda 150 ta resurs bo'lsa va men Amazon parallelizmini standart 10 dan 100 gacha oshirmoqchi bo'lsam, unda nimadir noto'g'ri bo'lishi mumkin. Yoki hozir hammasi yaxshi bo'lishi mumkin, lekin Amazon siz juda ko'p qo'ng'iroq qilayotganingizni aytganida, muammoga duch kelasiz.
Terraform ushbu muammolarning aksariyatini qayta ishga tushirishga harakat qiladi, ammo siz deyarli hech narsaga erisha olmaysiz. Parallelizm=1 AWS API yoki Terraform provayderi ichida biron bir xatoga duch kelsangiz foydalanish uchun muhim narsa. Va keyin siz belgilashingiz kerak: parallelizm = 1 va Terraform bitta qo'ng'iroqni, keyin ikkinchisini, keyin uchinchisini tugatguncha kuting. U ularni birma-bir ishga tushiradi.
Odamlar mendan tez-tez so'rashadi: "Nega men Terraform ish joylarini yomon deb o'ylayman?" Men infratuzilma tamoyili kod sifatida qanday infratuzilma yaratilganligini va qanday qadriyatlar bilan yaratilganligini ko'rishdan iborat deb hisoblayman.
Ish joylari foydalanuvchilar tomonidan yaratilmagan. Bu foydalanuvchilar GitHub muammolarida biz Terraform ish joylarisiz yashay olmasligimiz haqida yozishgan degani emas. Yo'q, bunday emas. Terraform Enterprise tijorat yechimidir. HashiCorp'dan Terraform bizga ish joylari kerak deb qaror qildi, shuning uchun biz uni topshirdik. Men uni alohida papkaga joylashtirishni ancha oson deb bilaman. Keyin biroz ko'proq fayllar bo'ladi, lekin aniqroq bo'ladi.
Kod bilan qanday ishlash kerak? Aslida, ro'yxatlar bilan ishlash yagona og'riqdir. Va Terraformni osonroq qabul qiling. Bu siz uchun hamma narsani ajoyib qiladigan narsa emas. Hujjatlarda yozilgan hamma narsani u yerga surishning hojati yo'q.
Hisobot mavzusi "kelajak uchun" deb yozilgan. Men bu haqda juda qisqacha gapirib beraman. Kelajak uchun bu 0.12 tez orada chiqariladi degan ma'noni anglatadi.
0.12 - bir tonna yangi narsalar. Agar siz muntazam dasturlashdan kelgan bo'lsangiz, unda siz chap va o'ng tomonlar bir vaqtning o'zida emas, balki vaziyatga qarab hisoblangan har xil dinamik bloklar, tsikllar, to'g'ri va shartli taqqoslash operatsiyalarini o'tkazib yuborasiz. Siz buni juda sog'inasiz, shuning uchun 0.12 buni siz uchun hal qiladi.
Lekin! Agar siz tayyor modullar va uchinchi tomon echimlaridan foydalangan holda kamroq va soddaroq yozsangiz, unda siz kutishingiz shart emas va 0.12 keladi va siz uchun hamma narsani tuzatadi deb umid qilaman.
Hisobot uchun rahmat! Siz infratuzilma haqida kod sifatida gapirdingiz va testlar haqida tom ma'noda bir so'z aytdingiz. Modullarda testlar kerakmi? Bu kimning javobgarligi? Men o'zim yozishim kerakmi yoki modullarning javobgarligi?
Kelgusi yil biz hamma narsani sinab ko'rishga qaror qilganimiz haqidagi hisobotlar bilan to'ldiriladi. Nimani sinab ko'rish - eng katta savol. Turli provayderlardan juda ko'p bog'liqliklar, ko'plab cheklovlar mavjud. Siz va men gaplashayotganimizda va siz: "Menga testlar kerak", deb aytsangiz, men: "Nimani sinab ko'rasiz?" Mintaqangizda imtihon qilaman deyapsiz. Keyin aytamanki, bu mening mintaqamda ishlamaydi. Ya'ni, biz bu borada kelisha olmaymiz. Ko'p texnik muammolar borligini aytmasa ham bo'ladi. Ya'ni, bu testlarni adekvat bo'lishi uchun qanday yozish kerak.
Men ushbu mavzuni faol ravishda o'rganyapman, ya'ni siz yozgan infratuzilma asosida testlarni avtomatik ravishda qanday yaratish kerak. Ya'ni, agar siz ushbu kodni yozgan bo'lsangiz, unda men uni ishga tushirishim kerak, shunga asoslanib testlarni yaratishim mumkin.
Terraform uchun integratsiya testlarini yozish imkonini beruvchi eng tez-tez tilga olingan kutubxonalardan biridir. Bu kommunal xizmatlardan biridir. Men DSL turini afzal ko'raman, masalan, rspec.
Anton, hisobot uchun rahmat! Mening ismim Valeriy. Biroz falsafiy savol bersam. Shartli ravishda ta'minlash, joylashtirish mavjud. Ta'minlash mening infratuzilmani yaratadi, joylashtirishda biz uni foydali narsa bilan to'ldiramiz, masalan, serverlar, ilovalar va boshqalar. Va mening fikrimcha, Terraform ko'proq ta'minlash uchun, Ansible esa ko'proq joylashtirish uchun, chunki Ansible ham jismoniy infratuzilma uchun. nginx, Postgres-ni o'rnatishga imkon beradi. Shu bilan birga, Ansible, masalan, Amazon yoki Google resurslarini ta'minlashga ruxsat berganga o'xshaydi. Ammo Terraform shuningdek, uning modullari yordamida ba'zi dasturlarni joylashtirishga imkon beradi. Sizningcha, Terraform va Ansible o'rtasida qandaydir chegara bormi, qaerda va nimani ishlatish yaxshiroq? Yoki, masalan, Ansible allaqachon axlat deb o'ylaysizmi, siz hamma narsa uchun Terraformdan foydalanishga harakat qilishingiz kerakmi?
Yaxshi savol, Valeriy. Men 2014 yildan beri Terraform maqsadi jihatidan o'zgarmaganiga ishonaman. U infratuzilma uchun yaratilgan va infratuzilma uchun o'lgan. Bizda Ansible konfiguratsiyasi boshqaruviga hali ham ehtiyoj bor edi va bo'ladi. Muammo shundaki, launch_configuration ichida foydalanuvchi ma'lumotlari mavjud. Va u erda siz Ansible-ni tortasiz va hokazo. Bu menga eng yoqadigan standart farq.
Agar biz chiroyli infratuzilma haqida gapiradigan bo'lsak, unda bu tasvirni to'playdigan Packer kabi yordamchi dasturlar mavjud. Keyin Terraform ushbu rasmni topish va ishga tushirish_konfiguratsiyasini yangilash uchun ma'lumotlar manbasidan foydalanadi. Ya'ni, bu tarzda quvur liniyasi biz birinchi navbatda Trackerni tortib olamiz, keyin Terraformni tortamiz. Va agar qurilish sodir bo'lsa, unda yangi o'zgarish sodir bo'ladi.
Salom! Hisobot uchun rahmat! Mening ismim Misha, RBS kompaniyasi. Resurs yaratishda provayder orqali Ansible-ga qo'ng'iroq qilishingiz mumkin. Ansible-da dinamik inventar deb nomlangan mavzu ham mavjud. Va siz avval Terraform-ga qo'ng'iroq qilishingiz va keyin Ansible-ga qo'ng'iroq qilishingiz mumkin, u davlatdan resurslarni olib, uni amalga oshiradi. Nimasi yaxshiroq?
Odamlar ikkalasini ham bir xil muvaffaqiyat bilan ishlatishadi. Menimcha, Ansible-da dinamik inventarizatsiya, agar biz avtomatik o'lchov guruhi haqida gapirmasak, qulay narsa. Chunki autoscaling guruhida bizda allaqachon start_configuration deb nomlangan o'z asboblar to'plami mavjud. launch_configuration-da biz yangi resurs yaratishda ishga tushirilishi kerak bo'lgan hamma narsani yozib olamiz. Shuning uchun, Amazon bilan, dinamik inventarizatsiyadan foydalanish va Terraform ts faylini o'qish, menimcha, ortiqcha. Va agar siz "avtomatik o'lchash guruhi" tushunchasi bo'lmagan boshqa vositalardan foydalansangiz, masalan, DigitalOcean yoki avtomatik o'lchov guruhi mavjud bo'lmagan boshqa provayderdan foydalansangiz, u erda siz API-ni qo'lda tortib olishingiz, IP manzillarini topishingiz, yaratishingiz kerak bo'ladi. dinamik inventar fayli va Ansible allaqachon u orqali aylanib chiqadi. Ya'ni, Amazon uchun launch_configuration mavjud va qolgan hamma narsa uchun dinamik inventar mavjud.
Manba: www.habr.com