Národní informační služba satelitních dat o životním prostředí (NESDIS) snížila náklady na správu konfigurace Red Hat Enterprise Linux (RHEL) o 35 % přechodem z Puppet Enterprise na Ansible Tower. V tomto videu kategorie „jak jsme to udělali“ systémový inženýr Michael Rau zdůvodňuje realizaci této migrace, sdílí užitečné tipy a zkušenosti získané z přechodu z jednoho SCM na druhé.
Z tohoto videa se dozvíte:
- jak zdůvodnit vedení rozumnost přechodu z Puppet Enterprise na Ansible Tower;
- jaké strategie použít pro co nejhladší přechod;
- tipy na transcoding PE manifestů do Ansible Playbook;
- doporučení pro optimální instalaci Ansible Tower.
Dobrý den všem, jmenuji se Michael Rau, jsem senior systémový inženýr ve společnosti ActioNet, která pracuje pro Národní úřad pro oceán a atmosféru (NOAA) službu NESDIS. Dnes si povíme o střihání řetězců – o mé vlastní zkušenosti s migrací z Puppet Enterprise na Ansible Tower. Téma této prezentace spočívá v tom, abych „představil své jizvy“, které zůstaly po mém přechodu na začátku roku. Chci sdílet, co jsem se během tohoto procesu naučil. Takže když se do něčeho podobného pustíte, budete moci přechod provést bez zbytečných obtíží.
Na začátku každé prezentace na Ansible Fest vidíte snímky podobné tomuto. Tento snímek popisuje historii automatizace mé firmy. Nejsem v tom nováček, protože používám Puppet/Puppet Enterprise od roku 2007. S Ansible jsem začal pracovat v roce 2016 a stejně jako mnoho dalších uživatelů tohoto produktu mě přilákala možnost „triků“ s pomocí příkazového řádku a jednoduché skripty (playbooks). Na konci roku 2017 jsem se obrátil na své vedení s vážnými důvody pro přechod na Ansible Tower. Za chvíli vám řeknu důvody, které mě k tomuto kroku vedly. Po získání souhlasu vedení trvalo ještě několik měsíců, než jsem realizoval to, co jsem zamýšlel, a přechod se uskutečnil v lednu až únoru tohoto roku. Takže jsme se zcela vzdali Puppet ve prospěch Ansible, a to je skvělé.
Nejvíce mě na Ansible přitahuje možnost psaní a používání rolí (roles) a scénářů (playbooks). Role jsou skvělé pro vytváření různých, avšak vzájemně souvisejících úkolů (tasks) a umístění všech dat vztahujících se k těmto úkolům na jedno místo. Playbook je syntaktický YAML, skriptový soubor, který popisuje akce pro jeden nebo více hostitelů. Těmto možnostem obvykle vysvětluji vývojářům softwaru. Ansible Tower umožňuje říci: „Ne, nemáte přístup k shellu, ale dávám vám možnost spustit všechny procesy Tower a restartovat službu, kdykoli potřebujete.“ Povím vám o pracovním prostředí a používaném vybavení.
Jedná se o federální LAN, 7 fyzických lokalit připojených přes cloudové MPLS, 140 serverů RHEL, přičemž 99 % z nich je virtuálních (vSphere), hardware SuperMicro, síťové úložiště NexentaStore, soubor přepínačů Cisco, Arista a Cumulus a prostředky pro jednotnou správu hrozeb Fortinet UTM na každé lokalitě.
Federální síť znamená, že musím používat všechny bezpečnostní prostředky požadované zákony. Měli byste mít na paměti, že Puppet Enterprise nepodporuje většinu námi používaného vybavení. Jsme nuceni používat levné hardwarové komponenty, protože státní instituce čelí problémům s financováním této položky výdajů. Proto nakupujeme hardware třídy SuperMicro a sestavujeme naše vybavení z jednotlivých částí, jehož údržbu zajišťují vládní smlouvy. Používáme Linux, což je jeden z důležitých důvodů přechodu na Ansible.
Naše historie spolupráce s Puppet je následující.
V roce 2007 jsme měli malou síť 20–25 uzlů, ve které jsme zavedli Puppet. V zásadě tyto uzly představovaly pouhé "boxy" RedHat. V roce 2010 jsme začali používat webové rozhraní Puppet Dashboard pro 45 uzlů. Jak se síť nadále rozrůstala, v roce 2014 jsme přešli na PE 3.3, provedli jsme celkový přechod s přepisem manifestu pro 75 uzlů. To bylo nutné, protože Puppet stále mění herní pravidla, a v tomto případě zcela změnili jazyk. O rok později, když skončila podpora 3. verze Puppet Enterprise, jsme museli migrovat na PE 2015.2. Znovu bylo nutné přepsat manifest podle nových serverů a zakoupit licenci s rezervou na 100 uzlů, i když jsme v té době měli pouze 85 uzlů.
Uplynuly pouhé 2 roky a museli jsme opět provést značnou práci na přechodu na novou verzi PE 2016.4. Zakoupili jsme licenci na 300 uzlů, přičemž jsme měli pouze 130. Opět bylo nutné provést významné změny v manifestu, protože nová verze jazyka měla syntaxi odlišnou od jazyka verze 2015. V důsledku toho naše SCM přešla z verzeovacího systému SVN na Bitbucket (Git). Takové byly naše "vztahy" s Puppet.
Takže jsem musel vysvětlit vedení, proč se musíme přepnout na jinou SCM, a to s následujícími argumenty. První je vysoká cena služby. Mluvil jsem s lidmi z RedHat a ti řekli, že náklady na údržbu sítě se 300 uzly pomocí Ansible Tower činí polovinu nákladů Puppet Enterprise. Pokud si ještě zakoupíte Ansible Engine, cena bude přibližně stejná, ale získáte mnohem více funkcí než u PE. Vzhledem k tomu, že jsme státní společnost financovaná z federálního rozpočtu, je to docela silný argument.
Druhým argumentem je univerzálnost. Puppet podporuje pouze to zařízení, na kterém je nainstalován agent Puppet. To znamená, že na všechny switche je třeba nainstalovat agenta, a to ve verzi, která je aktuální. A pokud část vašich switchů podporuje jednu verzi a část jinou, budete muset na ně nainstalovat novou verzi agenta PE, aby všechny mohly fungovat v jednom systému SCM.
Systém Ansible Tower funguje jinak, protože nemá žádné agenty, ale má moduly, které podporují switche Cisco a další switche. Tento SCM podporuje Qubes OS, Linux a 4.NET UTM. Ansible Tower také podporuje řadiče síťových uložišť NexentaStore, založené na jádru Illumos – open-source operačním systému na bázi Unixu. I když jde o omezenou podporu, Ansible Tower ji přesto poskytuje.
Třetí argument, velmi důležitý jak pro mě, tak pro naši administraci, je jednoduchost osvojování. Za 10 let jsem se učil moduly a kód manifestů Puppet, ale Ansible jsem se naučil během týdne, protože s tímto SCM je mnohem snazší pracovat. Když spouštíte spustitelné soubory, samozřejmě pokud to neděláte bezdůvodně, zkousnuti jsou rozumní a pružní zpracovatelé. Playbooky založené na YAML se vyznačují snadným učením a rychlostí použití. Ti, kteří nikdy předtím neslyšeli o YAML, si mohou jednoduše přečíst skripty a snadno pochopit, jak to funguje.
Upřímně řečeno, Puppet značně ztěžuje 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 provedete nějaké změny v manifestu a chcete otestovat svůj kód, musíte kód znovu napsat pro Puppet Master, tedy nastavit soubor Puppet Masteru /etc/hosts pro připojení všech klientů a spustit službu Puppet Server. Teprve poté budete moci vyzkoušet funkčnost síťového zařízení na jednom hostiteli. To je poměrně 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 se připojit k testovanému hostiteli přes SSH protokol. S tím je mnohem jednodušší 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 hardwaru. Tento SCM bez jakýchkoliv dalších kroků využívá všechny dostupné informace o vaší infrastruktuře a hardware, virtuálních strojích, serverech atd. Může komunikovat s vašimi servery RH Satellite, pokud nějaké máte, a poskytuje vám takovou integraci, kterou nikdy nezískáte, pokud pracujete s Puppet.
Další důležitou věcí je podrobná kontrola. Víte, že Puppet je modulární systém, jedná se o klient-server aplikaci, takže musíte definovat existující aspekty provozu všech vašich strojů v jednom dlouhém manifestu. Stav každého jednotlivého prvku systému by měl být testován každých třicet minut – to je výchozí období. Takto Puppet funguje.
Tower vás této potřeby zbaví. Můžete bez omezení provádět různé procesy na různém hardwaru, můžete vykonávat hlavní úkoly, spouštět další důležité procesy, nastavovat zabezpečení, pracovat s databázemi. Můžete dělat všechno, co v Puppet Enterprise souvisí s určitými obtížemi. Pokud jste provedli nastavení na jednom hostiteli, chvíli potrvá, než se změny projeví na ostatních hostitelích. V Ansible se všechny změny projeví současně.
Nakonec se podívejme na bezpečnostní modul. V Ansible Tower je implementován jednoduše úžasně, s velkou přesností a pečlivostí. Můžete uživatelům poskytovat přístup ke konkrétním službám nebo konkrétním hostitelům. Dělám to se svými zaměstnanci, kteří jsou zvyklí pracovat na Windows, a omezuji je v přístupu k Linuxové shell. Zajišťuji jim přístup k Tower, aby mohli vykonávat pouze tu práci a spouštět pouze ty služby, které spadají do jejich kompetence.
Podívejme se na věci, které je potřeba udělat předem, abychom usnadnili přechod na Ansible Tower. Především je nutné připravit vaše vybavení. Pokud některé prvky vaší infrastruktury chybí v databázi, je třeba je tam přidat. Existují systémy, které nemění své charakteristiky a proto chybí v databázi Puppet, ale pokud je tam před přechodem na Tower nepřidáte, přijdete o řadu výhod. Může to být „špinavá“ předběžná databáze, ale měla by obsahovat informace o veškerém vašem vybavení. Měli byste proto napsat dynamický skript vybavení, který automaticky zapracovává všechny změny infrastruktury do databáze, aby Ansible věděl, jaké hosty má mít v novém systému. Nebudete muset této SCM oznamovat, jaké hosty jste přidali a které hosty již neexistují, protože to zjistí automaticky. Čím více dat bude v databázi, tím užitečnější a flexibilnější bude Ansible. Funguje tak, jako by jednoduše načítal z databáze čárový kód stavu vybavení.
Věnujte nějaký čas seznámení se s příkazovým řádkem Ansible. Spusťte nějaké speciální příkazy, abyste otestovali fungování skriptu vybavení, napište a spusťte nějaké jednoduché, ale užitečné playbooky, využijte šablony Jinja2 tam, kde je to vhodné. Zkuste napsat roli a skript pro složitý vícestupňový proces, používající standardní, často používanou konfiguraci zařízení. Hrajte si s těmito věcmi, otestujte, jak to funguje. Tak se naučíte pracovat s nástroji pro vytváření knihoven používaných v Tower. Už jsem říkal, že příprava na přechod mi trvala asi 3 měsíce. Domnívám se, že na základě mých zkušeností to zvládnete rychleji. Nepovažujte tento čas za ztracený, protože později pocítíte všechny výhody vykonané práce.
Dále je potřeba rozhodnout, co očekáváte od Ansible Tower, co konkrétně by měl tento systém pro vás udělat.
Potřebujete nasazení systému na prázdném hardwaru nebo na prázdných virtuálních strojích? Nebo si chcete zachovat původní pracovní podmínky a nastavení stávajícího vybavení? To je velmi důležitý aspekt pro fungování státních společností, proto si musíte být jisti, že se vám podaří migrovat a nasadit Ansible na existující konfiguraci. Určete rutinní administrativní procesy, které chcete automatizovat. Zjistěte, zda potřebujete nasadit specifické aplikace a služby na novém systému. Sestavte seznam toho, co chcete udělat, a určete priority.
Pak začněte psát kód skriptů a rolí, které zabezpečí provedení vámi naplánovaných úkolů. Spojte je do projektů, logické kolekce příslušných skriptů playbooků. Každý projekt se bude vztahovat na samostatné úložiště Git nebo jiné úložiště v závislosti na tom, jaký správce kódu používáte. Můžete spravovat skripty playbooku a složky playbooku tak, že je ručně umístíte do Project Base Path na serveru Tower, nebo umístíte playbook do jakéhokoli systému řízení verzí (SCM) podporovaného Towerem, včetně Git, Subversion, Mercurial a Red Hat Insights. Uvnitř jednoho projektu můžete mít tolik skriptů, kolik chcete. Například jsem vytvořil jeden základní projekt, ve kterém jsem umístil skript pro základní prvky RedHat, skript pro základ Linuxu, skripty pro ostatní základní metriky. Takže v jednom projektu byly různé role a skripty, které byly spravovány z jednoho Git úložiště.
Spouštějte všechny tyto prvky přes příkazový řádek, je to dobrý způsob, jak ověřit jejich funkčnost. Tímto způsobem se připravíte na instalaci Tower.
Pojďme si promluvit o transkódování manifestu Puppet, protože jsem na to strávil hodně času, než jsem si uvědomil, co skutečně je třeba udělat.
Jak jsem již zmínil, Puppet uchovává všechna nastavení a parametry zařízení v jednom dlouhém manifestu, a v tomto manifestu je uloženo vše, co by tento SCM měl dělat. Při přechodu není třeba všechny úkoly shromáždit do jednoho seznamu; místo toho zvažte strukturu nového systému: role, scénáře, štítky, skupiny a co by do nich mělo patřit. Některé samostatné prvky sítě by měly být sloučeny do skupin, pro které lze vytvořit scénáře. Složitější prvky infrastruktury, které vyžadují značné množství zdrojů, včetně samostatných tříd, mohou být sloučeny do rolí. Před migrací si s tím musíte ujasnit. Pokud vytváříte objemné role nebo scénáře, které se na jednom displeji nevejdou, měli byste používat štítky, abyste byli schopni zachytit jednotlivé části infrastruktury.
18:00
Malá reklama 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavých materiálů? Podpořte nás objednávkou nebo doporučením známým, , unikátní alternativa entry-level serverů, kterou jsme pro vás vymysleli: (k dispozici varianty s RAID1 a RAID10, až 24 jader a až 40GB DDR4).
Dell R730xd je dvakrát levnější v datovém centru Equinix Tier IV v Amsterdamu? Jen u nás v Nizozemsku! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Čtěte o tom
Zdroj: habr.com
