DNS'ni kod bilan boshqarish: Terraform va OctoDNS amaliyoti

Ko'pchilik DNS yozuvlarini veb-panel orqali qo'lda qo'shadi: A yozuvi, keyin MX, keyin pochta uchun SPF va DKIM. Bitta sayt va bitta domen bo'lsa, bu usul yetarli. Lekin domenlar soni o'ntadan oshganda, jamoada bir nechta odam ishlaganda yoki har bir o'zgarishning kim tomonidan va nima uchun qilinganini bilish kerak bo'lganda, qo'lda boshqarish chalkashlikka olib keladi. "DNS as code" yondashuvi zonani matnli fayl ko'rinishida saqlash, uni Git'da versiyalash va maxsus vosita orqali DNS provayderiga avtomatik qo'llashni anglatadi.

Nima uchun DNS'ni fayl ko'rinishida saqlash foydali

Birinchi foyda tarix va javobgarlikdir. Har bir o'zgarish commit sifatida saqlanadi, unda muallif, sana va izoh bo'ladi. Agar ertalab pochta ishlamay qolsa, kecha MX yoki SPF yozuviga kim tegingani bir qarashda ko'rinadi va kerak bo'lsa o'zgarish bitta buyruq bilan orqaga qaytariladi. Panelda esa eski qiymatni eslab qolish yoki skrinshotlardan qidirishga to'g'ri keladi.

Ikkinchi foyda tekshiruvdir. O'zgarish to'g'ridan-to'g'ri jonli zonaga emas, avval pull request ko'rinishida keladi, hamkasb uni ko'rib chiqadi, vosita esa aynan qaysi yozuvlar qo'shilishi, o'zgarishi yoki o'chirilishini oldindan ko'rsatadi. Uchinchi foyda bir xillikdir: o'nta filial sayti bo'lgan tarmoq bir xil shablon asosida yozuvlarni oladi va birortasida "unutilgan" DMARC yoki eski IP qolib ketmaydi.

Bu yondashuv kimga mos va kimga ortiqcha

Toshkentdagi kichik qahvaxona bitta domen va beshta yozuv bilan ishlasa, Terraform o'rnatish vaqtni behuda sarflash bo'ladi. Ammo bir nechta brend, test va production muhitlari, o'nlab subdomenlari bo'lgan internet-do'kon yoki bir nechta klinika filiallariga xizmat ko'rsatadigan IT bo'lim uchun bu yondashuv tez o'zini oqlaydi. Asosiy shart: DNS provayderingiz API taqdim etishi yoki siz o'z DNS serveringizni boshqarishingiz kerak. API bo'lmasa, vosita yozuvlarni avtomatik yangilay olmaydi va siz baribir panelga qaytasiz.

Agar domeningiz sayt.uz'da bo'lsa, NS serverlarni kabinet orqali istalgan DNS xizmatiga yo'naltirish mumkin. Shu tariqa domen ro'yxati va to'lovlar kabinetda qoladi, zona esa kod orqali boshqariladigan DNS serverda yashaydi.

Terraform bilan DNS yozuvlari

Terraform infratuzilmani deklarativ tarzda tasvirlaydi: siz "qanday holat bo'lishi kerak"ligini yozasiz, vosita esa joriy holat bilan solishtirib, farqni qo'llaydi. DNS uchun turli provayderlarning plaginlari bor. Quyidagi misolda universal hashicorp/dns provayderi ishlatilgan, u RFC 2136 dinamik yangilanishlari orqali o'zingiz boshqaradigan BIND kabi serverga ulanadi. Kalit TSIG orqali tekshiriladi.

terraform {
  required_providers {
    dns = {
      source  = "hashicorp/dns"
      version = "~> 3.4"
    }
  }
}

provider "dns" {
  update {
    server        = "192.0.2.53"
    key_name      = "terraform-key."
    key_algorithm = "hmac-sha256"
    key_secret    = var.tsig_secret
  }
}

resource "dns_a_record_set" "www" {
  zone      = "example.uz."
  name      = "www"
  addresses = ["203.0.113.10"]
  ttl       = 3600
}

resource "dns_mx_record_set" "mail" {
  zone = "example.uz."
  ttl  = 3600
  mx {
    preference = 10
    exchange   = "mail.example.uz."
  }
}

Ish jarayoni uch buyruqdan iborat. terraform init plaginlarni yuklaydi, terraform plan nima o'zgarishini ko'rsatadi, terraform apply esa tasdiqdan keyin o'zgarishni qo'llaydi. Plan natijasini har doim diqqat bilan o'qing: agar unda kutilmagan "destroy" qatori bo'lsa, demak kimdir qo'lda yozuv qo'shgan yoki fayldagi nom xato yozilgan.

