Rahvuslik keskkonnaandmete satelliiditeenistus (NESDIS) on korraldamiskulud Red Hat Enterprise Linuxi (RHEL) haldamiseks vähendanud 35% võrra, minnes Puppet Enterprise'ilt Ansible Tower'ile. Selles "kuidas me selle tegime" kategooria videos põhjendab süsteemiinsener Michael Rau selle migratsiooni läbiviimist, jagab kasulikke nõuandeid ja kogemusi, mis tulenevad üleminekust ühest SCM-ist teise.
Selles videos saate teada:
- kuidas põhjendada juhtkonnale ülemineku mõistlikkust Puppet Enterprise'ilt Ansible Tower'ile;
- milliseid strateegiaid kasutada sujuvaks üleminekuks;
- nõuandeid PE manifestide transkodeerimiseks Ansible Playbooki;
- soovitusi Ansible Toweri optimaalseks installimiseks.
Tere kõik, minu nimi on Michael Rau, olen ActioNet'i vanem süsteemiinsener, kes töötab Rahvusliku Ookeani- ja Atmosfääriaadministratsiooni (NOAA) NESDIS teenistuses. Täna räägime stringide lõikamisest – minu isiklik kogemus migration Puppet Enterprise'ist Ansible Towerisse. Selle ettekande teema on "vaadata minu arme", mis jäid pärast seda, kui tegin selle ülemineku aasta alguses. Soovin jagada, mida ma selle protsessi jooksul õppisin. Nii et kui te võtate sarnase ülesande, olles minu kogemustega tutvunud, saate ülemineku sujuvamalt teha.
Näete slaide, mis sarnanevad sellele, Ansible Fest'i iga ettekande alguses. Sellel slaidil on jutustatud minu ettevõtte automatiseerimise ajalugu. Ma ei ole selles osas uus, kuna olen Puppet/Puppet Enterprise'i kasutanud alates 2007. aastast. Alustasin Ansible'i kasutamist 2016. aastal ja mind, nagu paljusid teisi selle toote kasutajaid, paelus võimalus teha „nippe” käsurea abil ja lihtsad skriptid (playbooks). 2017. aasta lõpus pöördusin oma juhtkonna poole, et arutada tõsiseid põhjuseid Ansible Towerile ülemiseks. Natuke aega pärast seda räägin teile põhjustest, mis mind selle sammu astuma sundisid. Pärast juhtkonna nõusolekut kulus veel paar kuud plaani elluviimiseks ja ma tegin ülemineku käesoleva aasta jaanuaris-veebruaris. Nii oleme täielikult loobunud Puppetist Ansible'i kasuks ja see on suurepärane saavutus.
Ansible'i juures paelub mind kõige rohkem võimalus kirjutada ja kasutada rolle (roles) ning skripte (playbooks). Rollid sobivad suurepäraselt mitmete, kuid omavahel seotud ülesannete (tasks) loomiseks ja nendele seotud kõigi andmete ühte kohta koondamiseks. Playbook on YAML-süntaks, skriptifail, mis kirjeldab toiminguid ühe või mitme hosti jaoks. Räägin nendest võimalustest eelkõige tarkvaraarendajatele. Ansible Tower võimaldab öelda: "ei, teil pole shell-juurdepääsu, kuid ma annan teile võimaluse käivitada kõik Toweri protsessid ja taaskäivitada teenus, kui see on vajalik." Räägin teile oma töö keskkonnast ja kasutatavast riistvarast.
See on föderaalne LAN, 7 füüsilist asukohta, mis on ühendatud pilve MPLS-i kaudu, 140 RHEL-serverit, millest 99% on virtuaalsed (vSphere), SuperMicro riistvara, NexentaStore võrgu salvestus, Cisco, Arista ja Cumulus lülitite komplekt ning Fortinet UTM igas asukohas koos ühtse ohtude haldamise süsteemiga.
Föderaalne võrk tähendab, et ma pean kasutama kõiki seadusandlikest aktidest tulenevaid teabe kaitse vahendeid. Peate arvestama, et Puppet Enterprise ei toeta enamikku meie kasutatavast riistvarast. Oleme sunnitud kasutama eelarvelist riistvara, kuna riigiasutustel on selle kulutuse rahastamisega probleeme. Seetõttu ostame SuperMicro klassi 'raudvara' ja koostame meie seadmed eriosadest, mille hooldust tagavad valitsuslepingud. Kasutame Linuxit, ja see on üks oluline põhjus üleminekuks Ansible'ile.
Meie koostööl Puppetiga on järgmine ajalugu.
2007. aastal oli meil väike võrk, kus oli 20–25 sõlme, kuhu me paigaldasime Puppet'i. Peamiselt koosnesid need sõlmed lihtsalt RedHat'i «karpidest». 2010. aastal hakkasime kasutama Puppet Dashboard'i veebirakendust 45 sõlme jaoks. Kuna võrk jätkas laienemist, 2014. aastal liikusime PE 3.3-le, tehes täieliku ülemineku, ümber kirjutades manifesti 75 sõlme jaoks. See tuli teha, kuna Puppet armastab mängureegleid muuta, ja antud juhul muudetigi keelt täielikult. Aasta hiljem, kui 3. versiooni Puppet Enterprise'i tugi lõpetati, pidime me migreerima PE 2015.2-le. Taas tuli manifest uute serverite jaoks ümber kirjutada ja osta litsents 100 sõlmele, kuigi sel hetkel oli meil vaid 85 sõlme.
Kaks aastat hiljem pidime uuesti tegema suure ülemineku uuele PE 2016.4 versioonile. Ostsime litsentsi 300 sõlmele, omades samal ajal vaid 130. Taas tuli meie manifesti olulisi muudatusi teha, kuna uue versiooni keel erines 2015. aasta versiooni süntaksist. Lõppkokkuvõttes liikus meie SCM versioonihaldussüsteemist SVN Bitbucket'i (Git) peale. Need olid meie «suhted» Puppet'iga.
Nii et mul tuli juhtkonnale seletada, miks peame liikuma teisele SCM-le, kasutades järgmisi argumente. Esiteks – teenuse kõrge hind. Rääkisin RedHati poistest ja nad ütlesid, et 300 sõlme haldamise maksumus Ansible Toweri kaudu on poole odavam kui Puppet Enterprise. Kui osta veel Ansible Engine, siis on maksumus umbes sama, kuid samas saate palju rohkem funktsioone kui PE-l. Kuna oleme riigiettevõte, mida rahastatakse föderaalsetest vahenditest, on see üsna oluline argument.
Teine argument – universaalsus. Puppet toetab ainult neid seadmeid, millel on Puppet agent. See tähendab, et iga silda tuleb installida agent ja see peab olema viimasel versioonil. Kui osa teie sildadest toetab ühte versiooni ja osa teist, siis peate neile paigaldama uue versiooni PE agentist, et kõik saaksid töötada ühes SCM-süsteemis.
Ansible Tower töötab erinevalt, kuna tal ei ole sisendeid, kuid selle asemel on moduld, mis toetavad Cisco lüliteid ja kõiki teisi lüliteid. See SCM toetab Qubes OS-i, Linuxit ja 4.NET UTM. Ansible Tower toetab ka NexentaStore'i võrgu salvestus kontrollerit, mis põhineb Illumose kernelil – avatud lähtekoodiga Unix'i põhine operatsioonisüsteem. Tugi on väga piiratud, kuid Ansible Tower pakub siiski seda võimalust.
Kolmas argument, mis on väga oluline nii mulle kui ka meie juhtele, on õppimise lihtsus. Olen kümme aastat õppinud Puppet'i mooduleid ja manifestikoodi, kuid Ansible'i õppisin nädala jooksul, kuna see SCM on palju lihtsam kasutada. Kui käitate täidetavaid faile, siis loomulikult, kui te ei tee seda ilma vajaduseta, on nendega seotud mõistlikud ja reageerivad töötlejad. YAML-põhised playbook-skripte on lihtne õppida ja kiiresti kasutada. Need, kes pole kunagi varem YAML-i kuulnud, saavad lihtsalt skripte lugeda ja kergesti aru, kuidas see töötab.
Ausalt öeldes muudab Puppet teie töö arendajana palju keerulisemaks, kuna see põhineb Puppet Masteri kasutamisel. See on ainus masin, millel on õigus suhelda Puppet agentidega. Kui olete manifesteerimisse mingid muudatused teinud ja soovite oma koodi testida, peate kirjutama koodi Puppet Masteri jaoks, st seadistama Puppet Masteri faili /etc/hosts, et ühendada kõik kliendid ja käivitama Puppet Serveri teenuse. Ainult pärast seda saate ühes hostis võrgu seadmete tööd proovida. See on piisavalt valuline protseduur.
Ansible'is on kõik palju lihtsam. Kõik, mida tuleb teha, on välja töötada kood masinale, mis suudab testitava hostiga SSH protokolli kaudu ühendust luua. Sellega on palju lihtsam töötada.
Ansible Tower'i järgmine suur eelis on võimalus kasutada juba olemasolevat tugisüsteemi ja säilitada olemasolev riistvarakonfiguratsioon. See SCM kasutab ilma täiendavate toiminguteta kogu teavet teie infrastruktuuri ja varade, virtuaalsete masinate, serverite jms kohta. Kui teil on RH Satellite serverid, saab see nendega suhelda ja pakub teile sellist integreerimist, mida te kunagi ei saaks, töötades Puppetiga.
Teine oluline aspekt on põhjalik kontroll. Teate, et Puppet on modulaarne süsteem, see on kliendi-serveri rakendus, seega peate määratlema kõigi teie masinate töö olemasolevad aspektid ühes pikas manifestis. Samuti tuleb iga üksiku süsteemi elemendi olekuid testida iga poole tunni järel – see on vaikimisi aeg. Nii töötab Puppet.
Tower vabastab teid sellest. Saate ilma piiranguteta teostada erinevaid protsesse erinevates seadmetes, tegeleda põhitegevusega, käivitada teisi olulisi protsesse, seadistada turvasüsteemi, töötada andmebaasidega. Saate teha kõike seda, mis Puppet Enterprise'i puhul esitab teatud raskusi. Kui olete seadistuse teinud ühes hostis, võtab aega, enne kui muudatused jõustuvad teistes hostides. Ansible'is jõustuvad kõik muudatused korraga.
Lõpuks vaatame turvamoont. Ansible Toweris on see ellu viidud erakordselt hästi, suure täpsuse ja hoolikusega. Saate anda kasutajatele juurdepääsu konkreetsetele teenustele või teatavatele hostidele. Tean, et minu töötajad, kes on harjunud Windowsiga, piiravad oma juurdepääsu Linuxi shell'ile. Ma tagan neile sellise juurdepääsu Towerisse, et nad saaksid teha ainult seda tööd ja käivitada ainult neid teenuseid, mis kuuluvad nende pädevusse.
Vaatame üle asjad, mida tuleb eelnevalt teha, et üleminek Ansible Towerile sujuvam oleks. Esiteks on oluline valmistada ette teie varustus. Kui mõni teie infrastruktuuri element puudub andmebaasis, tuleb see sinna lisada. On süsteeme, mis ei muuda oma omadusi ja seetõttu ei ole nad Puppet'i andmebaasis, kuid kui te ei lisa neid sinna enne üleminekut Towerile, jääte paljust kasust ilma. See võib olla 'määrdumise' eelnev andmebaas, kuid see peaks sisaldama teavet kogu teie olemasoleva varustuse kohta. Seetõttu peaksite kirjutama dünaamilise varustuse skripti, mis automaatselt kannab kõik infrastruktuuri muudatused andmebaasi, nii et Ansible teab, millised hostid peaksid uues süsteemis olema. Te ei pea sellele SCM'ile teatama, millised hostid on lisatud ja millised hostid enam ei eksisteeri, kuna kõik need andmed tuvastatakse automaatselt. Mida rohkem andmeid andmebaasis on, seda kasulikum ja paindlikum Ansible on. See töötab nagu oleks see lihtsalt skaneerimas andmebaasi varustuse oleku QR-koodi.
Kuluta veidi aega, et tutvuda Ansible’i käsureaga. Käivita mõned spetsiifilised käsklused, et kontrollida seadmeskripti tööd, kirjuta ja käivita mõned lihtsad, aga kasulikud playbook'i stsenaariumid, kasuta Jinja2 malli seal, kus see on asjakohane. Proovi kirjutada roll ja stsenaarium keerukaks mitmeastmeliseks protsessiks, kasutades standardset, sageli esinevat seadme konfiguratsiooni. Katseta nende asjadega, testige, kuidas see töötab. Nii õpid riistvara teekide loomiseks vajalike tööriistade kasutamist, mida Toweris kasutatakse. Olen juba maininud, et mul oli üleminekuks ettevalmistamiseks aega umbes 3 kuud. Usun, et minu kogemustelt lähtuvalt õnnestub sul seda kiiremini teha. Ära pea seda aega raisatud ajaks, kuna hiljem tunned kõiki vaeva andnud töö eeliseid.
Seejärel tuleb otsustada, mida sa Ansible Towerilt ootad, mida peaks see süsteem täpselt sinu jaoks tegema.
Kas vajate süsteemi käivitamist tühjale varustusele või tühi virtuaalmasinale? Või soovite säilitada olemasolevate seadmete algtingimusi ja seadistusi? See on väga oluline aspekt riigiettevõtete jaoks, seetõttu peate veenduma, et suudate migreerida ja käivitada Ansible olemasolevas konfiguratsioonis. Määrake rutiinsed administratiivsed protsessid, mida soovite automatiseerida. Selgitage välja, kas peate käivitama uue süsteemi jaoks spetsiifilisi rakendusi ja teenuseid. Koostage nimekiri asjadest, mida soovite teha, ja seostage need prioriteetidega.
Alustage skriptide ja rollide kirjutamist, mis tagavad teie planeeritud ülesannete täitmise. Koguge need Projects'isse, loogilisse kogumikku vastavaid playbook'e. Iga Project kuulub eraldi Git-repositooriumisse või muusse repositooriumisse, sõltuvalt sellest, millist koodihaldurit kasutate. Saate hallata playbook'e ja playbook'e katalooge, asetades need käsitsi Project Base Path'i Tower serveris, või paigutades playbook'i igasse Toweri toetatud allikakoodihaldussüsteemi (SCM), sealhulgas Git, Subversion, Mercurial ja Red Hat Insights. Ühes Project's saate paigutada nii palju skripte, kui soovite. Näiteks olen loonud ühe alusprojekti, kuhu olen paigutanud skripti RedHat'i põhielementide jaoks, skripti Linuxi põhialuste jaoks ning skripte ülejäänud põhinäitajate jaoks. Nii oli ühes projektis erinevaid rolle ja skripte, mida hallati ühest Git-repositooriumist.
Käivitage kõik need asjad käsurealt, see on hea viis nende toimivuse kontrollimiseks. Nii valmistute Toweri installimiseks.
Võtame hetk, et rääkida Puppet'i manifeedi transkodeerimisest, kuna ma olen selle kallal palju aega raisanud, enne kui mõistsin, mida tegelikult tegema peab.
Nagu ma juba mainisin, salvestab Puppet kõik seadistused ja riistvara parameetrid ühte pika manifeedi, kus on kirjas kõik, mida see SCM peab tegema. Ülemineku ajal ei pea te kõiki oma ülesandeid ühte nimekirja mahutama; hoopis mõelge uue süsteemi struktuurile: rollidele, skriptidele, ketastele, gruppidele ning sellele, mida sinna tuleks lisada. Mõned iseseisvad võrguelemendid tuleks koguda gruppidesse, mille jaoks saab luua skripte. Komplexsemad infrastruktuurielemendid, mis vajavad palju ressursse, sealhulgas iseseisvad klassid, saab koondada rollidesse. Enne migreerimist tuleb selle üle otsustada. Kui loote mahukaid rolle või skripte, mis ei mahu ühele ekraanile, peaksite kasutama kettaid, et saaksite eraldi infrastruktuuri osadele tähelepanu pöörata.
18:00
Veidi reklaami 🙂
Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. , ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).
Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas
Allikas: habr.com
