A Nemzeti Környezeti Adatszolgáltató Szolgálat (NESDIS) 35%-kal csökkentette a Red Hat Enterprise Linux (RHEL) konfigurációkezelési költségeit, amikor átállt a Puppet Enterprise-ről az Ansible Tower-re. Ebben a 'hogyan csináltuk' kategóriájú videóban Michael Rau rendszermérnök megindokolja ennek a migrációnak a létjogosultságát, hasznos tippeket és az átállás során szerzett tapasztalatait osztja meg.
A videóból megtudhatja:
- hogyan indokolja meg a vezetőségnek az átállás létjogosultságát a Puppet Enterprise-ről az Ansible Tower-re;
- milyen stratégiákat érdemes alkalmazni a lehető legzökkenőmentesebb átállás érdekében;
- tippek a PE manifesztumok Ansible Playbook-ra való transzkódolásához;
- ajánlások az Ansible Tower optimális telepítésére.
Üdvözlöm mindenkit, Michael Rau vagyok, az ActioNet vezérmérnöke, amely a NOAA NESDIS szolgálatán dolgozik. Ma a szálak levágásáról fogunk beszélni – a saját tapasztalataim az átállásról a Puppet Enterprise-ről az Ansible Tower-re. Az előadásom témája, hogy 'megnézhesse a hegeimet', amelyek a kezdeti átállás után maradtak. Szeretném elmondani, mit tanultam az átkelés során. Így amikor hasonlót csinál, az én tapasztalataimat felhasználva, zökkenőmentesen vállalhatja az átállást.
Olyan diákra néznek, mint ez, az Ansible Fest minden bemutatójának elején. Ezen a dián a vállalatom automatizálásának történetével ismerkedhetnek meg. Nem vagyok újonc a területen, mert 2007 óta használom a Puppet/Puppet Enterprise-t. 2016 óta foglalkozom Ansible-lal, és mint sok más felhasználót, engem is vonzottak a parancssori 'trükközés' lehetőségei és az egyszerű playbookok. 2017 végén jeleztem a vezetőségnek az Ansible Tower-re való áttérés mellett szóló komoly indokokat. Egy perc múlva arról fogok beszélni, miért döntöttem így. Miután megkaptam a főnökeim beleegyezését, még pár hónapra volt szükség ahhoz, hogy végrehajtsam az átalakítást, így január-február folyamán sikerült átállnom. Így teljesen elhagytuk a Puppet-et az Ansible javára, és ez nagyszerű dolog.
A legjobban az Ansible-ben a szerepek (roles) és a lejátszási fájlok (playbooks) írásának és használatának lehetősége vonz. A szerepek kiválóan alkalmasak különböző, de összefüggő feladatok (tasks) létrehozására, amelyekhez minden, ezekkel kapcsolatos adatot egy helyen tárolhatunk. A playbook egy YAML szintaxisú fájl, amely leírja a műveleteket egy vagy több hoszton. Ezen lehetőségekről elsősorban a szoftverfejlesztők számára beszélek. Az Ansible Tower lehetőséget ad arra, hogy azt mondhassam: „nincs shell-hez való hozzáférése, de lehetőséget adok arra, hogy minden Tower folyamatot elindítson, és újraindítsa a szolgáltatást, amikor szüksége van rá.” Beszélek a munkakörnyezetről és a használt berendezéseinkről.
Ez egy szövetségi LAN, 7 fizikailag csatlakoztatott helyszín egy felhő alapú MPLS-en keresztül, 140 RHEL szerver, amelyek 99%-a virtuális (vSphere), SuperMicro hardver, NexentaStore hálózati tárolás, Cisco, Arista és Cumulus switch-ek, valamint Fortinet UTM egységes fenyegetéskezelő eszközök minden helyszínen.
A szövetségi hálózat azt jelenti, hogy minden információvédelmi intézkedést alkalmaznom kell, amelyet a jogszabályok előírnak. Tudnia kell, hogy a Puppet Enterprise a használt berendezéseink nagy részét nem támogatja. Költségvetési hardvert vagyunk kénytelenek használni, mivel az állami intézmények anyagi nehézségekkel küzdenek ebben a költségvetési tételben. Ezért SuperMicro osztályú 'vasat' vásárolunk, és az eszközöket különféle alkatrészekből állítjuk össze, amelyek karbantartását kormányzati szerződések garantálják. Linuxot használunk, és ez az egyik fontos oka az Ansible-ra való áttérésnek.
A Puppet-tel kapcsolatos tapasztalataink története.
2007-ben egy 20-25 csomóból álló kis hálózatunk volt, ahol a Puppet-et telepítettük. Alapvetően ezek a csomópontok csak RedHat 'dobozok' voltak. 2010-ben elkezdtük használni a Puppet Dashboard webes felületét 45 csomópont számára. Ahogy a hálózat folyamatosan bővült, 2014-ben áttértünk a PE 3.3 verzióra, és teljesen átdolgoztuk a manifesztet 75 csomópontra. Ezt azért kellett megtennünk, mert a Puppet gyakran megváltoztatja a játékszabályokat, és ebben az esetben teljesen átváltoztatta a nyelvet. Egy év múlva, amikor megszűnt a 3. verzió támogatása, kénytelenek voltunk áttérni a PE 2015.2-re. Megint át kellett dolgoznunk a manifesztet az új szerverekhez, és vásárolnunk kellett egy licencet 100 csomópont támogatásához, bár akkoriban csak 85 csomópontunk volt.
Mindössze 2 év múlva újra nagy munkát kellett végeznünk a PE 2016.4 új verziójára való áttéréshez. Licencet vásároltunk 300 csomópontra, miközben csak 130 volt. Ismét komoly változtatásokat kellett végeznünk a manifesztben, mert az új verzió nyelve eltérő szintaxissal rendelkezett, mint a 2015-ös verzió. Ennek eredményeként a SCM-ünk áttért a SVN verziókezelő rendszerről a Bitbucket-re (Git). Ilyen volt a „kapcsolatunk” a Puppettel.
Tehát el kellett magyaráznom a vezetésnek, miért kell áttérnünk egy másik SCM-re, a következő érvek felhasználásával. Az első az szolgáltatás költsége. Beszéltem a RedHat munkatársaival, és ők elmondták, hogy 300 csomópont hálózatának karbantartása az Ansible Tower segítségével a Puppet Enterprise költségének felébe kerül. Ha megvesszük az Ansible Engine-t is, a költség körülbelül azonos lesz, de sokkal több funkciót kapunk, mint a PE-nél. Mivel állami tulajdonú vállalat vagyunk, amelyet a szövetségi költségvetés finanszíroz, ez elég jelentős érv.
A második érv a sokoldalúság. A Puppet csak azokat a berendezéseket támogatja, amelyeken Puppet ügynök található. Ez azt jelenti, hogy minden switchekre telepíteni kell az ügynököt, és az ügynöknek az utolsó verzióval kell rendelkeznie. Ha a switchek egy része egy verziót, míg más része egy másikat támogat, akkor új verziójú PE ügynököt kell telepíteni rájuk, hogy mindannyian egyetlen SCM rendszeren belül működhessenek.
Az Ansible Tower rendszere másképpen működik, mivel nincsenek ügynökök, de vannak modulok, amelyek támogatják a Cisco switch-eket és minden egyéb switch-et. Ez a SCM támogatja a Qubes OS-t, a Linux-ot és a .NET UTM-et. Az Ansible Tower emellett támogatja a NexentaStore hálózati tároló kontrollereit, amelyek az Illumos kernelre épülnek – ez egy Unix-alapú, nyílt forráskódú operációs rendszer. Ez egy nagyon kicsi támogatás, de az Ansible Tower így is biztosítja ezt.
A harmadik érv, ami nagyon fontos számomra és az adminisztrációnk számára is, az a könnyű tanulhatóság. Én 10 évig a Puppet moduljait és manifeszt kódját tanultam, de az Ansible-t egy hét alatt elsajátítottam, mert ezzel az SCM-mel sokkal egyszerűbb dolgozni. Ha futtatsz végrehajtható fájlokat, persze, ha nem csinálod ezt szükségtelenül, akkor ezekkel ésszerű és reagáló kezelők foglalkoznak. A YAML-alapú playbook forgatókönyvek könnyen tanulhatóak és gyorsan használhatóak. Akik még soha nem hallottak a YAML-ról, egyszerűen elolvashatják a forgatókönyveket, és könnyen megérthetik, hogyan működik.
Őszintén szólva, a Puppet sokkal bonyolultabbá teszi a munkádat fejlesztőként, mert a Puppet Master használatára épül. Ez az egyetlen gép, amelynek joga van kommunikálni a Puppet ügynökökkel. Ha változtatásokat hajtottál végre a manifesztben és szeretnéd tesztelni a kódodat, akkor újra kell írnod a kódot a Puppet Masterhez, azaz be kell állítanod a Puppet master fájlt /etc/hosts az összes kliens csatlakoztatásához, és el kell indítanod a Puppet Server szolgáltatást. Csak ezután tudod tesztelni a hálózati berendezés működését egy gépen. Ez egy elég fájdalmas eljárás.
Az Ansible-nél minden sokkal egyszerűbb. Csak annyit kell tenned, hogy kódot írj egy olyan gépre, amely képes SSH protokollon keresztül kapcsolatba lépni a tesztelt hosttal. Ezzel sokkal egyszerűbb dolgozni.
A következő nagy előnye az Ansible Tower-nek az, hogy képes kihasználni a már meglévő támogatási rendszeredet és megőrizni a meglévő berendezéskonfigurációt. Ez a SCM mindenféle további lépés nélkül használja az összes meglévő információt az infrastruktúrádról és a berendezésekről, virtuális gépekről, szerverekről stb. Képes kapcsolódni a RH Satellite szervereidhez, ha vannak ilyenek, és olyan integrációt biztosít, amit soha nem fogsz elérni a Puppet-tel való munkavégzés során.
Egy fontos dolog a részletes ellenőrzés. Tudja, hogy a Puppet moduláris rendszer, ez egy kliens-szerver alkalmazás, ezért meg kell határoznia az összes gép működésének meglévő aspektusait egy hosszú manifesztumban. Ekkor a rendszer minden egyes elemének állapotát félóránként kell tesztelni – ez az alapértelmezett időszak. Így működik a Puppet.
A Tower megszabadít ettől. Korlátlanul végezheti el a legkülönfélébb folyamatokat a különböző hardvereken, végezheti a fő munkát, indíthat más fontos folyamatokat, beállíthatja a biztonsági rendszert, dolgozhat az adatbázisokkal. Mindez nehézségekkel járhat a Puppet Enterprise esetében. Például, ha egy hoszton végezte el a beállítást, időbe telik, amíg a változások érvénybe lépnek a többi hoszton. Az Ansible-nál minden változás egyszerre lép érvénybe.
Végül nézzük meg a biztonsági modult. Az Ansible Tower-ben ez lenyűgözően van megvalósítva, nagy pontossággal és gondossággal. Lehetőséget adhat a felhasználóknak, hogy hozzáférjenek konkrét szolgáltatásokhoz vagy konkrét hosztokhoz. Én így járok el a Windows-on dolgozó munkatársaimmal, korlátozva hozzáférésüket a Linux shellhez. Olyan hozzáférést biztosítok számukra a Tower-ben, hogy csak azt a munkát végezhetik el és csak azokat a szolgáltatásokat indíthatják, amelyek a kompetenciájukba tartoznak.
Nézzük meg azokat a lépéseket, amelyeket előre meg kell tenni az Ansible Towerre való átállás megkönnyítése érdekében. Először is fel kell készíteni az Ön berendezéseit. Ha az infrastruktúrája egyes elemei még nincsenek nyilvántartva az adatbázisban, akkor ezeket hozzá kell adni. Vannak olyan rendszerek, amelyek nem változtatják meg a tulajdonságaikat, ezért hiányoznak a Puppet adatbázisból, de ha ezeket nem jegyzi fel az átállás előtt, lemond a számos előnyről. Lehet, hogy ez egy „koszos”, előzetes adatbázis, de annak tartalmaznia kell információt minden, a birtokában lévő berendezésről. Ezért érdemes egy dinamikus hardver-szkriptet írni, amely automatikusan nyilvántartásba veszi az infrastruktúra minden változását az adatbázisban, így az Ansible tudni fogja, hogy mely hostoknak kell megjelennie az új rendszerben. Nem kell majd elmondania ennek a SCM-nek, hogy mely hostokat adta hozzá, és melyek már nem léteznek, mert ezt mind automatikusan fogja észlelni. Minél több adat van az adatbázisban, annál hasznosabb és rugalmasabb lesz az Ansible. Olyan módon működik, mintha egyszerűen beolvasná az adatbázisból a berendezés állapotának vonalkódját.
Szánjon időt arra, hogy megismerkedjen az Ansible parancssor működésével. Indítson el néhány speciális parancsot a hardver-szkript működésének ellenőrzésére, írjon és futtasson le néhány egyszerű, de hasznos playbook forgatókönyvet, használjon Jinja2 sablonokat, ahol releváns. Próbáljon meg írni egy szerepet és forgatókönyvet egy komplex, többlépcsős folyamathoz, a standard, gyakran előforduló berendezéskonfigurációk felhasználásával. Játsszon ezekkel a dolgokkal, tesztelje, hogyan működnek. Ily módon megtanulja használni a Towerben alkalmazott könyvtárkészítő eszközöket. Már említettem, hogy az átállásra való felkészülés körülbelül 3 hónapig tartott. A tapasztalatom alapján úgy gondolom, hogy Önnek sikerülni fog ezt gyorsabban megtenni. Ne tekintse elveszett időnek ezt az időt, mert később érezni fogja a megtett munka előnyeit.
Ezután meg kell határoznia, hogy mit vár el az Ansible Tower-től, és pontosan mit kell tennie ennek a rendszernek az Ön számára.
Szüksége van egy rendszer telepítésére üres hardverre vagy üres virtuális gépekre? Vagy szeretné megtartani a meglévő hardver munkakörülményeit és beállításait? Ez egy nagyon fontos szempont az állami vállalatok működése szempontjából, ezért meg kell győződnie arról, hogy sikerül migrálnia és telepítenie az Ansible-t a meglévő konfiguráción. Határozza meg azokat az adminisztratív folyamatokat, amelyeket automatizálni szeretne. Derítse ki, szüksége van-e speciális alkalmazások és szolgáltatások telepítésére az új rendszerre. Készítsen listát arról, amit meg szeretne valósítani, és állítson fel prioritásokat.
Ezután kezdje el írni a szkripteket és szerepeket, amelyek biztosítják a tervezett feladatok végrehajtását. Csoportosítsa ezeket Projektekbe, amelyek logikai gyűjteménye a megfelelő playbook szkripteknek. Minden Projekt egy külön Git tárolóra vagy más tárolóra vonatkozik, attól függően, hogy milyen kódkezelőt használ. Kezelheti a playbook szkripteket és a playbook könyvtárakat, ha manuálisan helyezi őket a Tower szerver Project Base Path-jába, vagy elhelyezi a playbook-ot bármilyen forrást kezelő rendszerben (SCM), amelyet a Tower támogat, beleértve a Git-et, Subversion-t, Mercurial-t és a Red Hat Insights-t. Egy Projektben annyi szkriptet helyezhet el, amennyit csak szeretne. Például létrehoztam egy alap Projektet, amelyben egy szkript található a RedHat alapvető elemeihez, egy szkript a Linux alapokhoz, és szkriptek a többi alapvető mutatóhoz. Így egy projekten belül különféle szerepek és szkriptek voltak, amelyeket egy Git tárolóból kezeltek.
Futtassa ezeket a feladatokat a parancssoron keresztül, ez jó módja azok működésének ellenőrzésére. Így felkészül a Tower telepítésére.
Beszéljünk egy kicsit a Puppet manifestek átkonvertálásáról, mert sok időt töltöttem ezzel, mire rájöttem, hogy mit is kellene valójában tennem.
Ahogy már mondtam, a Puppet minden beállítást és hardverparamétert egy hosszú manifesztumban tárol, amelyben minden szerepel, amit ez a SCM végez. Az átmenet során nem szükséges az összes feladatot egy listába zsúfolni, inkább gondolkodjon az új rendszer felépítésén: szerepek, forgatókönyvek, címkék, csoportok, és hogy mi tartozik ezekbe. Néhány önálló hálózati elemet érdemes csoportosítani, amelyekhez forgatókönyveket lehet létrehozni. A bonyolultabb infrastruktúraelemek, amelyek nagy mennyiségű erőforrást igényelnek, beleértve az önálló osztályokat is, szerepekbe vonhatók. Az átköltözés előtt ezzel tisztában kell lennie. Ha olyan nagyméretű szerepeket vagy forgatókönyveket hoz létre, amelyek nem férnek el egy képernyőn, érdemes címkéket használni az infrastruktúra egyes részeinek megjelölésére.
18:00
Egy kis reklám 🙂
Köszönjük, hogy velünk tart. Tetszenek a cikkeink? Szeretne több érdekes anyagot látni? Támogasson minket, rendeljen vagy ajánlja barátainak, , egyedülálló belépő szintű szerverek analógja, amelyet önnek találtunk ki: (elérhetők RAID1 és RAID10 lehetőségek, 24 magig és 40GB DDR4-ig).
A Dell R730xd kétszer annyiba kerülhet az Equinix Tier IV adatközpontban Amszterdamban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99$-tól! Olvassa el, hogy
Forrás: habr.com
