DNS'ни код билан бошқариш: Terraform ва OctoDNS амалиёти

Кўпчилик DNS ёзувларини веб-панел орқали қўлда қўшади: A ёзуви, кейин MX, кейин почта учун SPF ва DKIM. Битта сайт ва битта домен бўлса, бу усул етарли. Лекин доменлар сони ўнтадан ошганда, жамоада бир нечта одам ишлаганда ёки ҳар бир ўзгаришнинг ким томонидан ва нима учун қилинганини билиш керак бўлганда, қўлда бошқариш чалкашликка олиб келади. "DNS as code" ёндашуви зонани матнли файл кўринишида сақлаш, уни Git'да версиялаш ва махсус восита орқали DNS провайдерига автоматик қўллашни англатади.

Нима учун DNS'ни файл кўринишида сақлаш фойдали

Биринчи фойда тарих ва жавобгарликдир. Ҳар бир ўзгариш коммит сифатида сақланади, унда муаллиф, сана ва изоҳ бўлади. Агар эрталаб почта ишламай қолса, кеча MX ёки SPF ёзувига ким тегингани бир қарашда кўринади ва керак бўлса ўзгариш битта буйруқ билан орқага қайтарилади. Панелда эса эски қийматни эслаб қолиш ёки скриншотлардан қидиришга тўғри келади.

Иккинчи фойда текширувдир. Ўзгариш тўғридан-тўғри жонли зонага эмас, аввал pull request кўринишида келади, ҳамкасб уни кўриб чиқади, восита эса айнан қайси ёзувлар қўшилиши, ўзгариши ёки ўчирилишини олдиндан кўрсатади. Учинчи фойда бир хилликдир: ўнта филиал сайти бўлган тармоқ бир хил шаблон асосида ёзувларни олади ва бирортасида "унутилган" DMARC ёки эски IP қолиб кетмайди.

Бу ёндашув кимга мос ва кимга ортиқча

Тошкентдаги кичик қаҳвахона битта домен ва бешта ёзув билан ишласа, Terraform ўрнатиш вақтни беҳуда сарфлаш бўлади. Аммо бир нечта бренд, тест ва production муҳитлари, ўнлаб субдоменлари бўлган интернет-дўкон ёки бир нечта клиника филиалларига хизмат кўрсатадиган IT бўлим учун бу ёндашув тез ўзини оқлайди. Асосий шарт: DNS провайдерингиз API тақдим этиши ёки сиз ўз DNS серверингизни бошқаришингиз керак. API бўлмаса, восита ёзувларни автоматик янгилай олмайди ва сиз барибир панелга қайтасиз.

Агар доменингиз sayt.uz'да бўлса, NS серверларни кабинет орқали исталган DNS хизматига йўналтириш мумкин. Шу тариқа домен рўйхати ва тўловлар кабинетда қолади, зона эса код орқали бошқариладиган DNS серверда яшайди.

Terraform билан DNS ёзувлари

Terraform инфратузилмани декларатив тарзда тасвирлайди: сиз "қандай ҳолат бўлиши керак"лигини ёзасиз, восита эса жорий ҳолат билан солиштириб, фарқни қўллайди. DNS учун турли провайдерларнинг плагинлари бор. Қуйидаги мисолда универсал hashicorp/dns провайдери ишлатилган, у RFC 2136 динамик янгиланишлари орқали ўзингиз бошқарадиган BIND каби серверга уланади. Калит TSIG орқали текширилади.

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."
  }
}

Иш жараёни уч буйруқдан иборат. terraform init плагинларни юклайди, terraform plan нима ўзгаришини кўрсатади, terraform apply эса тасдиқдан кейин ўзгаришни қўллайди. План натижасини ҳар доим диққат билан ўқинг: агар унда кутилмаган "destroy" қатори бўлса, демак кимдир қўлда ёзув қўшган ёки файлдаги ном хато ёзилган.

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

OctoDNS: зонани YAML файл сифатида сақлаш

OctoDNS фақат DNS учун яратилган восита бўлиб, зонани оддий YAML файлда сақлайди ва уни бир ёки бир нечта провайдерга синхронлайди. У айниқса битта зонани бир вақтда иккита DNS провайдерида юритиш, яъни захира DNS қуриш учун қулай. Конфигурация файли манба ва мақсадни белгилайди:

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

Зона файли zones/example.uz.yaml эса ёзувларни ўқишга қулай кўринишда сақлайди. Бўш калит доменнинг ўзини, яъни apex қисмини билдиради:

---
'':
  - 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 буйруғи сукут бўйича фақат синов режимида ишлайди ва ўзгаришлар рўйхатини чиқаради. Ҳақиқий қўллаш учун охирига --doit қўшилади. Бу ҳимоя механизми тасодифий ўчиришларнинг олдини олади.

Мавжуд зонани кодга кўчириш

Энг хавфли босқич бошланғич кўчиришдир. Агар файлда мавжуд ёзувлардан бирортаси бўлмаса, восита уни "ортиқча" деб ҳисоблаб ўчириши мумкин. Шунинг учун аввал жорий зонани тўлиқ экспорт қилинг, ҳар бир ёзувни файлга ўтказинг ва биринчи план ёки dry-run натижасида ҳеч қандай ўзгариш бўлмаслигига эришинг. Terraform'да мавжуд ёзувлар terraform import ёки import блоклари орқали ҳолатга қўшилади, OctoDNS'да эса octodns-dump буйруғи провайдердаги зонани YAML файлга ёзиб беради.

Мисол: Самарқанддаги ўқув марказининг IT мутахассиси 40 та ёзувли зонани кўчиришда аввал dump олди, кейин файлни тозалади ва план "0 to add, 0 to change, 0 to destroy" кўрсатгандан кейингина биринчи ҳақиқий ўзгаришни киритди. Шу тартиб туфайли почта ва сайт бир дақиқа ҳам узилмади.

Сирлар, ҳолат файли ва қўлда таҳрирлаш

API токенлари ва TSIG калитларини ҳеч қачон Git'га ёзманг, уларни муҳит ўзгарувчилари ёки CI тизимининг махфий созламалари орқали узатинг. Terraform ҳолат файли, яъни terraform.tfstate, махфий қийматларни очиқ сақлаши мумкин, шунинг учун у ҳам репозиторийга қўшилмайди ва ҳимояланган жойда туради. Бундан ташқари, код орқали бошқариладиган зонани панелда қўлда таҳрирлашни жамоада тақиқлаб қўйинг: навбатдаги apply бундай ўзгаришни жимгина бекор қилади ва бу кўпинча кутилмаган носозликка айланади.

TTL қийматларига ҳам эътибор беринг. Катта кўчириш ёки IP алмаштиришдан бир кун олдин муҳим ёзувларнинг TTL'ини 300 сонияга тушириб қўйиш, хато бўлганда тез қайтиш имконини беради. Иш тугагач, TTL яна бир соат ёки ундан кўпроққа қайтарилади.

CI орқали автоматлаштириш

Энг қулай схема шундай ишлайди: ҳар бир pull request'да CI автоматик равишда план ёки dry-run ишга туширади ва натижани изоҳ сифатида қолдиради. Асосий branch'га бирлаштирилгандан кейин эса apply бажарилади. Шу тарзда ҳеч ким жонли зонага тўғридан-тўғри тегмайди, ҳар бир ўзгариш икки жуфт кўздан ўтади ва керак бўлса олдинги коммитни қайтариш орқали зонани аввалги ҳолатига келтириш мумкин. Кичик жамоалар учун ҳам бу схема бир кунлик созлаш билан ишга тушади ва кейинги йиллар давомида вақтни тежайди.