Konfigurációkezelés a felhőben?

Amint egy előző cikkben említettem, ahhoz, hogy az alkalmazásunk a felhőben működhessen, bizonyos dolgokat máshogy kell megvalósítani, mint a hagyományos .NET fejlesztés során. Ezek közül elsőnek a konfigurációról írok.

Hagyományos, “földi” alkalmazásnál a konfigurációt jellemzően *.config fájlokban tároljuk. Ezekben a rendszergazdák tudják állítgatni a rendszer paramétereit, így rugalmassá tehető az alkalmazás használata. Például a kapcsolódó rendszerek elérési adatait vagy az adatbázis connection stringet nem kell a programba beégetni, megváltoztathatók lesznek az alkalmazás újratelepítése nélkül. Vagy vehetjük példának a naplózási szintet, amit hibakereséshez felemelhetünk (gyakran konfig állományban megadva azt is, hogy hová kerüljön a részletes napló).

A könnyű szerkeszthetőség megszült néhány mintát is, mikor a program működését is konfigurációs beállításokkal írjuk le. Például az objektumok összedrótozását vezénylő dependency injectiont, vagy a működést megvalósító plugin osztályok elérési útvonalát emeltük ki. Vagy a beégetett konstansokat vezettük ki, hogy hibakeresésnél a program működésének “tweakelése” egyszerűsödjön. Ez a fajta paraméterezhetőség nem az adminisztrátoroknak fontos, inkább a fejlesztők életét könnyíti meg, a tesztelhetőséget, támogathatóságot segíti.

Az Azure platformon ez kicsit máshogy viselkedik. A konfigurációs fájlok ugyan megmaradtak az összes fenti lehetőséggel, de azok a telepítés során a használt dll-ekkel együtt a .cspkg fájlba kerülnek (ez az a csomag, amit verzióváltásnál feltöltünk a felhőbe, de ott a tartalma az adminisztrátorok számára hozzáférhetetlen, módosíthatatlan lesz). Azaz van konfigurációnk, csak azt nem lehet megváltoztatni.

Persze ez nem gonoszságból van így, sokkal inkább biztonsági megfontolás. A titkosított csatornán feltöltött, digitális aláírással védett csomag garantálja azt, hogy a felhőben futó alkalmazás ugyanaz lesz, mint amit mi telepíteni akarunk. Kizárja a menet közbeni belepiszkálás lehetőségét, és az új alkalmazáspéldányok indításakor is garantálja, hogy a feltöltött kód változatlanul kerüljön telepítésre.

Valamilyen szintű konfigurálhatóságot enged az Azure platform ugyan a role configuration-on keresztül (ez a .cscfg fájl, amit szintén fel kell töltenünk telepítéskor), de ez elsősorban a feltöltött alkalmazás példányainak beállítását szolgálja. Azaz főleg arra van kihegyezve, hogy mekkora és hány virtuális gépen fusson, telepítéskor milyen extra lépéseket kell beállítani, hogyan történjen a diagnosztikai naplók publikálása, stb., és csak ezek mellett, kiegészítő lehetőségként szerepel, hogy egy egyszerű név-érték listában saját beállításokat adhassunk át az alkalmazáspéldányoknak.

Azaz szükség lehet az Azure konfiguráció kiterjesztésére. Jó lenne, ha olyan megoldást találnánk, ami transzparens (azaz nem csak felhőben, hanem helyi telepítéseknél is működik, sőt, a megszokott ConfigurationManager osztállyal analóg), támogatja az adminisztrátorok általi szerkeszthetőséget, ugyanolyan kifejezőereje van mint a megszokott .config fájloknak, de emellett azért biztonságos, és egyszerűen használható.

Gyári komponenst, ami ezt tudja, egyelőre nem találtam, így saját fejlesztéssel estem neki a megoldásának. A következő postban ezt mutatom majd be.

Reklámok

Architektúra – miben lehet más a felhő?

Novák István az utolsó Azure Klubon vetette fel az ötletet: mi lenne, ha készítenénk egy listát a felhő platform azon sajátosságairól, amik architekturális szinten is különbségeket eredményezhetnek a megszokott megoldásokhoz képest?

Az én listám:

  • Az alkalmazás nem kap full trust jogosultságot, azaz bizonyos .NET kódok amik eddig működtek, nem fognak (először a nem standard SMTP porton történő levélküldésnél futottam bele).
  • A program szinte biztosan több példányban fog futni, párhuzamos terheléselosztott környezetben, azaz fel kell készülnünk az állapotmentes, tranzakcionális viselkedésre.
  • Fájlrendszer és SQL szerver mellett megjelenik az Azure Storage, mint perzisztencia tároló, az alkalmazás tervezésekor ezt az alternatívát is figyelembe kell venni.
  • Az alkalmazás konfigurációja (*.config) telepítés után adminisztrátorok számára nem hozzáférhető, tehát az olyan beállításokat amiket változtatni kell, az Azure platform role configuration-jébe kell kiemelni.
  • A felhőben az autentikáció és autorizáció megoldások is eltérnek a megszokottól.

…és még folytatható akármeddig. Javaslom, hogy megjegyzésbe írjátok meg ti is, mik azok a különbségek amik számotokra fontosak, aztán később esetleg szerkesztett cikket is készíthetünk, amiben alaposabban körbejárjuk az egyes témákat.