Shërbimi Kombëtar i Informacionit të të Dhënave Satelitore për Mjedisin (NESDIS) ka ulur me 35% kostot e saj në menaxhimin e konfiguracioneve Red Hat Enterprise Linux (RHEL), duke kaluar nga Puppet Enterprise në Ansible Tower. Në këtë video nga kategoria 'si e bëmë këtë', inxhinieri sistemor Michael Rau diskuton arsyetimin pas këtij kalimi, ndan këshilla të dobishme dhe përvojën e fituar nga kalimi nga një SCM në një tjetër.
Nga kjo video do të mësoni:
- si të justifikoni udhëheqjes tuaj arsyeshmërinë e kalimit nga Puppet Enterprise në Ansible Tower;
- cila strategji të përdorni për një kalim sa më të qetë;
- këshilla për transkodimin e manifestëve PE në Ansible Playbook;
- rekomandime për instalimin optimal të Ansible Tower.
PĂ«rshĂ«ndetje tĂ« gjithĂ«ve, unĂ« quhem Michael Rau, inxhinier i lartĂ« sistemor nĂ« ActioNet, njĂ« kompani qĂ« punon me AdministratĂ«n KombĂ«tare tĂ« OqeanĂ«ve dhe AtmosferĂ«s (NOAA) nĂ« shĂ«rbimin NESDIS. Sot do tĂ« flasim pĂ«r shkurtime tĂ« linjave â pĂ«rvojĂ«n time personale tĂ« kalimit nga Puppet Enterprise nĂ« Ansible Tower. Tema e kĂ«tij prezantimi Ă«shtĂ« tĂ« 'shohim plagĂ«t e mia', qĂ« kanĂ« mbetur pas kalimit tim nĂ« fillim tĂ« kĂ«tij viti. Dua tĂ« ndaj se çfarĂ« kam mĂ«suar gjatĂ« kĂ«tij procesi. KĂ«shtu qĂ« kur tĂ« merreni me diçka tĂ« tillĂ«, duke pĂ«rdorur pĂ«rvojĂ«n time, do tĂ« mund tĂ« bĂ«ni kalimin pa shumĂ« vĂ«shtirĂ«si.
Shihni prezantime si kjo në fillim të çdo prezantimi në Ansible Fest. Në këtë slide është historia e automatizimit të kompanisë sime. Nuk jam i ri në këtë fushë, sepse kam përdorur Puppet/Puppet Enterprise që nga viti 2007. Kam filluar të punoj me Ansible në vitin 2016, dhe si shumë përdorues të tjerë të këtij produkti, u tërhoqa nga mundësitë 'truke' me komandat dhe skenarët e thjeshtë (playbooks). Në fund të vitit 2017, i kërkova udhëheqjes sime një arsyetim të fortë për kalimin në Ansible Tower. Pas disa minutash, do të flas për arsyet që më thanë ta bëja këtë hap. Pas miratimit nga udhëheqja, iu deshën disa muaj për të realizuar planin, dhe kalimin e bëra në janar-shkurt të këtij viti. Pra, ne u ndamë plotësisht nga Puppet në favor të Ansible, dhe kjo është një gjë e shkëlqyer.
Më shumë se çdo gjë tjetër në Ansible, më tërheq mundësia për të shkruar dhe përdorur rolet (roles) dhe skenarët (playbooks). Roli është shkëlqyer për të krijuar detyra (tasks) të ndryshme, por të lidhura, dhe për të vendosur të gjitha të dhënat e lidhura me këto detyra në një vend. Playbook është një sintaksë YAML, një skenar skedari që përshkruan veprimet për një ose më shumë hoste. Unë flas për këto mundësi ndaj përdoruesve, kryesisht zhvilluesve të softuerit. Ansible Tower ofron mundësinë për të thënë: "jo, nuk keni akses në shell, por unë ju jap mundësinë të filloni të gjithë proceset e Tower dhe të rinisni shërbimin kur ju nevojitet." Do t'ju flas për ambientin e punës dhe pajisjet që përdorim.
ĂshtĂ« njĂ« LAN federale, 7 vende fizike tĂ« lidhura pĂ«rmes njĂ« MPLS nĂ« re, 140 serverĂ« RHEL, 99% e tĂ« cilĂ«ve janĂ« virtualĂ« (vSphere), pajisje SuperMicro, ruajtje rrjeti NexentaStore, njĂ« grup kalibresh Cisco, Arista dhe Cumulus, dhe mjete tĂ« menaxhimit tĂ« unifikuar tĂ« kĂ«rcĂ«nimeve Fortinet UTM nĂ« çdo vend.
Rruga federale do të thotë se unë duhet të përdor të gjitha masat për mbrojtjen e informacionit të parashikuara nga ligjet. Duhet të keni parasysh se Puppet Enterprise nuk mbështet shumicën e pajisjeve që përdorim. Ne jemi të detyruar të përdorim pajisje buxhetore, pasi institucionet shtetërore përballen me probleme me financimin e këtij artikulli shpenzimesh. Prandaj, ne blejmë "harduer" të klasës SuperMicro dhe këtë pajisje e përbëjmë nga komponente të veçanta, mirëmbajtja e të cilave garantohet nga kontratat qeveritare. Ne përdorim Linux, dhe kjo është një nga arsyet kryesore për kalimin në Ansible.
Historia jonë me Puppet është ashtu.
Në vitin 2007, ne kishim një rrjet të vogël prej 20-25 nodesh, ku zbatova Puppet. Kryesisht, këto node ishin thjesht "box" RedHat. Në vitin 2010, filluam të përdorim ndërfaqen e uebit Puppet Dashboard për 45 node. Meqenëse rrjeti vazhdoi të zgjerohej, në vitin 2014 kaluam në PE 3.3, duke realizuar një kalim të plotë me rishkrimin e manifestit për 75 node. Kjo duhej bërë sepse Puppet pëlqen të ndryshojë rregullat e lojës, dhe në këtë rast ata e ndryshuan krejtësisht gjuhën. Një vit më vonë, kur u ndal mbështetja për versionin e tretë të Puppet Enterprise, ne u detyruam të migrojmë në PE 2015.2. Duhej sërish të rishkruhej manifesti për serverat e rinj dhe të blinim një licencë për 100 node, megjithatë në atë kohë kishim vetëm 85 node.
Ka kaluar vetëm 2 vjet, dhe na duhej sërish të bënim një punë të madhe për kalimin në versionin e ri PE 2016.4. Ne blëmë një licencë për 300 node, duke pasur vetëm 130. Na duhej sërish të bënim ndryshime të konsiderueshme në manifest, sepse versioni i ri i gjuhës kishte një sintaksë të ndryshme nga versioni i vitit 2015. Në fund, SCM jonë kaloi nga sistemi i kontrollit të versioneve SVN në Bitbucket (Git). Këto ishin "marrëdhëniet" tona me Puppet.
Pra, mĂ« duhej tĂ« shpjegoja menaxhmentit pse na duhej tĂ« kalonim nĂ« njĂ« SCM tjetĂ«r, duke pĂ«rdorur kĂ«to argumente. E para â kostoja e lartĂ« e shĂ«rbimit. Kam biseduar me djemtĂ« nga RedHat, dhe ata thanĂ« se kostoja e mirĂ«mbajtjes sĂ« njĂ« rrjeti prej 300 nodesh me Ansible Tower pĂ«rbĂ«n gjysmĂ«n e kostos sĂ« Puppet Enterprise. NĂ«se blini gjithashtu Ansible Engine, kostoja do tĂ« ishte pĂ«rafĂ«rsisht e njĂ«jtĂ«, por do tĂ« merrnit shumĂ« mĂ« tepĂ«r funksionalitet se sa me PE. Duke qenĂ« se jemi njĂ« kompani shtetĂ«rore, e financuar nga buxheti federal, kjo Ă«shtĂ« njĂ« argument i fuqishĂ«m.
Argumenti i dytĂ« â Ă«shtĂ« universialiteti. Puppet mbĂ«shtet vetĂ«m atĂ« pajisje qĂ« ka agentin Puppet tĂ« instaluar. Kjo do tĂ« thotĂ« se tĂ« gjitha switch-et duhet tĂ« kenĂ« agentin tĂ« instaluar, dhe ai duhet tĂ« jetĂ« versioni mĂ« i fundit. Dhe nĂ«se disa nga switch-et tuaja mbĂ«shtesin njĂ« version, ndĂ«rsa disa tĂ« tjera njĂ« version tjetĂ«r, do t'ju nevojitet tĂ« instaloni versionin e ri tĂ« agentit PE nĂ« ato pĂ«r tĂ« siguruar qĂ« tĂ« gjitha tĂ« mund tĂ« punojnĂ« nĂ« njĂ« sistem tĂ« vetĂ«m SCM.
Sistemi Ansible Tower punon ndryshe, sepse nuk ka asnjĂ« agjent, por ka module qĂ« mbĂ«shtesin switch-at Cisco dhe tĂ« gjitha switch-et e tjera. Ky SCM mbĂ«shtet Qubes OS, Linux dhe 4.NET UTM. Ansible Tower gjithashtu mbĂ«shtet kontrolluesit e ruajtjeve nĂ« re NexentaStore, tĂ« bazuar nĂ« bĂ«rthamĂ«n Illumos â njĂ« sistem operativ open-source tĂ« bazuar nĂ« Unix. Kjo Ă«shtĂ« njĂ« mbĂ«shtetje e vogĂ«l, por Ansible Tower akoma e realizon atĂ«.
Argumenti i tretë, shumë i rëndësishëm si për mua ashtu edhe për administratën tonë, është thjeshtësia në mësim. Kam kaluar 10 vjet duke e mësuar modulet dhe kodin e manifestave të Puppet, por Ansible e studiuar brenda një jave, sepse me këtë SCM është shumë më e lehtë të punosh. Nëse po ekzekutoni skedarë të ekzekutueshëm, sigurisht, nëse nuk po e bëni këtë pa nevojë, atëherë me ta punojnë përfundues të arsyeshëm dhe reagues. Skriptet e playbooks, të bazuara në YAML, karakterizohen nga mësimi i lehtë dhe shpejtësia e përdorimit. Ata që nuk kanë dëgjuar kurrë më parë për YAML, mund thjesht të lexojnë skenaret dhe të kuptojnë lehtë se si funksionon.
Sinqerisht, Puppet e komplikon shumë punën tuaj si zhvillues, sepse bazohet në përdorimin e Puppet Master. Kjo është makina e vetme që ka të drejtë të komunikojë me agjentët Puppet. Nëse bëni ndonjë ndryshim në manifest dhe dëshironi të testoni kodin tuaj, duhet të rishkruani kodin për Puppet Master, pra të konfiguroyni skedarin Puppet-master /etc/hosts për t'u lidhur me të gjithë klientët dhe të filloni shërbimin Puppet Server. Vetëm pas kësaj do të jeni në gjendje të provoni punën e pajisjeve rrjetore në një host të vetëm. Kjo është një procedurë mjaft e dhimbshme.
Në Ansible, gjithçka është shumë më e thjeshtë. Gjithçka që duhet të bëni është të zhvilloni kodin për makinën që ka mundësi të lidhet me protokollin SSH me hostin e testuar. Kjo është shumë më e lehtë për t'u punuar.
Avantazhi tjetër i madh i Ansible Tower është mundësia për të angazhuar sistemin e mbështetjes që tashmë e keni dhe për të ruajtur konfigurimin ekzistues të pajisjeve. Ky SCM përdor pa ndonjë veprim të mëtejshëm të gjitha informacionet ekzistuese rreth infrastrukturës dhe pajisjeve tuaja, makinave virtuale, serverëve etj. Ai mund të komunikojë me serverët tuaj RH Satellite, nëse i keni, dhe ju ofron një integrim që kurrë nuk do ta merrni duke punuar me Puppet.
NjĂ« gjĂ« tjetĂ«r e rĂ«ndĂ«sishme Ă«shtĂ« kontrolli i detajuar. E dini qĂ« Puppet Ă«shtĂ« njĂ« sistem modular, Ă«shtĂ« njĂ« aplikacion klient-server, prandaj duhet tĂ« pĂ«rcaktoni aspektet ekzistuese tĂ« funksionimit tĂ« tĂ« gjitha makinave tuaja nĂ« njĂ« manifest tĂ« gjatĂ«. NĂ« kĂ«tĂ« mĂ«nyrĂ«, gjendja e çdo elementi tĂ« vetĂ«m nĂ« sistem duhet tĂ« testohet çdo gjysmĂ« ore â ky Ă«shtĂ« periudha e paracaktuar. KĂ«shtu punon Puppet.
Tower ju çliron nga kjo. Mund të ekzekutoni procese të ndryshme pa kufizime në pajisje të ndryshme, mund të kryeni punën kryesore, të aktivizoni procese të tjera të rëndësishme, të konfiguroni sistemin e sigurisë, të punoni me baza të dhënash. Mund të bëni gjithçka që në Puppet Enterprise lidhet me vështirësi të caktuara. Kështu, nëse keni bërë konfigurimin në një host, do të duhen kohë që ndryshimet të hyjne në fuqi në hostet e tjera. Në Ansible, të gjitha ndryshimet hyjnë në fuqi njëkohësisht.
Së fundi, le të shqyrtojmë modulën e sigurisë. Në Ansible Tower, ajo është implementuar thjesht mahnitshëm, me saktësi të madhe dhe kujdes. Mund të jepni përdoruesve akses në shërbime specifike ose në hoste specifike. Unë e bëj këtë me punonjësit e mi, të cilët janë të zakonshëm të punojnë në Windows, duke u kufizuar atyre aksesin në shell-in Linux. Ju siguroj atyre një qasje në Tower, në mënyrë që të mund të kryejnë vetëm atë punë dhe të aktivizojnë vetëm ato shërbime që i përkasin kompetencës së tyre.
Le të shqyrtojmë disa hapa që duhet të përgatiten paraprakisht për të lehtësuar kalimin në Ansible Tower. Së pari, është e nevojshme të përgatitni pajisjet tuaja. Nëse disa elemente të infrastrukturës tuaj nuk janë ende të pranishme në bazën e të dhënave, ato duhet të shtohen atje. Ekzistojnë sisteme që nuk ndryshojnë karakteristikat e tyre dhe kështu nuk janë të pranishme në bazën e të dhënave të Puppet, por nëse nuk i shtoni ato para kalimit në Tower, do të humbni disa përfitime. Mund të jetë një bazë e dhënash
Merrni pak kohë për t'u njohur me punën e komandës në Ansible. Ekzekutoni disa komanda speciale për të verifikuar funksionimin e skenarit të pajisjes, shkruani dhe ekzekutoni disa skenarë të thjeshtë por të dobishëm të playbook, përdorni template të Jinja2 aty ku është e përshtatshme. Provoni të shkruani një rol dhe skenar për një proces kompleks me shumë hapa, duke përdorur një konfigurim standard dhe të zakonshëm të pajisjeve. Loja me këto gjëra, testi sesi funksionojnë ato. Kështu do të mësoni të punoni me mjetet për ndërtimin e bibliotekave që përdoren në Tower. Kisha thënë se mësimi për kalimin më mori rreth 3 muaj. Mendoj se, duke u bazuar në përvojën time, ju do të jeni në gjendje ta bëni këtë më shpejt. Mos e konsideroni këtë kohë të humbur, pasi më vonë do ta ndjeni të gjithë përfitimin e punës së bërë.
Më pas, duhet të përcaktoni se çfarë prisni nga Ansible Tower, çfarë konkretisht duhet të bëjë ky sistem për ju.
A keni nevojë për të implementuar sistemin në pajisje të zbrazëta, në makinat virtuale të zbrazëta? Apo dëshironi të ruani kushtet e punës dhe konfigurimet ekzistuese të pajisjeve? Ky është një aspekt shumë i rëndësishëm për funksionimin e kompanive publike, prandaj duhet të jeni të sigurt se do të mund të bëni migrimin dhe të implementoni Ansible në konfigurimin ekzistues. Përcaktoni proceset administrative rutinë që dëshironi të automatizoni. Zbuloni nëse ju nevojitet të implementoni aplikacione dhe shërbime specifike në sistemin e ri. Bëni një listë të asaj që dëshironi të bëni dhe vendosni prioritetet.
Pastaj filloni tĂ« shkruani kodin e skenarĂ«ve dhe roleve qĂ« do tĂ« sigurojnĂ« pĂ«rmbushjen e detyrave qĂ« keni planifikuar. Bashkoni ato nĂ« Projects, njĂ« koleksion logjik tĂ« skenarĂ«ve playbooks pĂ«rkatĂ«s. Ădo Projekt do t'i referohet njĂ« repozitori tĂ« veçantĂ« Git ose repozitorit tjetĂ«r, nĂ« varĂ«si tĂ« menaxherit tĂ« kodit qĂ« po pĂ«rdorni. Mund tĂ« menaxhoni skenarĂ«t playbook dhe katalogĂ«t e playbook duke i vendosur manualisht nĂ« Project Base Path nĂ« serverin Tower, ose duke vendosur playbook nĂ« çdo sistem menaxhimi tĂ« kodit burimor (SCM) qĂ« mbĂ«shtetet nga Tower, duke pĂ«rfshirĂ« Git, Subversion, Mercurial dhe Red Hat Insights. Brenda njĂ« Projekti, mund tĂ« vendosni aq skenarĂ« sa dĂ«shironi. PĂ«r shembull, kam krijuar njĂ« Projekt bazĂ«, ku kam vendosur njĂ« skenar pĂ«r elementĂ«t bazĂ« tĂ« RedHat, njĂ« skenar pĂ«r bazat e Linux-it, skenarĂ«t pĂ«r metrikat e tjera bazĂ«. KĂ«shtu, nĂ« njĂ« projekt kishte role dhe skenarĂ« tĂ« ndryshĂ«m qĂ« administroheshin nga njĂ« repozitor git.
Ekzekutoni të gjitha këto gjëra përmes komandës së linjës, është një mënyrë e mirë për të verifikuar funksionalitetin e tyre. Kështu do të përgatiteni për instalimin e Tower-it.
Le të flasim pak për transkodimin e manifestit Puppet, sepse kam harxhuar shumë kohë për këtë derisa kuptova se çfarë duhej të bëja në fakt.
Si kam thashë, Puppet ruan të gjitha konfigurimet dhe parametrat e pajisjeve në një manifest të gjatë, dhe në këtë manifest ruhet gjithçka që duhet të bëjë kjo SCM. Kur kaloni, nuk keni nevojë të ngarkoni të gjitha detyrat tuaja në një listë, por duhet të mendoni për strukturën e sistemit të ri: role, skenarë, etiketa, grupe dhe çfarë duhet të përfshijë aty. Disa elemente autonome të rrjetit duhet të grupohen në grupe, për të cilat mund të krijoni skenarë. Elementët më kompleksë të infrastrukturës, të cilët përdorin një sasi të madhe burimesh, përfshirë klasat autonome, mund të bashkohen në role. Para migrimit, duhet ta përcaktoni këtë. Nëse jeni duke krijuar role ose skenarë të mëdhenj që nuk përputhen në një ekran, duhet të përdorni etiketa për të qenë në gjendje të kapni pjesë të veçanta të infrastrukturës.
18:00
Pak reklamĂ« đ
Faleminderit që po qëndroni me ne. Ju pëlqen artikujt tanë? Doni të shihni më shumë materiale interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar tek miqtë tuaj, , një analog unik i serverëve entry-level që e kemi shpikur për Ju: (opcionet me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4 janë të disponueshme).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendĂ«r tĂ« tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m te ne nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
