Handler

Handler — configuration management playbook’ida boshqa task real o‘zgarish qilganda notification orqali ishga tushadigan maxsus task. U service restart, configuration reload, cache rebuild yoki daemon reconfiguration kabi o‘zgarishga bog‘liq amallarni keraksiz takrorlamaslik uchun ishlatiladi. Task changed=false bo‘lsa handler odatda chaqirilmaydi.

Notification modeli

Config template taski fayl mazmuni o‘zgarganda notify yuboradi. Handler nom yoki topic bo‘yicha notificationni qabul qiladi. Bir nechta task bir handlerni notify qilsa, u play yakunida odatda bir marta bajariladi.

tasks:
  - name: <a href="/wiki/nginx" target="_blank" rel="noopener" class="wiki-auto-link">Nginx</a> konfiguratsiyasini yozish
    <a href="/wiki/template" target="_blank" rel="noopener" class="wiki-auto-link">template</a>:
      src: nginx.conf.j2
      dest: /etc/<a href="/wiki/nginx" target="_blank" rel="noopener" class="wiki-auto-link">nginx</a>/nginx.conf
    notify: <a href="/wiki/nginx" target="_blank" rel="noopener" class="wiki-auto-link">Nginx</a> reload

handlers:
  - name: <a href="/wiki/nginx" target="_blank" rel="noopener" class="wiki-auto-link">Nginx</a> reload
    <a href="/wiki/service" target="_blank" rel="noopener" class="wiki-auto-link">service</a>:
      name: <a href="/wiki/nginx" target="_blank" rel="noopener" class="wiki-auto-link">nginx</a>
      <a href="/wiki/state" target="_blank" rel="noopener" class="wiki-auto-link">state</a>: reloaded

Bu tuzilma har run’da service’ni reload qilmaydi, faqat fayl diff bo‘lganda bajaradi.

Deduplication

Notificationlar handler nomi bo‘yicha yig‘iladi. O‘n template bir xil reloadni chaqirsa bitta reload yetadi. Bu uzilish va resource sarfini kamaytiradi. Handler loop yoki turli argument bilan har item uchun bajarilishi kerak bo‘lsa deduplication semantikasi alohida ko‘riladi.

Listen topic bir nechta handlerga umumiy notification olish imkonini beradi. Masalan, web stack changed topic’i config reload va monitoring annotation handlerlarini ishga tushirishi mumkin.

Bajarilish vaqti

Handler odatda play tasklari tugagach ishlaydi. Keyingi task yangi config bilan ishlayotgan service’ga bog‘liq bo‘lsa handlerlar oldinroq flush qilinadi. Juda erta flush ko‘p restart, juda kech flush esa eski config bilan davom etish muammosini yaratadi.

Vaqt	Natija
Play oxiri	Notificationlar birlashtiriladi
Explicit flush	Dependency boundary’da darhol ishlaydi
Role yoki play almashishi	Vosita qoidasi bo‘yicha handler bosqichi

Bajarilish tartibi handler definition yoki notification tartibiga bog‘liq bo‘lishi mumkin; dependency aniq bo‘lsa bitta orchestration handler yoki alohida play ishlatiladi.

Reload va restart

Reload processni to‘xtatmasdan konfiguratsiyani qayta o‘qishi mumkin. Restart processni qayta yaratadi va qisqa uzilish keltiradi. Service haqiqatan reload’ni qo‘llashi va barcha sozlama reload bo‘lishi tekshiriladi; ayrim field faqat restartda o‘zgaradi.

Rolling clusterda barcha node bir vaqtda restart qilinmaydi. Serial batch, health check va load balancer drain bilan handler navbatma-navbat ishlaydi. Oddiy handler semantikasi cluster quorumini o‘zicha bilmaydi.

Validatsiya

Config fayl yozilgach handlerdan oldin syntax validation bajariladi. Nginx config testi, SSH daemon config test yoki application dry-run xato bo‘lsa play to‘xtaydi va ishlayotgan service noto‘g‘ri fayl bilan restart qilinmaydi.

Atomic file write eski to‘g‘ri faylni qisman yozilishdan himoya qiladi. Validatsiyadan keyin reload, so‘ng port va health endpoint tekshiriladi. Command success service funksional ekanini isbotlamaydi.

Failure

Task play oxiriga yetmasdan fatal xato bersa oldin notify qilingan handler default holatda bajarilmasligi mumkin. Bu yangi fayl yozilgan, lekin service reload bo‘lmagan qisman holatni qoldiradi. Force-handlers kabi rejim mavjud, ammo xatodan keyin restart xavfsizmi degan savol alohida.

Critical change transactionga o‘xshash block, backup va recovery bilan tuziladi. Handler failure log, host va service status bilan aniq ko‘rsatiladi.

Changed status sifati

Handler to‘g‘ri ishlashi notifier taskning changed statusiga bog‘liq. Har run changed qaytaradigan shell task doim restart qiladi; real diffni aniqlaydigan modul afzal. Aksincha noto‘g‘ri changed=false zarur reloadni o‘tkazib yuboradi.

Notification nomi refactorda o‘zgarsa chaqiruvchi tasklar va handler birga yangilanadi. Topic-based listen couplingni kamaytirishi mumkin, lekin bir topic’ga ortiqcha side effectlarni yig‘maslik kerak.

Bog‘liq tushunchalar

Playbook, Task, Notification, Service reload, Idempotency, Configuration validation, Rolling update