Národná informačná služba satelitných údajov o životnom prostredí (NESDIS) znížila svoje náklady na správu konfigurácie Red Hat Enterprise Linux (RHEL) o 35 % prechodom z Puppet Enterprise na Ansible Tower. V tomto videu s kategóriou „ako sme to urobili“ systémový inžinier Michael Rau vysvetľuje dôvody tejto migrácie, zdieľa užitočné tipy a skúsenosti získané počas prechodu z jedného SCM na druhé.
Z tohto videa sa dozviete:
- ako ospravedlniť vedeniu oprávnenosť prechodu z Puppet Enterprise na Ansible Tower;
- aké stratégie použiť pre najhladší prechod;
- tipy na transcoding PE manifestov do Ansible Playbook;
- odporúčania pre optimálnu inštaláciu Ansible Tower.
Vítam vás všetkých, volám sa Michael Rau, som senior systémový inžinier spoločnosti ActioNet, ktorá pracuje pre Národnú správu oceánov a atmosféry (NOAA) službu NESDIS. Dnes budeme hovoriť o strihnutí riadkov – o mojich vlastných skúsenostiach s migráciou z Puppet Enterprise na Ansible Tower. Téma tejto prezentácie je „pozrite sa na moje jazvy“, ktoré zostali po tom, čo som prechod uskutočnil na začiatku roka. Chcem vám povedať, čo som sa v procese naučil. Takže keď sa rozhodnete pre niečo podobné, môžete s mojimi skúsenosťami prejsť bez zbytočných problémov.
Na začiatku každej prezentácie na Ansible Fest vidíte slidy podobné tomuto. Tento slid predkladá príbeh automatizácie mojej spoločnosti. Nie som nováčik v tejto oblasti, pretože používam Puppet/Puppet Enterprise od roku 2007. S Ansible som začal pracovať v roku 2016 a mňa, rovnako ako množstvo ďalších používateľov tohto produktu, priťahovala možnosť „trikov“ pomocou príkazového riadka a jednoduché scenáre (playbooks). Na konci roku 2017 som sa obrátil na svoje vedenie so závažnými dôvodmi pre prechod na Ansible Tower. O chvíľu vám poviem o dôvodoch, ktoré ma na tento krok podnietili. Po získaní súhlasu vedenia bolo potrebné ešte niekoľko mesiacov na realizáciu myšlienky a prechod som uskutočnil v januári-februári tohto roka. Takže sme sa úplne vzdali Puppetu v prospech Ansible, a to je skvelé.
Najviac ma na Ansible láka možnosť písať a používať úlohy (roles) a scenáre (playbooks). Úlohy sú skvelé na vytváranie rôznych, ale navzájom prepojených úloh (tasks) a umiestnenie všetkých údajov týkajúcich sa týchto úloh na jednom mieste. Playbook je syntax YAML, skriptový súbor, ktorý popisuje akcie pre jeden alebo viac hostiteľov. Tieto možnosti prezentujem používateľom, predovšetkým vývojárom softvéru. Ansible Tower umožňuje povedať: "nie, nemáte prístup k shell access, ale ponúkam vám možnosť spustiť všetky procesy Tower a reštartovať službu, kedykoľvek to budete potrebovať." Povieme si o pracovnom prostredí a používanom hardvéri.
Toto je federálna LAN, 7 fyzických lokalít prepojených cez cloudové MPLS, 140 serverov RHEL, z čoho 99 % sú virtuálne (vSphere), hardvér SuperMicro, sieťové úložisko NexentaStore, súprava prepínačov Cisco, Arista a Cumulus a prostriedky na unified threat management Fortinet UTM na každej lokalite.
Federálna sieť znamená, že musím použiť všetky prostriedky ochrany informácií stanovené legislatívou. Musíte mať na pamäti, že Puppet Enterprise nepodporuje väčšinu nášho používaného hardvéru. Sme nútení používať rozpočtové zariadenia, pretože štátne inštitúcie majú problémy s financovaním tejto položky. Preto kupujeme hardvér triedy SuperMicro a zostavujeme naše zariadenie z jednotlivých častí, ktorých údržbu zaručujú vládne zmluvy. Používame Linux a to je jeden z dôležitých dôvodov prechodu na Ansible.
Naša história práce s Puppet je taká.
V roku 2007 sme mali malú sieť zloženú z 20-25 uzlov, v ktorej sme nasadili Puppet. Tieto uzly boli väčšinou len "krabice" RedHat. V roku 2010 sme začali používať webové rozhranie Puppet Dashboard pre 45 uzlov. Keďže sa sieť naďalej rozširovala, v roku 2014 sme prešli na PE 3.3, pričom sme kompletne prepisovali manifest pre 75 uzlov. Toto bolo potrebné, pretože Puppet rád mení pravidlá, a v tomto prípade úplne zmenili jazyk. O rok neskôr, keď prestala podpora 3. verzie Puppet Enterprise, sme boli nútení migrovať na PE 2015.2. Opäť sme museli prepisovať manifest pre nové servery a zakúpiť licenciu s nadbytkom na 100 uzlov, hoci v tom čase sme mali len 85 uzlov.
Už uplynuli iba 2 roky a opäť sme museli vykonať významnú prácu na prechode na novú verziu PE 2016.4. Kúpili sme licenciu na 300 uzlov, pričom sme mali len 130. Opäť sme museli robiť vážne úpravy v manifeste, pretože nová verzia jazyka mala syntaktické rozdiely od jazyka verzie 2015. Nakoniec naša SCM prešla zo systému správy verzií SVN na Bitbucket (Git). Takto sme mali naše "vzťahy" s Puppet.
A tak som musel vysvetliť vedeniu, prečo musíme prejsť na inú SCM, pričom som použil nasledujúce argumenty. Prvý – vysoká cena služby. Hovoril som s chalanmi z RedHat a povedali, že náklady na údržbu siete z 300 uzlov pomocou Ansible Tower predstavujú polovicu ceny Puppet Enterprise. Ak zakúpite aj Ansible Engine, náklady budú približne rovnaké, ale získate oveľa viac funkcií, než ponúka PE. Keďže sme štátna spoločnosť financovaná z federálneho rozpočtu, to je celkom silný argument.
Druhý argument – univerzálnosť. Puppet podporuje iba to zariadenie, na ktorom je nainštalovaný agent Puppet. To znamená, že na všetky prepínače je potrebné nainštalovať agenta, pričom musí byť v najnovšej verzii. A ak časť vašich prepínačov podporuje jednu verziu a časť druhú, budete musieť nainštalovať na ne novú verziu agenta PE, aby všetky mohli fungovať v jednom systéme SCM.
Systém Ansible Tower funguje jinak, protože nemá žádné agenty, ale má moduly, které podporují switche Cisco a všechny ostatní switche. Tato SCM podporuje Qubes OS, Linux a 4.NET UTM. Ansible Tower také podporuje řadiče síťových úložišť NexentaStore, které jsou založeny na jádru Illumos – open-source operačním systému založeném na Unxu. To je velmi malá podpora, ale Ansible Tower ji přesto poskytuje.
Třetí argument, který je pro mě i naši administraci velmi důležitý, je snadnost ovládání. Během 10 let jsem se ovládal moduly a kódy manifestů Puppet, ale Ansible jsem se naučil během týdne, protože s touto SCM je mnohem snazší pracovat. Pokud spouštíte spustitelné soubory, samozřejmě pokud to neděláte zbytečně, pak s nimi pracují rozumní a citliví zpracovatelé. Playbooky založené na YAML se vyznačují snadným učením a rychlým použitím. Ti, kteří o YAML nikdy neslyšeli, si mohou jednoduše přečíst skripty a snadno pochopit, jak to funguje.
Upřímně řečeno, Puppet značně komplikuje vaši práci jako vývojáře, protože je založen na použití Puppet Master. To je jediný stroj, který má právo komunikovat s agenty Puppet. Pokud jste provedli nějaké změny v manifestu a chcete testovat svůj kód, musíte přepsat kód pro Puppet Master, to znamená nastavit soubor Puppet masteru /etc/hosts pro připojení všech klientů a spustit službu Puppet Server. Teprve poté můžete testovat funkci síťového zařízení na jednom hostiteli. To je dost bolestivý proces.
V Ansible je vše mnohem jednodušší. Vše, co musíte udělat, je vyvinout kód pro stroj, který má možnost komunikovat pomocí protokolu SSH s testovaným hostitelem. S tímto je mnohem snazší pracovat.
Další velkou výhodou Ansible Tower je možnost využít již existující podpůrný systém a zachovat stávající konfiguraci zařízení. Tato SCM bez jakoukoli další akce používá všechny dostupné informace o vaší infrastruktuře a zařízení, virtuálních strojích, serverech atd. Může komunikovat s vašimi RH Satellite servery, pokud nějaké máte, a poskytuje vám takovou integraci, kterou nikdy nezískáte při práci s Puppet.
Ďalšou dôležitou vecou je podrobná kontrola. Viete, že Puppet je modulárny systém, je to klient-server aplikácia, preto musíte definovať existujúce aspekty fungovania všetkých vašich strojov v jednom dlhom manifeste. Pri tom by sa stav každého jednotlivého prvku systému mal testovať každých polhodinu – to je predvolený interval. Takto Puppet funguje.
Tower vás zbavuje tohto. Môžete bez obmedzení vykonávať najrôznejšie procesy na rôznom hardvéri, môžete robiť základnú prácu, spúšťat ďalšie dôležité procesy, nastavovať systémovú bezpečnosť, pracovať s databázami. Môžete robiť všetko, čo je v Puppet Enterprise spojené s určitými ťažkosťami. Takže ak ste vykonali nastavenie na jednom hoste, bude trvať nejaký čas, kým sa zmeny prejavia na ostatných hostoch. V Ansible sa všetky zmeny prejavia okamžite.
Nakoniec sa pozrime na bezpečnostný modul. V Ansible Tower je realizovaný jednoducho úžasne, s veľkou presnosťou a dôvtipom. Môžete poskytovať užívateľom prístup k konkrétnym službám alebo k konkrétnym hostom. Robím to so svojimi zamestnancami, ktorí sú zvyknutí pracovať na Windows, obmedzujem ich prístup k shellu Linux. Zaisťujem im taký prístup k Tower, aby mohli vykonávať iba tú prácu a spúšťať iba tie služby, ktoré sa týkajú ich kompetencie.
Pozrime sa na veci, ktoré je potrebné urobiť vopred, aby ste uľahčili prechod na Ansible Tower. V prvom rade je potrebné pripraviť vaše zariadenia. Ak niektoré prvky vašej infraštruktúry ešte nie sú v databáze, je potrebné ich tam pridať. Existujú systémy, ktoré nemenia svoje charakteristiky a preto chýbajú v databáze Puppet, ale ak ich tam pred prechodom na Tower 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 zariadení, ktoré máte. Preto by ste mali napísať dynamický skript zariadenia, ktorý automaticky zanesie všetky zmeny infraštruktúry do databázy, aby Ansible vedel, aké hosty by mali byť v novom systéme. Nebudete musieť tejto SCM hlásiť, aké hosty ste pridali a ktoré hosty už neexistujú, pretože to všetko zistí automaticky. Čím viac údajov bude v databáze, tým užitočnejší a flexibilnejší bude Ansible. Funguje to tak, akoby jednoducho čítal z databázy čiarový kód stavu zariadenia.
Strávte nejaký čas oboznámením sa s prácou príkazového riadku v Ansible. Spustite niektoré špeciálne príkazy, aby ste overili prácu skriptu zariadenia, napíšte a spustite niektoré jednoduché, ale užitočné scenáre playbook, použite šablóny Jinja2 tam, kde je to vhodné. Skúste napísať rolu a scenár pre komplexný viacstupňový proces, používajúc štandardnú, často sa vyskytujúcu konfiguráciu zariadenia. Hrajte sa s týmito vecami, otestujte, ako to funguje. Týmto spôsobom sa naučíte pracovať s nástrojmi na vytváranie knižníc používaných v Tower. Už som spomenul, že moje prípravy na prechod trvali približne 3 mesiace. Myslím, že sa vám na základe mojej skúsenosti podarí urobiť to rýchlejšie. Nepovažujte tento čas za stratený, pretože neskôr pocítite všetky výhody vykonanej práce.
Ďalej je potrebné rozhodnúť, čo očakávate od Ansible Tower, čo konkrétne by tento systém mal pre vás urobiť.
Potrebujete nasadiť systém na prázdnom hardvéri alebo na prázdnych virtuálnych strojoch? Alebo chcete zachovať pôvodné podmienky a nastavenia existujúceho hardvéru? Toto je veľmi dôležitý aspekt pre fungovanie štátnych spoločností, preto musíte mať istotu, že sa vám podarí migrovať a nasadiť Ansible na existujúcej konfigurácii. Určte rutinné administratívne procesy, ktoré chcete automatizovať. Zistite, či potrebujete nasadiť špecifické aplikácie a služby na novej sústave. Zostavte zoznam toho, čo chcete urobiť, a usporiadajte priority.
Potom prejdite k písaniu kódu skriptov a rolí, ktoré zabezpečia vykonanie vašich naplánovaných úloh. Spojte ich do projektov, logickej zbierky súvisiacich skriptov playbookov. Každý projekt bude patriť k samostatnému repozitáru Git alebo inému repozitáru v závislosti od toho, akého správcu kódu používate. Môžete spravovať skripty playbook a adresáre playbooku tak, že ich ručne umiestnite do Project Base Path na servery Tower, alebo umiestnite playbook do akéhokoľvek systému správy zdrojového kódu (SCM), ktorý Tower podporuje, vrátane Git, Subversion, Mercurial a Red Hat Insights. V rámci jedného projektu môžete mať toľko skriptov, koľko chcete. Napríklad, vytvoril som jeden základný projekt, v ktorom som umiestnil skript pre základné prvky RedHat, skript pre základy Linuxu, skripty pre ostatné základné ukazovatele. Takže v jednom projekte existovali rôzne úlohy a skripty, ktoré sa spravovali z jedného Git-repozitára.
Spúšťajte všetky tieto veci cez príkazový riadok, je to dobrý spôsob, ako overiť ich funkčnosť. Týmto spôsobom sa pripravíte na inštaláciu Tower.
Poďme sa trochu porozprávať o transcodingu manifestu Puppet, pretože som tomuto venoval veľa času, kým som si neuvedomil, čo je skutočne potrebné urobiť.
Ako som už spomenul, Puppet uchováva všetky nastavenia a parametre zariadení v jednom dlhom manifeste, a v tomto manifeste sú zhrnuté všetky úlohy, ktoré má táto SCM vykonávať. Pri migrácii nie je potrebné napchávať všetky vaše úlohy do jedného zoznamu, skôr premýšľajte o štruktúre nového systému: rolách, scenároch, značkách, skupinách a tom, čo by tam malo byť zahrnuté. Niektoré z nezávislých prvkov siete by sa mali zlúčiť do skupín, pre ktoré je možné vytvoriť scenáre. Zložitejšie prvky infraštruktúry, ktoré vyžadujú značné množstvo zdrojov, ako sú samostatné triedy, je možné zlúčiť do rolí. Pred migráciou je potrebné to vyjasniť. Ak vytvárate rozsiahle rolí alebo scenárov, ktoré sa nezmestia na jednu obrazovku, mali by ste používať značky, aby ste mohli zachytiť jednotlivé časti infraštruktúry.
18:00
Trochu reklamy 🙂
Ďakujeme, že ostávate s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavých materiálov? Podporte nás, vytvorením objednávky alebo odporúčaním známym, , unikátny ekvivalent entry-level serverov, ktorý sme pre vás vytvorili: (k dispozícii varianty s RAID1 a RAID10, až 24 jadier a až 40GB DDR4).
Dell R730xd je dvakrát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len u nás v Holandsku! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolárov! Prečítajte si o tom
Zdroj: habr.com
