Keling, bir nechta tuzoqlarni, jumladan, looplar, if bayonotlari va joylashtirish usullari bilan bog'liq bo'lganlarni, shuningdek, Terraformga umuman ta'sir qiladigan umumiy masalalarni ajratib ko'rsatamiz:
- count va for_each parametrlarida cheklovlar mavjud;
- nol uzilish vaqtini joylashtirishni cheklash;
- hatto yaxshi reja ham muvaffaqiyatsiz bo'lishi mumkin;
- refaktoring o'z tuzoqlariga ega bo'lishi mumkin;
- kechiktirilgan muvofiqlik mos keladi... kechiktirish bilan.
count va for_each parametrlarida cheklovlar mavjud
Ushbu bobdagi misollarda count parametri va sikllardagi for_each ifodasi va shartli mantiqdan keng foydalaniladi. Ular yaxshi ishlaydi, lekin siz bilishingiz kerak bo'lgan ikkita muhim cheklovlarga ega.
- Count va for_each hech qanday chiqish manbasi o'zgaruvchilariga havola qila olmaydi.
- count va for_each modul konfiguratsiyasida ishlatilmaydi.
count va for_each hech qanday resurs chiqish o'zgaruvchilariga murojaat qila olmaydi
Tasavvur qiling-a, siz bir nechta EC2 serverlarini o'rnatishingiz kerak va negadir siz ASG dan foydalanishni xohlamaysiz. Sizning kodingiz shunday bo'lishi mumkin:
resource "aws_instance" "example_1" {
count = 3
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
Keling, ularni birma-bir ko'rib chiqaylik.
Hisoblash parametri statik qiymatga o'rnatilganligi sababli, bu kod muammosiz ishlaydi: qo'llash buyrug'ini ishga tushirganingizda, u uchta EC2 serverini yaratadi. Agar joriy AWS mintaqangizdagi har bir mavjudlik zonasida (AZ) bitta serverni joylashtirmoqchi bo'lsangiz nima bo'ladi? Kodingiz aws_availability_zones maʼlumotlar manbasidan zonalar roʻyxatini yuklashini, soʻngra har birini aylanib oʻtishini va count parametri va massiv indeksiga kirishdan foydalanib, unda EC2 serverini yaratishni soʻrashingiz mumkin:
resource "aws_instance" "example_2" {
count = length(data.aws_availability_zones.all.names)
availability_zone = data.aws_availability_zones.all.names[count.index]
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
data "aws_availability_zones" "all" {}Ushbu kod ham yaxshi ishlaydi, chunki count parametri hech qanday muammosiz ma'lumotlar manbalariga murojaat qilishi mumkin. Lekin siz yaratishingiz kerak bo'lgan serverlar soni qandaydir resurs chiqishiga bog'liq bo'lsa nima bo'ladi? Buni ko'rsatish uchun, eng oson yo'li, nomidan ko'rinib turibdiki, tasodifiy butun sonni qaytaradigan random_integer resursidan foydalanishdir:
resource "random_integer" "num_instances" {
min = 1
max = 3
}Bu kod 1 va 3 oʻrtasida tasodifiy son hosil qiladi. Keling, aws_instance resursining count parametrida ushbu resurs chiqishidan foydalanishga harakat qilsak nima boʻlishini koʻrib chiqamiz:
resource "aws_instance" "example_3" {
count = random_integer.num_instances.result
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}Agar siz ushbu kodda terraform rejasini ishga tushirsangiz, siz quyidagi xatolikni olasiz:
Error: Invalid count argument
on main.tf line 30, in resource "aws_instance" "example_3":
30: count = random_integer.num_instances.result
The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.Terraform har qanday resurslarni yaratish yoki o'zgartirishdan oldin rejalashtirish bosqichida count va for_each hisoblanishini talab qiladi. Bu shuni anglatadiki, count va for_each literallarga, o'zgaruvchilarga, ma'lumotlar manbalariga va hatto resurs ro'yxatiga (agar ularning uzunligi rejalashtirish vaqtida aniqlanishi mumkin bo'lsa) murojaat qilishi mumkin, lekin hisoblangan manba chiqishi o'zgaruvchilariga emas.
count va for_each modul konfiguratsiyasida ishlatilmaydi
Bir kuni siz modul konfiguratsiyasiga hisoblash parametrini qo'shish vasvasasiga tushishingiz mumkin:
module "count_example" {
source = "../../../../modules/services/webserver-cluster"
count = 3
cluster_name = "terraform-up-and-running-example"
server_port = 8080
instance_type = "t2.micro"
}Ushbu kod veb-server-klaster resursining uchta nusxasini yaratish uchun modul ichida hisoblashdan foydalanishga harakat qiladi. Yoki siz modulni ba'zi mantiqiy shartlar asosida uning count parametrini 0 ga o'rnatish orqali ulanishni ixtiyoriy qilishingiz mumkin. Bu o'rtacha kodga o'xshab ko'rinishi mumkin, ammo terraform rejasini ishga tushirishda siz ushbu xatoni olasiz:
Error: Reserved argument name in module block
on main.tf line 13, in module "count_example":
13: count = 3
The name "count" is reserved for use in a future version of Terraform.Afsuski, Terraform 0.12.6 dan boshlab modul resursida count yoki for_each dan foydalanish qo'llab-quvvatlanmaydi. Terraform 0.12 nashri eslatmalariga (http://bit.ly/3257bv4) ko'ra, HashiCorp kelajakda ushbu imkoniyatni qo'shishni rejalashtirmoqda, shuning uchun siz ushbu kitobni qachon o'qiganingizga qarab, u allaqachon mavjud bo'lishi mumkin. Aniq bilish uchun, .
Nol ishlamay qo'yish cheklovlari
Create_before_destroy blokidan ASG bilan birgalikda foydalanish nol ishlamay qo'yishni yaratish uchun ajoyib yechim bo'lib, bitta ogohlantirish bundan mustasno: avtomatik o'lchov qoidalari qo'llab-quvvatlanmaydi. Aniqroq qilib aytadigan bo'lsak, bu har bir joylashtirishda ASG o'lchamini min_size ga qaytaradi, agar siz ishlaydigan serverlar sonini oshirish uchun avtomatik o'lchov qoidalaridan foydalansangiz, bu muammo bo'lishi mumkin.
Masalan, veb-server-klaster moduli bir juft aws_autoscaling_schedule resurslarini o'z ichiga oladi, ular ertalab soat 9 da klasterdagi serverlar sonini ikkitadan o'nga oshiradi. Agar siz, aytaylik, soat 11:9 da joylashtirsangiz, yangi ASG o'nta emas, faqat ikkita server bilan ishga tushadi va ertasi kuni ertalab soat XNUMX ga qadar shu holatda qoladi.
Ushbu cheklovni bir necha usul bilan chetlab o'tish mumkin.
- aws_autoscaling_schedule dagi takrorlanish parametrini 0 9 * * * (“soat 9:0 da ishga tushirish”) dan 59-9 17-9 * * * (“har daqiqada soat 5:XNUMX dan XNUMX:XNUMX gacha yugurish”)ga o‘zgartiring. Agar ASG allaqachon o'nta serverga ega bo'lsa, ushbu avtomatik o'lchov qoidasini qayta ishga tushirish hech narsani o'zgartirmaydi, bu biz xohlagan narsadir. Ammo agar ASG yaqinda ishga tushirilgan bo'lsa, bu qoida bir daqiqada uning serverlari soni o'ntaga yetishini ta'minlaydi. Bu mutlaqo oqlangan yondashuv emas va o'ndan ikkita serverga va orqaga katta sakrashlar ham foydalanuvchilar uchun muammolarni keltirib chiqarishi mumkin.
- ASG’dagi faol serverlar sonini aniqlash uchun AWS API’dan foydalanadigan maxsus skript yarating, tashqi ma’lumotlar manbasi yordamida unga qo‘ng‘iroq qiling (249-betdagi “Tashqi ma’lumotlar manbai”ga qarang) va ASG’ning istalgan_kapasitet parametrini qaytargan qiymatga o‘rnating. skript. Shunday qilib, har bir yangi ASG namunasi har doim mavjud Terraform kodi bilan bir xil quvvatda ishlaydi va uni saqlashni qiyinlashtiradi.
Albatta, Terraform nol ishlamay qo'yish uchun o'rnatilgan qo'llab-quvvatlashga ega bo'lar edi, ammo 2019 yil may oyidan boshlab HashiCorp jamoasi bu funksiyani qo'shishni rejalashtirmagan ().
To'g'ri reja muvaffaqiyatsiz amalga oshirilishi mumkin
Ba'zan reja buyrug'i to'liq to'g'ri joylashtirish rejasini ishlab chiqaradi, lekin qo'llash buyrug'i xatoni qaytaradi. Masalan, 2-bobda avval yaratgan IAM foydalanuvchisi uchun ishlatgan nom bilan aws_iam_user resursini qo‘shib ko‘ring:
resource "aws_iam_user" "existing_user" {
# Подставьте сюда имя уже существующего пользователя IAM,
# чтобы попрактиковаться в использовании команды terraform import
name = "yevgeniy.brikman"
}Endi, agar siz reja buyrug'ini ishlatsangiz, Terraform o'rtacha ko'rinadigan joylashtirish rejasini chiqaradi:
Terraform will perform the following actions:
# aws_iam_user.existing_user will be created
+ resource "aws_iam_user" "existing_user" {
+ arn = (known after apply)
+ force_destroy = false
+ id = (known after apply)
+ name = "yevgeniy.brikman"
+ path = "/"
+ unique_id = (known after apply)
}
Plan: 1 to add, 0 to change, 0 to destroy.Qo'llash buyrug'ini ishga tushirsangiz, quyidagi xatoni olasiz:
Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.
on main.tf line 10, in resource "aws_iam_user" "existing_user":
10: resource "aws_iam_user" "existing_user" {Muammo shundaki, bu nomga ega IAM foydalanuvchisi allaqachon mavjud. Va bu nafaqat IAM foydalanuvchilarida, balki deyarli har qanday manbada sodir bo'lishi mumkin. Kimdir bu resursni qo'lda yoki buyruq qatori yordamida yaratgan bo'lishi mumkin, ammo har qanday holatda ham identifikatorlarning mos kelishi nizolarga olib keladi. Ushbu xatoning ko'plab variantlari mavjud bo'lib, ular ko'pincha Terraformga yangi kelganlarni hayratda qoldiradilar.
Asosiy nuqta shundaki, terraform rejasi buyrug'i faqat Terraform davlat faylida ko'rsatilgan resurslarni hisobga oladi. Agar resurslar boshqa yo'l bilan yaratilgan bo'lsa (masalan, AWS konsolida bosish orqali qo'lda), ular davlat faylida tugamaydi va shuning uchun Terraform reja buyrug'ini bajarishda ularni hisobga olmaydi. Natijada, bir qarashda to'g'ri ko'rinadigan reja muvaffaqiyatsiz bo'ladi.
Bundan ikkita saboq olish kerak.
- Agar siz allaqachon Terraform bilan ishlashni boshlagan bo'lsangiz, boshqa hech narsa ishlatmang. Agar infratuzilmangizning bir qismi Terraform yordamida boshqarilsa, uni endi qo‘lda o‘zgartira olmaysiz. Aks holda, siz nafaqat g'alati Terraform xatolarini xavf ostiga qo'yasiz, balki IaC-ning ko'pgina afzalliklarini ham inkor etasiz, chunki kod endi sizning infratuzilmangizning aniq ifodasi bo'lmaydi.
- Agar sizda allaqachon infratuzilma mavjud bo'lsa, import buyrug'idan foydalaning. Agar siz Terraform-dan mavjud infratuzilma bilan foydalanishni boshlayotgan bo'lsangiz, uni terraform import buyrug'i yordamida davlat fayliga qo'shishingiz mumkin. Shunday qilib, Terraform qanday infratuzilmani boshqarish kerakligini bilib oladi. Import buyrug'i ikkita argumentni oladi. Birinchisi, konfiguratsiya fayllaringizdagi manba manzili. Bu yerdagi sintaksis resurs havolalari bilan bir xil: _. (masalan, aws_iam_user.existing_user). Ikkinchi argument import qilinadigan resursning identifikatoridir. Aytaylik, aws_iam_user resurs identifikatori foydalanuvchi nomi (masalan, yevgeniy.brikman) va aws_instance resurs identifikatori EC2 server identifikatori (masalan, i-190e22e5). Resursni qanday import qilish odatda sahifaning pastki qismidagi hujjatlarda ko'rsatilgan.
Quyida siz Terraform konfiguratsiyasiga qoʻshgan aws_iam_user resursini 2-bobdagi IAM foydalanuvchisi bilan sinxronlashtiradigan import buyrugʻi keltirilgan (albatta yevgeniy.brikman oʻrniga ismingizni qoʻyadi):
$ terraform import aws_iam_user.existing_user yevgeniy.brikmanTerraform sizning IAM foydalanuvchingizni topish va u bilan Terraform konfiguratsiyasidagi aws_iam_user.existing_user resursi o‘rtasida davlat fayl assotsiatsiyasini yaratish uchun AWS API-ga qo‘ng‘iroq qiladi. Bundan buyon, reja buyrug'ini ishga tushirganingizda, Terraform IAM foydalanuvchisi allaqachon mavjudligini bilib oladi va uni qayta yaratishga urinmaydi.
Shuni ta'kidlash kerakki, agar sizda Terraform-ga import qilmoqchi bo'lgan juda ko'p resurslaringiz bo'lsa, kodni qo'lda yozish va har birini bir vaqtning o'zida import qilish qiyinchilik tug'dirishi mumkin. Shunday qilib, AWS hisobingizdan kod va holatni avtomatik ravishda import qila oladigan Terraforming (http://terraforming.dtan4.net/) kabi vositani ko'rib chiqishga arziydi.
Refaktoring o'zining kamchiliklariga ega bo'lishi mumkin
Refaktoring bu dasturlashda keng tarqalgan amaliyot bo'lib, tashqi xatti-harakatni o'zgarishsiz qoldirib, kodning ichki tuzilishini o'zgartirasiz. Bu kodni aniqroq, toza va saqlashni osonlashtirish uchun qilingan. Refaktoring muntazam ravishda qo'llanilishi kerak bo'lgan ajralmas texnikadir. Ammo Terraform yoki boshqa IaC vositasi haqida gap ketganda, siz kodning "tashqi xatti-harakati" deganda nimani nazarda tutayotganingizga juda ehtiyot bo'lishingiz kerak, aks holda kutilmagan muammolar paydo bo'ladi.
Masalan, refaktoringning keng tarqalgan turi o'zgaruvchilar yoki funktsiyalar nomlarini tushunarliroqlari bilan almashtirishdir. Ko'pgina IDE-lar qayta ishlash uchun o'rnatilgan yordamga ega va loyiha davomida o'zgaruvchilar va funktsiyalarni avtomatik ravishda qayta nomlashlari mumkin. Umumiy maqsadli dasturlash tillarida bu siz o'ylamasligingiz mumkin bo'lgan arzimas protsedura, lekin Terraformda bu bilan juda ehtiyot bo'lishingiz kerak, aks holda siz uzilishlarga duch kelishingiz mumkin.
Masalan, veb-server-klaster modulida cluster_name kiritish o'zgaruvchisi mavjud:
variable "cluster_name" { description = "The name to use for all the cluster resources" type = string }Tasavvur qiling-a, siz ushbu moduldan foo deb nomlangan mikroservisni o'rnatish uchun foydalanishni boshladingiz. Keyinchalik, siz xizmat nomini barga o'zgartirmoqchisiz. Bu o'zgarish ahamiyatsiz bo'lib tuyulishi mumkin, lekin aslida u xizmatda uzilishlarga olib kelishi mumkin.
Gap shundaki, veb-server-klaster moduli cluster_name o'zgaruvchisidan bir qator resurslarda, jumladan ikkita xavfsizlik guruhining nom parametri va ALBda foydalanadi:
resource "aws_lb" "example" { name = var.cluster_name load_balancer_type = "application" subnets = data.aws_subnet_ids.default.ids security_groups = [aws_security_group.alb.id] }Agar siz resursdagi nom parametrini o'zgartirsangiz, Terraform ushbu resursning eski versiyasini o'chiradi va uning o'rniga yangisini yaratadi. Ammo agar bu resurs ALB bo'lsa, uni o'chirish va yangi versiyani yuklab olish o'rtasida sizda trafikni veb-serveringizga yo'naltirish mexanizmi bo'lmaydi. Xuddi shunday, agar xavfsizlik guruhi o'chirilsa, sizning serverlaringiz yangi guruh yaratilmaguncha har qanday tarmoq trafigini rad etishni boshlaydi.
Sizni qiziqtirishi mumkin bo'lgan yana bir refaktoring turi Terraform identifikatorini o'zgartirishdir. Misol tariqasida veb-server-klaster modulidagi aws_security_group resursini olaylik:
resource "aws_security_group" "instance" { # (...) }Ushbu resursning identifikatori instansiya deb ataladi. Tasavvur qiling-a, refaktoring paytida siz uni yanada tushunarli (sizning fikringizcha) cluster_instance nomiga o'zgartirishga qaror qildingiz:
resource "aws_security_group" "cluster_instance" { # (...) }Oxiri nima bo'ladi? To'g'ri: buzilish.
Terraform har bir resurs identifikatorini bulut provayderi identifikatori bilan bog‘laydi. Masalan, iam_user AWS IAM foydalanuvchi identifikatori bilan bog‘langan va aws_instance AWS EC2 server identifikatori bilan bog‘langan. Agar siz resurs identifikatorini o'zgartirsangiz (aytaylik, aws_security_group bilan bo'lgani kabi misoldan cluster_instance ga), Terraformga u eski resursni o'chirib, yangisini qo'shgandek ko'rinadi. Agar siz ushbu o'zgarishlarni qo'llasangiz, Terraform eski xavfsizlik guruhini o'chiradi va yangisini yaratadi, shu bilan birga serverlaringiz har qanday tarmoq trafigini rad etishni boshlaydi.
Mana, ushbu muhokamadan olib tashlashingiz kerak bo'lgan to'rtta asosiy saboq.
- Har doim reja buyrug'idan foydalaning. Bu barcha illatlarni ochib berishi mumkin. Uning chiqishini diqqat bilan ko'rib chiqing va Terraform o'chirilmasligi kerak bo'lgan resurslarni o'chirishni rejalashtirgan holatlarga e'tibor bering.
- O'chirishdan oldin yarating. Agar siz resursni almashtirmoqchi bo'lsangiz, asl nusxani o'chirishdan oldin uning o'rnini yaratishingiz kerakmi yoki yo'qligini yaxshilab o'ylab ko'ring. Agar javob ha bo'lsa, create_before_destroy yordam berishi mumkin. Xuddi shu natijaga ikki bosqichni bajarish orqali qo'lda erishish mumkin: avval konfiguratsiyaga yangi resurs qo'shing va qo'llash buyrug'ini ishga tushiring, so'ngra eski resursni konfiguratsiyadan olib tashlang va yana qo'llash buyrug'idan foydalaning.
- Identifikatorlarni o'zgartirish holatni o'zgartirishni talab qiladi. Agar siz resurs bilan bog'langan identifikatorni o'zgartirmoqchi bo'lsangiz (masalan, aws_security_group nomini misoldan cluster_instancega o'zgartiring), resursni o'chirmasdan va uning yangi versiyasini yaratmasdan, Terraform holat faylini mos ravishda yangilashingiz kerak. Buni hech qachon qo'lda qilmang - buning o'rniga terraform holati buyrug'idan foydalaning. Identifikatorlarning nomini o'zgartirishda siz quyidagi sintaksisga ega bo'lgan terraform state mv buyrug'ini bajarishingiz kerak:
terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>ORIGINAL_REFERENCE — joriy koʻrinishdagi resursga ishora qiluvchi ibora, NEW_REFERENCE esa uni koʻchirmoqchi boʻlgan joy. Masalan, aws_security_group guruhini misoldan cluster_instancega o'zgartirganda, siz quyidagi buyruqni bajarishingiz kerak:
$ terraform state mv aws_security_group.instance aws_security_group.cluster_instanceBu Terraform’ga avval aws_security_group.instance bilan bog‘langan holat endi aws_security_group.cluster_instance bilan bog‘lanishi kerakligini aytadi. Agar ushbu buyruqni qayta nomlash va ishga tushirgandan so'ng, terraform rejasi hech qanday o'zgarishlarni ko'rsatmasa, unda siz hamma narsani to'g'ri bajardingiz.
- Ba'zi sozlamalarni o'zgartirib bo'lmaydi. Ko'pgina resurslarning parametrlari o'zgarmasdir. Agar siz ularni o'zgartirishga harakat qilsangiz, Terraform eski resursni o'chiradi va uning o'rniga yangisini yaratadi. Har bir manba sahifasi odatda ma'lum bir sozlamani o'zgartirganda nima sodir bo'lishini ko'rsatadi, shuning uchun hujjatlarni tekshirishni unutmang. Har doim reja buyrug'idan foydalaning va create_before_destroy strategiyasidan foydalanishni o'ylab ko'ring.
Kechiktirilgan mustahkamlik mos keladi... kechiktirish bilan
AWS kabi ba'zi bulutli provayderlarning API'lari asinxrondir va barqarorlikni kechiktiradi. Asinxroniya interfeys so'ralgan amalni bajarishni kutmasdan darhol javob qaytarishi mumkinligini anglatadi. Kechiktirilgan izchillik o'zgarishlarning butun tizim bo'ylab tarqalishi uchun vaqt talab qilishi mumkinligini anglatadi; bu sodir bo'layotganda, javoblaringiz mos kelmasligi va qaysi ma'lumot manbasi replikasi API qo'ng'iroqlaringizga javob berishiga bog'liq bo'lishi mumkin.
Tasavvur qiling, masalan, siz AWS-ga EC2 serverini yaratishni so'rab API qo'ng'iroq qilasiz. API serverning o'zi yaratilishini kutmasdan deyarli bir zumda "muvaffaqiyatli" javobni (201 yaratilgan) qaytaradi. Agar siz darhol unga ulanishga harakat qilsangiz, u deyarli muvaffaqiyatsiz bo'ladi, chunki o'sha paytda AWS hali ham resurslarni ishga tushirmoqda yoki muqobil ravishda server hali yuklanmagan. Bundan tashqari, agar siz ushbu server haqida ma'lumot olish uchun boshqa qo'ng'iroq qilsangiz, siz xatoga yo'l qo'yishingiz mumkin (404 topilmadi). Gap shundaki, ushbu EC2 serveri haqidagi ma'lumotlar hamma joyda mavjud bo'lgunga qadar AWS bo'ylab tarqalishi mumkin, siz bir necha soniya kutishingiz kerak bo'ladi.
Har doim dangasa konsistensiyaga ega asinxron API dan foydalansangiz, amal tugaguncha va tizim boʻylab tarqalguncha vaqti-vaqti bilan soʻrovingizni qayta urinib koʻrishingiz kerak. Afsuski, AWS SDK buning uchun yaxshi vositalarni taqdim etmaydi va Terraform loyihasi 6813 (https://github.com/hashicorp/terraform/issues/6813) kabi ko'plab xatolardan aziyat chekardi:
$ terraform apply aws_subnet.private-persistence.2: InvalidSubnetID.NotFound: The subnet ID 'subnet-xxxxxxx' does not existBoshqacha qilib aytganda, siz resurs yaratasiz (masalan, quyi tarmoq) va keyin u haqida ma'lumot olishga harakat qilasiz (masalan, yangi yaratilgan pastki tarmoq identifikatori) va Terraform uni topa olmaydi. Ushbu xatolarning aksariyati (jumladan, 6813) tuzatildi, lekin ular hali ham vaqti-vaqti bilan paydo bo'ladi, ayniqsa Terraform yangi resurs turini qo'llab-quvvatlaganida. Bu zerikarli, lekin ko'p hollarda hech qanday zarar keltirmaydi. Terraform ilovasini qayta ishga tushirganingizda, hamma narsa ishlashi kerak, chunki bu vaqtga kelib ma'lumotlar allaqachon butun tizimga tarqalib bo'ladi.
Ushbu parcha Evgeniy Brikmanning kitobidan keltirilgan .
Manba: www.habr.com