Die National Environmental Satellite Data Information Service (NESDIS) het sy konfigurasiebestuurskoste vir Red Hat Enterprise Linux (RHEL) met 35% verminder deur van Puppet Enterprise na Ansible Tower te migreer. In hierdie "hoe ons dit gedoen het"-video, verduidelik stelselingenieur Michael Rau die saak vir hierdie migrasie, en deel nuttige wenke en lesse wat geleer is om van een SCM na 'n ander te beweeg.
Uit hierdie video sal jy leer:
- hoe om die haalbaarheid van die oorskakeling van Puppet Enterprise na Ansible Tower aan die bestuur te regverdig;
- watter strategieë om te gebruik om die oorgang so glad moontlik te maak;
- wenke vir die transkodering van PE-manifeste in Ansible Playbook;
- Aanbevelings vir optimale installasie van Ansible Tower.
Hallo almal, my naam is Michael Rau, ek is 'n Senior Stelselingenieur by ActioNet, wat vir die Nasionale Oseaniese en Atmosferiese Administrasie (NOAA) NESDIS-diens werk. Vandag sal ons praat oor tou snoei - my eie ervaring van migreer van Puppet Enterprise na Ansible Tower. Die tema van hierdie aanbieding is om te "kyk na my letsels" wat gelaat is nadat ek vroeër die jaar hierdie oorgang gemaak het. Ek wil deel wat ek deur hierdie proses geleer het. So wanneer jy so iets aanpak, deur my ervaring te gebruik, kan jy die oorgang maak sonder enige ekstra werk.
Jy sien skyfies soortgelyk aan hierdie aan die begin van elke aanbieding by Ansible Fest. Hierdie skyfie skets die geskiedenis van my maatskappy se outomatisering. Ek is nie nuut hierin nie, want ek gebruik Puppet/Puppet Enterprise sedert 2007. Ek het in 2016 met Ansible begin werk, en soos baie ander gebruikers van hierdie produk, was ek aangetrokke deur die moontlikheid van "toertjies" met behulp van die opdragreël en eenvoudige skrifte (speelboeke). Aan die einde van 2017 het ek my bestuur genader oor die sterk redes om na Ansible Tower te verhuis. Ek sal jou binne 'n minuut vertel van die redes wat my aangespoor het om hierdie stap te neem. Nadat ek die bestuur se toestemming ontvang het, het dit nog etlike maande geneem om die plan te voltooi, en ek het die oorgang in Januarie-Februarie vanjaar gemaak. So, ons het Puppet heeltemal laat vaar ten gunste van Ansible, en dit is 'n wonderlike ding.
Wat my die meeste aanspreek van Ansible is die vermoë om rolle en speelboeke te skryf en te gebruik. Rolle is ideaal om afsonderlike maar verwante take te skep en al die data wat met daardie take verband hou, op een plek te plaas. 'n Speelboek is 'n YAML-sintaksis, skriflêer wat aksies vir een of meer gashere beskryf. Ek vertel gebruikers van hierdie kenmerke, hoofsaaklik sagteware-ontwikkelaars. Ansible Tower gee jou die vermoë om te sê, "nee, jy het nie doptoegang nie, maar ek gee jou die vermoë om alle Tower-prosesse te laat loop en die diens te herbegin wanneer jy dit nodig het." Ek sal jou vertel van die werksomgewing en die toerusting wat ons gebruik.
Dit is 'n federale LAN, 7 fisiese werwe gekoppel via wolk MPLS, 140 RHEL-bedieners, waarvan 99% virtuele (vSphere), SuperMicro-hardeware, NexentaStore-netwerkberging, 'n stel Cisco-, Arista- en Cumulus-skakelaars en Fortinet UTM verenigde bedreigingsbestuur is gereedskap op elke webwerf.
Die federale netwerk beteken dat ek al die inligtingsekuriteitsmaatreëls moet gebruik wat deur die wet voorsien word. Jy moet in gedagte hou dat Puppet Enterprise nie die meeste van die hardeware wat ons gebruik ondersteun nie. Ons word gedwing om begrotingshardeware te gebruik omdat regeringsagentskappe probleme ondervind om hierdie uitgawe-item te finansier. Dit is hoekom ons SuperMicro-hardeware koop en ons toerusting saamstel uit individuele onderdele, waarvan die instandhouding deur staatskontrakte gewaarborg word. Ons gebruik Linux en dit is een van die belangrike redes om oor te skakel na Ansible.
Ons geskiedenis met Puppet is soos volg.
In 2007 het ons 'n klein netwerk van 20-25 nodusse gehad, waarin ons Puppet ontplooi het. Basies was hierdie nodusse net RedHat "bokse". In 2010 het ons die Puppet Dashboard-webkoppelvlak vir 45 nodusse begin gebruik. Soos die netwerk aanhou uitbrei het, het ons in 2014 na PE 3.3 oorgeskuif en 'n volledige oorgang gemaak met 'n manifes-herskryf vir 75 nodusse. Dit moes gedoen word omdat Puppet daarvan hou om die reëls van die spel te verander, en in hierdie geval het hulle die taal heeltemal verander. 'n Jaar later, toe ondersteuning vir weergawe 3 van Puppet Enterprise beëindig is, was ons gedwing om na PE 2015.2 te migreer. Ons moes die manifes weer vir die nuwe bedieners herskryf en 'n lisensie koop met 'n reserwe van 100 nodusse, hoewel ons op daardie tydstip net 85 nodusse gehad het.
Slegs 2 jaar het verloop, en ons moes weer baie werk doen om na die nuwe weergawe PE 2016.4 te migreer. Ons het 'n lisensie vir 300 nodusse gekoop, met slegs 130. Ons moes weer groot veranderinge aan die manifes aanbring omdat die nuwe weergawe van die taal 'n ander sintaksis as die taal van die 2015-weergawe gehad het. As gevolg hiervan het ons SCM oorgeskakel van SVN-weergawebeheer na Bitbucket (Git). Dit was ons "verhouding" met Puppet.
So, ek moes aan die bestuur verduidelik waarom ons na 'n ander SCM moes oorskuif deur die volgende argumente te gebruik. Die eerste is die hoë prys van die diens. Ek het met die ouens by RedHat gepraat en hulle het gesê dat die koste van die bestuur van 'n 300 node-netwerk met Ansible Tower die helfte van die koste van Puppet Enterprise is. As jy ook Ansible Engine koop, sal die koste omtrent dieselfde wees, maar jy sal baie meer funksies as PE kry. Aangesien ons 'n staatsbeheerde maatskappy is wat uit die federale begroting gefinansier word, is dit 'n redelik kragtige argument.
Die tweede argument is veelsydigheid. Puppet ondersteun slegs hardeware wat 'n Puppet-agent het. Dit beteken dat 'n agent op alle skakelaars geïnstalleer moet word, en dit moet die nuutste weergawe wees. En as sommige van jou skakelaars een weergawe ondersteun, en sommige 'n ander, sal jy 'n nuwe weergawe van die PE-agent op hulle moet installeer sodat hulle almal in dieselfde SCM-stelsel kan werk.
Die Ansible Tower-stelsel werk anders omdat dit nie enige agente het nie, maar dit het wel modules wat Cisco-skakelaars en alle ander skakelaars ondersteun. Hierdie SCM ondersteun Qubes OS, Linux en 4.NET UTM. Ansible Tower ondersteun ook NexentaStore-netwerkbergingbeheerders gebaseer op die Illumos-kern, 'n oopbron Unix-gebaseerde bedryfstelsel. Dit is baie min ondersteuning, maar Ansible Tower doen dit in elk geval.
Die derde argument, wat vir my sowel as vir ons administrasie baie belangrik is, is gebruiksgemak. Ek het 10 jaar spandeer om Puppet-modules en manifestkode te bemeester, maar ek het Ansible binne 'n week geleer, want hierdie SCM is baie makliker om mee te werk. As jy natuurlik uitvoerbare lêers laat loop, tensy jy dit onnodig doen, werk intelligente en responsiewe hanteerders daarmee saam. YAML-gebaseerde speelboeke is maklik om te leer en vinnig om te gebruik. Diegene wat nog nooit van YAML gehoor het nie, kan eenvoudig die skrifte lees en maklik verstaan hoe dit werk.
Om eerlik te wees, Puppet maak jou werk as 'n ontwikkelaar baie moeiliker omdat dit gebaseer is op die gebruik van Puppet Master. Dit is die enigste masjien wat toegelaat word om met Puppet-agente te kommunikeer. As jy enige veranderinge aan die manifes aangebring het en jou kode wil toets, moet jy die kode vir Puppet Master herskryf, dit wil sê, die Puppet Master /etc/hosts-lêer konfigureer om alle kliënte te verbind en die Puppet Server-diens te begin. Eers hierna sal jy die werking van netwerktoerusting op een gasheer kan toets. Dit is 'n taamlik pynlike prosedure.
Alles is baie eenvoudiger in Ansible. Al wat u hoef te doen is om kode te ontwikkel vir 'n masjien wat via SSH kan kommunikeer met die gasheer wat getoets word. Dit is baie makliker om mee te werk.
Die volgende groot voordeel van Ansible Tower is die vermoë om jou bestaande ondersteuningstelsel te benut en jou bestaande hardeware-konfigurasie te handhaaf. Hierdie SCM gebruik alle beskikbare inligting oor jou infrastruktuur en hardeware, virtuele masjiene, bedieners, ens. sonder enige bykomende stappe. Dit kan met jou RH Satellite-bedieners praat, as jy een het, en gee jou integrasies wat jy nooit met Puppet sal kry nie.
Nog 'n belangrike ding is gedetailleerde beheer. Jy weet dat Puppet 'n modulêre stelsel is, dit is 'n kliënt-bediener-toepassing, so jy moet die bestaande aspekte van al jou masjiene in een lang manifes definieer. In hierdie geval moet die toestand van elke individuele element van die stelsel elke halfuur getoets word - dit is die verstekperiode. Dit is hoe Puppet werk.
Tower red jou daarvan. Jy kan 'n verskeidenheid prosesse sonder beperkings op 'n verskeidenheid toerusting laat loop; jy kan basiese werk doen, ander belangrike prosesse uitvoer, 'n sekuriteitstelsel opstel en met databasisse werk. Jy kan alles doen wat moeilik is in Puppet Enterprise. Dus, as jy dit op een gasheer gekonfigureer het, sal dit tyd neem vir die veranderinge om in werking te tree op die oorblywende gashere. In Ansible tree alle veranderinge op dieselfde tyd in werking.
Laastens, kom ons kyk na die sekuriteitsmodule. Ansible Tower implementeer dit eenvoudig ongelooflik, met groot presisie en sorg. Jy kan gebruikers toegang gee tot spesifieke dienste of aan spesifieke gashere. Ek doen dit met my werknemers wat gewoond is om op Windows te werk, wat hul toegang tot die Linux-dop beperk. Ek verseker dat hulle toegang tot Tower het sodat hulle net die werk kan doen en net die dienste kan bedryf wat vir hulle relevant is.
Kom ons kyk na die dinge wat jy voor die tyd moet doen om jou oorgang na Ansible Tower makliker te maak. Eerstens moet u u toerusting voorberei. As sommige elemente van jou infrastruktuur nie reeds in die databasis is nie, moet jy dit daar byvoeg. Daar is stelsels wat nie hul eienskappe verander nie en dus nie in die Puppet-databasis is nie, maar as jy dit nie daar byvoeg voordat jy na Tower beweeg nie, sal jy 'n aantal voordele verloor. Dit kan 'n "vuil", voorlopige databasis wees, maar dit moet inligting bevat oor al die toerusting wat jy het. Daarom moet jy 'n dinamiese hardeware script skryf wat outomaties alle infrastruktuurveranderinge in die databasis sal stoot, dan sal Ansible weet watter gashere op die nuwe stelsel teenwoordig moet wees. Jy hoef nie vir hierdie SCM te sê watter gashere jy bygevoeg het en watter gashere nie meer bestaan nie, want dit sal dit alles outomaties weet. Hoe meer data daar in die databasis is, hoe meer bruikbaar en buigsaam sal Ansible wees. Dit werk asof dit bloot die hardeware-statusstrepieskode vanaf 'n databasis lees.
Spandeer tyd om vertroud te raak met die opdragreël in Ansible. Voer 'n paar pasgemaakte opdragte uit om die hardeware-skrip te toets, skryf en voer 'n paar eenvoudige maar nuttige speelboek-skrifte uit, gebruik Jinja2-sjablone waar toepaslik. Probeer om 'n rol en skrif vir 'n komplekse, veelstap-proses te skryf deur 'n algemene hardeware-konfigurasie te gebruik. Speel met hierdie dinge, toets hoe dit werk. Op hierdie manier sal jy leer hoe om die biblioteekskeppingnutsmiddels wat in Tower gebruik word, te gebruik. Ek het reeds gesê dat dit my ongeveer 3 maande geneem het om vir die oorgang voor te berei. Ek dink dat op grond van my ervaring, jy dit vinniger sal kan doen. Moenie hierdie tyd as gemors beskou nie, want later sal jy al die voordele ervaar van die werk wat gedoen is.
Vervolgens moet jy besluit wat jy van Ansible Tower verwag, wat presies hierdie stelsel vir jou moet doen.
Moet u die stelsel op blote hardeware, op kaal virtuele masjiene ontplooi? Of wil jy die oorspronklike bedryfstoestande en instellings van bestaande toerusting handhaaf? Dit is 'n baie belangrike aspek vir publieke maatskappye, so jy moet seker wees dat jy in staat sal wees om Ansible op jou bestaande konfigurasie te migreer en te ontplooi. Identifiseer roetine administratiewe prosesse wat jy wil outomatiseer. Vind uit of jy spesifieke toepassings en dienste op die nuwe stelsel moet ontplooi. Maak 'n lys van wat jy wil doen en prioritiseer dit.
Begin dan om skrifkode en rolle te skryf wat die take wat jy beplan om te voltooi sal moontlik maak. Kombineer hulle in Projects, 'n logiese versameling relevante speelboeke. Elke projek sal aan 'n aparte Git-bewaarplek of 'n ander bewaarplek behoort, afhangende van watter kodebestuurder jy gebruik. Jy kan speelboekskrifte en speelboekgidse bestuur deur dit handmatig in die Project Base Path op die Tower-bediener te plaas, of deur die speelboek in enige bronkodebestuurstelsel (SCM) te plaas wat deur Tower ondersteun word, insluitend Git, Subversion, Mercurial en Red Hat Insigte. Binne een projek kan jy soveel skrifte plaas as wat jy wil. Ek het byvoorbeeld een basiese projek geskep waarin ek 'n skrif vir die RedHat-kernelemente, 'n skrif vir die Linux-kern en skrifte vir die res van die basislyne geplaas het. Dus, in een projek was daar 'n verskeidenheid rolle en scenario's wat vanuit een Git-bewaarplek bestuur is.
Om al hierdie dinge deur die opdragreël te laat loop, is 'n goeie manier om hul funksionaliteit te toets. Dit sal jou voorberei vir die toring-installasie.
Kom ons praat 'n bietjie oor die transkodering van die Puppet-manifes, want ek het baie tyd hieraan spandeer totdat ek uitgevind het wat eintlik gedoen moet word.
Soos ek voorheen gesê het, stoor Puppet al die instellings en hardeware-opsies in een lang manifes, en hierdie manifes stoor alles wat hierdie SCM veronderstel is om te doen. Wanneer jy die oorgang maak, hoef jy nie al jou take in een lys te prop nie; dink eerder aan die struktuur van die nuwe stelsel: rolle, skrifte, etikette, groepe en wat daarheen moet gaan. Sommige van die outonome netwerkelemente moet in groepe gegroepeer word waarvoor skrifte geskep kan word. Meer komplekse infrastruktuurelemente wat 'n groot aantal hulpbronne behels, insluitend selfstandige klasse, kan in rolle gekombineer word. Voordat jy migreer, moet jy hieroor besluit. As jy groot rolle of scenario's skep wat nie op een skerm pas nie, moet jy merkers gebruik om spesifieke dele van die infrastruktuur te kan vasvang.
18:00
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com