Прерязване на нишките: мигриране от Puppet Enterprise към Ansible Tower. Част 1

Националната информационна служба за сателитни данни за околната среда (NESDIS) намали разходите си за управление на конфигурацията за Red Hat Enterprise Linux (RHEL) с 35% чрез мигриране от Puppet Enterprise към Ansible Tower. В това видео „как го направихме“ системният инженер Майкъл Рау обяснява случая за тази миграция, споделяйки полезни съвети и научени уроци от преминаването от един SCM към друг.

От това видео ще научите:

• как да се обоснове пред ръководството възможността за преминаване от Puppet Enterprise към Ansible Tower;
• какви стратегии да използвате, за да направите прехода възможно най-плавен;
• съвети за транскодиране на PE манифести в Ansible Playbook;
• Препоръки за оптимален монтаж на Ansible Tower.

Здравейте на всички, казвам се Майкъл Рау, аз съм старши системен инженер в ActioNet, който работи за услугата NESDIS на Националната администрация за океаните и атмосферата (NOAA). Днес ще говорим за подрязване на низове - моят собствен опит от мигриране от Puppet Enterprise към Ansible Tower. Темата на тази презентация е да „разгледам белезите си“, останали след като направих този преход по-рано през годината. Искам да споделя какво научих чрез този процес. Така че, когато се заемете с нещо подобно, използвайки моя опит, можете да направите прехода без допълнителна работа.

Виждате подобни слайдове в началото на всяка презентация на Ansible Fest. Този слайд очертава историята на автоматизацията на моята компания. Не съм нов в това, защото използвам Puppet/Puppet Enterprise от 2007 г. Започнах да работя с Ansible през 2016 г. и като много други потребители на този продукт бях привлечен от възможността за „трикове“ с помощта на командния ред и прости скриптове (книги за игри). В края на 2017 г. се обърнах към моето ръководство относно силните причини да се преместя в Ansible Tower. След малко ще ви разкажа за причините, които ме подтикнаха да направя тази стъпка. След като получих съгласието на ръководството, бяха необходими още няколко месеца за завършване на плана и аз направих прехода през януари-февруари тази година. И така, ние напълно изоставихме Puppet в полза на Ansible и това е страхотно нещо.

Това, което ме привлича най-много в Ansible, е способността да пиша и използвам роли и книги-игри. Ролите са чудесни за създаване на отделни, но свързани задачи и поставяне на всички данни, свързани с тези задачи, на едно място. Книгата за игра е YAML синтаксис, скриптов файл, който описва действия за един или повече хостове. Казвам на потребителите за тези функции, предимно на разработчиците на софтуер. Ansible Tower ви дава възможност да кажете „не, нямате достъп до shell, но ви давам възможността да изпълнявате всички процеси на Tower и да рестартирате услугата, когато имате нужда от нея.“ Ще ви разкажа за работната среда и оборудването, което използваме.

Това е федерална локална мрежа, 7 физически сайта, свързани чрез облачен MPLS, 140 RHEL сървъра, 99% от които са виртуални (vSphere), хардуер SuperMicro, NexentaStore мрежово съхранение, набор от комутатори Cisco, Arista и Cumulus и Fortinet UTM унифицирано управление на заплахи инструменти на всеки сайт.

Федералната мрежа означава, че трябва да използвам всички мерки за сигурност на информацията, предвидени от закона. Трябва да имате предвид, че Puppet Enterprise не поддържа повечето от хардуера, който използваме. Принудени сме да използваме бюджетен хардуер, защото държавните агенции имат проблеми с финансирането на тази разходна позиция. Затова закупуваме хардуер SuperMicro и сглобяваме нашето оборудване от отделни части, чиято поддръжка е гарантирана с държавни поръчки. Използваме Linux и това е една от важните причини да преминем към Ansible.

Нашата история с Puppet е следната.

През 2007 г. имахме малка мрежа от 20-25 възела, в която внедрихме Puppet. По принцип тези възли бяха просто „кутии“ на RedHat. През 2010 г. започнахме да използваме уеб интерфейса Puppet Dashboard за 45 възела. Тъй като мрежата продължи да се разширява, ние преминахме към PE 2014 през 3.3 г., като направихме пълен преход с пренаписване на манифест за 75 възела. Това трябваше да се направи, защото Puppet обича да променя правилата на играта, а в този случай те промениха напълно езика. Година по-късно, когато поддръжката за версия 3 на Puppet Enterprise приключи, бяхме принудени да мигрираме към PE 2015.2. Трябваше да пренапишем отново манифеста за новите сървъри и да закупим лиценз с резерв от 100 възела, въпреки че по това време имахме само 85 възела.

