La National Environmental Satellite Data Information Service (NESDIS) reduktis siajn agordajn administradkostojn por Red Hat Enterprise Linux (RHEL) je 35% per migrado de Puppet Enterprise al Ansible Tower. En ĉi tiu video "kiel ni faris ĝin", sistem-inĝeniero Michael Rau klarigas la kazon por ĉi tiu migrado, dividante utilajn konsiletojn kaj lecionojn lernitajn de moviĝado de unu SCM al alia.
De ĉi tiu video vi lernos:
- kiel pravigi al administrado la fareblecon ŝanĝi de Puppet Enterprise al Ansible Tower;
- kiajn strategiojn uzi por fari la transiron kiel eble plej glata;
- konsiletoj por transkodi PE manifestojn en Ansible Playbook;
- Rekomendoj por optimuma instalado de Ansible Tower.
Saluton al ĉiuj, mia nomo estas Michael Rau, mi estas Senior Systems Engineer ĉe ActioNet, kiu laboras por la National Oceanic and Atmospheric Administration (NOAA) NESDIS-servo. Hodiaŭ ni parolos pri kordotondado - mia propra sperto de migrado de Puppet Enterprise al Ansible Tower. La temo de ĉi tiu prezento estas "rigardi miajn cikatrojn" post kiam mi faris ĉi tiun transiron pli frue en la jaro. Mi volas dividi tion, kion mi lernis per ĉi tiu procezo. Do kiam vi prenas ion tian, uzante mian sperton, vi povas fari la transiron sen ia kroma laboro.
Vi vidas lumbildojn similajn al ĉi tio komence de ĉiu prezento ĉe Ansible Fest. Ĉi tiu diapozitivo skizas la historion de la aŭtomatigo de mia kompanio. Mi ne estas nova pri tio, ĉar mi uzas Puppet/Puppet Enterprise ekde 2007. Mi komencis labori kun Ansible en 2016, kaj kiel multaj aliaj uzantoj de ĉi tiu produkto, min allogis la ebleco de "trukoj" uzante la komandlinion kaj simplajn skriptojn (ludlibroj). Fine de 2017, mi kontaktis mian administradon pri la fortaj kialoj por translokiĝi al Ansible Tower. Post minuto mi rakontos al vi pri la kialoj, kiuj instigis min fari ĉi tiun paŝon. Post ricevi la konsenton de la administrado, daŭris plurajn monatojn por kompletigi la planon, kaj mi faris la transiron en januaro-februaro de ĉi tiu jaro. Do, ni tute forlasis Puppeton favore al Ansible, kaj ĝi estas bonega afero.
Kio plej plaĉas al mi pri Ansible estas la kapablo skribi kaj uzi rolojn kaj ludlibrojn. Roloj estas bonegaj por krei apartajn sed rilatajn taskojn kaj meti ĉiujn datumojn rilatajn al tiuj taskoj en unu loko. Ludlibro estas YAML-sintakso, skriptodosiero, kiu priskribas agojn por unu aŭ pluraj gastigantoj. Mi rakontas uzantojn pri ĉi tiuj funkcioj, ĉefe programistoj. Ansible Tower donas al vi la kapablon diri, "ne, vi ne havas ŝelan aliron, sed mi donas al vi la kapablon ruli ĉiujn Tower-procezojn kaj rekomenci la servon kiam vi bezonas ĝin." Mi rakontos al vi pri la labormedio kaj la ekipaĵo, kiun ni uzas.
Ĉi tio estas federacia LAN, 7 fizikaj retejoj konektitaj per nuba MPLS, 140 RHEL-serviloj, 99% el kiuj estas virtualaj (vSphere), SuperMicro-aparataro, NexentaStore retstokado, aro de Cisco, Arista kaj Cumulus-ŝaltiloj kaj Fortinet UTM unuigita minaco-administrado. iloj en ĉiu retejo.
La federacia reto signifas, ke mi devas uzi ĉiujn informsekurecajn rimedojn provizitajn de la leĝo. Vi devas memori, ke Puppet Enterprise ne subtenas plejparton de la aparataro, kiun ni uzas. Ni estas devigitaj uzi buĝetajn aparataron ĉar registaraj agentejoj havas problemojn financi ĉi tiun elspezaĵon. Tial ni aĉetas SuperMicro-aparaton kaj muntas nian ekipaĵon el individuaj partoj, kies bontenado estas garantiita de registaraj kontraktoj. Ni uzas Linukson kaj ĉi tio estas unu el la gravaj kialoj por ŝanĝi al Ansible.
Nia historio kun Puppet estas jena.
En 2007, ni havis malgrandan reton de 20-25 nodoj, en kiuj ni deplojis Puppet. Esence, ĉi tiuj nodoj estis nur RedHat "skatoloj". En 2010, ni komencis uzi la interfacon de Puppet Dashboard por 45 nodoj. Dum la reto daŭre vastiĝis, ni moviĝis al PE 2014 en 3.3, farante kompletan transiron kun manifesta reverko por 75 nodoj. Ĉi tio devis esti farita ĉar Puppet ŝatas ŝanĝi la regulojn de la ludo, kaj ĉi-kaze ili tute ŝanĝis la lingvon. Jaron poste, kiam finiĝis subteno por versio 3 de Puppet Enterprise, ni estis devigitaj migri al PE 2015.2. Ni devis reverki la manifeston denove por la novaj serviloj kaj aĉeti permesilon kun rezervo de 100 nodoj, kvankam en tiu tempo ni havis nur 85 nodojn.
Nur 2 jaroj pasis, kaj ni denove devis multe labori por migri al la nova versio PE 2016.4. Ni aĉetis permesilon por 300 nodoj, havante nur 130. Ni denove devis fari gravajn ŝanĝojn al la manifesto ĉar la nova versio de la lingvo havis alian sintakson ol la lingvo de la 2015-a versio. Kiel rezulto, nia SCM ŝanĝis de SVN-versia kontrolo al Bitbucket (Git). Ĉi tio estis nia "rilato" kun Puppet.
Do, mi devis klarigi al administrado kial ni devis translokiĝi al malsama SCM uzante la jenajn argumentojn. La unua estas la alta prezo de la servo. Mi parolis kun la uloj ĉe RedHat kaj ili diris, ke la kosto de funkciigado de 300 noda reto kun Ansible Tower estas duono de la kosto de Puppet Enterprise. Se vi ankaŭ aĉetos Ansible Engine, la kosto estos proksimume la sama, sed vi ricevos multe pli da funkcioj ol PE. Ĉar ni estas ŝtata kompanio financita el la federacia buĝeto, ĉi tio estas sufiĉe potenca argumento.
La dua argumento estas ĉiuflankeco. Puppet nur subtenas aparataron kiu havas Puppet-agenton. Ĉi tio signifas, ke agento devas esti instalita sur ĉiuj ŝaltiloj, kaj ĝi devas esti la plej nova versio. Kaj se iuj el viaj ŝaltiloj subtenas unu version, kaj iuj subtenas alian, vi devos instali novan version de la PE-agento sur ili, por ke ili ĉiuj povu funkcii en la sama SCM-sistemo.
La sistemo de Ansible Tower funkcias malsame ĉar ĝi ne havas agentojn, sed ĝi havas modulojn kiuj subtenas Cisco-ŝaltilojn kaj ĉiujn aliajn ŝaltilojn. Ĉi tiu SCM subtenas Qubes OS, Linukso kaj 4.NET UTM. Ansible Tower ankaŭ subtenas NexentaStore-retajn stokadregilojn bazitajn sur la Illumos-kerno, malfermfonte Unikso-bazita operaciumo. Ĉi tio estas tre malmulte da subteno, sed Ansible Tower faras ĝin ĉiukaze.
La tria argumento, kiu estas tre grava kaj por mi kaj por nia administrado, estas facileco de uzado. Mi pasigis 10 jarojn regante Puppet-modulojn kaj manifestkodon, sed mi lernis Ansible ene de semajno ĉar ĉi tiu SCM estas multe pli facile labori kun. Se vi rulas ruleblajn dosierojn, kompreneble, krom se vi faras tion senbezone, tiam inteligentaj kaj respondemaj prizorgantoj laboras kun ili. YAML-bazitaj ludlibroj estas facile lerneblaj kaj rapide uzeblaj. Tiuj, kiuj neniam antaŭe aŭdis pri YAML, povas simple legi la skriptojn kaj facile kompreni kiel ĝi funkcias.
Por esti honesta, Puppet faras vian laboron kiel programisto multe pli malfacila ĉar ĝi baziĝas sur uzado de Puppet Master. Ĝi estas la nura maŝino permesita komuniki kun Puppet-agentoj. Se vi faris ajnajn ŝanĝojn al la manifesto kaj volas testi vian kodon, vi devas reverki la kodon por Puppet Master, tio estas, agordi la Puppet Master /etc/hosts-dosieron por konekti ĉiujn klientojn kaj komenci la servon Puppet Server. Nur post tio vi povos testi la funkciadon de retaj ekipaĵoj sur unu gastiganto. Ĉi tio estas sufiĉe dolora proceduro.
Ĉio estas multe pli simpla en Ansible. Ĉio, kion vi bezonas fari, estas evoluigi kodon por maŝino, kiu povas komuniki per SSH kun la gastiganto sub testo. Ĉi tio estas multe pli facile labori kun.
La sekva granda avantaĝo de Ansible Tower estas la kapablo utiligi vian ekzistantan subtenan sistemon kaj konservi vian ekzistantan aparataron. Ĉi tiu SCM uzas ĉiujn disponeblajn informojn pri via infrastrukturo kaj aparataro, virtualaj maŝinoj, serviloj ktp sen pliaj paŝoj. Ĝi povas paroli kun viaj RH Satellite-serviloj, se vi havas tian, kaj donas al vi integraĵojn, kiujn vi neniam ricevos kun Puppet.
Alia grava afero estas detala kontrolo. Vi scias, ke Puppet estas modula sistemo, ĝi estas kliento-servila aplikaĵo, do vi devas difini la ekzistantajn aspektojn de ĉiuj viaj maŝinoj en unu longa manifesto. En ĉi tiu kazo, la stato de ĉiu individua elemento de la sistemo devas esti provita ĉiun duonhoron - ĉi tiu estas la defaŭlta periodo. Tiel funkcias Puppet.
Turo savas vin de tio. Vi povas ruli diversajn procezojn sur diversaj ekipaĵoj sen limigoj; vi povas fari bazan laboron, funkciigi aliajn gravajn procezojn, agordi sekurecan sistemon kaj labori kun datumbazoj. Vi povas fari ĉion, kio estas malfacila en Puppet Enterprise. Do, se vi agordis ĝin sur unu gastiganto, necesos tempo por ke la ŝanĝoj efektiviĝu sur la ceteraj gastigantoj. En Ansible ĉiuj ŝanĝoj efektiviĝas samtempe.
Fine, ni rigardu la sekurecan modulon. Ansible Tower efektivigas ĝin simple mirinde, kun granda precizeco kaj zorgo. Vi povas doni al uzantoj aliron al specifaj servoj aŭ al specifaj gastigantoj. Mi faras tion kun miaj dungitoj, kiuj kutimas labori en Vindozo, limigante sian aliron al la Linukso-ŝelo. Mi certigas, ke ili havas aliron al Turo, por ke ili nur povu fari la laboron kaj funkcii nur la servojn, kiuj rilatas al ili.
Ni rigardu la aferojn, kiujn vi devas fari antaŭtempe por faciligi vian transiron al Ansible Tower. Antaŭ ĉio, vi devas prepari vian ekipaĵon. Se iuj elementoj de via infrastrukturo ne estas jam en la datumbazo, vi devas aldoni ilin tie. Estas sistemoj, kiuj ne ŝanĝas siajn karakterizaĵojn kaj tial ne estas en la Puppet-datumbazo, sed se vi ne aldonas ilin tie antaŭ ol translokiĝi al Turo, vi perdos kelkajn avantaĝojn. Ĉi tio povas esti "malpura", prepara datumbazo, sed ĝi devus enhavi informojn pri ĉiuj ekipaĵoj, kiujn vi havas. Sekve, vi devus skribi dinamikan aparatan skripton, kiu aŭtomate puŝos ĉiujn infrastrukturajn ŝanĝojn en la datumbazon, tiam Ansible scios, kiuj gastigantoj devas ĉeesti en la nova sistemo. Vi ne bezonos diri al ĉi tiu SCM kiujn gastigantojn vi aldonis kaj kiuj gastigantoj ne plu ekzistas, ĉar ĝi scios ĉion ĉi aŭtomate. Ju pli da datumoj estas en la datumbazo, des pli utila kaj fleksebla estos Ansible. Ĝi funkcias kvazaŭ ĝi simple legas la aparatan statusan strekkodon el datumbazo.
Pasigu iom da tempo por konatiĝi kun la komandlinio en Ansible. Rulu kelkajn kutimajn komandojn por testi la aparatan skripton, verki kaj ruli kelkajn simplajn sed utilajn ludlibrojn, uzu Jinja2-ŝablonojn kie konvene. Provu skribi rolon kaj skripton por kompleksa, plurpaŝa procezo uzante oftan, ofte renkontitan aparatan agordon. Ludu kun ĉi tiuj aferoj, provu kiel ĝi funkcias. Tiel vi lernos kiel uzi la bibliotekkreajn ilojn uzatajn en Turo. Mi jam diris, ke mi bezonis ĉirkaŭ 3 monatojn por prepari por la transiro. Mi pensas, ke laŭ mia sperto, vi povos fari tion pli rapide. Ne konsideru ĉi tiun tempon malŝparita, ĉar poste vi spertos ĉiujn profitojn de la farita laboro.
Poste, vi devas decidi, kion vi atendas de Ansible Tower, kion ĝuste ĉi tiu sistemo devus fari por vi.
Ĉu vi bezonas deploji la sistemon sur nuda aparataro, sur nudaj virtualaj maŝinoj? Aŭ ĉu vi volas konservi la originalajn funkciajn kondiĉojn kaj agordojn de ekzistantaj ekipaĵoj? Ĉi tio estas tre grava aspekto por publikaj kompanioj, do vi devas esti certa, ke vi povos migri kaj deploji Ansible sur via ekzistanta agordo. Identigu rutinajn administrajn procezojn, kiujn vi volas aŭtomatigi. Eltrovu ĉu vi bezonas disfaldi specifajn aplikojn kaj servojn sur la nova sistemo. Faru liston de tio, kion vi volas fari kaj prioritatu ĝin.
Poste komencu skribi skriptokodon kaj rolojn, kiuj ebligos la taskojn, kiujn vi planas plenumi. Kombinu ilin en Projektojn, logikan kolekton de koncernaj ludlibroj. Ĉiu Projekto apartenos al aparta Git-deponejo aŭ malsama deponejo depende de kiu kodmanaĝero vi uzas. Vi povas administri ludlibrojn kaj ludlibro-dosierujojn permane metante ilin en la Projektan Bazan Vojon sur la Tower-servilon, aŭ metante la ludlibron en ajna fontkoda administrado (SCM) sistemo subtenata de Tower, inkluzive de Git, Subversion, Mercurial kaj Red Hat. Enrigardoj. Ene de unu Projekto vi povas meti tiom da skriptoj kiom vi volas. Ekzemple, mi kreis unu bazan Projekton en kiu mi metis skripton por la RedHat-kernelementoj, skripton por la Linukso-kerno, kaj skriptojn por la resto de la bazlinioj. Tiel, en unu projekto estis diversaj roloj kaj scenaroj, kiuj estis administritaj de unu Git-deponejo.
Kuri ĉiujn ĉi tiujn aferojn tra la komandlinio estas bona maniero testi ilian funkciecon. Ĉi tio preparos vin por la instalado de Turo.
Ni parolu iomete pri transkodado de la Puppet-manifesto, ĉar mi pasigis multan tempon pri tio, ĝis mi eltrovis, kion efektive necesas fari.
Kiel mi diris antaŭe, Puppet konservas ĉiujn agordojn kaj aparataron en unu longa manifesto, kaj ĉi tiu manifesto konservas ĉion, kion ĉi tiu SCM devus fari. Kiam vi faras la transiron, vi ne bezonas kunigi ĉiujn viajn taskojn en unu liston; anstataŭe, pensu pri la strukturo de la nova sistemo: roloj, skriptoj, etikedoj, grupoj kaj kio devus esti tie. Kelkaj el la aŭtonomaj retaj elementoj devus esti grupigitaj en grupojn por kiuj skriptoj povas esti kreitaj. Pli kompleksaj infrastrukturelementoj kiuj implikas grandan nombron da resursoj, inkluzive de memstaraj klasoj, povas esti kombinitaj en rolojn. Antaŭ ol migri, vi devas decidi pri tio. Se vi kreas grandajn rolojn aŭ scenarojn, kiuj ne taŭgas sur unu ekrano, vi devus uzi etikedojn por povi kapti specifajn partojn de la infrastrukturo.
18:00
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com