A National Environmental Satellite Data Information Service (NESDIS) 35%-kal csökkentette a Red Hat Enterprise Linux (RHEL) konfigurációkezelési költségeit azáltal, hogy átállt a Puppet Enterprise-ról az Ansible Towerre. Ebben a „hogyan csináltuk” videóban Michael Rau rendszermérnök elmagyarázza az átállás esetét, hasznos tippeket és tanulságokat osztva meg az egyik SCM-ről a másikra való átállás során.
Ebből a videóból megtudhatja:
- hogyan igazolja a menedzsment számára a Puppet Enterprise-ról az Ansible Towerre való átállás megvalósíthatóságát;
- milyen stratégiákat kell alkalmazni annak érdekében, hogy az átmenet a lehető legzökkenőmentesebb legyen;
- tippek a PE manifesztek Ansible Playbook-ba való átkódolásához;
- Javaslatok az Ansible Tower optimális telepítéséhez.
Üdvözlök mindenkit! A nevem Michael Rau, vezető rendszermérnök vagyok az ActioNetnél, amely a National Oceanic and Atmospheric Administration (NOAA) NESDIS szolgáltatásának dolgozik. Ma a húrvágásról fogunk beszélni – az én saját tapasztalatom a Puppet Enterprise-ból az Ansible Towerbe való vándorlás során. Ennek az előadásnak a témája, hogy „vessek egy pillantást a hegeimre”, amelyek az év elején történt átállás után maradtak. Szeretném megosztani, mit tanultam ezen a folyamaton keresztül. Tehát, ha valami ehhez hasonlót felvállal, tapasztalataim alapján minden további munka nélkül megteheti az átállást.
Az Ansible Fest minden prezentációja elején ehhez hasonló diák látható. Ez a dia bemutatja cégem automatizálásának történetét. Nem vagyok új ebben, mert 2007 óta használom a Puppet/Puppet Enterprise-t. 2016-ban kezdtem el dolgozni az Ansible-vel, és a termék sok más felhasználójához hasonlóan engem is vonzott a parancssor és az egyszerű szkriptek (játékkönyvek) használatával történő „trükkök” lehetősége. 2017 végén megkerestem a vezetőséget az Ansible Towerhez való költözés nyomós okaival kapcsolatban. Egy percben elmesélem az okokat, amelyek arra késztettek, hogy megtegyem ezt a lépést. A menedzsment hozzájárulását követően még több hónapot vett igénybe a terv elkészítése, az átállást idén január-februárban végeztem el. Tehát teljesen elhagytuk a Puppet-et az Ansible javára, és ez nagyszerű dolog.
Az Ansible-ben leginkább az a képesség vonz, hogy szerepeket és játékkönyveket írhatok és használhatok. A szerepkörök kiválóan alkalmasak különálló, de kapcsolódó feladatok létrehozására, és az ezekkel kapcsolatos összes adat egy helyen történő elhelyezésére. A játékkönyv egy YAML szintaxis, parancsfájl, amely leírja egy vagy több gazdagép műveleteit. Ezekről a szolgáltatásokról a felhasználókat tájékoztatom, elsősorban a szoftverfejlesztőket. Az Ansible Tower lehetőséget ad arra, hogy azt mondja: „Nem, nincs shell-hozzáférése, de lehetőséget adok Önnek arra, hogy minden Tower folyamatot lefusson, és amikor szüksége van rá, újraindítsa a szolgáltatást.” Mesélek a munkakörnyezetről és az általunk használt eszközökről.
Ez egy szövetségi LAN, 7 felhő MPLS-en keresztül összekapcsolt fizikai webhely, 140 RHEL szerver, amelyek 99%-a virtuális (vSphere), SuperMicro hardver, NexentaStore hálózati tároló, Cisco, Arista és Cumulus kapcsolókészlet, valamint Fortinet UTM egységes fenyegetéskezelés. eszközök az egyes webhelyeken.
A szövetségi hálózat azt jelenti, hogy a törvényben előírt összes információbiztonsági intézkedést be kell vetnem. Ne feledje, hogy a Puppet Enterprise nem támogatja az általunk használt hardverek többségét. Kénytelenek vagyunk költségvetési hardvert használni, mert az állami szerveknek problémái vannak ennek a kiadási tételnek a finanszírozásával. Ezért vásárolunk SuperMicro hardvert és egyedi alkatrészekből szereljük össze berendezéseinket, melyek karbantartását állami szerződések garantálják. Linuxot használunk, és ez az egyik fontos oka annak, hogy Ansible-re váltsunk.
A Puppet történetünk a következő.
2007-ben volt egy 20-25 csomópontból álló kis hálózatunk, amelyben a Puppet-et telepítettük. Alapvetően ezek a csomópontok csak RedHat „dobozok” voltak. 2010-ben kezdtük el használni a Puppet Dashboard webes felületet 45 csomóponthoz. Ahogy a hálózat tovább bővült, 2014-ben áttértünk a PE 3.3-ra, teljes átállást hajtottunk végre a 75 csomópont jegyzék-átírásával. Ezt azért kellett megtenni, mert a Puppet szereti megváltoztatni a játékszabályokat, és ebben az esetben teljesen megváltoztatták a nyelvet. Egy évvel később, amikor a Puppet Enterprise 3-as verziójának támogatása megszűnt, kénytelenek voltunk áttérni a PE 2015.2-re. Újra át kellett írnunk a manifesztet az új szerverekhez, és 100 csomópontos tartalékkal licencet kellett vásárolnunk, bár akkor még csak 85 csomópontunk volt.
Csak 2 év telt el, és ismét sokat kellett dolgoznunk, hogy átálljunk az új PE 2016.4 verzióra. 300 csomópontra vásároltunk licencet, amiből csak 130 volt. Ismét jelentős változtatásokat kellett végrehajtanunk a manifestben, mert a nyelv új verziójának szintaxisa eltér a 2015-ös verzió nyelvétől. Ennek eredményeként az SCM-ünk az SVN verzióvezérlésről Bitbucketre (Git) váltott. Ez volt a „kapcsolatunk” Bábbal.
Tehát a következő érvekkel el kellett magyaráznom a vezetőségnek, hogy miért kellett egy másik SCM-re váltanunk. Az első a szolgáltatás magas ára. Beszéltem a RedHat srácaival, és azt mondták, hogy egy 300 csomópontos hálózat működtetésének költsége az Ansible Towerrel fele a Puppet Enterprise költségének. Ha az Ansible Engine-t is megvásárolja, a költség körülbelül ugyanannyi lesz, de sokkal több funkciót kap, mint a PE. Mivel a szövetségi költségvetésből finanszírozott állami vállalat vagyunk, ez elég erős érv.
A második érv a sokoldalúság. A Puppet csak azokat a hardvereket támogatja, amelyek rendelkeznek Puppet ügynökkel. Ez azt jelenti, hogy minden kapcsolóra telepíteni kell egy ügynököt, és annak a legújabb verziónak kell lennie. És ha egyes kapcsolói támogatják az egyik verziót, mások pedig egy másikat, telepítenie kell rájuk a PE-ügynök új verzióját, hogy mindegyik ugyanabban az SCM-rendszerben működjön.
Az Ansible Tower rendszer másként működik, mert nincsenek benne ügynökök, de vannak benne olyan modulok, amelyek támogatják a Cisco és az összes többi kapcsolót. Ez az SCM támogatja a Qubes OS-t, a Linuxot és a 4.NET UTM-et. Az Ansible Tower támogatja a NexentaStore hálózati tárolóvezérlőket is, amelyek az Illumos kernelen, egy nyílt forráskódú Unix-alapú operációs rendszeren alapulnak. Ez nagyon kevés támogatás, de az Ansible Tower mégis megteszi.
A harmadik érv, ami nagyon fontos számomra és az adminisztrációnk számára is, a könnyű használhatóság. 10 évet töltöttem a Puppet modulok és a manifest kód elsajátításával, de egy héten belül megtanultam az Ansible-t, mert ezzel az SCM-mel sokkal könnyebb dolgozni. Ha futtatható fájlokat futtat, persze, hacsak nem feleslegesen, akkor intelligens és érzékeny kezelők dolgoznak velük. A YAML-alapú játékkönyvek könnyen megtanulhatók és gyorsan használhatók. Azok, akik még soha nem hallottak a YAML-ről, egyszerűen elolvashatják a szkripteket, és könnyen megérthetik, hogyan működik.
Hogy őszinte legyek, a Puppet sokkal nehezebbé teszi a fejlesztői munkáját, mert a Puppet Master használatán alapul. Ez az egyetlen gép, amely képes kommunikálni a Puppet ügynökökkel. Ha bármilyen változtatást hajtott végre a jegyzékben, és szeretné tesztelni a kódot, akkor át kell írnia a Puppet Master kódját, azaz be kell állítania a Puppet Master /etc/hosts fájlt az összes kliens csatlakoztatásához és a Puppet Server szolgáltatás elindításához. Csak ezt követően tudja tesztelni a hálózati berendezések működését egy gazdagépen. Ez egy meglehetősen fájdalmas eljárás.
Ansible-ben minden sokkal egyszerűbb. Mindössze annyit kell tennie, hogy kódot kell fejlesztenie egy olyan géphez, amely SSH-n keresztül tud kommunikálni a tesztelt gazdagéppel. Ezzel sokkal könnyebb dolgozni.
Az Ansible Tower következő nagy előnye, hogy képes kihasználni a meglévő támogatási rendszert és karbantartani a meglévő hardverkonfigurációt. Ez az SCM minden további lépés nélkül felhasznál minden rendelkezésre álló információt az infrastruktúráról és a hardverről, a virtuális gépekről, a szerverekről stb. Képes kommunikálni az RH Satellite szervereivel, ha van ilyen, és olyan integrációkat biztosít, amelyeket soha nem kaphat meg a Puppettel.
Egy másik fontos dolog a részletes ellenőrzés. Tudja, hogy a Puppet egy moduláris rendszer, egy kliens-szerver alkalmazás, ezért egy hosszú manifestben kell meghatároznia minden gépének meglévő szempontjait. Ebben az esetben 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 megment ettől. Különféle folyamatokat futtathat különféle berendezéseken korlátozás nélkül; elvégezheti az alapvető feladatokat, futtathat más fontos folyamatokat, felállíthat biztonsági rendszert és dolgozhat adatbázisokkal. A Puppet Enterprise-ban mindent megtehet, ami nehéz. Tehát, ha egy gazdagépen konfigurálta, időbe telhet, amíg a változtatások érvénybe lépnek a többi gépen. Az Ansible-ben minden változtatás egyszerre lép életbe.
Végül nézzük a biztonsági modult. Az Ansible Tower egyszerűen elképesztően, nagy pontossággal és körültekintéssel valósítja meg. Hozzáférést biztosíthat a felhasználóknak bizonyos szolgáltatásokhoz vagy adott gazdagépekhez. Ezt az alkalmazottaimmal teszem, akik hozzászoktak ahhoz, hogy Windowson dolgozzanak, korlátozva hozzáférésüket a Linux rendszerhéjhoz. Biztosítom, hogy hozzáférjenek a Towerhez, hogy csak a számukra fontos munkát végezhessék, és csak azokat a szolgáltatásokat üzemeltethessék.
Nézzük meg azokat a dolgokat, amelyeket előre meg kell tennie az Ansible Towerre való átállás megkönnyítése érdekében. Először is fel kell készítenie a felszerelést. Ha az infrastruktúra egyes elemei még nem szerepelnek az adatbázisban, akkor hozzá kell adni azokat. Vannak olyan rendszerek, amelyek nem változtatják meg a jellemzőit, ezért nem szerepelnek a Puppet adatbázisban, de ha nem adja hozzá őket a Towerhez való költözés előtt, akkor számos előnyét elveszíti. Lehet, hogy ez egy „piszkos”, előzetes adatbázis, de tartalmaznia kell az összes eszközzel kapcsolatos információkat. Ezért érdemes egy dinamikus hardveres szkriptet írni, amely az összes infrastruktúra-módosítást automatikusan az adatbázisba helyezi, így az Ansible tudni fogja, mely gazdagépeknek kell jelen lenniük az új rendszeren. Nem kell megmondania ennek az SCM-nek, hogy mely gazdagépeket adta hozzá, és melyek már nem léteznek, mert mindezt automatikusan tudni fogja. Minél több adat van az adatbázisban, annál hasznosabb és rugalmasabb lesz az Ansible. Úgy működik, mintha egyszerűen kiolvasná a hardver állapotának vonalkódját egy adatbázisból.
Szánjon egy kis időt az Ansible parancssorának megismerésére. Futtasson néhány egyéni parancsot a hardver szkriptjének teszteléséhez, írjon és futtasson néhány egyszerű, de hasznos játékkönyv szkriptet, és adott esetben használjon Jinja2 sablonokat. Próbáljon meg írni egy szerepkört és szkriptet egy összetett, többlépéses folyamathoz egy általános, gyakran előforduló hardverkonfiguráció használatával. Játssz ezekkel a dolgokkal, teszteld, hogyan működik. Így megtanulhatja, hogyan kell használni a Towerben használt könyvtárkészítő eszközöket. Már mondtam, hogy körülbelül 3 hónapba telt felkészülni az átállásra. Azt gondolom, hogy tapasztalataim alapján ezt gyorsabban megteheti. Ne tekintse elpazaroltnak ezt az időt, mert később megtapasztalhatja az elvégzett munka minden előnyét.
Ezután el kell döntenie, hogy mit vár el az Ansible Towertől, pontosan mit kell tennie ennek a rendszernek.
Csupasz hardverre, csupasz virtuális gépekre kell telepítenie a rendszert? Vagy szeretné megőrizni a meglévő berendezések eredeti működési feltételeit és beállításait? Ez egy nagyon fontos szempont az állami vállalatok számára, ezért biztosnak kell lennie abban, hogy képes lesz áttelepíteni és telepíteni az Ansible-t a meglévő konfigurációján. Határozza meg az automatizálni kívánt rutin adminisztrációs folyamatokat. Tudja meg, hogy kell-e bizonyos alkalmazásokat és szolgáltatásokat telepítenie az új rendszeren. Készítsen listát arról, hogy mit szeretne tenni, és állítsa be a prioritásokat.
Ezután kezdje el írni a szkriptkódot és a szerepköröket, amelyek lehetővé teszik a tervezett feladatok elvégzését. Kombinálja őket Projects-be, amely a releváns játékkönyvek logikus gyűjteménye. Minden projekt egy külön Git-tárhoz vagy egy másik lerakathoz fog tartozni, attól függően, hogy melyik kódkezelőt használja. Kezelheti a játékkönyv szkripteket és a játékkönyvkönyvtárakat úgy, hogy manuálisan elhelyezi őket a Project Base Path útvonalon a Tower szerveren, vagy elhelyezi a játékkönyvet a Tower által támogatott bármely forráskód-kezelő (SCM) rendszerbe, beleértve a Git, Subversion, Mercurial és Red Hat rendszereket. Insights. Egy projekten belül annyi szkriptet helyezhet el, amennyit csak akar. Például létrehoztam egy alapprojektet, amelyben elhelyeztem egy szkriptet a RedHat alapelemeihez, egy szkriptet a Linux maghoz, és szkripteket a többi alapvonalhoz. Így egy projektben számos szerepkör és forgatókönyv volt, amelyeket egyetlen Git-tárolóból kezeltek.
Ezeknek a dolgoknak a parancssoron keresztüli futtatása jó módja a működésük tesztelésének. Ez felkészíti Önt a torony telepítésére.
Beszéljünk egy kicsit a Puppet manifest átkódolásáról, mert sok időt töltöttem ezzel, amíg rájöttem, mit is kell valójában tenni.
Ahogy korábban mondtam, a Puppet az összes beállítást és hardver opciót egyetlen hosszú jegyzékben tárolja, és ez a jegyzék mindent tárol, amit ennek az SCM-nek meg kell tennie. Az átállás során nem kell az összes feladatot egy listába zsúfolni, hanem gondolja át az új rendszer felépítését: szerepeket, szkripteket, címkéket, csoportokat és azt, hogy mi kerüljön oda. Az autonóm hálózati elemek egy részét csoportokba kell csoportosítani, amelyekhez szkriptek hozhatók létre. Az összetettebb, nagyszámú erőforrást magában foglaló infrastrukturális elemek, beleértve az önálló osztályokat is, szerepekké kombinálhatók. A migráció előtt döntenie kell erről. Ha nagy szerepeket vagy forgatókönyveket hoz létre, amelyek nem férnek el egy képernyőn, akkor címkéket kell használnia az infrastruktúra meghatározott részei rögzítéséhez.
18:00
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com