National Environmental Satellite Data Information Service (NESDIS) on vähendanud Red Hat Enterprise Linuxi (RHEL) konfiguratsioonihalduskulusid 35% võrra, kolides Puppet Enterprise'ilt Ansible Towerile. Selles videos "Kuidas me seda tegime" selgitab süsteemiinsener Michael Rau selle migratsiooni juhtumit, jagades kasulikke näpunäiteid ja õppetunde, mis on saadud ühelt SCM-ilt teisele üleminekul.
Sellest videost saate teada:
- kuidas põhjendada juhtkonnale Nupuettevõttelt Ansible Towerile ülemineku teostatavust;
- milliseid strateegiaid kasutada, et üleminek oleks võimalikult sujuv;
- näpunäiteid PE manifestide ümberkodeerimiseks Ansible Playbookiks;
- Soovitused Ansible Toweri optimaalseks paigaldamiseks.
Tere kõigile, minu nimi on Michael Rau, olen vanemsüsteemiinsener ettevõttes ActioNet, mis töötab riikliku ookeani- ja atmosfääriameti (NOAA) NESDISe teenuses. Täna räägime nööride trimmimisest – minu enda kogemus Puppet Enterprise’ist Ansible Towerisse rännamisel. Selle ettekande teema on „heata pilk minu armidele”, mis jäid pärast selle ülemineku tegemist aasta alguses. Tahan jagada seda, mida selle protsessi käigus õppisin. Nii et kui võtate midagi sellist ette, saate minu kogemust kasutades teha ülemineku ilma lisatööta.
Sellega sarnaseid slaide näete iga Ansible Festi esitluse alguses. See slaid annab ülevaate minu ettevõtte automatiseerimise ajaloost. Ma pole selles osas uus, sest olen kasutanud Puppet/Puppet Enterprise'i alates 2007. aastast. Alustasin Ansiblega koostööd 2016. aastal ja nagu paljusid teisi selle toote kasutajaid, köitis mind käsurea ja lihtsate skriptide (näiteraamatute) abil “nippide” võimalus. 2017. aasta lõpus pöördusin oma juhtkonna poole Ansible Towerisse kolimise tugevate põhjuste osas. Minuti pärast räägin teile põhjustest, mis ajendasid mind seda sammu astuma. Peale juhtkonna nõusoleku saamist kulus plaani täitmiseks veel mitu kuud ning ülemineku tegin selle aasta jaanuaris-veebruaris. Niisiis, me loobusime Puppetist täielikult Ansible'i kasuks ja see on suurepärane asi.
Ansible juures köidab mind kõige enam oskus kirjutada ja kasutada rolle ja mänguraamatuid. Rollid sobivad suurepäraselt erinevate, kuid seotud ülesannete loomiseks ja kõigi nende ülesannetega seotud andmete ühte kohta paigutamiseks. Playbook on YAML-i süntaks, skriptifail, mis kirjeldab ühe või mitme hosti toiminguid. Räägin nendest funktsioonidest kasutajatele, peamiselt tarkvaraarendajatele. Ansible Tower annab teile võimaluse öelda: "Ei, teil pole juurdepääsu shellile, kuid ma annan teile võimaluse käitada kõiki Toweri protsesse ja taaskäivitada teenus, kui seda vajate." Räägin teile töökeskkonnast ja kasutatavatest seadmetest.
See on föderaalne kohtvõrk, 7 pilve MPLS-i kaudu ühendatud füüsilist saiti, 140 RHEL-serverit, millest 99% on virtuaalsed (vSphere), SuperMicro riistvara, NexentaStore'i võrgusalvestusruum, Cisco, Arista ja Cumuluse lülitite komplekt ning Fortinet UTM ühtne ohuhaldus tööriistad igal saidil.
Föderaalvõrk tähendab, et pean kasutama kõiki seaduses sätestatud infoturbe meetmeid. Peaksite meeles pidama, et Puppet Enterprise ei toeta enamikku meie kasutatavast riistvarast. Oleme sunnitud kasutama eelarveriistvara, sest riigiasutustel on probleeme selle kuluartikli rahastamisega. Seetõttu ostame SuperMicro riistvara ja komplekteerime oma seadmed üksikutest osadest, mille hooldus on tagatud riigihankelepingutega. Kasutame Linuxit ja see on üks olulisi põhjusi Ansiblele üleminekuks.
Meie ajalugu Puppetiga on järgmine.
2007. aastal oli meil väike 20–25 sõlmest koosnev võrk, milles kasutasime Puppeti. Põhimõtteliselt olid need sõlmed lihtsalt RedHati "kastid". 2010. aastal hakkasime 45 sõlme jaoks kasutama veebiliidest Puppet Dashboard. Kuna võrk laienes jätkuvalt, läksime 2014. aastal üle PE 3.3-le, tehes täieliku ülemineku manifesti ümberkirjutamisega 75 sõlme jaoks. Seda tuli teha, sest Nukule meeldib mängureegleid muuta ja antud juhul muutsid nad täielikult keelt. Aasta hiljem, kui Puppet Enterprise'i versiooni 3 tugi lõppes, olime sunnitud üle minema PE 2015.2-le. Pidime uute serverite manifesti uuesti ümber kirjutama ja ostma litsentsi 100 sõlme reserviga, kuigi tol ajal oli meil ainult 85 sõlme.
Vaid 2 aastat on möödas ja pidime taas palju tööd tegema, et migreeruda uuele versioonile PE 2016.4. Ostsime litsentsi 300 sõlme jaoks, millel oli ainult 130. Pidime taas manifestis suuri muudatusi tegema, kuna keele uuel versioonil oli 2015. aasta versiooni keele süntaks erinev. Selle tulemusena lülitus meie SCM SVN-i versioonikontrollilt Bitbucketile (Git). See oli meie "suhe" Nukuga.
Seega pidin järgmiste argumentide abil juhtkonnale selgitama, miks me pidime teisele SCM-ile üle minema. Esimene on teenuse kõrge hind. Rääkisin RedHati kuttidega ja nad ütlesid, et 300 sõlmega võrgu haldamine Ansible Toweriga on poole väiksem kui Puppet Enterprise. Kui ostate ka Ansible Engine, on hind umbes sama, kuid saate palju rohkem funktsioone kui PE. Kuna oleme föderaaleelarvest finantseeritav riigiettevõte, on see päris võimas argument.
Teine argument on mitmekülgsus. Puppet toetab ainult riistvara, millel on Puppeti agent. See tähendab, et agent peab olema installitud kõikidesse lülititesse ja see peab olema uusim versioon. Ja kui mõned teie lülitid toetavad ühte versiooni ja mõned teist, peate neile installima PE-agendi uue versiooni, et need kõik saaksid töötada samas SCM-süsteemis.
Ansible Toweri süsteem töötab teisiti, kuna sellel pole agente, kuid sellel on moodulid, mis toetavad Cisco lüliteid ja kõiki teisi lüliteid. See SCM toetab Qubes OS-i, Linuxi ja 4.NET UTM-i. Ansible Tower toetab ka NexentaStore'i võrgusalvestuskontrollereid, mis põhinevad Illumos tuumal, avatud lähtekoodiga Unixi-põhisel operatsioonisüsteemil. See on väga väike toetus, kuid Ansible Tower teeb seda siiski.
Kolmas argument, mis on väga oluline nii minu kui ka meie administratsiooni jaoks, on kasutusmugavus. Ma kulutasin 10 aastat Puppeti moodulite ja manifesti koodi valdamiseks, kuid õppisin Ansible nädalaga selgeks, kuna selle SCM-iga on palju lihtsam töötada. Kui käitate täitmisfaile, muidugi, kui te seda asjatult ei tee, töötavad nendega intelligentsed ja reageerivad töötlejad. YAML-põhiseid mänguraamatuid on lihtne õppida ja neid on kiire kasutada. Need, kes pole YAMList varem kuulnud, saavad lihtsalt skripte lugeda ja saavad hõlpsasti aru, kuidas see töötab.
Kui aus olla, siis Puppet teeb teie töö arendajana palju keerulisemaks, kuna põhineb Puppet Masteri kasutamisel. See on ainus masin, millel on lubatud Nukuagentidega suhelda. Kui olete manifestis muudatusi teinud ja soovite koodi testida, peate Puppet Masteri koodi ümber kirjutama, st konfigureerima faili Puppet Master /etc/hosts, et ühendada kõik kliendid ja käivitada Puppet Server teenus. Alles pärast seda saate testida võrguseadmete tööd ühes hostis. See on üsna valus protseduur.
Ansibles on kõik palju lihtsam. Kõik, mida pead tegema, on välja töötada kood masinale, mis suudab testitava hostiga SSH kaudu suhelda. Sellega on palju lihtsam töötada.
Ansible Toweri järgmine suur eelis on võime kasutada olemasolevat tugisüsteemi ja säilitada olemasolevat riistvarakonfiguratsiooni. See SCM kasutab ilma täiendavate sammudeta kogu saadaolevat teavet teie infrastruktuuri ja riistvara, virtuaalmasinate, serverite jms kohta. See suudab suhelda teie RH Satellite serveritega, kui teil see on, ja annab teile integratsioonid, mida te Puppetiga kunagi ei saa.
Teine oluline asi on üksikasjalik kontroll. Teate, et Puppet on modulaarne süsteem, see on klient-serveri rakendus, seega peate määratlema kõigi oma masinate olemasolevad aspektid ühes pikas manifestis. Sel juhul tuleb iga poole tunni järel testida süsteemi iga üksiku elemendi olekut – see on vaikeperiood. Nii töötab Puppet.
Torn päästab teid sellest. Saate piiranguteta käivitada mitmesuguseid protsesse mitmesugustel seadmetel; saate teha põhitöid, käivitada muid olulisi protsesse, seadistada turvasüsteemi ja töötada andmebaasidega. Puppet Enterprise'is saate teha kõike, mis on keeruline. Seega, kui konfigureerisite selle ühes hostis, kulub aega, enne kui muudatused ülejäänud masinates jõustuvad. Ansibles jõustuvad kõik muudatused samal ajal.
Lõpuks vaatame turvamoodulit. Ansible Tower rakendab seda lihtsalt hämmastavalt, suure täpsuse ja hoolega. Saate anda kasutajatele juurdepääsu konkreetsetele teenustele või konkreetsetele hostidele. Ma teen seda oma töötajatega, kes on harjunud töötama Windowsiga, piirates nende juurdepääsu Linuxi kestale. Ma tagan neile juurdepääsu Towerile, et nad saaksid teha ainult tööd ja osutada ainult neile olulisi teenuseid.
Vaatame asju, mida peate enne tähtaega tegema, et muuta Ansible Towerile üleminek lihtsamaks. Kõigepealt peate oma seadmed ette valmistama. Kui mõnda teie infrastruktuuri elementi pole veel andmebaasis, peate need sinna lisama. On süsteeme, mis ei muuda oma omadusi ja pole seetõttu Puppeti andmebaasis, kuid kui te neid enne Towerisse kolimist sinna ei lisa, kaotate hulga eeliseid. See võib olla "määrdunud", esialgne andmebaas, kuid see peaks sisaldama teavet kogu teie varustuse kohta. Seetõttu peaksite kirjutama dünaamilise riistvaraskripti, mis lükkab kõik infrastruktuuri muudatused automaatselt andmebaasi, siis saab Ansible teada, millised hostid peaksid uues süsteemis olema. Te ei pea SCM-ile ütlema, millised hostid lisasite ja milliseid hoste enam ei eksisteeri, sest see saab sellest kõik automaatselt teada. Mida rohkem andmeid andmebaasis on, seda kasulikum ja paindlikum on Ansible. See töötab nii, nagu loeks see lihtsalt andmebaasist riistvara oleku vöötkoodi.
Veetke aega Ansible'i käsureaga tutvumiseks. Käivitage riistvara skripti testimiseks kohandatud käske, kirjutage ja käivitage lihtsaid, kuid kasulikke mänguraamatu skripte, vajadusel kasutage Jinja2 malle. Proovige kirjutada keerulise, mitmeastmelise protsessi jaoks roll ja skript, kasutades tavalist, sageli esinevat riistvarakonfiguratsiooni. Mängige nende asjadega, katsetage, kuidas see töötab. Nii saate teada, kuidas kasutada Toweris kasutatavaid raamatukogu loomise tööriistu. Olen juba öelnud, et üleminekuks valmistumine võttis mul umbes 3 kuud. Arvan, et minu kogemuse põhjal saate sellega kiiremini hakkama. Ärge pidage seda aega raisatuks, sest hiljem kogete tehtud töö kõiki eeliseid.
Järgmiseks peate otsustama, mida te Ansible Towerilt ootate, mida see süsteem teie heaks tegema peaks.
Kas peate süsteemi juurutama tühjal riistvaral, tühjadel virtuaalmasinatel? Või soovite säilitada olemasolevate seadmete algsed töötingimused ja seadistused? See on riigiettevõtete jaoks väga oluline aspekt, seega peate olema kindel, et saate Ansible'i oma olemasolevas konfiguratsioonis migreerida ja juurutada. Tuvastage rutiinsed haldusprotsessid, mida soovite automatiseerida. Uurige, kas peate uues süsteemis juurutama konkreetseid rakendusi ja teenuseid. Koostage nimekiri sellest, mida soovite teha, ja seadke see prioriteediks.
Seejärel alustage skriptikoodi ja rollide kirjutamist, mis võimaldavad ülesandeid, mida kavatsete täita. Ühendage need projektideks, mis on asjakohaste mänguraamatute loogiline kogu. Iga projekt kuulub eraldi Giti hoidlasse või erinevasse hoidlasse, olenevalt sellest, millist koodihaldurit kasutate. Saate hallata mänguraamatu skripte ja mänguraamatute katalooge, asetades need käsitsi Toweri serveri projekti baasteele või paigutades mänguraamatu mis tahes lähtekoodihaldussüsteemi (SCM), mida Tower toetab, sealhulgas Git, Subversion, Mercurial ja Red Hat. Insights. Ühe projekti raames saate paigutada nii palju skripte, kui soovite. Näiteks lõin ühe põhiprojekti, kuhu panin skripti RedHati põhielementide jaoks, skripti Linuxi tuuma jaoks ja skriptid ülejäänud lähtejoonte jaoks. Seega oli ühes projektis erinevaid rolle ja stsenaariume, mida hallati ühest Giti hoidlast.
Kõigi nende asjade käivitamine käsurea kaudu on hea viis nende funktsionaalsuse testimiseks. See valmistab teid torni paigaldamiseks ette.
Räägime natuke Puppeti manifesti ümberkodeerimisest, sest ma kulutasin sellele palju aega, kuni sain aru, mida tegelikult on vaja teha.
Nagu ma varem ütlesin, salvestab Puppet kõik seaded ja riistvaravalikud ühte pikka manifesti ning see manifest salvestab kõik, mida see SCM tegema peaks. Ülemineku tegemisel ei pea te kõiki oma ülesandeid ühte loendisse toppima, selle asemel mõelge uue süsteemi ülesehitusele: rollid, skriptid, sildid, rühmad ja mis sinna peaksid kuuluma. Mõned autonoomsed võrguelemendid tuleks rühmitada rühmadesse, mille jaoks saab luua skripte. Keerulisemaid infrastruktuurielemente, mis hõlmavad suurt hulka ressursse, sealhulgas iseseisvaid klasse, saab kombineerida rollideks. Enne migreerimist peate selle üle otsustama. Kui loote suuri rolle või stsenaariume, mis ühele ekraanile ei mahu, peaksite infrastruktuuri konkreetsete osade jäädvustamiseks kasutama silte.
18:00
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com