Terraform modullari: qayta ishlatiladigan infratuzilmani tuzish

Qisqa javob

Terraform’da modul — bu shunchaki .tf fayllari bor papka. Har qanday konfiguratsiya allaqachon ildiz modul, qayta ishlatiladigan modullar esa module bloki bilan chaqiriladigan papkalardir.

Yaxshi modul:

• bitta yaxlit narsani tavsiflaydi: tarmoq, zaxira nusxalari bilan ma’lumotlar bazasi, balanslovchi bilan servis;
• oqilona standart qiymatlarga ega bir nechta tiplangan kirishlarni qabul qiladi;
• stekning boshqa qismlariga haqiqatan kerak bo‘lgan outputs’ni qaytaradi;
• versiyalanadi, shunda muhitlar tasodifan emas, ongli ravishda yangilanadi.

Muhitlar (dev, staging, prod) — bir xil modullarni turli qiymatlar bilan chaqiradigan va alohida state saqlaydigan yupqa ildiz konfiguratsiyalari.

Kirishlar, chiqishlar va modul shartnomasi

# modules/postgres/variables.tf
variable "name" {
  type        = string
  description = "Instance name prefix"
}

variable "instance_size" {
  type    = string
  default = "small"
}

variable "backup_retention_days" {
  type    = number
  default = 7
  validation {
    condition     = var.backup_retention_days >= 1
    error_message = "Retention must be at least one day."
  }
}

# modules/postgres/outputs.tf
output "endpoint" {
  value = aws_db_instance.this.address
}

output "password_secret_arn" {
  value     = aws_secretsmanager_secret.db.arn
  sensitive = true
}

O‘zgaruvchilar va chiqishlarga ommaviy API sifatida qarang:

• type va description’ni ko‘rsating; xato qilish oson bo‘lgan qiymatlar uchun validation qo‘shing.
• Maydonlarni bitta object-o‘zgaruvchiga faqat ular haqiqatan bog‘liq bo‘lsa birlashtiring.
• Sirlarni sensitive = true deb belgilang va ular baribir state’ga tushishini unutmang, shuning uchun state backend’ini himoyalang.
• Qayta ishlatiladigan modullar ichida provider bloklarini e’lon qilmang — provayderlarni chaqiruvchi tomon uzatsin.

Versiyalash

Modulni Git repozitoriydan yoki registry’dan chaqirganda versiyani mahkamlash mumkin:

module "db" {
  source = "git::https://github.com/acme/terraform-modules.git//postgres?ref=v1.3.0"

  name                  = "shop-prod"
  instance_size         = "large"
  backup_retention_days = 14
}

• Relizlarni semantik versiyalar bilan belgilang: kirishlar yoki resurs manzillaridagi buzuvchi o‘zgarishlar — yangi major versiya.
• Avval dev’ni, keyin staging’ni, so‘ng prod’ni yangilang va har safar terraform plan’ni o‘qing.
• Modul ichida resurslarni qayta nomlaganda moved bloklarini qo‘shing, shunda Terraform resurslarni qayta yaratmay, manzillarni yangilaydi.
• Provayder versiyalarini required_providers’da mahkamlang va lock-faylni commit qiling.

Repozitoriyning oqilona tuzilmasi

infra/
  modules/
    network/
    postgres/
    app-service/
  envs/
    dev/
      main.tf
      backend.tf
      terraform.tfvars
    staging/
    prod/

• envs/ ichidagi har bir papka o‘z state’i va backend sozlamalariga ega alohida ildiz. Dev’dagi xato production state’iga tegmaydi.
• Muhitlar orasidagi farqlar nusxalangan resurslarda emas, o‘zgaruvchilarda yashaydi.
• Plan sekin yoki xavfli bo‘lib qolsa, katta muhitlarni bir nechta stekka (tarmoq, ma’lumotlar, ilovalar) ajrating. Ular orasida qiymatlarni outputs va data sources orqali uzating.
• Workspaces deyarli bir xil muhitlar uchun mos, ammo alohida papkalar farqlarni yaqqolroq ko‘rsatadi va kirishni cheklashni osonlashtiradi.

Registry modullaridan xavfsiz foydalanish

Ommaviy modullar vaqtni tejaydi, lekin siz begona kodni o‘z bulut kirish ma’lumotlaringiz bilan ishga tushirasiz.

• Faol issue va relizlarga ega tasdiqlangan yoki faol qo‘llab-quvvatlanadigan mualliflarning modullarini tanlang.
• Har doim aniq versiyani mahkamlang, eng so‘nggisiga tayanmang.
• Manba kodini va plan’ni o‘qing: modul qanday resurslar va IAM huquqlarini yaratadi?
• Standart qiymatlarni tekshiring, ayniqsa shifrlash, ommaviy kirish va loglashni.
• Muhim infratuzilma uchun modulni tashkilotingizda fork yoki ko‘zgu qilishni o‘ylab ko‘ring.

Anti-patternlar

• Haddan tashqari abstrakt modullar: istalgan narsani yarata oladigan, o‘nlab flaglarga ega «universal» modul. Uni oddiy resurslardan ko‘ra o‘qish qiyinroq, har bir o‘zgarish esa barcha foydalanuvchilarga ta’sir qilishi mumkin.
• Bitta resursning argumentlarini shunchaki qayta nomlab, hech narsa qo‘shmaydigan o‘ram-modullar.
• Chuqur ichma-ichlik: bir necha daraja pastga modul chaqiradigan modullar plan’ni tushunarsiz qiladi.
• Vaqt o‘tib bir-biridan uzoqlashadigan nusxalangan muhitlar.
• Qayta ishlatiladigan modul ichidagi region, akkaunt ID yoki CIDR kabi qattiq yozilgan qiymatlar.
• Hamma narsa uchun bitta ulkan state, natijada har bir apply butun kompaniyaga tegadi.

Yaxshi qoida: modulning kamida ikkita haqiqiy qo‘llanilishi bo‘lganda yoki u hamma joyda bir xil bajarilishi kerak bo‘lgan standartni mustahkamlaganda yozing.