Röviden: A helyszíni javítás konfigurációs driftet szül; az újraépítés-alapú megközelítés kiszámíthatóbb. Mit jelent az immutable elv a gyakorlatban, és hol vannak a határai?
Van egy mélyen belénk ivódott reflex: ha egy szerverrel baj van, belépünk, és megjavítjuk. Frissítünk egy csomagot, átírunk egy konfigot, újraindítunk egy szolgáltatást. Az immutable (megváltoztathatatlan) infrastruktúra elve szerint pont ez a reflex a probléma forrása. Ahelyett, hogy javítanánk egy futó szervert, kicseréljük egy frissen, tisztán felépítettre. Ez elsőre pazarlásnak tűnhet, de valójában kiszámíthatóságot és megbízhatóságot ad.
A mutable infrastruktúra problémája
A hagyományos, módosítható (mutable) szerver idővel egyedivé válik. Minden kézi beavatkozás, minden gyors javítás, minden „csak most az egyszer” módosítás egy réteget rak rá. Két hónap múlva senki nem tudja pontosan, mi van rajta és miért. Ez a konfigurációs drift: a szerverek elkezdenek eltérni egymástól és a dokumentált állapottól, és a hibakeresés rémálommá válik, mert minden gép kicsit más.
Az immutable elv
Az immutable megközelítésben a szervert soha nem módosítod a helyszínen. Ha változás kell — új verzió, patch, konfigmódosítás —, akkor egy új, tiszta példányt építesz a kívánt állapottal, és lecseréled a régit. A futó példány élettartama alatt nem változik; a változás mindig újraépítés.
- A kívánt állapotot egy építési folyamat (pl. image-készítés) rögzíti.
- Új verziónál új image épül, tesztelten.
- A régi példányokat az újak váltják, nem módosítás történik.
- A visszaállítás egyszerű: az előző, ismert jó image.
Miért kiszámíthatóbb?
Ha minden példány ugyanabból az image-ből épül, akkor tudod, hogy azonosak. Nincs „ezen a gépen valamiért más van” rejtély. A tesztelt image, ami stagingben működött, productionben is ugyanaz lesz. A drift megszűnik, mert nincs helyszíni módosítás, ami eltérést okozhatna. Ez a reprodukálhatóság az immutable elv legnagyobb ajándéka.
A visszaállítás egyszerűsége
Az immutable infrastruktúra egyik legnagyobb gyakorlati előnye a rollback. Ha egy új verzió hibás, nem kell kapkodva visszajavítani a futó szervert — egyszerűen visszaállsz az előző, ismert jó image-re. A rollback ugyanolyan művelet, mint a deploy: kiszámítható és gyors, nem pánikszerű kézi hibajavítás.
A határok
Az immutable elv nem mindenre való. A tartós állapotot kezelő komponensek (adatbázisok) nem cserélhetők ki csak úgy — ezeket máshogy kell kezelni. Emellett a nagyon gyors, apró változtatásoknál az újraépítés lassabbnak tűnhet, mint egy helyszíni módosítás — de ez a lassúság a kiszámíthatóság ára, és jellemzően megéri. A fejlesztői kísérletezésnél pedig van létjogosultsága a rugalmasabb, módosítható környezetnek.
A mutable szerver problémája
A hagyományos, módosítható szerver idővel egyedivé válik. Minden kézi beavatkozás, minden gyors javítás, minden "csak most az egyszer" módosítás egy réteget rak rá. Két hónap múlva senki nem tudja pontosan, mi van rajta és miért. Ez a konfigurációs drift: a szerverek elkezdenek eltérni egymástól és a dokumentált állapottól, és a hibakeresés rémálommá válik, mert minden gép kicsit más.
Az immutable megközelítés ezt szünteti meg: a szervert soha nem módosítod a helyszínen, hanem ha változás kell, egy új, tiszta példányt építesz és lecseréled a régit.
A kiszámíthatóság és a rollback
Ha minden példány ugyanabból az image-ből épül, akkor tudod, hogy azonosak — nincs "ezen a gépen valamiért más van" rejtély. A tesztelt image, ami stagingben működött, productionben is ugyanaz lesz. És a rollback triviális: ha egy új verzió hibás, egyszerűen visszaállsz az előző, ismert jó image-re, ahelyett hogy kapkodva javítanád a futó szervert.
- A kívánt állapotot egy építési folyamat rögzíti (image).
- Változásnál új image épül, tesztelten, és lecseréli a régit.
- A rollback = visszaállás az előző ismert jó image-re.
Mit jelent ez neked?
Az immutable infrastruktúra lényege: ne javítsd a futó szervert, hanem cseréld le egy frissen, tisztán épített példányra. Ez megszünteti a konfigurációs driftet, azonossá teszi a példányokat, és a rollbackot ugyanolyan egyszerűvé, mint a deployt. Az elv a compute-ra vonatkozik — a tartós állapotot le kell választani külső tárolóra. A helyszíni javítás reflexét cseréld le az újraépítés fegyelmére; a kezdeti kényelmetlenséget bőven megtérüli a kiszámíthatóság.