az alkalmazáskód írása megelőzi a legtöbb felhőmegoldást—olyan megoldásokat, amelyeket a legtöbb alkalmazásprogramozó kifejezetten ezekre a napokra ír.
ennek a disszonanciának a kezelésére a 12 faktoros alkalmazás módszertan alakult ki. A 12 tényező egy olyan megközelítés, amely segít a programozóknak deklaratív módon írni a modern alkalmazásokat, felhőn keresztül telepített tiszta szerződések felhasználásával.
ebben a cikkben bemutatom a 12 faktoros alkalmazás módszertant, és magas szintű összefoglalót kínálok alapelveiről.
mi a 12 faktoros alkalmazás módszertana?
2012-ben a Heroku programozói bemutatták a 12 faktoros alkalmazás módszertant. Ezek a programozók több száz alkalmazást fejlesztettek ki és telepítettek, akik ezt a módszertant írták, a SaaS alkalmazások “vadonban” való látásának tapasztalataira támaszkodva.
Ez a csoport a módszertant a következők háromszögelésének tekinti:
- ideális gyakorlatok az alkalmazásfejlesztés támogatására
- az alkalmazásként előforduló dinamika szervesen növekszik
- a kódbázis-fejlesztők közötti kapcsolat és együttműködés
céljuk kettős:
- a szoftvereróziós költségek elkerülése érdekében
- hogy felhívja a figyelmet a modern alkalmazásfejlesztésben megfigyelt szisztémás problémákra
A csoport két inspiráló forrásra mutat, a vállalati alkalmazás-architektúra mintáira és a Refaktorálásra, mind a professzionális Fejlesztő, Martin Fowler által.
és most bemutatom mind a 12 tényezőt.
I. alapelv kódbázis
“egy kódbázis nyomon követhető a revízióvezérlésben, sok telepít”
a kódbázisnak logikai verziókezelő rendszerrel kell rendelkeznie, amely könnyen érthető.
minden telepítésnek rendelkeznie kell saját kódtárral, amely több környezetbe telepíthető. Kerülje a több alkalmazás elhelyezését ugyanabban a tárolóban. Ez szinte lehetetlenné teszi a verzióvezérlés megértését, és a verziók összezavarodnak, ami nem hozzáadott értékű munkát eredményez.
elv II. függőségek
“a függőségek explicit deklarálása és izolálása”
Ez az elv azt állítja, hogy soha nem szabad támaszkodni a rendszerszintű csomagok implicit létezésére. Ehelyett ”
- győződjön meg arról, hogy az alkalmazás-specifikus könyvtárak rendelkezésre állnak
- ellenőrizze, hogy az operációs rendszerhez való hozzáférés
- ellenőrizze, hogy rendelkezésre állnak-e a szükséges rendszerkönyvtárak, például a curl vagy az ImageMagick. (Nincs garancia arra, hogy ezek minden olyan rendszeren léteznek, ahol az alkalmazás a jövőben futhat.)
összességében egy 12 faktoros alkalmazásnak öntartónak kell lennie. Az alkalmazást kellően el kell különíteni, hogy elkerülje a gazdagépen telepített ütköző könyvtárakkal való interakciókat.
nézzünk egy példát. A Pythonban deklarációt és izolációt érhet el a PIP és a Virtualenv használatával. Ennek az elvnek a kielégítéséhez mindig mind a függőség, mind az elszigeteltség nyilatkozatát kell használnia. A függőségek kezelése az alkalmazáson belül, nem külső forrásból. A függőségeket az alkalmazáson belüli tárolóban kell tárolni
III. alapelv. Config
“Config tárolása a környezetben”
egy alkalmazásnak és konfigurációjának teljesen függetlennek kell lennie. Ezenkívül teljesen el kell kerülni a konfigurációk folyamatos kódban történő tárolását.
a konfigurációknak külön fájllal kell rendelkezniük, és nem szabad a kódtárban tárolni őket. Egy külön konfigurációs fájl megkönnyíti a konfigurációs értékek frissítését a tényleges kódbázis megérintése nélkül, így nincs szükség az alkalmazások újbóli telepítésére bizonyos konfigurációs értékek megváltoztatásakor.
Ha a konfigurációk a környezetben vannak, nem pedig az alkalmazásban, változóként könnyen áthelyezheti egy másik környezetbe a forráskód megérintése nélkül. A tizenkét tényezős alkalmazások változóként konfigurálják a konfigurációkat, így “valószínűleg nem kerülnek be véletlenül a tárolóba”. Egy másik bónusz: akkor a konfigurációk függetlenek a nyelvtől és az operációs rendszertől.
alapelv IV. háttérszolgáltatások
“A háttérszolgáltatásokat csatolt erőforrásként kezeljük”
egy 12 faktoros alkalmazásban minden olyan szolgáltatást, amely nem támogatja a core alkalmazást, szolgáltatásként kell elérni. Ezek a nem alapvető alapvető szolgáltatások a következők lehetnek:
- adatbázisok
- külső tároló
- üzenetsorok
- stb.
ezeket erőforrásként lehet kezelni. Ezeket szolgáltatásként kell elérni HTTP-n vagy hasonló kérésen keresztül, majd a konfigurációban meg kell adni. Ily módon a szolgáltatás forrása megváltoztatható anélkül, hogy befolyásolná az alkalmazás alapkódját.
például egy üzenetsoroló rendszert használó alkalmazás a legjobb, ha csak a konfigurációs információk megváltoztatásával könnyen átválthat RabbitMQ-ról ZeroMQ-ra ActiveMQ-ra.
elv V. Build, release, run
“szigorúan külön építeni és futtatni szakaszok”
a 12-faktor alkalmazás szigorúan elválasztja a három szakaszában épület, felszabadító, és fut.
indítsa el a build folyamatot az alkalmazás forrásvezérlésben történő tárolásával, majd építse ki függőségeit. A konfigurációs információk elválasztása azt jelenti, hogy kombinálhatja azt a kiadási szakasz felépítésével—majd készen áll a futási szakaszra. Az is fontos, hogy minden kiadás egyedi azonosítóval rendelkezzen.
elv VI. Processes
“az alkalmazás végrehajtása egy vagy több állapot nélküli folyamatként”
tárolja azokat az adatokat, amelyek szükségesek ahhoz, hogy fennmaradjanak egy állapotos háttérszolgáltatásban, például adatbázisokban. Az elképzelés az, hogy a folyamat hontalan, és nem oszt meg semmit.
míg sok fejlesztő hozzászokott a “ragadós munkamenetekhez”, az információk tárolása a munkamenetben, arra számítva, hogy a következő kérés ugyanattól a szolgáltatástól származik, ellentmond ennek a módszertannak.
elv VII. Portkötési elv
“szolgáltatások exportálása portkötésen keresztül”
a 12 tényezős alkalmazásoknak mindig függetlennek kell lenniük a további alkalmazásoktól. Minden funkciónak saját folyamatnak kell lennie-teljes elszigeteltségben.
hagyományos környezetben feltételezzük, hogy a különböző folyamatok különböző funkciókat kezelnek. Mint ilyen, könnyű tovább feltételezni, hogy ezek a funkciók webes protokollon keresztül érhetők el, mint például a HTTP, így valószínű, hogy az alkalmazások webszerverek mögött futnak, mint például az Apache vagy a Tomcat. De ez ellentétes a 12 faktoros módszertannal.
ehelyett adjon hozzá egy webkiszolgáló könyvtárat vagy hasonlót a core alkalmazáshoz. Ez azt jelenti, hogy az alkalmazás várhat kéréseket egy meghatározott porton, legyen az HTTP vagy más protokoll.
elv VIII. konkurencia
“skálázzuk keresztül a folyamat modell”
egy igazi 12-faktor alkalmazás célja a méretezés. Készítse el az alkalmazásokat úgy, hogy a felhőben a méretezés zökkenőmentes legyen. Ha fejleszteni az alkalmazást, hogy egyidejű, akkor spin fel az új példányok a felhő könnyedén.
nagyobb kapacitás hozzáadásához (további folyamatok indítása további gépeken) az alkalmazásnak képesnek kell lennie arra, hogy több példányt adjon hozzá a helyi gépen lévő több memória vagy CPU helyett.
IX. elv. Eldobhatóság
“maximalizálja a robusztusságot gyors indítással és kecses leállítással”
az eldobható folyamatok fogalma azt jelenti, hogy egy alkalmazás bármikor meghalhat, de ez nem befolyásolja a felhasználót—az alkalmazás helyettesíthető más alkalmazásokkal, vagy újra elindulhat. Az eldobhatóság beépítése az alkalmazásba biztosítja, hogy az alkalmazás kecsesen leálljon: meg kell tisztítania az összes felhasznált erőforrást, és zökkenőmentesen le kell állítania.
ha ilyen módon tervezték, az alkalmazás gyorsan visszatér. Hasonlóképpen, amikor a folyamatok befejeződnek, be kell fejezniük az aktuális kérésüket, el kell utasítaniuk a beérkező kéréseket, és ki kell lépniük.
alapelv X. Dev / prod paritás
“a fejlesztés, a staging és a termelés a lehető legközelebb legyen”
a fejlesztésre és gyártásra telepített alkalmazásoknak paritásúnak kell lenniük. Lényegében csak a legkisebb különbségnek kell lennie mindkét telepítés között.
a hatalmas különbség nem szándékos kompatibilitási problémákhoz vezethet a dev és a termelési kód között. 12 tényezős alkalmazás létrehozásakor a dev és a prod közötti háttérszolgáltatásoknak azonosnak kell lenniük; a különbség itt jelentős problémákat okozhat a sorban.
alapelv Xi. Logs
“kezelje a naplókat eseményfolyamként”
ellentétben a monolitikus és hagyományos alkalmazásokkal, amelyek naplózási információkat tárolnak egy fájlban, ez az elv azt állítja, hogy a naplókat egy kiválasztott helyre kell streamelni—nem egyszerűen csak naplófájlba dobni.
a naplók általában nem ugyanazon a helyen találhatók a felhőalapú környezetekben minden írás után. Amint új folyamatok indulnak, vagy az alkalmazás összeomlik, a naplók több felhőalapú gépen oszlanak meg; nem ülnek egyetlen gépen vagy gazdagépen.
oldja meg ezt a problémát úgy, hogy megnevez egy közös helyet a naplók streameléséhez. Bizonyos esetekben egyszerűen átirányíthatja az Stdout fájlt. Valószínűbb azonban, hogy telepíteni szeretne egy log routert, mint a Fluentd, és mentse a naplókat a Hadoopba vagy egy adott Szolgáltatásba, például a Splunkba.
elv XII. Admin folyamatok
“futtassa az admin / menedzsment feladatokat egyszeri folyamatokként”
az utolsó 12 tényezős alkalmazás elv javasolja az adminisztratív feladatok elválasztását az alkalmazás többi részétől. Ezek a feladatok magukban foglalhatják az adatbázis áttelepítését vagy a rekordok ellenőrzését.
bár az adminisztrációs folyamatok külön vannak, továbbra is ugyanabban a környezetben kell futtatnia őket, és magának az alkalmazásnak az alapkódjával és konfigurációjával szemben. Az admin feladatok kódjának szállítása az alkalmazás mellett megakadályozza a sodródást.
kapcsolódó olvasás
- BMC DevOps Blog
- agilis vs vízesés SDLCs: mi a különbség?
- telepítési csővezetékek (CI/CD) a szoftverfejlesztésben
- mi az extrém programozás (XP)?
- hogyan & miért lesz egy szoftver gyár
- Top konferenciák programozás & szoftverfejlesztés