Ana içeriğe geç

Update ve Rollback Stratejisi

Bu sayfa, Docker Swarm uzerinde Qapu servislerinin nasil guncellenecegini ve sorun halinde nasil geri alinacagini tanimlar.

Temel Ayrim​

Tum servisler ayni guncelleme stratejisi ile ele alinmaz.

Stateless Servisler​

Ornek:

  • api
  • ingest
  • stream
  • rule
  • action
  • communication
  • automation
  • egress
  • heartbeat

Onerilen davranis:

  • rolling update
  • healthcheck gating
  • start-first update order (uygunsa)
  • on-failure restart policy
  • resource limit tanimi

Stateful Servisler​

Ornek:

  • postgres
  • kafka
  • redis
  • firmware storage'la dogrudan bagli servisler

Onerilen davranis:

  • kontrollu update
  • backup/health precheck
  • gerekiyorsa maintenance window
  • rollback planinin update'ten once hazir olmasi

Healthcheck Onemi​

Docker Swarm rollout davranisinda healthcheck kritik rol oynar.

Qapu deployment icin temel kural:

  • healthcheck olmayan servis, guvenli rolling update adayi sayilmamalidir

Healthcheck kapsami servis tipine gore degisir:

  • api -> HTTP readiness
  • consumer servisleri -> dependency reachability + internal ready state
  • infra servisleri -> kendi native health semantics

Rollback Ilkesi​

Rollback yalniz image tag geri alma degildir.

Bazi servislerde rollback su boyutlari icerebilir:

  • image rollback
  • config rollback
  • secret rotation rollback
  • DB migration geri alma veya forward-fix karari
  • Kafka consumer behavior degisikligi

Onerilen Runbook Basliklari​

Gelecek sertlestirme icin su runbook'lar yazilmalidir:

  • yeni image rollout proseduru
  • acil rollback proseduru
  • manager node drain proseduru
  • worker node bakim proseduru
  • stateful service update checklist'i
  • firmware storage degisimi checklist'i

Sonuc​

Qapu deployment modelinde update ve rollback, yalniz DevOps operasyonu degil, sistem guvenilirliginin parcasidir. Bu nedenle deployment belgeleri ile servis belgeleri ayni gercegin farkli katmanlari olarak ele alinmalidir.