DevOps a felhőben Terraformmal (x)
Hogyan használja a Terraformot a Magyar Telekom DevOps csapata nyilvános felhőben? Erről adtak elő a cég szakemberei a HWSW májusi DevOps meetupján. A Magyar Telekom kimondottan elől jár a modern DevOps eszközök használatában, cégen belül már 2016-ban került élesbe (!) az első Docker konténeres alkalmazás, azóta pedig nagyszámú alkalmazást sikerült konténeressé alakítani - mondja a Magyar Telekom üzemeltetési szakmérnöke. "Ezek jelenleg a Telekom VMware-alapú virtualizált szerverfarmján futnak, linuxos virtuális gépeken." Ha pedig már konténeresek az alkalmazások, akkor megnyílik az út egyébként afelé, hogy ezeket publikus felhőbe (a Telekom esetében többek között az Oracle Cloudba) költöztessük. És itt jön be az előadás témája, a Terraform. A Terraform egy Infrastructure-as-code eszköz, amellyel konfigurációs fájlban le tudjuk írni az virtuális infrastruktúrát - akár a teljes géptermet, ha igényünk van rá. Ezt tetszőleges alkalommal futtathatjuk le, a módosításokat követhetjük akár verziókezelővel, tehát sokkal-sokkal hatékonyabb, konzisztensebb megoldás, mint kézzel konfigurálni a publikus felhőt. Maga a Terraform már széles támogatásnak örvend, a nagyobb felhős szolgáltatók már támogatják, az API-t pedig rengeteg szoftvereszköz elfogadja. De mi hajtja? Az alap állomány a main.tf, ez írja le az erőforrásokat és azok kapcsolatait. A különböző környezeti változókat külön állományok tartalmazzák (például variables.tf, hogy ez ne zavarjon be a fő dokumentumban - ilyenek például a bejelentkezési paraméterek (felhasználónév-jelszó párosok), amivel hozzáférünk a publikus felhőhöz. Ugyanitt definiálhatjuk a a virtuális gépeinket, SSH-kulccsal és felhasználókkal. A main.tf-re visszatérve: ez a legfontosabb konfigurációs fájl, amely a definiált erőforrásokat fogja létrehozni, függőségeivel együtt. Itt kell definiálni a virtuális gépekhez tartozó IP-címeket, biztonsági szabálycsomagot, stb. A biztonsági szabályok definiálják, hogy a gépet hogyan tudjuk elérni az internetről és a belső hálózatról. A script nem csak a megfelelő instance-et hozza létre, hanem az alkalmazást is segít beindítani (esetünkben Docker Compose-zal). A Terraform megközelítés másik eleme az állapotot rögzítő .tfstate fájlok, amelyek tulajdonképp a rendszer lelkét képezik: ezek rendelik össze a korábban definiált és beindított erőforrásokat, párosítja össze a publikus felhőben létrejött erőforrásokat a mi hivatkozásainkkal. Ez rögzíti, hogy mely erőforrások léteznek már a rendszerben, és tudja, hogy ezeket a script új futtatásakor már nem kell újra létrehoznia. A kritikus fájlot ezért érdemes úgy tárolni, hogy biztosan elérhető és perzisztens maradjon. A scriptek emberileg olvashatóak, de nem túl felhasználóbarátak, ha át szeretnénk tekinteni az infrastruktúrát. Ebben segít a Terraform Resource Graph és a GraphViz, amely vizualizálja az összekötött erőforrásokat és kirajzolja a létrehozott gráfot. De mi van, ha egy erőforrást a Terraform rendszerén kívül hoztunk létre, de szeretnénk Terraformmal, automatizáltan kezelni? Erre is van megoldás, különböző importáló scriptek segítségével tudathatjuk a Terraformmal hogy milyen erőforrásaink léteznek még és vegye át azok kezelését. Az egyes erőforrásokat (például VM-eket) nekünk kell kézzel listázni, ebből pedig a rendszer generálja a már említett state fájlt. Milyen alternatívák vannak? A infrastruktúra-mint-kód piacon a Terraformon kívül is rengeteg népszerű szereplő van, azonban minden cég kicsit másképp fogja fel saját szerepét és máshová teszi a hangsúlyokat. A konfigurációmenedzsment vs orkesztráció osztásban a Terraform egyértelműen az utóbbi csoportot erősíti, akár nulláról képes egész infrastruktúrát létrehozni, a meglévőt pedig tovább "hangszerelni", ezért kiegészítőre, például Dockerre van szüksége a futó alkalmazások további menedzsmentjéhez. A mutable-immutable is releváns felosztás, ebben a Terraform az immutable logikát követi, vagyis például az operációs rendszerekre nem telepít frissítéseket, hanem lekapcsolja a régit és felpörget egy új, frissített lemezképet. Ennek előnye, hogy az egyes szerverek bitre azonosak maradnak, nem alakulnak ki egyedi konfigurációk - és nem mellékesen leszoktatja az üzemeltetőket a manuális konfigurációról, hiszen azok elvesznek a következő változáskor. Procedurális vagy deklaratív? A Chef vagy az Ansible a procedurális utat választja, vagyis azt bátorítja, hogy az üzemeltető írja le a kívánt állapothoz vezető útvonalat. Ezzel szemben a Terraform (és például a Puppet) deklaratív, tehát csupán az elérni kívánt konfigurációt kell rögzíteni, a rendszer pedig megoldja a közbenső lépéseket. A HWSW májusi DevOps meetupján elhangzott előadás diái itt érhetőek el. Érdekelne mindez belülről? Nézd át a Magyar Telekom állásajánlatait! (A Magyar Telekom megbízásából készített anyag.)