Изминаха само 2 години и отново трябваше да свършим много работа, за да мигрираме към новата версия PE 2016.4. Купихме лиценз за 300 възела, като имахме само 130. Отново трябваше да направим големи промени в манифеста, защото новата версия на езика имаше различен синтаксис от езика на версията от 2015 г. В резултат на това нашият SCM премина от SVN контрол на версиите към Bitbucket (Git). Това беше нашата „връзка“ с Puppet.

Така че трябваше да обясня на ръководството защо трябва да преминем към различен SCM, използвайки следните аргументи. Първата е високата цена на услугата. Говорих с момчетата от RedHat и те казаха, че цената за управление на мрежа от 300 възела с Ansible Tower е половината от цената на Puppet Enterprise. Ако закупите и Ansible Engine, цената ще бъде приблизително същата, но ще получите много повече функции от PE. Тъй като сме държавна компания, финансирана от федералния бюджет, това е доста силен аргумент.

Вторият аргумент е универсалността. Puppet поддържа само хардуер, който има агент Puppet. Това означава, че агент трябва да бъде инсталиран на всички комутатори и трябва да е най-новата версия. И ако някои от вашите превключватели поддържат една версия, а други друга, ще трябва да инсталирате нова версия на PE агента върху тях, така че всички да могат да работят в една и съща SCM система.

Системата Ansible Tower работи по различен начин, защото няма никакви агенти, но има модули, които поддържат комутатори на Cisco и всички други комутатори. Този SCM поддържа Qubes OS, Linux и 4.NET UTM. Ansible Tower също поддържа NexentaStore мрежови контролери за съхранение, базирани на ядрото Illumos, Unix-базирана операционна система с отворен код. Това е много малко поддръжка, но Ansible Tower го прави така или иначе.

Третият аргумент, който е много важен както за мен, така и за нашата администрация, е лекотата на използване. Прекарах 10 години в овладяване на Puppet модули и манифестен код, но научих Ansible в рамките на една седмица, защото този SCM е много по-лесен за работа. Ако стартирате изпълними файлове, разбира се, освен ако не го правите ненужно, тогава интелигентни и отзивчиви манипулатори работят с тях. Базираните на YAML книги-игри са лесни за научаване и бързи за използване. Тези, които никога преди не са чували за YAML, могат просто да прочетат скриптовете и лесно да разберат как работи.

Честно казано, Puppet прави работата ви като разработчик много по-трудна, защото се основава на използването на Puppet Master. Това е единствената машина, на която е позволено да комуникира с марионетни агенти. Ако сте направили промени в манифеста и искате да тествате кода си, трябва да пренапишете кода за Puppet Master, тоест да конфигурирате файла Puppet Master /etc/hosts, за да свържете всички клиенти и да стартирате услугата Puppet Server. Само след това ще можете да тествате работата на мрежовото оборудване на един хост. Това е доста болезнена процедура.
Всичко е много по-просто в Ansible. Всичко, което трябва да направите, е да разработите код за машина, която може да комуникира чрез SSH с тествания хост. Това е много по-лесно за работа.

Следващото голямо предимство на Ansible Tower е възможността да използвате съществуващата си система за поддръжка и да поддържате съществуващата си хардуерна конфигурация. Този SCM използва цялата налична информация за вашата инфраструктура и хардуер, виртуални машини, сървъри и т.н. без никакви допълнителни стъпки. Може да общува с вашите сървъри RH Satellite, ако имате такъв, и ви дава интеграции, които никога няма да получите с Puppet.

Друго важно нещо е детайлният контрол. Знаете, че Puppet е модулна система, това е клиент-сървър приложение, така че трябва да дефинирате съществуващите аспекти на всичките си машини в един дълъг манифест. В този случай състоянието на всеки отделен елемент от системата трябва да се тества на всеки половин час - това е периодът по подразбиране. Ето как работи Puppet.

Кулата ви спасява от това. Можете да изпълнявате различни процеси на различно оборудване без ограничения; можете да извършвате основна работа, да изпълнявате други важни процеси, да настройвате система за сигурност и да работите с бази данни. Можете да направите всичко, което е трудно в Puppet Enterprise. Така че, ако сте го конфигурирали на един хост, ще отнеме време, докато промените влязат в сила на останалите хостове. В Ansible всички промени влизат в сила едновременно.

И накрая, нека да разгледаме модула за сигурност. Ansible Tower го изпълнява просто невероятно, с голяма прецизност и внимание. Можете да предоставите на потребителите достъп до конкретни услуги или до конкретни хостове. Правя това с моите служители, които са свикнали да работят на Windows, ограничавайки достъпа им до обвивката на Linux. Гарантирам, че имат достъп до Tower, така че да могат да вършат само работата и да изпълняват само услугите, които са подходящи за тях.

