Shërbimi Kombëtar i Informacionit për Të Dhënat Satelitore mbi Mjedisin (NESDIS) ka përgjysmuar kostot e menaxhimit të konfiguracionit të Red Hat Enterprise Linux (RHEL) me 35% duke kaluar nga Puppet Enterprise në Ansible Tower. Në këtë video të kategorisë "si e bëmë", inxhinieri sistemor Michael Rau justifikon këtë migrim, duke ndarë 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 drejtuesve racionalitetin e kalimit nga Puppet Enterprise në Ansible Tower;
- cilat strategji të përdorni për një kalim sa më të qetë;
- këshilla për transkodimin e manifestove PE në Ansible Playbook;
- rekomandime për një instalim optimal të Ansible Tower.
TĂ« pĂ«rshĂ«ndes tĂ« gjithĂ«ve, emri im Ă«shtĂ« Michael Rau, inxhinier senior i sistemeve nĂ« ActioNet, e cila punon pĂ«r AdministratĂ«n KombĂ«tare tĂ« Oqeanit dhe AtmosferĂ«s (NOAA) shĂ«rbimin NESDIS. Sot do tĂ« flasim pĂ«r prerjen e simboleve â pĂ«rvojĂ«n time personale tĂ« migrimit nga Puppet Enterprise nĂ« Ansible Tower. Tema e kĂ«saj prezantimi Ă«shtĂ« "tĂ« shohĂ«sh gjurmĂ«t e mia", pas kĂ«tij kalimi nĂ« fillim tĂ« vitit. Dua tĂ« ndaj atĂ« qĂ« kam mĂ«suar gjatĂ« kĂ«saj procedure. KĂ«shtu, kur ju tĂ« angazhoheni nĂ« njĂ« ngjashĂ«m, duke pĂ«rdorur pĂ«rvojĂ«n time, do tĂ« mund ta bĂ«ni kalimin mĂ« lehtĂ«.
Ju shihni slajde të ngjashme me këtë në fillim të çdo prezantimi në Ansible Fest. Në këtë slajd është përshkruar historia e automatizimit të kompanisë sime. Nuk jam fillestar në këtë fushë, sepse kam përdorur Puppet/Puppet Enterprise që nga viti 2007. Kam filluar të punoj me Ansible që nga viti 2016, dhe si shumë përdorues të tjerë të këtij produkti, më ka tërhequr mundësia e "trukave" përmes komandave të linjës dhe skenarëve të thjeshtë (playbooks). Në fund të vitit 2017, kam biseduar me drejtorët e mi mbi arsyet e forta për kalimin në Ansible Tower. Pas disa minutash do t'ju flas për arsyet që më ndihmuan në këtë hap. Pasi mora miratimin e drejtorëve, u deshën disa muaj të tjerë për të realizuar atë që kishim menduar, dhe unë e realizova kalimin në janar-shkurt të këtij viti. Kështu, ne u ndamë plotësisht nga Puppet në favor të Ansible, dhe kjo është një gjë e madhe.
Më së shumti, ajo që më tërheq në Ansible është mundësia për të shkruar dhe përdorur rolle (roles) dhe skenario (playbooks). Rrole janë të shkëlqyera për krijimin e detyrave të ndryshme, por të ndërthurura (tasks) dhe për të vendosur të dhënat përkatëse në një vend. Playbook është një sintaksë YAML, një skenar që përshkruan veprimet për një ose disa hosta. Unë i tregoj këto mundësi përdoruesve, sidomos zhvilluesve të softuerit. Ansible Tower ofron mundësinë të thuash: "jo, nuk keni akses në shell, por unë ju ofroj mundësinë të aktivizoni të gjitha proceset e Tower dhe të rinisni shërbimin kur të jetë e nevojshme". Unë do t'ju flas për ambientin tonë të punës dhe pajisjet që përdorim.
Kjo është një LAN federale, 7 vende fizike të lidhura përmes MPLS në re, 140 servera RHEL, 99% prej të cilëve janë virtualë (vSphere), pajisje të SuperMicro, ruajtje rrjetesh NexentaStore, një grup switch-esh Cisco, Arista dhe Cumulus dhe mjete të menaxhimit të rrezikut të unifikuar Fortinet UTM në çdo vend.
Rrjeta federale nënkupton se duhet të përdor të gjitha mjetet e sigurisë së informacionit që parashikohen nga ligjet. Duhet të mbani mend se Puppet Enterprise nuk mbështet shumicën e pajisjeve që kemi. Jemi të detyruar të përdorim pajisje të buxhetit, pasi institucionet shtetërore kanë probleme me financimin e kësaj kategorie shpenzimesh. Prandaj blejmë "harduer" klase SuperMicro dhe e përbëjmë pajisjen tonë nga pjesë të veçanta, mirëmbajtja e të cilave sigurohet nga kontratat qeveritare. Ne përdorim Linux, dhe kjo është një nga arsyet kryesore për kalimin në Ansible.
Historia jonë e punës me Puppet është si më poshtë.
Në 2007, kishim një rrjet të vogël prej 20-25 nyjesh, ku e implementuam Puppet. Kryesisht këto nyje ishin thjesht "kuti" RedHat. Në 2010, filluam të përdorim ndërfaqen grafike të Puppet Dashboard për 45 nyje. Ndërsa rrjeti vazhdonte të zgjerohej, në 2014 kaluam në PE 3.3, duke realizuar kalimin e plotë me rishkrimin e manifestit për 75 nyje. Kjo ishte e nevojshme, sepse Puppet pëlqen të ndryshojë rregullat e lojës, dhe në këtë rast e kanë ndryshuar krejtësisht gjuhën. Një vit më vonë, kur mbështetja për versionin 3 të Puppet Enterprise u ndal, na duhej të migronim në PE 2015.2. Sërish, u detyruam të rishkruajmë manifestin për serverat e rinj dhe të blinim një licencë me rezervë për 100 nyje, ndonëse në atë kohë kishim vetëm 85 nyje.
Ka kaluan vetëm 2 vjet, dhe përsëri na duhej të bënim një punë të madhe për t'u kaluar në versionin e ri PE 2016.4. Ne blehëm një licencë për 300 node, duke pasur vetëm 130. Na u deshën përsëri të bënim ndryshime të rëndësishme në manifest, sepse versioni i ri i gjuhës kishte një sintaksë që ndryshonte nga versioni i vitit 2015. Si rezultat, SCM-ja jonë kaloi nga sistemi i kontrollit të versioneve SVN në Bitbucket (Git). Këto ishin "raportet" tona me Puppet.
Pra, më duhej të shpjegoja menaxhmentit pse na duhej të kalonim në një SCM tjetër duke përdorur argumentet e mëposhtme. E para - çmimi i lartë i shërbimit. Bisedova me djemtë nga RedHat dhe ata thanë se kostoja e mbajtjes së një rrjeti me 300 node me Ansible Tower është gjysma e kostos së Puppet Enterprise. Nëse blenitet edhe Ansible Engine, kostoja do të jetë përafërsisht e njëjtë, por do të merrni shumë më tepër funksionalitete se me PE. Duke qenë se jemi një kompani shtetërore që financohet nga buxheti federal, ky është një argument mjaft i rëndësishëm.
Argumenti i dytë është universialiteti. Puppet mbështet vetëm pajisjet ku ka agent Puppet. Kjo do të thotë se në të gjithë switch-at duhet të instaloni agjent dhe ai duhet të jetë versioni më i fundit. Dhe nëse disa nga switch-at tuaj mbështesin një version, ndërsa disa të tjerë një tjetër, do t'ju duhet të instaloni versionin e ri të agjentit PE për të siguruar që të gjithë ata të mund të punojnë në një sistem SCM.
Sistemi Ansible Tower funksionon ndryshe, sepse nuk ka asnjë agent, por ka module që mbështesin switch-at Cisco dhe të gjithë switch-at e tjerë. Kjo SCM mbështet Qubes OS, Linux dhe 4.NET UTM. Ansible Tower gjithashtu mbështet kontrolluesit e magazinave rrjetore NexentaStore, të bazuar në bërthamën Illumos - një sistem operativ open-source të bazuar në Unix. Kjo është një mbështetje shumë e vogël, por Ansible Tower akoma e ofron atë.
Argumenti i tretë, shumë i rëndësishëm si për mua ashtu edhe për administratën tonë, është thjeshtësia e mësimit. Unë kalova 10 vjet duke mësuar modulet dhe kodin e manifestëve Puppet, por studiuar Ansible në një javë, sepse është shumë më e lehtë të punohet me këtë SCM. Nëse ekzekutoni skedarë ekzekutivë, sigurisht, nëse nuk e bëni këtë pa nevojë, atëherë me ta punojnë menaxherë të arsyeshëm dhe reagues. Skriptet playbooks, të bazuara në YAML, karakterizohen nga mësimi i lehtë dhe shpejtësia e përdorimit. Ata që nuk kanë dëgjuar ndonjëherë për YAML mund thjesht të lexojnë skriptet dhe të kuptojnë lehtësisht 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 keni bërë ndonjë ndryshim në manifest dhe dëshironi të testoni kodin tuaj, ju duhet të rishkruani kodin për Puppet Master, që do të thotë të konfiguroni skedarin Puppet-master /etc/hosts për të lidhur të gjithë klientët dhe të nisni shërbimin Puppet Server. Vetëm pas kësaj do të mund të provoni punën e pajisjeve të rrjetit në një host. Kjo është një procedurë mjaft e dhimbshme.
Në Ansible, gjithçka është shumë më e thjeshtë. Ajo që duhet të bëni është të zhvilloni kod për makinën që ka mundësinë të komunikojë përmes protokollit SSH me hostin që po testoni. Kjo është shumë më e lehtë për t'u bërë.
Avantazhi tjetër i madh i Ansible Tower është mundësia për të angazhuar sistemin tuaj të mbështetjes që keni në dispozicion dhe për të ruajtur konfigurimin ekzistues të pajisjeve. Kjo SCM, pa ndonjë veprim të mëtejshëm, përdor të gjitha informacionet që keni në infrastrukturën dhe pajisjet tuaja, makinat virtuale, serverat, etj. Ajo mund të komunikojë me serverat tuaj RH Satellite, nëse i keni, dhe ju ofron një integrim që nuk do ta merrni kurrë duke punuar me Puppet.
Një gjë tjetër e rëndësishme është kontrolli i detajuar. Ju e dini se Puppet është një sistem modular, është një aplikacion klient-server, kështu që duhet të përcaktoni aspektet ekzistuese të funksionimit të gjithë makinerive tuaja në një manifest të gjatë. Gjendja e çdo elementi të veçantë të sistemit duhet të testohet çdo gjysmë ore - ky është periudha e paracaktuar. Kështu punon Puppet.
Tower ju çliron nga kjo. Mund të realizoni pa kufizime procese të ndryshme në pajisje të ndryshme, mund të bëni punën kryesore, të nisni procese të tjera të rëndësishme, të konfiguroni sigurinë, të punoni me bazat e të dhënave. 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ë hyjnë në fuqi në hostet e tjerë. Në Ansible, të gjitha ndryshimet hyjnë në fuqi në të njëjtën kohë.
Së fundi, le të shqyrtojmë modulën e sigurisë. Në Ansible Tower, ajo është implementuar thjesht mahnitshëm, me një saktësi dhe kujdes të madh. Ju mund të jepni përdoruesve akses në shërbime specifike ose në hosta të veçantë. Unë veproj kështu me punonjësit e mi që janë mësuar të punojnë në Windows, duke iu kufizuar aksesin në shellin e Linux. Unë ofroj akses për ta në Tower, që ata të mund të kryejnë vetëm atë punë dhe të nisin vetëm ato shërbime që i përkasin kompetencave të tyre.
Le të shikojmë disa gjëra që duhet bërë më parë për të lehtësuar kalimin në Ansible Tower. E para, duhet të përgatisni pajisjet tuaja. Nëse ndonjë element i infrastrukturës suaj nuk është akoma në bazën e të dhënave, duhet ta shtoni atë. Ka sisteme që nuk ndryshojnë karakteristikat e tyre dhe për pasojë mungojnë në DB-në e Puppet, por nëse nuk i regjistroni ato para kalimit në Tower, do të humbni disa përfitime. Mund të jetë një DB e 'papastërt' paraprak, por ajo duhet të përmbajë informacione për gjithë pajisjet që keni. Prandaj, duhet të shkruani një skript dinamik të pajisjeve, i cili automatikisht do të regjistrojë të gjitha ndryshimet e infrastrukturës në bazën e të dhënave, atëherë Ansible do të dijë se cilët hosta duhet të jenë në sistemin e ri. Nuk do t'ju nevojitet të informoni këtë SCM për cilët hosta keni shtuar dhe cilët hosta nuk ekzistojnë më, sepse gjithçka kjo do ta mësojë automatikisht. Sa më shumë të dhëna të ketë në DB, aq më të dobishëm dhe fleksibël do të jetë Ansible. Ai funksionon sikur thjesht të lexojë nga baza e të dhënave një kod-bar të gjendjes së pajisjeve.
Shpenzoni ca kohë për të njohur funksionimin e komandës së linjës në Ansible. Ekzekutoni disa komanda të veçanta për të verifikuar funksionimin e skriptit të pajisjeve, shkruani dhe lançoni disa skenare të thjeshta, por të dobishme për playbook, përdorni shabllonet Jinja2 kur është e përshtatshme. Provoni të shkruani një rol dhe një skenar për një proces të ndërlikuar shumëfazësh, duke përdorur një konfigurim standard, që herë pas here ndodh. Luajini me këto gjëra, testoni se si funksionojnë. Kështu do të mësoni të punoni me mjetet për krijimin e bibliotekave që përdoren në Tower. Unë kam thënë tashmë se përgatitja ime për kalimin mori rreth 3 muaj. Besoj se, duke u mbështetur në përvojën time, do të jeni në gjendje ta bëni këtë më shpejt. Mos e merrni këtë kohë si të humbur, pasi më vonë do të ndjeni të gjitha përfitimet e punës së kryer.
Më pas, duhet tëVendosni se çfarë prisni nga Ansible Tower, çfarë konkretisht duhet të bëjë kjo sistem për ju.
A keni nevojë për një implementim të sistemit në pajisje të paprishura, në makinat virtuale të paprishura? Apo dëshironi të ruani kushtet dhe konfigurimet ekzistuese të pajisjeve? Ky është një aspekt shumë i rëndësishëm për kompanitë shtetërore, prandaj duhet të jeni të sigurt se do të jeni në gjendje të realizoni migrimin dhe të implementoni Ansible në konfigurimin ekzistues. Përcaktoni proceset administrativë rutinore që dëshironi të automatizoni. Zgjidhni nëse keni nevojë të implementoni aplikacione dhe shërbime specifike në sistemin e ri. Përgatitni një listë të asaj që dëshironi të bëni dhe caktoni prioritete.
Pastaj filloni tĂ« shkruani kodin e skenarĂ«ve dhe rolit qĂ« do tĂ« sigurojĂ« realizimin e detyrave qĂ« keni planifikuar. Bashkoni ato nĂ« Projects, njĂ« koleksion logjik tĂ« skenarĂ«ve tĂ« lidhur playbooks. Ădo Project do tĂ« lidhet me njĂ« depozitĂ« tĂ« veçantĂ« Git ose njĂ« depozitĂ« tjetĂ«r nĂ« varĂ«si tĂ« menaxherit tĂ« kodit qĂ« po pĂ«rdorni. Mund tĂ« menaxhoni skenarĂ«t playbook dhe katalogĂ«t playbook duke i vendosur manualisht nĂ« Projektin BazĂ« nĂ« serverin Tower, ose duke vendosur playbook nĂ« çdo sistem menaxhimi tĂ« kodit burim (SCM), tĂ« mbĂ«shtetur nga Tower, pĂ«rfshirĂ« Git, Subversion, Mercurial dhe Red Hat Insights. Brenda njĂ« Project-i mund tĂ« vendosni sa mĂ« shumĂ« skenarĂ« qĂ« dĂ«shironi. PĂ«r shembull, unĂ« krijova njĂ« Project bazĂ«, ku vendosa njĂ« skenar pĂ«r elementet bazĂ« tĂ« RedHat, njĂ« skenar pĂ«r bazĂ«n Linux dhe skenarĂ« pĂ«r treguesit e tjerĂ« bazĂ«. KĂ«shtu, nĂ« njĂ« projekt ishin tĂ« pranishme role dhe skenarĂ« tĂ« ndryshĂ«m qĂ« menaxhoheshin nga njĂ« depozitĂ« Git.
Dërgoni të gjitha këto gjëra përmes komandës, kjo është një mënyrë e mirë për të kontrolluar funksionalitetin e tyre. Kështu do të përgatiteni për instalimin e Tower.
Le të flasim pak për transcoding-un e manifestit Puppet, sepse kam kaluar shumë kohë për këtë, derisa kuptova se çfarë duhet të bëj në të vërtetë.
Si e përmenda, Puppet ruan të gjitha konfigurimet dhe parametrat e pajisjeve në një manifesto të gjatë dhe në këtë manifesto është gjithçka që duhet të bëjë kjo SCM. Kur kaloni, nuk duhet të vendosni të gjitha detyrat tuaja në një listë, por të mendoni për strukturën e sistemit të ri: rolet, skenarët, etiketat, grupet dhe se çfarë duhet të përfshihet atje. Disa nga elementët autonomë të rrjetit duhet të bashkohen në grupe, për të cilat mund të krijoni skenarë. Elementet më komplekse të infrastrukturës, të cilat angazhojnë një sasi të madhe burimesh, duke përfshirë klasat autonome, mund të bashkohen në role. Para migrimit, duhet të vendosni këtë. Nëse po krijoni role ose skenarë të mëdhenj që nuk përputhen në një ekran, duhet të përdorni etiketat për të mundësuar kapjen e pjesëve të veçanta të infrastrukturës.
18:00
Pak reklamĂ« đ
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendrĂ«n e tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m kĂ«tu nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
