Éles váltás

Hibás a legfrissebb fejlesztés, és csupán egy éjszaka maradt arra, hogy élesben elinduljon a rendszer, mert másnap lejár a törvényi határidő az átállásra? Közben a fejlesztőt nem lehet elérni? A Docker technológiával ilyen helyzet sosem állhat elő.

A hagyományos rendszereknél a fejlesztők elkészítenek egy szoftvert, egy alkalmazást – lehet az egy webshop, de egy banki háttérrendszer egyik funkciója is – majd átadják az üzemeltetőknek, akik egy leírás alapján feltelepítik azt egy másik szerverre. Az üzemeltetők és a fejlesztők egymástól függetlenül dolgoznak: a kész szoftvert a fejlesztők saját gépeiken tesztelik, majd az üzemeltetők a leírtak alapján reprodukálják. Egy mail küldő rendszer esetében például beállítják, hogy a postázás a teszt levélküldő szerveren keresztül történjen. Aztán később ugyanezt meg kell ismételni, átállítani az „éles” mail küldő szerverre.

Sok iparágban a két feladatkört szigorú szabályokkal különítik el egymástól. A pénzügyi szektorban például különösen fontos, hogy a fejlesztők az éles rendszerekhez ne férhessenek hozzá. A két team sokszor csak a leírások révén kommunikál egymással a földrajzi távolság és időeltolódás miatt. Ám ebből bonyodalmak származhatnak a pontatlan, vagy nem karbantartott leírások, vagy éppen egy az utolsó pillanatban beesett – és a szövegből véletlenül kimaradt – változás miatt.

‍

E problémára ad megoldást egy új technológia, a Docker.

‍

Lényege, hogy az előkészítő lépéseket nem papírokon vagy közös dokumentumokban tartják nyilván, hanem egy gép által értelmezhető file-ban írják le. Az üzemeltetőnek csak el kell indítania az alkalmazást, melynek a belső felépítéséről így kevesebb ismeret is elegendő. A futó példányt nevezzük Docker konténernek.

A környezetet előállító file-okat Dockerfile-oknak hívják. Arra is van lehetőség, hogy ezek aktualizált változata a forráskódok mellett, a verziókezelő rendszerben legyen elérhető, így megkönnyítve egy régebbi teljes rendszer visszaállítását. A file-ok csak parancsokat írnak le, az érzékeny adatokat (ilyenek például az adatbázis jelszavak) az üzemeltetők külön helyen adják meg.

Ily módon nincs kockázat: a Dockeren keresztül a fejlesztéstől akár az éles rendszerig ugyanaz fut, tehát egy esetleges hibát a fejlesztő már „magánál” észrevesz – hiszen akkor már nála sem működik a szoftver.

‍

Hogyan fest mindez a gyakorlatban?

‍

Maradjunk a mailes példánál! Tegyük fel, hogy írtunk egy webshop programot, amely az ügyfeleknek levelet küld ki. Ahhoz, hogy ez az alkalmazás fusson, szükség van egy futtatókörnyezetre, ehhez tehát definiálunk egy Docker környezetet.

A file első sorába azt írjuk le, hogy milyen operációs rendszerből induljon ki, a következőben pedig azt adjuk meg, hogy milyen csomagokat kell feltelepíteni. Leírjuk, hogy a szerveren egyéb beállításokat kell még végezni, mint például adatbázisok definiálása és külső kapcsolatok beállítása. A beállítások egy része a felhasználáshoz kapcsolódó környezeti változókkal adható meg.

Mi a teendője az üzemeltetőnek? Nos, amikor mindezt megkapja, meghatározott helyen csupán átírja a tesztrendszer email küldő szerverének címét az éles rendszer szerverére, és ezzel elő is állt a környezet, ahol az alkalmazás futni tud.

‍

Mit jelent mindez az ügyfelek számára?

‍

Mindenekelőtt gyorsaságot és pontosságot. Nem mennek el órák-napok a szöveges dokumentumokba került hibák vagy hiányosságok keresgélésével – márpedig ezek éppen a rendszerek élesítése előtti napon-éjszakán szoktak előjönni.

Üzemeltetési oldalról is sokkal egyszerűbb ez a megoldás. Nem szükséges a szervereknek és az alkalmazásoknak olyan pontos ismerete sem, mint korábban. Ahogyan a szállításnál a konténer nagy áttörést jelentett – nem kellett többé az eltérő méretű és tulajdonságú csomagokkal bajlódni – a Docker esetében is hasonló a helyzet: egységes módon kezelhetők a különböző alkalmazások.

Persze ez a megoldás sem jó mindenre. Egyszerűbb projekteknél nem érdemes alkalmazni, és olyan eset is van, amikor Docker file-ok bevetésére nincs is mód. Minthogy e technológia lényege, hogy Linuxos környezetben leírja, miképpen lehet egy szervert föltelepíteni, ha a megoldás, amit elkészítettek, Linux platformon nem tud futni, akkor a Docker módszer nem alkalmazható.

‍

Ahol azonban bonyolult egy környezet összeállítása, ott mindenképpen ezt ajánljuk.

‍

Olyan Java-s fejlesztéseknél ugyancsak szerencsés e technológiát használni, ahol alkalmazásszerverre kell telepíteni, és mikroszervizeknél is érdemes Dockert használni. Ekkor az önálló életciklussal rendelkező szolgáltatásokat érdemes külön-külön Docker konténerként futtatni.

E megoldás sajátossága, hogy a fejlesztés kezdeti szakasza és új infrastruktúra elemek bekapcsolása – a környezet folyamatos karbantartása miatt – picit hosszabb lehet, ám a teljes folyamathoz képest ez elenyésző. Cserébe viszont a telepítések előtti kommunikációra és hibakeresésre fordított idő nagyon lerövidül.

A technológia és az ezt biztosító szoftver pedig ingyenes.

Mindezek tükrében úgy vélem, nagy és bonyolult projektek esetében a Word dokumentumokban átadott leírások ideje lejárt.