Ana içeriğe geç

FOTA / Firmware Storage Deployment Contract

Bu sayfa, Qapu icinde firmware artifact serving ve FOTA delivery plane'inin Docker Swarm uzerindeki deployment contract'ini tanimlar.

Rol​

FOTA serving katmani su iki seyi birlikte tasir:

  • firmware artifact storage'a erisim
  • plain FTP delivery plane

Bu nedenle deployment contract acisindan storage ve edge davranisi birlikte dusunulur.

Benimsenen Model​

  • FOTA/FTP katmani Swarm icinde containerized calisir
  • deterministic placement alir
  • artifact path determinism korunur
  • API traffic plane ile FTP delivery plane ayri dusunulur

Placement​

Onerilen constraint mantigi:

  • node.role.qapu.storage=true
  • gerekiyorsa node.role.qapu.stateful=true

Temel kural:

  • FOTA serving katmani rastgele node'a dagitilmaz
  • artifact path ve storage baglami deployment contract ile sabitlenir

Storage Secenekleri​

Bu contract icinde desteklenebilir modeller:

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

Qapu icin kritik olcutler:

  • path determinism
  • file consistency
  • Telit uyumlulugu
  • backup/restore
  • node degisiminde serving surekliligi

Onerilen Ilk Yaklasim​

Ilk asamada en durust deployment modeli sunlardan biri olmalidir:

  • pinned serving node + deterministic local/shared storage
  • veya shared storage + deterministic serving placement

Kritik ilke:

  • artifact path runtime'da surpriz sekilde degismemelidir
  • FOTA serving plane operasyonel olarak API plane'den ayri dusunulmelidir

Network​

Tipik network uyeligi:

  • qapu-storage
  • edge-facing FTP plane gerekiyorsa ilgili network
  • gerekiyorsa qapu-ops

Not:

  • API ve FTP ayni ingress contract ile dusunulmemelidir
  • FOTA delivery plane icin ayrik security policy gerekebilir

Secrets ve Configs​

Secrets​

  • FTP credential'lari
  • storage credential'lari varsa onlar

Configs​

  • base firmware path
  • retention policy
  • serving mode
  • connection timeout ve transfer tuning ayarlari

Health ve Readiness​

Health mantigi yalniz process ayakta mi sorusu olmamalidir.

Anlamli readiness beklentisi:

  • firmware base path erisilebilir mi?
  • serving katmani path resolve edebiliyor mu?
  • gerekli credential'lar yuklenmis mi?

Update Stratejisi​

FOTA/storage update'i su nedenle hassastir:

  • transfer sirasinda kesinti olusabilir
  • artifact path tutarliligi bozulabilir
  • serving node degisirse path/symlink/mount sorunlari cikabilir

Bu nedenle update modeli:

  • kontrollu rollout
  • serving path dogrulamasi
  • artifact gorunurlugu kontrolu
  • gerekiyorsa bakim penceresi

Operasyonel Not​

Bu contract'in en kritik basari olcutu su degildir:

  • FTP container ayakta mi?

Asil olcut sunlardir:

  • dogru artifact dogru path'ten servis ediliyor mu?
  • serving node placement deterministic mi?
  • storage modeli restore ve backup ile uyumlu mu?
  • API plane ile FTP delivery plane birbirine karismadan yonetiliyor mu?