3. Konfiguráció

Tárolja a konfigurációt környezeti változókban¶

Egy alkalmazás konfigurációja mindaz, ami valószínűleg eltérhet a telepítések között (teszt, produkció, fejlesztői környezet stb.). Ide tartozik:

• Erőforrás kezelők a adatbázishoz, Memcached-hez és más háttérszolgáltatásokhoz
• Hozzáférési adatok külső szolgáltatásokhoz, például az Amazon S3-hoz vagy a Twitterhez
• Telepítésenként változó értékek, például a telepítés kanonikus hosztneve

Az alkalmazások néha konfigurációt tárolnak a kódban rögzített konstansok formájában. Ez sérti a twelve-factor alapelvét, amely szigorú elkülönítést ír elő a konfiguráció és a kód között. A konfiguráció jelentősen eltérhet a telepítések között, a kód pedig nem.

Egy alkalmazásnak minden konfigurációt helyesen ki kell választania a kódból annak érdekében, hogy a kódbázis bármikor nyilvánosan hozzáférhetővé váljon anélkül, hogy veszélyeztetné a hitelesítő adatokat.

Fontos megjegyezni, hogy a "konfiguráció" definíciója nem tartalmazza az alkalmazás belső konfigurációját, például a config/routes.rb fájlt a Rails-ben, vagy hogy hogyan vannak összekapcsolva a kódmodulok a Springben. Ez a típusú konfiguráció nem változik a telepítések között, így azt érdemes a kódban kezelni.

Egy másik megközelítés a konfigurációhoz a konfigurációs fájlok használata, amelyeket nem ellenőriznek a verziókezelő rendszerben, például a config/database.yml a Rails-ben. Ez egy hatalmas előrelépés a konstansok használatához képest, amelyeket a kód repójában ellenőriznek, de még mindig vannak gyengeségek: könnyű véletlenül belekerülni egy konfigurációs fájlt a repóba; a konfigurációs fájlokra jellemző, hogy szétszóródnak különböző helyeken és különböző formátumokban, ami megnehezíti az összes konfiguráció egy helyen való megtekintését és kezelését. Ezenkívül ezek a formátumok általában a programozási nyelvhez vagy a keretrendszerhez kötöttek.

A twelve-factor alkalmazás a konfigurációt környezeti változókban (gyakran rövidítve env vars vagy env) tárolja. A környezeti változók könnyen megváltoztathatók telepítés között anélkül, hogy a kódon változtatnánk; ellentétben a konfigurációs fájlokkal, kevés esély van arra, hogy véletlenül bekerüljenek a kód repójába; és eltérően a testreszabott konfigurációs fájloktól vagy más konfigurációs mechanizmusoktól, mint például a Java rendszer tulajdonságok, ezek a környezeti változók egy nyelv- és operációs rendszerfüggetlen szabványnak felelnek meg.

A konfigurációkezelés másik szempontja a csoportosítás. Néha az alkalmazások csoportosítják a konfigurációt elnevezett csoportokba (gyakran "környezetek" néven), amelyeket a különböző telepítések után neveznek el, például a fejlesztési, tesztelési és termelési környezetek a Rails-ben. Ez a módszer nem skálázódik tisztán: ahogy több alkalmazás-telepítés jön létre, új környezetnevek szükségesek, például a staging vagy qa. Ahogy a projekt tovább növekszik, a fejlesztők hozzáadhatnak saját speciális környezeteket, mint például a joes-staging, ami konfigurációs kombináció robbanáshoz vezet, és nagyon törékenyé teszi az alkalmazás telepítéseinek kezelését.

Egy twelve-factor alkalmazásban a környezeti változók részletesebb irányításúak, és teljes mértékben függetlenek egymástól. Soha nem csoportosulnak össze "környezetekként", hanem függetlenül kezelik őket minden egyes telepítésnél. Ez egy olyan modell, amely simán skálázódik, ahogy az alkalmazás természetesen növekszik és újabb telepítésekre kerül sor az élettartama során.