Сечење на нишките: мигрирање од 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, кој работи за Националната океанска и атмосферска администрација (NOAA) NESDIS услуга. Денес ќе зборуваме за потстрижување на жици - мое сопствено искуство за мигрирање од Puppet Enterprise во Ansible Tower. Темата на оваа презентација е „да ги погледнеме моите лузни“ оставени откако ја направив оваа транзиција претходно во годината. Сакам да споделам што научив низ овој процес. Така, кога ќе преземете нешто вакво, користејќи го моето искуство, можете да ја направите транзицијата без дополнителна работа.

Гледате слајдови слични на овој на почетокот на секоја презентација на Ansible Fest. Овој слајд ја прикажува историјата на автоматизацијата на мојата компанија. Не сум нов во ова бидејќи користам Puppet/Puppet Enterprise од 2007 година. Почнав да работам со Ansible во 2016 година, и како и многу други корисници на овој производ, ме привлече можноста за „трикови“ со помош на командната линија и едноставни скрипти (книги). На крајот на 2017 година, му се обратив на моето раководство за силните причини за преселба во Ansible Tower. За една минута ќе ви кажам за причините што ме поттикнаа на овој чекор. По добивањето на согласност од раководството, беа потребни уште неколку месеци за да се заврши планот, а транзицијата ја направив во јануари-февруари оваа година. Значи, целосно го напуштивме Puppet во корист на Ansible, и тоа е одлична работа.

Она што најмногу ме привлекува кај Ansible е способноста да пишува и користи улоги и книги. Улогите се одлични за создавање различни, но поврзани задачи и ставање на сите податоци поврзани со тие задачи на едно место. Playbook е синтакса на YAML, датотека со скрипта што опишува дејства за еден или повеќе домаќини. Им кажувам на корисниците за овие карактеристики, првенствено за развивачите на софтвер. Ansible Tower ви дава можност да кажете: „не, немате пристап до школка, но јас ви давам можност да ги извршите сите процеси на 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 година, почнавме да го користиме веб-интерфејсот за кукли табла за 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). Ова беше нашата „врска“ со Кукла.

Така, морав да му објаснам на раководството зошто требаше да се преселиме во друг 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 години совладувајќи ги куклените модули и манифестниот код, но научив 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. Обезбедувам дека тие имаат пристап до кулата за да можат да ја вршат само работата и да ги водат само услугите што се релевантни за нив.

Ајде да ги погледнеме работите што треба да ги направите предвреме за да ја олесните вашата транзиција кон Ansible Tower. Пред сè, треба да ја подготвите вашата опрема. Ако некои елементи од вашата инфраструктура не се веќе во базата на податоци, треба да ги додадете таму. Има системи кои не ги менуваат своите карактеристики и затоа ги нема во базата на кукли, но ако не ги додадете таму пред да се преселите во Tower, ќе изгубите голем број на предности. Ова може да е „валкана“, прелиминарна база на податоци, но треба да содржи информации за целата опрема што ја имате. Затоа, треба да напишете динамична хардверска скрипта која автоматски ќе ги турка сите промени во инфраструктурата во базата на податоци, а потоа Ansible ќе знае кои хостови треба да бидат присутни на новиот систем. Нема да треба да му кажувате на овој SCM кои хостови сте ги додале и кои хостови повеќе не постојат, бидејќи сето тоа ќе го знае автоматски. Колку повеќе податоци има во базата, толку покорисен и пофлексибилен ќе биде Ansible. Работи како едноставно да го чита баркодот за статусот на хардверот од базата на податоци.

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

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

Дали треба да го распоредите системот на гол хардвер, на голи виртуелни машини? Или сакате да ги задржите оригиналните работни услови и поставките на постоечката опрема? Ова е многу важен аспект за јавните претпријатија, па затоа треба да бидете сигурни дека ќе можете да мигрирате и распоредите Ansible на вашата постоечка конфигурација. Идентификувајте рутински административни процеси што сакате да ги автоматизирате. Дознајте дали треба да распоредите специфични апликации и услуги на новиот систем. Направете листа на она што сакате да го правите и дајте му приоритет.

Потоа започнете да пишувате код за скрипта и улоги кои ќе ги овозможат задачите што планирате да ги завршите. Комбинирајте ги во Проекти, логична колекција на релевантни книги за играње. Секој проект ќе припаѓа на посебно складиште на Git или различно складиште во зависност од тоа кој менаџер на код го користите. Можете да управувате со скрипти и директориуми за плејбук со рачно ставање во Project Base Path на серверот Tower или со поставување на Playbook во кој било систем за управување со изворниот код (SCM) поддржан од Tower, вклучувајќи ги Git, Subversion, Mercurial и Red Hat Увиди. Во рамките на еден проект можете да поставите онолку скрипти колку што сакате. На пример, создадов еден основен проект во кој поставив скрипта за основните елементи на RedHat, скрипта за јадрото на Linux и скрипти за остатокот од основните линии. Така, во еден проект имаше различни улоги и сценарија кои беа управувани од едно складиште на Git.

Извршувањето на сите овие работи преку командната линија е добар начин за тестирање на нивната функционалност. Ова ќе ве подготви за инсталацијата на кулата.

Ајде да разговараме малку за транскодирање на манифестот на кукли, бидејќи потрошив многу време на ова додека не сфатив што всушност треба да се направи.

Како што реков претходно, 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 јадра и до 40 GB 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 телевизор од 199 долари во Холандија! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - од 99 долари! Прочитајте за Како да се изгради инфраструктурна корп. класа со употреба на сервери Dell R730xd E5-2650 v4 вредни 9000 евра за денар?

Извор: www.habr.com