Националната информационна служба за сателитни данни за околната среда (NESDIS) намали разходите си за управление на конфигурацията на Red Hat Enterprise Linux (RHEL) с 35%, преминавайки от Puppet Enterprise на Ansible Tower. В това видео от категорията „как направихме това“ системният инженер Майкъл Рау обосновава извършването на тази миграция, споделя полезни съвети и опит, придобит от прехода от една SCM на друга.
От това видео ще научите:
- как да обосновете на ръководството целесъобразността на прехода от Puppet Enterprise на Ansible Tower;
- какви стратегии да използвате за максимално плавен преход;
- съвети за трансформиране на PE манифести в Ansible Playbook;
- препоръки за оптимална инсталация на Ansible Tower.
Здравейте на всички, аз съм Майкъл Рау, старши системен инженер в ActioNet, която работи по Националната администрация за океански и атмосферни проучвания (NOAA) на службата NESDIS. Днес ще говорим за мигновението на стринговете – моят собствен опит при миграцията от Puppet Enterprise на Ansible Tower. Темата на тази презентация е "да погледнем на белезите ми", останали след като направих този преход в началото на годината. Искам да споделя какво научих по време на този процес. Когато поемете подобно начинание, използвайки моя опит, ще можете да направите прехода без излишни усилия.
Виждате слайдове, подобни на този, в началото на всяка презентация на Ansible Fest. На този слайд е изложена историята за автоматизацията на моята компания. Не съм новичък в това, тъй като използвам Puppet/Puppet Enterprise от 2007 година. Започнах да работя с Ansible през 2016 година, и мен, както много други потребители на този продукт, привлече възможността за "трикове" чрез командния ред и простите сценарии (playbooks). В края на 2017 година се обърнах към ръководството си с основателни причини за прехода към Ansible Tower. След малко ще разкажа за причините, които ме подтикнаха да предприема тази стъпка. След получаването на одобрение от ръководството, отне още няколко месеца, за да се реализира замисленото, и аз осъществих прехода през януари-февруари тази година. И така, ние напълно се отказахме от Puppet в полза на Ansible, и това е значимо постижение.
Най-вече в Ansible ме привлече възможността да пиша и използвам роли (roles) и сценарии (playbooks). Ролите са отлични за създаване на различни, но свързани задачи (tasks) и за централизирането на всички данни, свързани с тези задачи, на едно място. Playbook е YAML синтаксис, файл-сценарий, който описва действия за един или няколко хоста. Разказвам за тези възможности на потребителите, предимно на софтуерни разработчици. Ansible Tower дава възможност да се каже: „не, нямате достъп до shell access, но ви предоставям възможността да стартирате всички процеси на Tower и да рестартирате услугата, когато имате нужда“. Ще ви разкажа за работната среда и използваното от нас оборудване.
Това е федерална LAN, 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 възела. Тъй като мрежата продължаваше да расте, през 2014 г. преминахме на PE 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 е много по-лесно да се работи. Ако стартирате изпълними файлове, разбира се, ако не го правите без необходимост, с тях работят разумни и отзивчиви обработвачи. Сценарите playbooks, базирани на YAML, се отличават с лесно усвояване и бързина на използване. Тези, които никога преди не са чували за YAML, могат просто да прочетат сценария и лесно да разберат как работи.
Честно казано, Puppet значително усложнява труда ви като разработчик, тъй като е базиран на използването на Puppet Master. Това е единствената машина, която има право да комуникира с агентите Puppet. Ако внесете някакви промени в манефеста и искате да тествате кода си, трябва да препишете кода за Puppet Master, т.е. да настроите файла на Puppet Master /etc/hosts за свързване на всички клиенти и да стартирате услугата Puppet Server. Само след това можете да тествате работата на мрежовото оборудване на един хост. Това е доста болезнена процедура.
С Ansible всичко е много по-лесно. Всичко, което трябва да направите, е да разработите код за машина, която може да се свърже по протокол SSH с тествания хост. Работата с това е много по-лесна.
Следващото голямо предимство на Ansible Tower е възможността да се използва вече съществуващата система за поддръжка и да се запази съществуващата конфигурация на оборудването. Тази SCM без никакви допълнителни действия използва всичката налична информация за вашата инфраструктура и оборудване, виртуални машини, сървъри и т.н. Тя може да комуникира с вашите RH Satellite сървъри, ако такива имате, и ви предоставя такава интеграция, каквато никога не ще получите, работейки с Puppet.
Още една важна вещ е детайлният контрол. Вие знаете, че Puppet е модулна система, клиент-сървърно приложение, така че трябва да определите съществуващите аспекти на работата на всичките си машини в един дълъг манифест. В същото време състоянието на всеки отделен елемент от системата трябва да бъде тествано на всеки половин час – това е периодът по подразбиране. Ето как работи Puppet.
Tower ви освобождава от това. Можете неограничено да изпълнявате най-разнообразни процеси на най-различно оборудване, да вършите основната работа, да стартирате други важни процеси, да настройвате системата за сигурност, да работите с бази данни. Можете да правите всичко онова, което в Puppet Enterprise е свързано с определени затруднения. Така, ако сте направили настройки на един хост, ще е нужно време, за да встъпят промените в сила на останалите хостове. При Ansible всички промени влизат в сила наведнъж.
Накрая, нека разгледаме модула за сигурност. В Ansible Tower той е реализиран просто невероятно, с висока точност и внимание. Можете да предоставите на потребителите достъп до конкретни услуги или до конкретни хостове. Аз действам така с моите служители, свикнали да работят на Windows, като им ограничавам достъпа до Linux шел. Осигурявам им такъв достъп до Tower, че да могат да извършват само онези задачи и да стартират само онези услуги, които са в тяхната компетенция.
Нека разгледаме нещата, които трябва да направите предварително, за да улесните прехода към Ansible Tower. На първо място е необходимо да подготвите вашето оборудване. Ако някои елементи от вашата инфраструктура не са налични в базата данни, трябва да ги добавите там. Има системи, които не променят характеристиките си и затова липсват в БД Puppet, но ако не ги внесете преди прехода към Tower, ще загубите редица предимства. Може да е „мръсна“ предварителна БД, но тя трябва да съдържа информация за всичкото оборудване, което притежавате. Затова трябва да напишете динамичен скрипт за оборудването, който автоматично да внася всички промени в инфраструктурата в базата данни, така че Ansible да знае какви хостове трябва да присъстват в новата система. Няма да е необходимо да уведомявате тази SCM за това какви хостове сте добавили и кои повече не съществуват, тъй като всичко това тя ще разбере автоматично. Колкото повече данни има в БД, толкова по-полезен и гъвкав ще бъде Ansible. Той работи така, сякаш просто чете от базата данни баркод на състоянието на оборудването.
Посветете известно време на опознаване на комадния ред в Ansible. Изпълнете специални команди, за да проверите работата на скрипта за оборудване, напишете и стартирайте няколко прости, но полезни playbook сценария, използвайте шаблони Jinja2 там, където е уместно. Опитайте да напишете роля и сценарий за сложен многоетапен процес, използвайки стандартна, често срещана конфигурация на оборудването. Поиграйте с тези неща, тествайте как работят. По този начин ще научите как да работите с инструментите за създаване на библиотеки, използвани в Tower. Вече казах, че подготовката ми за прехода отне около 3 месеца. Мисля, че, опирайки се на моя опит, ще успеете да направите това по-бързо. Не считайте това време за изгубено, защото по-късно ще усетите всички предимства на свършената работа.
Накрая е необходимо да решите какво очаквате от Ansible Tower, какво точно тази система трябва да направи за вас.
Нуждаете ли се от инсталирането на система на празно оборудване, на празни виртуални машини? Или искате да запазите първоначалните условия на работа и настройките на съществуващото оборудване? Това е изключително важен аспект за работата на държавните компании, затова трябва да сте сигурни, че можете да извършите миграция и да инсталирате Ansible на съществуващата конфигурация. Определете рутинните административни процеси, които искате да автоматизирате. Уточнете дали ще трябва да инсталирате специфични приложения и услуги на новата система. Създайте списък с това, което искате да направите, и определете приоритетите.
След това започнете да пишете скриптове и роли, които ще осигурят изпълнението на планираните от вас задачи. Обединете ги в проекти, логическа колекция от съответстващи playbook скриптове. Всеки проект ще бъде свързан с отделен Git репозиториум или друг репозиториум в зависимост от мениджъра на кода, който използвате. Можете да управлявате playbook скриптове и директории, като ги поставите ръчно в Project Base Path на сървъра Tower, или като поставите playbook в която и да е система за управление на изходния код (SCM), поддържана от Tower, включително Git, Subversion, Mercurial и Red Hat Insights. В рамките на един проект можете да разположите толкова скриптове, колкото пожелаете. Например, аз създадох един основен проект, в който разположих скрипт за основни елементи на RedHat, скрипт за основата на Linux и скриптове за останалите основни показатели. Така в един проект присъстваха разнообразни роли и скриптове, управлявани от един Git репозиториум.
Изпълнявайте всички тези неща през командния ред; това е добър начин да проверите тяхната функционалност. По този начин ще се подготвите за инсталирането на Tower.
Нека поговорим малко за транскодирането на манифеста Puppet, защото отделих много време за това, докато не разбрах какво всъщност трябва да направя.
Както вече споменах, Puppet съхранява всички настройки и параметри на оборудването в един дълъг манифест, а в него е записано всичко, което тази SCM трябва да прави. При миграцията не е необходимо да събирате всичките си задачи в един списък, вместо това помислете за структурата на новата система: роли, сценарии, тагове, групи и какво трябва да бъде включено. Някои самостоятелни мрежови елементи следва да бъдат обединени в групи, за които могат да се създадат сценарии. По-сложни инфраструктурни елементи, които използват значителни ресурси, включително самостоятелни класове, могат да бъдат обединени в роли. Преди миграцията е важно да уточните всичко това. Ако създавате обширни роли или сценарии, които не се поместят на един екран, е добре да използвате тагове, за да можете да уловите отделни части от инфраструктурата.
18:00
Малко реклама 🙂
Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, , уникален аналог на entry-level сървъри, който е създаден от нас за вас: (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това
Източник: habr.com
