National Environmental Satellite Data Information Service (NESDIS) hefur lækkað stillingarstjórnunarkostnað fyrir Red Hat Enterprise Linux (RHEL) um 35% með því að flytja úr Puppet Enterprise til Ansible Tower. Í þessu myndbandi „hvernig við gerðum það“ útskýrir kerfisfræðingurinn Michael Rau rökin fyrir þessari flutningi, og deilir gagnlegum ráðum og lærdómi af því að flytja frá einum SCM til annars.
Í þessu myndbandi lærir þú:
- hvernig á að réttlæta fyrir stjórnendum hagkvæmni þess að skipta úr Puppet Enterprise í Ansible Tower;
- hvaða aðferðir á að nota til að gera umskiptin eins mjúk og mögulegt er;
- ábendingar um umkóðun PE birtinga í Ansible Playbook;
- Ráðleggingar um bestu uppsetningu Ansible Tower.
Halló allir, ég heiti Michael Rau, ég er yfirkerfisverkfræðingur hjá ActioNet, sem starfar fyrir National Oceanic and Atmospheric Administration (NOAA) NESDIS þjónustuna. Í dag munum við tala um strengjaklippingu - mína eigin reynslu af því að flytja frá Puppet Enterprise til Ansible Tower. Þema þessarar kynningar er að „kíkja á örin mín“ sem urðu eftir eftir að ég gerði þessa umskipti fyrr á árinu. Mig langar að deila því sem ég lærði í gegnum þetta ferli. Svo þegar þú tekur að þér eitthvað eins og þetta, með því að nota mína reynslu, geturðu gert umskiptin án aukavinnu.
Þú sérð glærur svipaðar þessu í upphafi hverrar kynningar á Ansible Fest. Þessi glæra sýnir sögu sjálfvirkni fyrirtækisins míns. Ég er ekki nýr í þessu því ég hef notað Puppet/Puppet Enterprise síðan 2007. Ég byrjaði að vinna með Ansible árið 2016 og eins og margir aðrir notendur þessarar vöru laðaðist ég að mér möguleikann á „brellum“ með því að nota skipanalínuna og einfaldar forskriftir (leikritabækur). Í lok árs 2017 leitaði ég til stjórnenda minnar um sterkar ástæður fyrir því að flytja í Ansible Tower. Eftir eina mínútu mun ég segja þér frá ástæðunum sem urðu til þess að ég tók þetta skref. Eftir að hafa fengið samþykki stjórnenda tók það nokkra mánuði í viðbót að klára áætlunina og ég gerði umskipti í janúar-febrúar á þessu ári. Þannig að við yfirgáfum Puppet algjörlega í þágu Ansible og það er frábært.
Það sem höfðar mest til mín við Ansible er hæfileikinn til að skrifa og nota hlutverk og leikrit. Hlutverk eru frábær til að búa til sérstök en skyld verkefni og setja öll gögn sem tengjast þessum verkefnum á einn stað. Leikbók er YAML setningafræði, handritaskrá sem lýsir aðgerðum fyrir einn eða fleiri gestgjafa. Ég segi notendum frá þessum eiginleikum, fyrst og fremst hugbúnaðarhönnuðum. Ansible Tower gefur þér möguleika á að segja, "nei, þú hefur ekki skeljaaðgang, en ég gef þér möguleika á að keyra öll Tower ferla og endurræsa þjónustuna þegar þú þarft á henni að halda." Ég mun segja þér frá vinnuumhverfinu og þeim búnaði sem við notum.
Þetta er alríkis staðarnet, 7 líkamlegar síður tengdar með MPLS skýi, 140 RHEL netþjónar, 99% þeirra eru sýndar (vSphere), SuperMicro vélbúnaður, NexentaStore netgeymsla, sett af Cisco, Arista og Cumulus rofum og Fortinet UTM sameinuð ógnarstjórnun verkfæri á hverri síðu.
Alríkisnetið þýðir að ég þarf að nota allar þær upplýsingaöryggisráðstafanir sem kveðið er á um í lögum. Þú ættir að hafa í huga að Puppet Enterprise styður ekki flestan vélbúnað sem við notum. Við neyðumst til að nota fjárhagsáætlunarvélbúnað vegna þess að ríkisstofnanir eiga í vandræðum með að fjármagna þennan kostnaðarlið. Þess vegna kaupum við SuperMicro vélbúnað og setjum saman búnaðinn okkar úr einstökum hlutum, sem er tryggt með ríkissamningum. Við notum Linux og þetta er ein mikilvægasta ástæðan fyrir því að skipta yfir í Ansible.
Saga okkar með Puppet er sem hér segir.
Árið 2007 vorum við með lítið net með 20-25 hnútum, þar sem við settum Puppet. Í grundvallaratriðum voru þessir hnútar bara RedHat „kassar“. Árið 2010 byrjuðum við að nota Puppet Dashboard vefviðmótið fyrir 45 hnúta. Þegar netið hélt áfram að stækka, færðum við okkur yfir í PE 2014 árið 3.3, og gerðum algjöra umskipti með endurskrifun upplýsingaskrár fyrir 75 hnúta. Þetta varð að gera vegna þess að Puppet finnst gaman að breyta leikreglunum og í þessu tilviki breyttu þeir tungumálinu algjörlega. Ári síðar, þegar stuðningi við útgáfu 3 af Puppet Enterprise lauk, neyddumst við til að flytja til PE 2015.2. Við þurftum að endurskrifa upplýsingaskrána aftur fyrir nýju netþjónana og kaupa leyfi með 100 hnúta varaforða, þó að á þeim tíma hefðum við aðeins 85 hnúta.
Aðeins 2 ár eru liðin og við þurftum aftur að leggja mikla vinnu í að flytja yfir í nýju útgáfuna PE 2016.4. Við keyptum leyfi fyrir 300 hnúta, með aðeins 130. Við þurftum aftur að gera miklar breytingar á upplýsingaskránni vegna þess að nýja útgáfan af tungumálinu var með aðra setningafræði en tungumálið í 2015 útgáfunni. Fyrir vikið skipti SCM okkar úr SVN útgáfustýringu yfir í Bitbucket (Git). Þetta var „samband“ okkar við Puppet.
Svo ég þurfti að útskýra fyrir stjórnendum hvers vegna við þurftum að fara yfir í annan SCM með því að nota eftirfarandi rök. Í fyrsta lagi er hátt verð þjónustunnar. Ég talaði við strákana á RedHat og þeir sögðu að kostnaðurinn við að reka 300 hnúta net með Ansible Tower væri helmingi hærri en Puppet Enterprise. Ef þú kaupir líka Ansible Engine verður kostnaðurinn um það bil sá sami, en þú færð miklu fleiri eiginleika en PE. Þar sem við erum ríkisfyrirtæki sem fjármagnað er af alríkisfjárlögum er þetta ansi öflug rök.
Önnur rökin eru fjölhæfni. Puppet styður aðeins vélbúnað sem hefur Puppet umboðsmann. Þetta þýðir að umboðsmaður verður að vera uppsettur á öllum rofum og það verður að vera nýjasta útgáfan. Og ef sumir af rofunum þínum styðja eina útgáfu, og sumir styðja aðra, þarftu að setja upp nýja útgáfu af PE umboðsmanninum á þá svo þeir geti allir unnið í sama SCM kerfinu.
Ansible Tower kerfið virkar öðruvísi vegna þess að það hefur enga umboðsmenn, en það hefur einingar sem styðja Cisco rofa og alla aðra rofa. Þessi SCM styður Qubes OS, Linux og 4.NET UTM. Ansible Tower styður einnig NexentaStore netgeymslustýringar byggða á Illumos kjarnanum, opnu Unix-stýrikerfi. Þetta er mjög lítill stuðningur, en Ansible Tower gerir það samt.
Þriðja röksemdin, sem er mjög mikilvæg bæði fyrir mig og stjórnsýsluna okkar, er auðveld í notkun. Ég eyddi 10 árum í að ná tökum á Puppet einingar og manifest kóða, en ég lærði Ansible innan viku vegna þess að þetta SCM er miklu auðveldara að vinna með. Ef þú keyrir executable skrár, auðvitað, nema þú gerir það að óþörfu, þá vinna greindir og móttækilegir meðhöndlarar með þeim. YAML-undirstaða leikbók er auðvelt að læra og fljótlegt í notkun. Þeir sem hafa aldrei heyrt um YAML áður geta einfaldlega lesið handritin og skilið auðveldlega hvernig það virkar.
Til að vera heiðarlegur, Puppet gerir starf þitt sem þróunaraðila mun erfiðara vegna þess að það byggist á því að nota Puppet Master. Það er eina vélin sem hefur leyfi til að eiga samskipti við umboðsmenn Puppet. Ef þú hefur gert einhverjar breytingar á upplýsingaskránni og vilt prófa kóðann þinn verður þú að endurskrifa kóðann fyrir Puppet Master, það er að stilla Puppet Master /etc/hosts skrána til að tengja alla viðskiptavini og ræsa Puppet Server þjónustuna. Aðeins eftir þetta geturðu prófað virkni netbúnaðar á einum gestgjafa. Þetta er frekar sársaukafull aðferð.
Allt er miklu einfaldara í Ansible. Allt sem þú þarft að gera er að þróa kóða fyrir vél sem getur átt samskipti í gegnum SSH við gestgjafann sem er í prófun. Þetta er miklu auðveldara að vinna með.
Næsti stóri kostur Ansible Tower er hæfileikinn til að nýta núverandi stuðningskerfi og viðhalda núverandi vélbúnaðaruppsetningu. Þessi SCM notar allar tiltækar upplýsingar um innviði þína og vélbúnað, sýndarvélar, netþjóna o.s.frv. án frekari skrefa. Það getur talað við RH Satellite netþjóna þína, ef þú ert með einn, og gefur þér samþættingar sem þú munt aldrei fá með Puppet.
Annað mikilvægt atriði er nákvæm eftirlit. Þú veist að Puppet er mátkerfi, það er biðlara-miðlaraforrit, svo þú verður að skilgreina núverandi þætti allra véla þinna í einni langri upplýsingaskrá. Í þessu tilviki verður að prófa ástand hvers einstaks þáttar kerfisins á hálftíma fresti - þetta er sjálfgefið tímabil. Svona virkar Puppet.
Tower bjargar þér frá því. Hægt er að keyra margvíslega ferla á ýmsum búnaði án takmarkana, hægt er að vinna grunnvinnu, keyra önnur mikilvæg ferla, setja upp öryggiskerfi og vinna með gagnagrunna. Þú getur gert allt sem er erfitt í Puppet Enterprise. Þannig að ef þú stilltir það á einum gestgjafa mun það taka tíma fyrir breytingarnar að taka gildi á þeim sem eftir eru. Í Ansible taka allar breytingar gildi á sama tíma.
Að lokum skulum við líta á öryggiseininguna. Ansible Tower útfærir það einfaldlega ótrúlega, af mikilli nákvæmni og umhyggju. Þú getur veitt notendum aðgang að tiltekinni þjónustu eða tilteknum gestgjöfum. Ég geri þetta með starfsmönnum mínum sem eru vanir að vinna á Windows, takmarka aðgang þeirra að Linux skelinni. Ég tryggi að þeir hafi aðgang að Tower þannig að þeir geti aðeins unnið verkið og rekið aðeins þá þjónustu sem snertir þá.
Við skulum skoða hlutina sem þú þarft að gera fyrirfram til að gera umskipti þín yfir í Ansible Tower auðveldari. Fyrst af öllu þarftu að undirbúa búnaðinn þinn. Ef sumir þættir innviða þíns eru ekki þegar í gagnagrunninum þarftu að bæta þeim við þar. Það eru til kerfi sem breyta ekki eiginleikum sínum og eru þar af leiðandi ekki í Puppet gagnagrunninum, en ef þú bætir þeim ekki við þar áður en þú ferð yfir í Tower muntu tapa ýmsum kostum. Þetta getur verið „óhreinn“ bráðabirgðagagnagrunnur, en hann ætti að innihalda upplýsingar um allan þann búnað sem þú hefur. Þess vegna ættir þú að skrifa kraftmikið vélbúnaðarforskrift sem mun sjálfkrafa ýta öllum innviðabreytingum inn í gagnagrunninn, þá mun Ansible vita hvaða vélar eiga að vera til staðar á nýja kerfinu. Þú þarft ekki að segja þessum SCM hvaða vélar þú bættir við og hvaða vélar eru ekki lengur til, því það mun vita allt þetta sjálfkrafa. Því fleiri gögn sem eru í gagnagrunninum því gagnlegri og sveigjanlegri verður Ansible. Það virkar eins og það lesi einfaldlega stöðu strikamerki vélbúnaðar úr gagnagrunni.
Eyddu smá tíma í að kynnast skipanalínunni í Ansible. Keyrðu nokkrar sérsniðnar skipanir til að prófa vélbúnaðarforskriftina, skrifaðu og keyrðu nokkur einföld en gagnleg leikbókarforskrift, notaðu Jinja2 sniðmát þar sem við á. Prófaðu að skrifa hlutverk og handrit fyrir flókið, margra þrepa ferli með því að nota algenga, algenga vélbúnaðaruppsetningu. Spilaðu með þessa hluti, prófaðu hvernig það virkar. Þannig munt þú læra hvernig á að nota verkfæri til að búa til bókasafn sem notuð eru í Tower. Ég hef þegar sagt að það hafi tekið mig um 3 mánuði að undirbúa mig fyrir umskiptin. Ég held að miðað við mína reynslu muntu geta gert þetta hraðar. Ekki telja þennan tíma sóun, því seinna muntu upplifa alla kosti vinnunnar.
Næst þarftu að ákveða hvað þú býst við frá Ansible Tower, hvað nákvæmlega þetta kerfi ætti að gera fyrir þig.
Þarftu að dreifa kerfinu á berum vélbúnaði, á berum sýndarvélum? Eða viltu viðhalda upprunalegum rekstrarskilyrðum og stillingum núverandi búnaðar? Þetta er mjög mikilvægur þáttur fyrir opinber fyrirtæki, svo þú þarft að vera viss um að þú getir flutt og sett Ansible á núverandi stillingar þínar. Tilgreindu venjubundin stjórnunarferli sem þú vilt gera sjálfvirkan. Finndu út hvort þú þarft að nota tiltekin forrit og þjónustu á nýja kerfinu. Búðu til lista yfir það sem þú vilt gera og forgangsraðaðu því.
Byrjaðu síðan að skrifa handritskóða og hlutverk sem gera þau verkefni sem þú ætlar að klára. Sameina þau í Projects, rökrétt safn af viðeigandi leikbókum. Hvert verkefni mun tilheyra sérstakri Git geymslu eða annarri geymslu eftir því hvaða kóðastjóra þú notar. Þú getur stjórnað leikbókarforskriftum og leikbókaskrám með því að setja þau handvirkt í Project Base Path á Tower-þjóninum eða með því að setja leikbókina í hvaða frumkóðastjórnunarkerfi (SCM) sem Tower styður, þar á meðal Git, Subversion, Mercurial og Red Hat Innsýn. Innan eins verkefnis geturðu sett eins mörg forskriftir og þú vilt. Til dæmis bjó ég til eitt grunnverkefni þar sem ég setti handrit fyrir RedHat kjarnaþættina, handrit fyrir Linux kjarna og forskriftir fyrir restina af grunnlínunum. Þannig að í einu verkefni voru margvísleg hlutverk og atburðarás sem var stjórnað úr einni Git geymslu.
Að keyra alla þessa hluti í gegnum skipanalínuna er góð leið til að prófa virkni þeirra. Þetta mun undirbúa þig fyrir Tower uppsetninguna.
Við skulum tala aðeins um umkóðun Puppet manifestið, því ég eyddi miklum tíma í þetta þar til ég komst að því hvað raunverulega þyrfti að gera.
Eins og ég sagði áður, geymir Puppet allar stillingar og vélbúnaðarvalkosti í einni langri upplýsingaskrá og þessi upplýsingaskrá geymir allt sem þessi SCM ætti að gera. Þegar þú gerir umskipti þarftu ekki að troða öllum verkefnum þínum á einn lista heldur skaltu hugsa um uppbyggingu nýja kerfisins: hlutverk, forskriftir, merki, hópa og hvað ætti að fara þar. Sumir af sjálfstæðu netþáttunum ættu að vera flokkaðir í hópa sem hægt er að búa til forskriftir fyrir. Hægt er að sameina flóknari innviðaþætti sem fela í sér mikinn fjölda auðlinda, þar á meðal sjálfstæða flokka, í hlutverk. Áður en þú flytur þarftu að ákveða þetta. Ef þú ert að búa til stór hlutverk eða atburðarás sem passa ekki á einn skjá ættirðu að nota merki til að geta fanga tiltekna hluta innviðanna.
18:00
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com