Nacionalna informacijska služba za satelitske podatke o okolju (NESDIS) je znižala svoje stroške upravljanja konfiguracije za Red Hat Enterprise Linux (RHEL) za 35 % s prehodom iz Puppet Enterprise na Ansible Tower. V tem videoposnetku o tem, kako smo to naredili, sistemski inženir Michael Rau razloži primer te selitve ter deli koristne nasvete in izkušnje, pridobljene pri prehodu z enega SCM na drugega.
Iz tega videa se boste naučili:
- kako vodstvu utemeljiti izvedljivost prehoda iz Puppet Enterprise na Ansible Tower;
- katere strategije uporabiti, da bo prehod čim bolj gladek;
- nasveti za prekodiranje manifestov PE v Ansible Playbook;
- Priporočila za optimalno namestitev Ansible Tower.
Pozdravljeni vsi, moje ime je Michael Rau, sem višji sistemski inženir pri ActioNet, ki dela za storitev NESDIS Nacionalne uprave za oceane in atmosfero (NOAA). Danes bomo govorili o obrezovanju vrvic - moji lastni izkušnji selitve iz Puppet Enterprise v Ansible Tower. Tema te predstavitve je "poglejte si svoje brazgotine", ki so ostale po tem, ko sem v začetku leta naredil ta prehod. Želim deliti, kar sem se naučil skozi ta proces. Torej, ko se lotite česa takega, lahko na podlagi mojih izkušenj opravite prehod brez dodatnega dela.
Diapozitive, podobne temu, vidite na začetku vsake predstavitve na Ansible Festu. Ta diapozitiv opisuje zgodovino avtomatizacije mojega podjetja. Nisem nov v tem, ker uporabljam Puppet/Puppet Enterprise od leta 2007. Z Ansible sem začel delati leta 2016 in tako kot mnoge druge uporabnike tega produkta me je pritegnila možnost “trikov” z uporabo ukazne vrstice in preprostih skript (playbooks). Konec leta 2017 sem se obrnil na svoje vodstvo glede močnih razlogov za selitev v Ansible Tower. Čez minuto vam bom povedal o razlogih, ki so me spodbudili k temu koraku. Po prejemu soglasja vodstva je trajalo še nekaj mesecev za dokončanje načrta, prehod pa sem izvedel v januarju-februarju letos. Tako smo popolnoma opustili Puppet v korist Ansiblea in to je odlična stvar.
Kar me najbolj privlači pri Ansibleu, je sposobnost pisanja in uporabe vlog in iger. Vloge so odlične za ustvarjanje ločenih, a povezanih nalog in za shranjevanje vseh podatkov, povezanih s temi nalogami, na enem mestu. Playbook je sintaksa YAML, skriptna datoteka, ki opisuje dejanja za enega ali več gostiteljev. O teh funkcijah govorim uporabnikom, predvsem razvijalcem programske opreme. Ansible Tower vam omogoča, da rečete: "ne, nimate dostopa do lupine, vendar vam dam možnost, da zaženete vse procese stolpa in znova zaženete storitev, ko jo potrebujete." Povedal vam bom o delovnem okolju in opremi, ki jo uporabljamo.
To je zvezni LAN, 7 fizičnih lokacij, povezanih prek MPLS v oblaku, 140 strežnikov RHEL, od katerih je 99 % virtualnih (vSphere), strojna oprema SuperMicro, omrežna shramba NexentaStore, sklop stikal Cisco, Arista in Cumulus ter enotno upravljanje groženj Fortinet UTM orodja na vsakem spletnem mestu.
Zvezno omrežje pomeni, da moram uporabljati vse ukrepe za varnost informacij, ki jih določa zakon. Upoštevati morate, da Puppet Enterprise ne podpira večine strojne opreme, ki jo uporabljamo. Prisiljeni smo uporabljati proračunsko strojno opremo, ker imajo državne agencije težave s financiranjem te odhodkovne postavke. Zato kupujemo strojno opremo SuperMicro in svojo opremo sestavljamo iz posameznih delov, katerih vzdrževanje je zagotovljeno z državnimi pogodbami. Uporabljamo Linux in to je eden od pomembnih razlogov za prehod na Ansible.
Naša zgodovina z lutko je naslednja.
Leta 2007 smo imeli majhno mrežo 20-25 vozlišč, v katero smo postavili Puppet. V bistvu so bila ta vozlišča samo "škatle" RedHat. Leta 2010 smo začeli uporabljati spletni vmesnik Puppet Dashboard za 45 vozlišč. Ko se je omrežje še naprej širilo, smo leta 2014 prešli na PE 3.3 in izvedli popoln prehod s prepisom manifesta za 75 vozlišč. To je bilo treba storiti, ker Puppet rad spreminja pravila igre, v tem primeru pa so povsem spremenili jezik. Leto pozneje, ko se je podpora za različico 3 Puppet Enterprise končala, smo bili prisiljeni preiti na PE 2015.2. Ponovno smo morali napisati manifest za nove strežnike in kupiti licenco z rezervo 100 vozlišč, čeprav smo takrat imeli le 85 vozlišč.
Minili sta samo 2 leti in spet smo morali opraviti veliko dela za prehod na novo različico PE 2016.4. Kupili smo licenco za 300 vozlišč, imeli pa smo le 130. Spet smo morali narediti velike spremembe v manifestu, ker je imela nova različica jezika drugačno sintakso kot jezik različice 2015. Posledično je naš SCM prešel z nadzora različic SVN na Bitbucket (Git). To je bil naš »razmerje« z Lutko.
Zato sem moral z naslednjimi argumenti vodstvu razložiti, zakaj se moramo premakniti na drug SCM. Prvi je visoka cena storitve. Pogovarjal sem se s fanti pri RedHatu in rekli so, da so stroški delovanja omrežja s 300 vozlišči z Ansible Tower polovica stroškov Puppet Enterprise. Če kupite tudi Ansible Engine, bodo stroški približno enaki, vendar boste dobili veliko več funkcij kot PE. Ker smo državno podjetje, financirano iz zveznega proračuna, je to precej močan argument.
Drugi argument je vsestranskost. Puppet podpira samo strojno opremo, ki ima agenta Puppet. To pomeni, da mora biti agent nameščen na vseh stikalih in mora biti najnovejša različica. In če nekatera vaša stikala podpirajo eno različico, nekatera pa drugo, boste morali nanje namestiti novo različico agenta PE, da bodo lahko vsa delovala v istem sistemu SCM.
Sistem Ansible Tower deluje drugače, ker nima nobenih agentov, ima pa module, ki podpirajo stikala Cisco in vsa druga stikala. Ta SCM podpira Qubes OS, Linux in 4.NET UTM. Ansible Tower podpira tudi omrežne krmilnike za shranjevanje NexentaStore, ki temeljijo na jedru Illumos, odprtokodnem operacijskem sistemu, ki temelji na Unixu. To je zelo malo podpore, vendar Ansible Tower to vseeno počne.
Tretji argument, ki je zelo pomemben tako zame kot za našo upravo, je enostavnost uporabe. 10 let sem porabil za obvladovanje modulov Puppet in manifestne kode, vendar sem se Ansible naučil v enem tednu, ker je s tem SCM veliko lažje delati. Če seveda izvajate izvedljive datoteke, razen če tega ne počnete po nepotrebnem, potem z njimi delajo inteligentni in odzivni upravljalci. Zbirke iger, ki temeljijo na YAML, so preproste za učenje in hitre za uporabo. Tisti, ki še nikoli niso slišali za YAML, lahko preprosto preberejo skripte in zlahka razumejo, kako deluje.
Iskreno povedano, Puppet močno oteži vaše delo razvijalca, ker temelji na uporabi Puppet Master. Je edini stroj, ki mu je dovoljeno komunicirati z lutkovnimi agenti. Če ste kakor koli spremenili manifest in želite preizkusiti svojo kodo, morate znova napisati kodo za Puppet Master, to je konfigurirati datoteko Puppet Master /etc/hosts za povezavo vseh odjemalcev in zagon storitve Puppet Server. Šele po tem boste lahko preizkusili delovanje omrežne opreme na enem gostitelju. To je precej boleč postopek.
V Ansibleu je vse veliko preprostejše. Vse, kar morate storiti, je razviti kodo za stroj, ki lahko prek SSH komunicira s preizkušanim gostiteljem. S tem je veliko lažje delati.
Naslednja velika prednost Ansible Tower je zmožnost izkoriščanja vašega obstoječega podpornega sistema in vzdrževanja obstoječe konfiguracije strojne opreme. Ta SCM uporablja vse razpoložljive informacije o vaši infrastrukturi in strojni opremi, virtualnih strojih, strežnikih itd. brez dodatnih korakov. Lahko se pogovarja z vašimi strežniki RH Satellite, če jih imate, in vam omogoča integracije, ki jih s Puppetom ne boste nikoli dobili.
Druga pomembna stvar je natančen nadzor. Veste, da je Puppet modularen sistem, je aplikacija odjemalec-strežnik, zato morate definirati obstoječe vidike vseh vaših strojev v enem dolgem manifestu. V tem primeru je treba stanje vsakega posameznega elementa sistema testirati vsake pol ure – to je privzeto obdobje. Tako deluje Puppet.
Tower te reši tega. Brez omejitev lahko izvajate različne procese na različni opremi, lahko opravljate osnovna dela, izvajate druge pomembne procese, postavljate varnostni sistem in delate z bazami podatkov. V Puppet Enterprise lahko naredite vse, kar je težko. Torej, če ste ga konfigurirali na enem gostitelju, bo trajalo nekaj časa, da spremembe začnejo veljati na preostalih gostiteljih. V Ansibleu vse spremembe stopijo v veljavo hkrati.
Na koncu si poglejmo varnostni modul. Ansible Tower izvaja preprosto neverjetno, z veliko natančnostjo in skrbnostjo. Uporabnikom lahko omogočite dostop do določenih storitev ali do določenih gostiteljev. To počnem s svojimi zaposlenimi, ki so navajeni delati v sistemu Windows, in jim omejim dostop do lupine Linux. Zagotavljam, da imajo dostop do Towerja, tako da lahko opravljajo samo delo in izvajajo samo storitve, ki so zanje pomembne.
Oglejmo si stvari, ki jih morate storiti vnaprej, da bo vaš prehod na Ansible Tower lažji. Najprej morate pripraviti opremo. Če nekateri elementi vaše infrastrukture še niso v bazi podatkov, jih morate dodati tja. Obstajajo sistemi, ki ne spreminjajo svojih lastnosti in jih zato ni v bazi Puppet, a če jih tja ne dodate pred selitvijo v Tower, boste izgubili številne prednosti. To je lahko "umazana", predhodna zbirka podatkov, vendar mora vsebovati informacije o vsej opremi, ki jo imate. Zato bi morali napisati dinamični strojni skript, ki bo samodejno potisnil vse spremembe infrastrukture v bazo podatkov, nato pa bo Ansible vedel, kateri gostitelji morajo biti prisotni v novem sistemu. Temu SCM vam ne bo treba povedati, katere gostitelje ste dodali in kateri gostitelji ne obstajajo več, ker bo vse to vedel samodejno. Več podatkov kot je v bazi podatkov, bolj uporaben in prilagodljiv bo Ansible. Deluje, kot da preprosto prebere črtno kodo stanja strojne opreme iz baze podatkov.
Porabite nekaj časa, da se seznanite z ukazno vrstico v Ansible. Zaženite nekaj ukazov po meri za preizkušanje skripta strojne opreme, napišite in zaženite nekaj preprostih, a uporabnih skriptov priročnika, po potrebi uporabite predloge Jinja2. Poskusite napisati vlogo in skript za zapleten proces v več korakih z uporabo običajne konfiguracije strojne opreme, ki se pogosto pojavlja. Igrajte se s temi stvarmi, preizkusite, kako deluje. Tako se boste naučili uporabljati orodja za ustvarjanje knjižnice, ki se uporabljajo v Towerju. Rekel sem že, da sem potreboval približno 3 mesece, da sem se pripravil na prehod. Glede na moje izkušnje mislim, da vam bo to uspelo hitreje. Ne menite, da je ta čas izgubljen, saj boste kasneje izkusili vse prednosti opravljenega dela.
Nato se morate odločiti, kaj pričakujete od Ansible Towerja, kaj točno naj bi ta sistem naredil za vas.
Ali morate sistem razmestiti na goli strojni opremi, na golih virtualnih strojih? Ali pa želite ohraniti prvotne pogoje delovanja in nastavitve obstoječe opreme? To je zelo pomemben vidik za javna podjetja, zato morate biti prepričani, da boste lahko preselili in uvedli Ansible v svoji obstoječi konfiguraciji. Določite rutinske administrativne procese, ki jih želite avtomatizirati. Ugotovite, ali morate v novem sistemu namestiti določene aplikacije in storitve. Naredite seznam tega, kar želite storiti, in to prednostno razvrstite.
Nato začnite pisati skriptno kodo in vloge, ki bodo omogočile naloge, ki jih nameravate dokončati. Združite jih v Projects, logično zbirko ustreznih priročnikov. Vsak projekt bo pripadal ločenemu repozitoriju Git ali drugemu repozitoriju, odvisno od tega, kateri upravitelj kode uporabljate. Skripte knjig in imenike knjig lahko upravljate tako, da jih ročno postavite v osnovno pot projekta na strežniku Tower ali tako, da knjižico postavite v kateri koli sistem za upravljanje izvorne kode (SCM), ki ga podpira Tower, vključno z Git, Subversion, Mercurial in Red Hat Vpogledi. Znotraj enega projekta lahko postavite poljubno število skriptov. Na primer, ustvaril sem en osnovni projekt, v katerega sem umestil skript za jedrne elemente RedHat, skript za jedro Linuxa in skripte za preostale osnovne črte. Tako so bile v enem projektu različne vloge in scenariji, ki so bili upravljani iz enega repozitorija Git.
Zagon vseh teh stvari prek ukazne vrstice je dober način za preizkus njihove funkcionalnosti. To vas bo pripravilo na namestitev stolpa.
Pogovorimo se malo o prekodiranju Puppet manifesta, ker sem za to porabil veliko časa, dokler nisem ugotovil, kaj je pravzaprav treba storiti.
Kot sem že rekel, Puppet shranjuje vse nastavitve in možnosti strojne opreme v enem dolgem manifestu in ta manifest shranjuje vse, kar bi moral narediti ta SCM. Pri prehodu vam ni treba strpati vseh nalog na en seznam; namesto tega razmislite o strukturi novega sistema: vlogah, skriptih, oznakah, skupinah in o tem, kaj bi moralo biti tja. Nekatere elemente avtonomnega omrežja je treba združiti v skupine, za katere je mogoče ustvariti skripte. Kompleksnejše elemente infrastrukture, ki vključujejo veliko število virov, vključno s samostojnimi razredi, je mogoče združiti v vloge. Pred selitvijo se morate o tem odločiti. Če ustvarjate velike vloge ali scenarije, ki se ne prilegajo enemu zaslonu, uporabite oznake, da boste lahko zajeli določene dele infrastrukture.
18:00
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com