Ana içeriğe geç

Overlay Network ve Trafik Modeli

Bu sayfa, Qapu servislerinin Docker Swarm icinde hangi network segmentlerinde calisacagini ve trafik akislarinin nasil ayrilacagini tanimlar.

Neden Network Ayrimi?​

Tek overlay network ile her seyi ayni duzlemde birakmak kolaydir ama production'da risklidir.

Network ayrimi sunlari saglar:

  • gereksiz dogrudan erisimi azaltir
  • servis sinirlarini daha gorunur hale getirir
  • edge-facing ve internal servisleri ayirir
  • stateful data plane'i daha kontrollu hale getirir

Onerilen Networkler​

qapu-public​

Bu network, dis trafik alan edge servisler icindir.

Tipik uyeler:

  • reverse proxy
  • api (gerekiyorsa)

qapu-app​

Bu network, stateless application servisleri arasindaki ana servis trafigi icindir.

Tipik uyeler:

  • api
  • ingest
  • stream
  • calibration
  • raw-writer
  • synthesis
  • window
  • rule
  • action
  • communication
  • observer
  • automation
  • egress
  • heartbeat

qapu-data​

Bu network, data infrastructure servisleri ile uygulama servisleri arasindaki kontrollu iletisim icindir.

Tipik uyeler:

  • postgres
  • redis
  • kafka
  • secili app servisleri

qapu-storage​

Bu network, stateful storage access veya firmware artifact serving katmanlari icin kullanilir.

Tipik uyeler:

  • fota/ftp serving katmani
  • firmware storage'a erisen servisler
  • gerekiyorsa secili backup/restore araclari

qapu-ops​

Bu network, metrics, logs, backup, admin tooling gibi operasyon servisleri icindir.

Tipik uyeler:

  • metrics/log agent'lari
  • backup job'lari
  • admin tooling

Temel Kural​

Bir servis yalniz ihtiyac duydugu network'e baglanmalidir.

Ornek:

  • api -> qapu-public, qapu-app, gerektiginde qapu-data
  • rule -> qapu-app, qapu-data
  • postgres -> yalniz qapu-data
  • reverse proxy -> qapu-public

Ingress ve East-West Trafik Ayrimi​

North-South Trafik​

Disaridan gelen trafik:

  • client -> reverse proxy -> api

East-West Trafik​

Cluster icindeki servisler arasi trafik:

  • api -> app services
  • app services -> redis/postgres/kafka
  • event consumer/producer akislari

Bu iki trafik modeli ayri dusunulmelidir.

FOTA ve Dosya Dagitimi Notu​

Firmware file delivery plain FTP ile yapilacaksa, bu trafik modelinin API trafiginden ayri dusunulmesi gerekir.

Qapu icin benimsenen deployment modelinde FTP/FOTA katmani da Swarm icinde calisacaktir.

Bu nedenle temel ayrim su sekilde korunmalidir:

  • API traffic plane ile FTP delivery plane ayni sey degildir
  • FOTA servisi qapu-storage ve gerekiyorsa edge-facing network ile birlikte dusunulmelidir
  • firmware storage local veya shared olabilir, ancak path determinism ve node placement deployment contract ile netlestirilmelidir

Bu nedenle FOTA delivery plane'i deployment tasariminda ayrica ele alinmalidir.