Ana içeriğe geç

Stateful Servis Stratejisi

Bu sayfa, Docker Swarm icinde stateful servislerin nasil ele alinmasi gerektigini anlatir.

Neden Ayrik Strateji Gerekli?​

Stateful servisler, stateless app servisleri gibi replica sayisini arttirip gecilebilecek bilesenler degildir.

Temel farklar:

  • disk ve volume bagimliligi vardir
  • node affinity ister
  • backup/restore ihtiyaci vardir
  • failure senaryolari daha hassastir
  • upgrade/rollback stratejisi daha kontrollu olmalidir

PostgreSQL​

PostgreSQL, Qapu icin authoritative source katmanidir ve benimsenen deployment kararina gore Swarm icinde calisacaktir.

Bu nedenle PostgreSQL icin temel model:

  • tek authoritative primary instance
  • persistent volume
  • pinned node placement
  • backup ve restore disiplini

Onerilen ilk deployment modeli:

  • kontrollu persistent volume + node affinity ile tek authoritative instance
  • production buyudugunde backup, PITR ve failover stratejisi ayri sertlestirilmeli

Kritik not:

  • PostgreSQL icin ilk asamada yalanci HA yerine guvenli single-primary tercih edilir
  • rollback kadar restore drill de deployment contract'in parcasi olmalidir

Redis​

Redis Qapu'da authoritative source degildir ve deployment kararina gore Swarm icinde calisacaktir.

Bu durum deployment esnekligi verir. Ancak yine de dikkat edilmesi gerekenler vardir:

  • cache olarak kullaniliyorsa veri kaybi daha tolere edilebilir
  • runtime state kullanildigi icin restart/kayip sonrasi rebuild davranisi dokumante edilmelidir
  • persistence acik mi kapali mi, use-case'e gore karar verilmelidir

Onerilen yaklasim:

  • Redis persistent olsa bile disposable/rebuildable zihniyetle ele alinir
  • Redis kaybi sistemin authoritative truth'unu bozmaz, fakat rebuild davranisi deployment ve operasyon belgelerinde acik yazilir

Kafka​

Kafka event tasima omurgasidir ve deployment kararina gore Swarm icinde calisacaktir.

Swarm icinde Kafka calistirmak mumkundur ama hassastir. Dikkat edilmesi gerekenler:

  • broker identity
  • advertised listeners
  • disk placement
  • replication factor
  • partition strategy
  • restart ve rolling update davranisi

Onerilen model:

  • 3 broker
  • her broker icin ayri kimlik
  • her broker icin ayri volume veya host path
  • her broker icin deterministic placement

Bu nedenle Kafka deployment'i "replicas: 3" seviyesinde dusunulmez; broker broker topology olarak ele alinmalidir.

Firmware File Storage​

FOTA delivery katmani icin firmware artefact storage deployment mimarisinin kritik parcasi haline gelir ve bu katman da Swarm deployment modelinin parcasi olarak dusunulur.

Temel secenekler:

  • local disk
  • shared volume
  • NFS benzeri ag depolama
  • object storage + FTP serving bridge

Burada karar yalniz storage maliyeti ile degil, su basliklarla verilmelidir:

  • path determinism
  • file consistency
  • backup/restore
  • node failover
  • Telit uyumlulugu

Onerilen ilk zihinsel model:

  • FOTA/FTP serving katmani deterministic node placement alir
  • storage local veya shared olabilir, ancak artifact path kararliligi deployment contract ile sabitlenir

Temel Kural​

Qapu deployment mimarisinde stateful servisler icin su soru her zaman sorulmalidir:

  • bu servisin gercek dogrulugu disk ve node kimligine ne kadar bagli?

Bu sorunun cevabi ne kadar yuksekse, Swarm deployment contract'i o kadar dikkatli yazilmalidir.

Qapu icin kesinlesen deployment ilkesi sunudur:

  • PostgreSQL, Redis ve Kafka da Docker Swarm icinde calisacaktir
  • ancak stateful-on-swarm modeli yalniz deterministic placement, acik storage stratejisi ve operasyon runbook'u ile kabul edilebilir sayilir