terraform init
terraform plan -out=dns.plan
terraform apply dns.plan

OctoDNS: zonani YAML fayl sifatida saqlash

OctoDNS faqat DNS uchun yaratilgan vosita bo'lib, zonani oddiy YAML faylda saqlaydi va uni bir yoki bir nechta provayderga sinxronlaydi. U ayniqsa bitta zonani bir vaqtda ikkita DNS provayderida yuritish, ya'ni zaxira DNS qurish uchun qulay. Konfiguratsiya fayli manba va maqsadni belgilaydi:

providers:
  config:
    class: octodns.provider.yaml.YamlProvider
    directory: ./zones
  cloudflare:
    class: octodns_cloudflare.CloudflareProvider
    token: env/CLOUDFLARE_TOKEN

zones:
  example.uz.:
    sources:
      - config
    targets:
      - cloudflare

Zona fayli zones/example.uz.yaml esa yozuvlarni o'qishga qulay ko'rinishda saqlaydi. Bo'sh kalit domenning o'zini, ya'ni apex qismini bildiradi:

---
'':
  - type: A
    value: 203.0.113.10
  - type: MX
    values:
      - exchange: mail.example.uz.
        preference: 10
www:
  type: CNAME
  value: example.uz.

octodns-sync --config-file=config/production.yaml buyrug'i sukut bo'yicha faqat sinov rejimida ishlaydi va o'zgarishlar ro'yxatini chiqaradi. Haqiqiy qo'llash uchun oxiriga --doit qo'shiladi. Bu himoya mexanizmi tasodifiy o'chirishlarning oldini oladi.

Mavjud zonani kodga ko'chirish

Eng xavfli bosqich boshlang'ich ko'chirishdir. Agar faylda mavjud yozuvlardan birortasi bo'lmasa, vosita uni "ortiqcha" deb hisoblab o'chirishi mumkin. Shuning uchun avval joriy zonani to'liq eksport qiling, har bir yozuvni faylga o'tkazing va birinchi plan yoki dry-run natijasida hech qanday o'zgarish bo'lmasligiga erishing. Terraform'da mavjud yozuvlar terraform import yoki import bloklari orqali holatga qo'shiladi, OctoDNS'da esa octodns-dump buyrug'i provayderdagi zonani YAML faylga yozib beradi.

Misol: Samarqanddagi o'quv markazining IT mutaxassisi 40 ta yozuvli zonani ko'chirishda avval dump oldi, keyin faylni tozaladi va plan "0 to add, 0 to change, 0 to destroy" ko'rsatgandan keyingina birinchi haqiqiy o'zgarishni kiritdi. Shu tartib tufayli pochta va sayt bir daqiqa ham uzilmadi.

Sirlar, holat fayli va qo'lda tahrirlash

API tokenlari va TSIG kalitlarini hech qachon Git'ga yozmang, ularni muhit o'zgaruvchilari yoki CI tizimining maxfiy sozlamalari orqali uzating. Terraform holat fayli, ya'ni terraform.tfstate, maxfiy qiymatlarni ochiq saqlashi mumkin, shuning uchun u ham repozitoriyga qo'shilmaydi va himoyalangan joyda turadi. Bundan tashqari, kod orqali boshqariladigan zonani panelda qo'lda tahrirlashni jamoada taqiqlab qo'ying: navbatdagi apply bunday o'zgarishni jimgina bekor qiladi va bu ko'pincha kutilmagan nosozlikka aylanadi.

TTL qiymatlariga ham e'tibor bering. Katta ko'chirish yoki IP almashtirishdan bir kun oldin muhim yozuvlarning TTL'ini 300 soniyaga tushirib qo'yish, xato bo'lganda tez qaytish imkonini beradi. Ish tugagach, TTL yana bir soat yoki undan ko'proqqa qaytariladi.

CI orqali avtomatlashtirish

Eng qulay sxema shunday ishlaydi: har bir pull request'da CI avtomatik ravishda plan yoki dry-run ishga tushiradi va natijani izoh sifatida qoldiradi. Asosiy branch'ga birlashtirilgandan keyin esa apply bajariladi. Shu tarzda hech kim jonli zonaga to'g'ridan-to'g'ri tegmaydi, har bir o'zgarish ikki juft ko'zdan o'tadi va kerak bo'lsa oldingi commit'ni qaytarish orqali zonani avvalgi holatiga keltirish mumkin. Kichik jamoalar uchun ham bu sxema bir kunlik sozlash bilan ishga tushadi va keyingi yillar davomida vaqtni tejaydi.