Националната информационна служба за спътникови данни за околната среда (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 – open-source операционна система, базирана на Unix. Въпреки че е много ограничена поддръжка, Ansible Tower все пак я предоставя.
Третият аргумент, много важен както за мен, така и за нашата администрация, е простотата при усвояване. Аз усвоявах модулите и кода на манифестите Puppet в продължение на 10 години, но Ansible изучих за седмица, защото с тази SCM е много по-лесно да се работи. Когато стартирате изпълними файлове, разбира се, ако не правите това без нужда, те се обработват от разумни и отзивчиви обработчици. Плейбуците, основани на YAML, са лесни за изучаване и бързи за използване. Тези, които никога преди не са чували за YAML, могат просто да прочетат сценарии и лесно да разберат как работи.
Честно казано, Puppet значително усложнява работата ви като разработчик, тъй като е основан на използването на Puppet Master. Това е единствената машина, която има право да комуникира с агентите Puppet. Ако сте внесли някакви промени в манифеста и искате да тествате кода си, трябва да пренапишете кода за Puppet Master, т.е. да конфигурирате файла Puppet-мастера /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, ще загубите редица предимства. Това може да бъде „мръсна“, предварителна БД, но тя трябва да съдържа информация за всичкото ваше оборудване. Следователно, трябва да напишете динамичен скрипт за оборудването, който автоматично ще внесe всички промени в инфраструктурата в базата данни, за да може Ansible да знае кои хостове трябва да присъстват в новата система. Няма да е необходимо да информирате тази SCM за добавените хостове и хостовете, които вече не съществуват, тъй като всичко това тя ще знае автоматично. Колкото повече данни има в БД, толкова по-полезен и гъвкав ще бъде Ansible. Той работи така, сякаш просто чете от базата данни баркод на състоянието на оборудването.
Отделете малко време, за да се запознаете с работата на командния ред в Ansible. Стартирайте специални команди, за да проверите работата на скрипта за оборудване, напишете и стартирайте прости, но полезни сценарии playbook, използвайте Jinja2 шаблони там, където е уместно. Опитайте се да напишете роля и сценарий за сложен многостепенен процес, използвайки стандартна, често срещана конфигурация на оборудване. Играйте с тези неща, тествайте как работят. По този начин ще се научите да работите с инструментите за създаване на библиотеки, използвани в Tower. Вече казах, че подготовката ми за преминаването отне около 3 месеца. Мисля, че опирайки се на моя опит, ще успеете да направите това по-бързо. Не считайте това време за загубено, тъй като по-късно ще усетите всички предимства на свършената работа.
Следващата стъпка е да решите какво очаквате от Ansible Tower и какво точно тази система трябва да направи за вас.
Нужно ли ви разгръщане на система на празно оборудване, на празни виртуални машини? Или искате ли да запазите първоначалните условия на работа и настройки на съществуващото оборудване? Това е много важен аспект за работата на държавни компании, така че трябва да сте сигурни, че ще успеете да мигрирате и разгръщате Ansible на съществуващата конфигурация. Определете рутинните административни процеси, които искате да автоматизирате. Изяснете дали имате нужда да разгръщате специфични приложения и услуги на новата система. Съставете списък на това, което искате да направите, и подредете приоритетите.
След това продължете с написването на кодове на сценарии и роли, които ще осигурят изпълнението на планираните от вас задачи. Обединете ги в Projects, логическа колекция от съответстващи сценарии playbooks. Всеки Project ще се отнася до отделен Git репозиторий или друг репозиторий в зависимост от това, какъв мениджър на код използвате. Можете да управлявате сценарии playbook и директории playbook, като ги поставите ръчно в Project Base Path на сервера Tower, или като поставите playbook в която и да е система за управление на изходния код (SCM), която се поддържа от Tower, включително Git, Subversion, Mercurial и Red Hat Insights. В рамките на един Project можете да поставите толкова сценарии, колкото желаете. Например, създадох един основен Project, в който поставих сценарий за основните елементи на 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
