National Environmental Satellite Data Information Service (NESDIS) znížil svoje náklady na správu konfigurácie pre Red Hat Enterprise Linux (RHEL) o 35 % migráciou z Puppet Enterprise na Ansible Tower. V tomto videu „ako sme to urobili“ vysvetľuje systémový inžinier Michael Rau dôvod tejto migrácie a zdieľa užitočné tipy a ponaučenia z prechodu od jedného SCM k druhému.
Z tohto videa sa dozviete:
- ako zdôvodniť manažmentu uskutočniteľnosť prechodu z Puppet Enterprise na Ansible Tower;
- aké stratégie použiť, aby bol prechod čo najhladší;
- tipy na prekódovanie PE manifestov do Ansible Playbook;
- Odporúčania pre optimálnu inštaláciu Ansible Tower.
Ahojte všetci, volám sa Michael Rau, som senior systémový inžinier v spoločnosti ActioNet, ktorá pracuje pre službu NESDIS National Oceanic and Atmospheric Administration (NOAA). Dnes si povieme niečo o orezávaní strún – mojej vlastnej skúsenosti s migráciou z Puppet Enterprise do Ansible Tower. Témou tejto prezentácie je „pozrieť sa na moje jazvy“, ktoré mi zostali po tomto prechode začiatkom roka. Chcem sa podeliť o to, čo som sa počas tohto procesu naučil. Takže keď sa pustíte do niečoho podobného, s využitím mojich skúseností môžete prechod vykonať bez akejkoľvek ďalšej práce.
Podobné snímky vidíte na začiatku každej prezentácie na Ansible Feste. Táto snímka načrtáva históriu automatizácie mojej spoločnosti. Nie som v tom nový, pretože Puppet/Puppet Enterprise používam od roku 2007. S Ansible som začal pracovať v roku 2016 a rovnako ako mnohých iných používateľov tohto produktu ma upútala možnosť „trikov“ pomocou príkazového riadku a jednoduchých skriptov (playbookov). Koncom roka 2017 som oslovil svoje vedenie ohľadom závažných dôvodov presťahovania sa do Ansible Tower. O chvíľu vám poviem o dôvodoch, ktoré ma viedli k tomuto kroku. Po získaní súhlasu vedenia trvalo niekoľko mesiacov, kým sa plán dokončil, a prechod som uskutočnil v januári až februári tohto roku. Takže sme úplne opustili Puppet v prospech Ansible a je to skvelá vec.
Čo ma na Ansible najviac oslovuje, je schopnosť písať a používať role a playbooky. Roly sú skvelé na vytváranie odlišných, ale súvisiacich úloh a ukladanie všetkých údajov súvisiacich s týmito úlohami na jedno miesto. Playbook je syntax YAML, súbor skriptu, ktorý popisuje akcie pre jedného alebo viacerých hostiteľov. O týchto funkciách hovorím používateľom, predovšetkým vývojárom softvéru. Ansible Tower vám dáva možnosť povedať: „Nie, nemáte prístup k shellu, ale dávam vám možnosť spustiť všetky procesy Tower a reštartovať službu, keď to potrebujete.“ Poviem vám o pracovnom prostredí a vybavení, ktoré používame.
Ide o federálnu sieť LAN, 7 fyzických lokalít pripojených cez cloud MPLS, 140 serverov RHEL, z ktorých 99 % je virtuálnych (vSphere), hardvér SuperMicro, sieťové úložisko NexentaStore, sadu prepínačov Cisco, Arista a Cumulus a jednotnú správu hrozieb Fortinet UTM. nástroje na každej stránke.
Federálna sieť znamená, že musím použiť všetky opatrenia na zabezpečenie informácií stanovené zákonom. Mali by ste mať na pamäti, že Puppet Enterprise nepodporuje väčšinu hardvéru, ktorý používame. Sme nútení používať rozpočtový hardvér, pretože vládne agentúry majú problémy s financovaním tejto výdavkovej položky. Preto nakupujeme hardvér SuperMicro a naše zariadenia skladáme z jednotlivých dielov, ktorých údržbu garantujú štátne zákazky. Používame Linux a to je jeden z dôležitých dôvodov prechodu na Ansible.
Naša história s Puppet je nasledovná.
V roku 2007 sme mali malú sieť 20-25 uzlov, do ktorých sme nasadili Puppet. V podstate boli tieto uzly len „boxy“ RedHat. V roku 2010 sme začali používať webové rozhranie Puppet Dashboard pre 45 uzlov. Keď sa sieť naďalej rozširovala, v roku 2014 sme prešli na PE 3.3, čím sme vykonali úplný prechod s prepísaním manifestu pre 75 uzlov. Muselo sa to urobiť, pretože Puppet rád mení pravidlá hry a v tomto prípade úplne zmenili jazyk. O rok neskôr, keď podpora pre verziu 3 Puppet Enterprise skončila, sme boli nútení prejsť na PE 2015.2. Museli sme znova prepísať manifest pre nové servery a zakúpiť licenciu s rezervou 100 uzlov, hoci v tom čase sme mali len 85 uzlov.
Prešli len 2 roky a opäť sme museli urobiť veľa práce, aby sme migrovali na novú verziu PE 2016.4. Kúpili sme licenciu pre 300 uzlov, pričom sme ich mali len 130. Opäť sme museli urobiť veľké zmeny v manifeste, pretože nová verzia jazyka mala inú syntax ako jazyk verzie z roku 2015. V dôsledku toho naše SCM prešlo z kontroly verzií SVN na Bitbucket (Git). Toto bol náš „vzťah“ s Puppet.
Takže som musel vysvetliť vedeniu, prečo sme sa museli presunúť do iného SCM, pomocou nasledujúcich argumentov. Prvým je vysoká cena služby. Hovoril som s chalanmi z RedHat a povedali, že náklady na prevádzku 300-uzlovej siete s Ansible Tower sú polovičné ako náklady na Puppet Enterprise. Ak si kúpite aj Ansible Engine, cena bude približne rovnaká, ale získate oveľa viac funkcií ako PE. Keďže sme štátny podnik financovaný z federálneho rozpočtu, je to dosť silný argument.
Druhým argumentom je všestrannosť. Puppet podporuje iba hardvér, ktorý má agenta Puppet. To znamená, že na všetkých prepínačoch musí byť nainštalovaný agent a musí to byť najnovšia verzia. A ak niektoré z vašich prepínačov podporujú jednu verziu a niektoré inú, budete musieť na ne nainštalovať novú verziu agenta PE, aby mohli všetky fungovať v rovnakom systéme SCM.
Systém Ansible Tower funguje inak, pretože nemá žiadnych agentov, ale má moduly, ktoré podporujú Cisco prepínače a všetky ostatné prepínače. Tento SCM podporuje Qubes OS, Linux a 4.NET UTM. Ansible Tower tiež podporuje radiče sieťového úložiska NexentaStore založené na jadre Illumos, open-source operačnom systéme založenom na Unixe. Toto je veľmi malá podpora, ale Ansible Tower to aj tak robí.
Tretím argumentom, ktorý je veľmi dôležitý pre mňa aj pre našu administratívu, je jednoduchosť používania. Strávil som 10 rokov ovládaním modulov Puppet a kódu manifestu, ale Ansible som sa naučil za týždeň, pretože s týmto SCM sa oveľa ľahšie pracuje. Ak spúšťate spustiteľné súbory, samozrejme, pokiaľ to nerobíte zbytočne, potom s nimi pracujú inteligentné a pohotové obslužné programy. Príručky založené na YAML sa dajú ľahko naučiť a rýchlo sa používajú. Tí, ktorí nikdy predtým nepočuli o YAML, si môžu jednoducho prečítať skripty a ľahko pochopiť, ako to funguje.
Aby som bol úprimný, Puppet robí vašu prácu vývojára oveľa ťažšou, pretože je založený na používaní Puppet Master. Je to jediný stroj, ktorý môže komunikovať s bábkovými agentmi. Ak ste vykonali nejaké zmeny v manifeste a chcete otestovať svoj kód, musíte prepísať kód pre Puppet Master, to znamená nakonfigurovať súbor Puppet Master /etc/hosts na pripojenie všetkých klientov a spustenie služby Puppet Server. Až potom budete môcť otestovať fungovanie sieťového zariadenia na jednom hostiteľovi. Ide o pomerne bolestivý postup.
V Ansible je všetko oveľa jednoduchšie. Všetko, čo musíte urobiť, je vyvinúť kód pre stroj, ktorý dokáže komunikovať cez SSH s testovaným hostiteľom. S tým sa pracuje oveľa jednoduchšie.
Ďalšou veľkou výhodou Ansible Tower je schopnosť využiť váš existujúci podporný systém a udržiavať vašu existujúcu hardvérovú konfiguráciu. Tento SCM používa všetky dostupné informácie o vašej infraštruktúre a hardvéri, virtuálnych strojoch, serveroch atď. bez akýchkoľvek ďalších krokov. Dokáže komunikovať s vašimi RH Satellite servermi, ak nejaký máte, a poskytuje vám integrácie, ktoré s Puppet nikdy nezískate.
Ďalšou dôležitou vecou je detailné ovládanie. Viete, že Puppet je modulárny systém, je to aplikácia klient-server, takže musíte definovať existujúce aspekty všetkých vašich počítačov v jednom dlhom manifeste. V tomto prípade musí byť stav každého jednotlivého prvku systému testovaný každú pol hodinu - toto je predvolené obdobie. Takto funguje Puppet.
Veža vás od toho zachráni. Na rôznych zariadeniach môžete bez obmedzení spúšťať rôzne procesy, môžete vykonávať základnú prácu, spúšťať ďalšie dôležité procesy, nastavovať bezpečnostný systém a pracovať s databázami. V Puppet Enterprise môžete robiť všetko, čo je ťažké. Ak ste ho teda nakonfigurovali na jednom hostiteľovi, bude chvíľu trvať, kým sa zmeny prejavia na zostávajúcich hostiteľoch. V Ansible sa všetky zmeny prejavia súčasne.
Nakoniec sa pozrime na bezpečnostný modul. Ansible Tower to implementuje jednoducho úžasne, s veľkou presnosťou a starostlivosťou. Používateľom môžete udeliť prístup ku konkrétnym službám alebo konkrétnym hostiteľom. Robím to so svojimi zamestnancami, ktorí sú zvyknutí pracovať na Windowse a obmedzujúc ich prístup k shellu Linuxu. Zabezpečujem, aby mali prístup k Toweru, aby mohli vykonávať iba prácu a spúšťať iba služby, ktoré sú pre nich relevantné.
Pozrime sa na veci, ktoré musíte urobiť vopred, aby ste si uľahčili prechod na Ansible Tower. V prvom rade si musíte pripraviť vybavenie. Ak niektoré prvky vašej infraštruktúry ešte nie sú v databáze, musíte ich tam pridať. Sú systémy, ktoré nemenia svoje vlastnosti a teda nie sú v databáze Puppet, no ak ich tam pred presunom do Toweru nepridáte, prídete o množstvo výhod. Môže to byť „špinavá“, predbežná databáza, ale mala by obsahovať informácie o všetkom vybavení, ktoré máte. Preto by ste mali napísať dynamický hardvérový skript, ktorý automaticky vloží všetky zmeny infraštruktúry do databázy, potom Ansible bude vedieť, ktorí hostitelia by mali byť prítomní v novom systéme. Tomuto SCM nebudete musieť povedať, ktorých hostiteľov ste pridali a ktorí hostitelia už neexistujú, pretože to všetko bude vedieť automaticky. Čím viac údajov bude v databáze, tým užitočnejší a flexibilnejší bude Ansible. Funguje to tak, že jednoducho načíta čiarový kód stavu hardvéru z databázy.
Strávte nejaký čas oboznámením sa s príkazovým riadkom v Ansible. Spustite nejaké vlastné príkazy na otestovanie hardvérového skriptu, napíšte a spustite niekoľko jednoduchých, ale užitočných skriptov playbooku, použite šablóny Jinja2, kde je to vhodné. Skúste napísať rolu a skript pre zložitý viackrokový proces s použitím bežnej, bežne sa vyskytujúcej hardvérovej konfigurácie. Hrajte sa s týmito vecami, vyskúšajte, ako to funguje. Týmto spôsobom sa naučíte používať nástroje na vytváranie knižníc používané v Tower. Už som povedal, že príprava na prechod mi trvala asi 3 mesiace. Myslím si, že na základe mojich skúseností to zvládnete rýchlejšie. Nepovažujte tento čas za stratený, pretože neskôr zažijete všetky výhody vykonanej práce.
Ďalej sa musíte rozhodnúť, čo od Ansible Tower očakávate, čo presne by vám tento systém mal robiť.
Potrebujete nasadiť systém na holý hardvér, na holé virtuálne stroje? Alebo chcete zachovať pôvodné prevádzkové podmienky a nastavenia existujúcich zariadení? Toto je veľmi dôležitý aspekt pre verejné spoločnosti, takže si musíte byť istí, že budete môcť migrovať a nasadiť Ansible na vašej existujúcej konfigurácii. Identifikujte rutinné administratívne procesy, ktoré chcete automatizovať. Zistite, či potrebujete nasadiť špecifické aplikácie a služby v novom systéme. Urobte si zoznam toho, čo chcete robiť, a stanovte si priority.
Potom začnite písať kód skriptu a roly, ktoré umožnia úlohy, ktoré plánujete dokončiť. Skombinujte ich do projektov, logickej zbierky relevantných príručiek. Každý projekt bude patriť do samostatného úložiska Git alebo iného úložiska v závislosti od toho, ktorého správcu kódu používate. Skripty a adresáre playbookov môžete spravovať ich manuálnym umiestnením do Project Base Path na serveri Tower alebo umiestnením playbooku do akéhokoľvek systému správy zdrojového kódu (SCM), ktorý podporuje Tower, vrátane Git, Subversion, Mercurial a Red Hat. Insights. V rámci jedného projektu môžete umiestniť toľko skriptov, koľko chcete. Napríklad som vytvoril jeden základný projekt, do ktorého som umiestnil skript pre základné prvky RedHat, skript pre jadro Linuxu a skripty pre zvyšok základných línií. V jednom projekte teda existovali rôzne úlohy a scenáre, ktoré boli spravované z jedného úložiska Git.
Spustenie všetkých týchto vecí cez príkazový riadok je dobrý spôsob, ako otestovať ich funkčnosť. Tým sa pripravíte na inštaláciu veže.
Poďme sa trochu porozprávať o prekódovaní Bábkového manifestu, pretože som nad tým strávil veľa času, kým som prišiel na to, čo je vlastne potrebné urobiť.
Ako som už povedal, Puppet ukladá všetky nastavenia a možnosti hardvéru do jedného dlhého manifestu a tento manifest ukladá všetko, čo by mal tento SCM robiť. Pri prechode nemusíte všetky svoje úlohy vtesnať do jedného zoznamu, namiesto toho sa zamyslite nad štruktúrou nového systému: roly, skripty, značky, skupiny a čo by tam malo byť. Niektoré z prvkov autonómnej siete by mali byť zoskupené do skupín, pre ktoré je možné vytvárať skripty. Zložitejšie prvky infraštruktúry, ktoré zahŕňajú veľké množstvo zdrojov, vrátane samostatných tried, možno kombinovať do rolí. Pred migráciou sa o tom musíte rozhodnúť. Ak vytvárate veľké roly alebo scenáre, ktoré sa nezmestia na jednu obrazovku, mali by ste použiť značky, aby ste mohli zachytiť konkrétne časti infraštruktúry.
18:00
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com