National Environmental Satellite Data Information Service (NESDIS) snížila své náklady na správu konfigurace pro Red Hat Enterprise Linux (RHEL) o 35 % migrací z Puppet Enterprise na Ansible Tower. V tomto videu „jak jsme to udělali“ vysvětluje systémový inženýr Michael Rau důvod této migrace a sdílí užitečné tipy a ponaučení z přechodu od jednoho SCM k druhému.
Z tohoto videa se dozvíte:
- jak managementu zdůvodnit proveditelnost přechodu z Puppet Enterprise na Ansible Tower;
- jaké strategie použít, aby byl přechod co nejhladší;
- tipy pro překódování PE manifestů do Ansible Playbook;
- Doporučení pro optimální instalaci Ansible Tower.
Ahoj všichni, jmenuji se Michael Rau, jsem senior systémový inženýr ve společnosti ActioNet, která pracuje pro službu NESDIS National Oceanic and Atmospheric Administration (NOAA). Dnes budeme mluvit o ořezávání strun – o mé vlastní zkušenosti s migrací z Puppet Enterprise do Ansible Tower. Tématem této prezentace je „podívat se na mé jizvy“, které zbyly po tomto přechodu na začátku roku. Chci se podělit o to, co jsem se během tohoto procesu naučil. Takže když si vezmete něco takového, s využitím mých zkušeností, můžete přechod provést bez jakékoli práce navíc.
Podobné snímky vidíte na začátku každé prezentace na Ansible Festu. Tento snímek nastiňuje historii automatizace mé společnosti. Nejsem v tom nováček, protože Puppet/Puppet Enterprise používám od roku 2007. S Ansible jsem začal pracovat v roce 2016 a stejně jako mnoho dalších uživatelů tohoto produktu mě zaujala možnost „triků“ pomocí příkazové řádky a jednoduchých skriptů (playbooků). Na konci roku 2017 jsem oslovil své vedení ohledně závažných důvodů pro přesun do Ansible Tower. Za chvíli vám řeknu o důvodech, které mě přiměly k tomuto kroku. Po obdržení souhlasu vedení trvalo několik měsíců, než byl plán dokončen, a přechod jsem provedl v lednu až únoru tohoto roku. Takže jsme úplně opustili Puppet ve prospěch Ansible a je to skvělá věc.
Co mě na Ansible nejvíce oslovuje, je schopnost psát a používat role a playbooky. Role jsou skvělé pro vytváření odlišných, ale souvisejících úkolů a ukládání všech dat souvisejících s těmito úkoly na jedno místo. Playbook je syntaxe YAML, soubor skriptu, který popisuje akce pro jednoho nebo více hostitelů. O těchto funkcích říkám uživatelům, především vývojářům softwaru. Ansible Tower vám dává možnost říci: „Ne, nemáte přístup k shellu, ale dávám vám možnost spouštět všechny procesy Tower a restartovat službu, když to potřebujete.“ Řeknu vám o pracovním prostředí a vybavení, které používáme.
Jedná se o federální LAN, 7 fyzických míst připojených přes cloud MPLS, 140 serverů RHEL, z nichž 99 % je virtuálních (vSphere), hardware SuperMicro, síťové úložiště NexentaStore, sadu přepínačů Cisco, Arista a Cumulus a jednotnou správu hrozeb Fortinet UTM nástroje na každém webu.
Federální síť znamená, že musím použít všechna zákonem stanovená opatření pro zabezpečení informací. Měli byste mít na paměti, že Puppet Enterprise nepodporuje většinu hardwaru, který používáme. Jsme nuceni používat rozpočtový hardware, protože vládní agentury mají problémy s financováním této nákladové položky. Proto nakupujeme hardware SuperMicro a naše zařízení skládáme z jednotlivých dílů, jejichž údržbu garantují státní zakázky. Používáme Linux a to je jeden z důležitých důvodů pro přechod na Ansible.
Naše historie s Puppet je následující.
V roce 2007 jsme měli malou síť 20-25 uzlů, do kterých jsme nasadili Puppet. V podstatě byly tyto uzly jen „krabicemi“ RedHat. V roce 2010 jsme začali používat webové rozhraní Puppet Dashboard pro 45 uzlů. S dalším rozšiřováním sítě jsme v roce 2014 přešli na PE 3.3, čímž jsme provedli kompletní přechod s přepsáním manifestu pro 75 uzlů. To muselo být provedeno, protože Puppet rádi mění pravidla hry a v tomto případě zcela změnili jazyk. O rok později, když podpora pro verzi 3 Puppet Enterprise skončila, jsme byli nuceni přejít na PE 2015.2. Museli jsme znovu přepsat manifest pro nové servery a zakoupit licenci s rezervou 100 uzlů, ačkoliv jsme v té době měli pouze 85 uzlů.
Uplynuly pouhé 2 roky a my jsme opět museli udělat hodně práce, abychom migrovali na novou verzi PE 2016.4. Zakoupili jsme licenci pro 300 uzlů, máme jich pouze 130. Opět jsme museli provést velké změny v manifestu, protože nová verze jazyka měla jinou syntaxi než jazyk verze z roku 2015. V důsledku toho naše SCM přešlo z řízení verzí SVN na Bitbucket (Git). To byl náš „vztah“ s Puppet.
Musel jsem tedy vedení vysvětlit, proč jsme potřebovali přejít k jinému SCM, pomocí následujících argumentů. Prvním je vysoká cena služby. Mluvil jsem s kluky z RedHat a řekli, že náklady na provoz 300uzlové sítě s Ansible Tower jsou poloviční než náklady na Puppet Enterprise. Pokud si také zakoupíte Ansible Engine, cena bude přibližně stejná, ale získáte mnohem více funkcí než PE. Vzhledem k tomu, že jsme státní podnik financovaný z federálního rozpočtu, je to docela silný argument.
Druhým argumentem je všestrannost. Puppet podporuje pouze hardware, který má Puppet agenta. To znamená, že na všech přepínačích musí být nainstalován agent a musí se jednat o nejnovější verzi. A pokud některé z vašich přepínačů podporují jednu verzi a některé jinou, budete na ně muset nainstalovat novou verzi agenta PE, aby všechny mohly pracovat ve stejném systému SCM.
Systém Ansible Tower funguje jinak, protože nemá žádné agenty, ale má moduly, které podporují přepínače Cisco a všechny ostatní přepínače. Tento SCM podporuje Qubes OS, Linux a 4.NET UTM. Ansible Tower také podporuje řadiče síťového úložiště NexentaStore založené na jádře Illumos, open-source operačním systému založeném na Unixu. To je velmi malá podpora, ale Ansible Tower to stejně dělá.
Třetím argumentem, který je velmi důležitý jak pro mě, tak pro naši administrativu, je snadnost použití. Strávil jsem 10 let zvládnutím modulů Puppet a kódu manifestu, ale Ansible jsem se naučil během týdne, protože s tímto SCM je mnohem jednodušší pracovat. Pokud spouštíte spustitelné soubory, samozřejmě, pokud to neděláte zbytečně, pak s nimi pracují inteligentní a reagující handlery. Příručky založené na YAML se snadno učí a rychle se používají. Ti, kteří nikdy předtím o YAML neslyšeli, si mohou jednoduše přečíst skripty a snadno pochopit, jak to funguje.
Abych byl upřímný, Puppet dělá vaši práci vývojáře mnohem obtížnější, protože je založen na používání Puppet Master. Je to jediný stroj, který může komunikovat s agenty Puppet. Pokud jste provedli nějaké změny v manifestu a chcete otestovat svůj kód, musíte přepsat kód pro Puppet Master, to znamená nakonfigurovat soubor Puppet Master /etc/hosts pro připojení všech klientů a spuštění služby Puppet Server. Teprve poté budete moci otestovat provoz síťového zařízení na jednom hostiteli. Jedná se o poměrně bolestivý postup.
V Ansible je vše mnohem jednodušší. Vše, co musíte udělat, je vyvinout kód pro stroj, který dokáže komunikovat přes SSH s testovaným hostitelem. S tím je mnohem jednodušší pracovat.
Další velkou výhodou Ansible Tower je schopnost využít váš stávající podpůrný systém a udržovat vaši stávající hardwarovou konfiguraci. Tento SCM používá všechny dostupné informace o vaší infrastruktuře a hardwaru, virtuálních strojích, serverech atd. bez dalších kroků. Může mluvit s vašimi RH Satellite servery, pokud nějaký máte, a poskytuje vám integrace, které s Puppet nikdy nezískáte.
Další důležitou věcí je detailní ovládání. Víte, že Puppet je modulární systém, je to aplikace klient-server, takže musíte definovat existující aspekty všech vašich strojů v jednom dlouhém manifestu. V tomto případě musí být stav každého jednotlivého prvku systému testován každou půlhodinu - to je výchozí období. Takhle funguje Puppet.
Tower vás od toho zachrání. Na nejrůznějších zařízeních můžete bez omezení spouštět nejrůznější procesy, provádět základní práce, spouštět další důležité procesy, nastavovat bezpečnostní systém a pracovat s databázemi. V Puppet Enterprise můžete dělat vše, co je obtížné. Pokud jste jej tedy nakonfigurovali na jednom hostiteli, bude chvíli trvat, než se změny projeví na zbývajících hostitelích. V Ansible se všechny změny projeví současně.
Nakonec se podíváme na bezpečnostní modul. Ansible Tower to implementuje jednoduše úžasně, s velkou přesností a pečlivostí. Uživatelům můžete udělit 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 omezovat jejich přístup k Linuxu. Zajišťuji, aby měli přístup k Toweru, aby mohli vykonávat pouze práci a provozovat pouze služby, které jsou pro ně relevantní.
Pojďme se podívat na věci, které musíte udělat s předstihem, abyste si usnadnili přechod na Ansible Tower. Nejprve si musíte připravit vybavení. Pokud některé prvky vaší infrastruktury ještě nejsou v databázi, musíte je tam přidat. Existují systémy, které nemění své vlastnosti, a proto nejsou v databázi Puppet, ale pokud je tam před přesunem do Toweru 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 vybavení, které máte. Proto byste měli napsat dynamický hardwarový skript, který automaticky vloží všechny změny infrastruktury do databáze, pak Ansible bude vědět, kteří hostitelé by měli být přítomni na novém systému. Nebudete muset tomuto SCM sdělovat, které hostitele jste přidali a kteří hostitelé již neexistují, protože to vše bude vědět automaticky. Čím více dat bude v databázi, tím užitečnější a flexibilnější bude Ansible. Funguje to tak, že jednoduše načte čárový kód stavu hardwaru z databáze.
Věnujte nějaký čas seznámení se s příkazovým řádkem v Ansible. Spusťte některé vlastní příkazy pro testování hardwarového skriptu, napište a spusťte několik jednoduchých, ale užitečných skriptů playbooku, použijte šablony Jinja2, kde je to vhodné. Zkuste napsat roli a skript pro složitý vícekrokový proces s použitím běžné, běžně se vyskytující hardwarové konfigurace. Hrajte si s těmito věcmi, vyzkoušejte, jak to funguje. Tímto způsobem se naučíte používat nástroje pro vytváření knihoven používané v Toweru. Už jsem řekl, že příprava na přechod mi trvala asi 3 měsíce. Myslím, že na základě mých zkušeností to zvládnete rychleji. Nepovažujte tento čas za ztracený, protože později zažijete všechny výhody odvedené práce.
Dále se musíte rozhodnout, co od Ansible Tower očekáváte, co přesně by pro vás tento systém měl dělat.
Potřebujete nasadit systém na holý hardware, na holé virtuální stroje? Nebo chcete zachovat původní provozní podmínky a nastavení stávajících zařízení? Toto je velmi důležitý aspekt pro veřejné společnosti, takže si musíte být jisti, že budete schopni migrovat a nasadit Ansible na vaší stávající konfiguraci. Identifikujte rutinní administrativní procesy, které chcete automatizovat. Zjistěte, zda potřebujete nasadit konkrétní aplikace a služby na nový systém. Udělejte si seznam toho, co chcete dělat, a stanovte si priority.
Poté začněte psát kód skriptu a role, které umožní úkoly, které plánujete dokončit. Spojte je do projektů, logické sbírky relevantních příruček. Každý projekt bude patřit do samostatného úložiště Git nebo jiného úložiště v závislosti na tom, kterého správce kódu používáte. Skripty playbooků a adresáře playbooků můžete spravovat jejich ručním umístěním do Project Base Path na serveru Tower nebo umístěním playbooku do libovolného systému správy zdrojového kódu (SCM) podporovaného společností Tower, včetně Git, Subversion, Mercurial a Red Hat. Postřehy. V rámci jednoho projektu můžete umístit tolik skriptů, kolik chcete. Vytvořil jsem například jeden základní projekt, do kterého jsem umístil skript pro základní prvky RedHat, skript pro jádro Linuxu a skripty pro zbytek základních linií. V jednom projektu tedy existovala řada rolí a scénářů, které byly spravovány z jednoho úložiště Git.
Spuštění všech těchto věcí prostřednictvím příkazového řádku je dobrý způsob, jak otestovat jejich funkčnost. Tím se připravíte na instalaci věže.
Promluvme si trochu o překódování manifestu Puppet, protože jsem nad tím strávil spoustu času, než jsem přišel na to, co je vlastně potřeba udělat.
Jak jsem řekl dříve, Puppet ukládá všechna nastavení a možnosti hardwaru do jednoho dlouhého manifestu a tento manifest ukládá vše, co by tento SCM měl dělat. Při přechodu nemusíte všechny své úkoly nacpat do jednoho seznamu, místo toho přemýšlejte o struktuře nového systému: role, skripty, značky, skupiny a co by tam mělo být. Některé z prvků autonomní sítě by měly být seskupeny do skupin, pro které lze vytvářet skripty. Složitější prvky infrastruktury, které zahrnují velké množství zdrojů, včetně samostatných tříd, lze kombinovat do rolí. Před migrací se o tom musíte rozhodnout. Pokud vytváříte velké role nebo scénáře, které se nevejdou na jednu obrazovku, měli byste použít značky, abyste mohli zachytit konkrétní části infrastruktury.
18:00
Nějaké inzeráty 🙂
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ého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com