Нека да разгледаме нещата, които трябва да направите предварително, за да улесните прехода си към Ansible Tower. На първо място, трябва да подготвите оборудването си. Ако някои елементи от вашата инфраструктура все още не са в базата данни, трябва да ги добавите там. Има системи, които не променят характеристиките си и следователно не са в базата данни Puppet, но ако не ги добавите там, преди да преминете към Tower, ще загубите редица предимства. Това може да е „мръсна“, предварителна база данни, но трябва да съдържа информация за цялото оборудване, което имате. Следователно трябва да напишете динамичен хардуерен скрипт, който автоматично ще вкара всички инфраструктурни промени в базата данни, след което Ansible ще разбере кои хостове трябва да присъстват в новата система. Няма да е необходимо да казвате на този SCM кои хостове сте добавили и кои хостове вече не съществуват, защото той ще знае всичко това автоматично. Колкото повече данни има в базата данни, толкова по-полезен и гъвкав ще бъде Ansible. Работи така, сякаш просто чете баркода за състоянието на хардуера от база данни.

Прекарайте известно време, за да се запознаете с командния ред в Ansible. Изпълнете някои персонализирани команди, за да тествате хардуерния скрипт, напишете и изпълнете някои прости, но полезни скриптове за игри, използвайте Jinja2 шаблони, където е подходящо. Опитайте да напишете роля и скрипт за сложен, многоетапен процес, като използвате обща, често срещана хардуерна конфигурация. Играйте с тези неща, тествайте как работи. По този начин ще научите как да използвате инструментите за създаване на библиотека, използвани в Tower. Вече казах, че подготовката за прехода ми отне около 3 месеца. Мисля, че въз основа на моя опит ще можете да направите това по-бързо. Не смятайте това време за пропиляно, защото по-късно ще изпитате всички предимства на свършената работа.

След това трябва да решите какво очаквате от Ansible Tower, какво точно тази система трябва да прави за вас.

Трябва ли да разположите системата на гол хардуер, на голи виртуални машини? Или искате да запазите оригиналните работни условия и настройки на съществуващото оборудване? Това е много важен аспект за публичните компании, така че трябва да сте сигурни, че ще можете да мигрирате и внедрите Ansible на вашата съществуваща конфигурация. Идентифицирайте рутинни административни процеси, които искате да автоматизирате. Разберете дали трябва да внедрите конкретни приложения и услуги в новата система. Направете списък с това, което искате да направите, и го подредете по приоритет.

След това започнете да пишете код на скрипт и роли, които ще позволят задачите, които планирате да изпълните. Комбинирайте ги в проекти, логична колекция от подходящи учебници. Всеки проект ще принадлежи към отделно Git хранилище или различно хранилище в зависимост от това кой мениджър на кодове използвате. Можете да управлявате скриптове и директории на книги за игри, като ги поставите ръчно в основния път на проекта на сървъра на Tower или като поставите книгата за игри във всяка система за управление на изходния код (SCM), поддържана от Tower, включително Git, Subversion, Mercurial и Red Hat Прозрения. В рамките на един проект можете да поставите колкото искате скриптове. Например, създадох един основен проект, в който поставих скрипт за основните елементи на RedHat, скрипт за ядрото на Linux и скриптове за останалите базови линии. Така в един проект имаше различни роли и сценарии, които се управляваха от едно Git хранилище.

Пускането на всички тези неща през командния ред е добър начин да тествате тяхната функционалност. Това ще ви подготви за инсталирането на Tower.

Нека поговорим малко за транскодирането на манифеста на Puppet, защото отделих много време за това, докато разбера какво всъщност трябва да се направи.

Както казах преди, Puppet съхранява всички настройки и хардуерни опции в един дълъг манифест и този манифест съхранява всичко, което този SCM трябва да прави. Когато правите прехода, не е необходимо да натъпквате всичките си задачи в един списък; вместо това помислете за структурата на новата система: роли, скриптове, тагове, групи и какво трябва да отиде там. Някои от автономните мрежови елементи трябва да бъдат групирани в групи, за които да могат да се създават скриптове. По-сложни инфраструктурни елементи, които включват голям брой ресурси, включително самостоятелни класове, могат да бъдат комбинирани в роли. Преди да мигрирате, трябва да решите това. Ако създавате големи роли или сценарии, които не се побират на един екран, трябва да използвате тагове, за да можете да уловите конкретни части от инфраструктурата.

18:00

Прерязване на нишките: мигриране от Puppet Enterprise към Ansible Tower. Част 2

Малко реклами 🙂

Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, облачен VPS за разработчици от $4.99, уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да споделите сървър? (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV от $199 в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за Как да изградим инфраструктура Corp. клас с използване на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за стотинка?

Източник: www.habr.com