National Environmental Satellite Data Information Service (NESDIS) smanjio je svoje troškove upravljanja konfiguracijom za Red Hat Enterprise Linux (RHEL) za 35% prelaskom sa Puppet Enterprise na Ansible Tower. U ovom videu "kako smo to uradili", sistemski inženjer Michael Rau objašnjava slučaj ove migracije, dijeleći korisne savjete i lekcije naučene prelaskom s jednog SCM-a na drugi.
Iz ovog videa ćete naučiti:
- kako menadžmentu opravdati izvodljivost prelaska sa Puppet Enterprisea na Ansible Tower;
- koje strategije koristiti da bi tranzicija bila što glatkija;
- savjeti za transkodiranje PE manifesta u Ansible Playbook;
- Preporuke za optimalnu ugradnju Ansible Towera.
Pozdrav svima, moje ime je Michael Rau, ja sam viši sistemski inženjer u ActioNetu, koji radi za NESDIS uslugu Nacionalne uprave za okeane i atmosferu (NOAA). Danas ćemo pričati o rezivanju žica - moje vlastito iskustvo migracije sa Puppet Enterprisea na Ansible Tower. Tema ove prezentacije je „pogledati moje ožiljke“ koji su ostali nakon što sam napravio ovu tranziciju ranije ove godine. Želim podijeliti ono što sam naučio kroz ovaj proces. Dakle, kada preuzmete nešto poput ovoga, koristeći moje iskustvo, možete napraviti tranziciju bez dodatnog rada.
Slične slajdove vidite na početku svake prezentacije na Ansible Festu. Ovaj slajd ocrtava istoriju automatizacije moje kompanije. Nisam nov u ovome jer koristim Puppet/Puppet Enterprise od 2007. Počeo sam da radim sa Ansible-om 2016. godine, a kao i mnoge druge korisnike ovog proizvoda, privukla me je mogućnost “trikova” korišćenjem komandne linije i jednostavnih skripti (playbooks). Krajem 2017. obratio sam se svom menadžmentu o jakim razlozima preseljenja u Ansible Tower. Za koji minut ću vam reći o razlozima koji su me naveli na ovaj korak. Nakon što sam dobio saglasnost menadžmenta, trebalo je još nekoliko mjeseci da se plan završi, a ja sam napravio tranziciju u januaru-februaru ove godine. Dakle, potpuno smo napustili Puppet u korist Ansiblea, i to je sjajna stvar.
Ono što me najviše privlači kod Ansiblea je sposobnost pisanja i korištenja uloga i knjiga. Uloge su odlične za kreiranje različitih, ali povezanih zadataka i stavljanje svih podataka koji se odnose na te zadatke na jedno mjesto. Playbook je YAML sintaksa, datoteka skripte koja opisuje radnje za jedan ili više hostova. O ovim karakteristikama govorim korisnicima, prvenstveno programerima softvera. Ansible Tower vam daje mogućnost da kažete: "ne, nemate pristup ljusci, ali ja vam dajem mogućnost da pokrenete sve Tower procese i ponovo pokrenete uslugu kada vam zatreba." Reći ću vam o radnom okruženju i opremi koju koristimo.
Ovo je federalni LAN, 7 fizičkih lokacija povezanih putem MPLS-a u oblaku, 140 RHEL servera, od kojih je 99% virtualno (vSphere), SuperMicro hardver, NexentaStore mrežna pohrana, set Cisco, Arista i Cumulus prekidača i Fortinet UTM objedinjeno upravljanje prijetnjama alati na svakoj stranici.
Federalna mreža znači da moram koristiti sve mjere informacione sigurnosti predviđene zakonom. Imajte na umu da Puppet Enterprise ne podržava većinu hardvera koji koristimo. Primorani smo koristiti budžetski hardver jer državne agencije imaju problema s finansiranjem ove stavke rashoda. Zbog toga kupujemo SuperMicro hardver i sastavljamo našu opremu od pojedinačnih delova čije održavanje je garantovano državnim ugovorima. Koristimo Linux i to je jedan od važnih razloga za prelazak na Ansible.
Naša istorija sa Puppet-om je sledeća.
2007. godine imali smo malu mrežu od 20-25 čvorova u koju smo postavili Puppet. U osnovi, ovi čvorovi su bili samo RedHat „kutije“. 2010. godine počeli smo koristiti web interfejs Puppet Dashboard za 45 čvorova. Kako je mreža nastavila da se širi, prešli smo na PE 2014 3.3. godine, napravivši potpunu tranziciju sa ponovnim pisanjem manifesta za 75 čvorova. To je moralo biti učinjeno jer Puppet voli mijenjati pravila igre, au ovom slučaju su potpuno promijenili jezik. Godinu dana kasnije, kada je završila podrška za verziju 3 Puppet Enterprisea, bili smo primorani da pređemo na PE 2015.2. Morali smo ponovo pisati manifest za nove servere i kupiti licencu sa rezervom od 100 čvorova, iako smo tada imali samo 85 čvorova.
Prošle su samo 2 godine, a mi smo opet morali puno raditi da bismo prešli na novu verziju PE 2016.4. Kupili smo licencu za 300 čvorova, a imamo samo 130. Opet smo morali napraviti velike promjene u manifestu jer je nova verzija jezika imala drugačiju sintaksu od jezika verzije iz 2015. godine. Kao rezultat toga, naš SCM se prebacio sa SVN kontrole verzije na Bitbucket (Git). To je bio naš "odnos" sa Puppetom.
Dakle, morao sam da objasnim menadžmentu zašto smo morali da pređemo na drugi SCM koristeći sledeće argumente. Prva je visoka cijena usluge. Razgovarao sam sa momcima u RedHat-u i rekli su da je trošak vođenja mreže od 300 čvorova sa Ansible Towerom upola manji od cijene Puppet Enterprisea. Ako također kupite Ansible Engine, cijena će biti približno ista, ali ćete dobiti mnogo više funkcija od PE. Pošto smo mi državna kompanija koja se finansira iz federalnog budžeta, ovo je prilično snažan argument.
Drugi argument je svestranost. Puppet podržava samo hardver koji ima Puppet agenta. To znači da agent mora biti instaliran na svim prekidačima i mora biti najnovija verzija. A ako neki od vaših prekidača podržavaju jednu verziju, a neki drugu, morat ćete na njih instalirati novu verziju PE agenta kako bi svi mogli raditi u istom SCM sistemu.
Ansible Tower sistem radi drugačije jer nema agente, ali ima module koji podržavaju Cisco prekidače i sve ostale prekidače. Ovaj SCM podržava Qubes OS, Linux i 4.NET UTM. Ansible Tower takođe podržava NexentaStore mrežne kontrolere za skladištenje zasnovane na Illumos kernelu, operativnom sistemu otvorenog koda zasnovanom na Unixu. Ovo je vrlo mala podrška, ali Ansible Tower to ipak radi.
Treći argument, koji je vrlo važan i za mene i za našu administraciju, je jednostavnost korištenja. Proveo sam 10 godina savladavajući Puppet module i manifest kod, ali sam naučio Ansible za nedelju dana jer je sa ovim SCM-om mnogo lakše raditi. Ako pokrenete izvršne datoteke, naravno, osim ako to ne radite nepotrebno, onda inteligentni i prilagodljivi rukovaoci rade s njima. Priručnici zasnovani na YAML-u su laki za učenje i brzi za upotrebu. Oni koji nikada ranije nisu čuli za YAML mogu jednostavno pročitati skripte i lako razumjeti kako funkcionira.
Da budem iskren, Puppet znatno otežava vaš posao programera jer se zasniva na korištenju Puppet Mastera. To je jedina mašina kojoj je dozvoljeno da komunicira sa agentima lutke. Ako ste napravili bilo kakve promjene u manifestu i želite testirati svoj kod, morate ponovo napisati kod za Puppet Master, odnosno konfigurirati datoteku Puppet Master /etc/hosts da poveže sve klijente i pokrene uslugu Puppet Server. Tek nakon toga moći ćete testirati rad mrežne opreme na jednom hostu. Ovo je prilično bolan postupak.
Sve je mnogo jednostavnije u Ansibleu. Sve što treba da uradite je da razvijete kod za mašinu koja može da komunicira preko SSH-a sa hostom koji se testira. Sa ovim je mnogo lakše raditi.
Sljedeća velika prednost Ansible Tower-a je mogućnost korištenja postojećeg sistema podrške i održavanja postojeće hardverske konfiguracije. Ovaj SCM koristi sve dostupne informacije o vašoj infrastrukturi i hardveru, virtuelnim mašinama, serverima, itd. bez ikakvih dodatnih koraka. Može razgovarati sa vašim RH Satellite serverima, ako ga imate, i daje vam integracije koje nikada nećete dobiti sa Puppet-om.
Druga važna stvar je detaljna kontrola. Znate da je Puppet modularni sistem, to je klijent-server aplikacija, tako da morate definisati postojeće aspekte svih vaših mašina u jednom dugačkom manifestu. U tom slučaju, stanje svakog pojedinačnog elementa sistema mora se testirati svakih pola sata - ovo je zadani period. Ovako funkcionira Puppet.
Toranj te spašava od toga. Možete pokrenuti različite procese na različitoj opremi bez ograničenja; možete obavljati osnovni posao, pokretati druge važne procese, postaviti sigurnosni sistem i raditi sa bazama podataka. U Puppet Enterpriseu možete učiniti sve što je teško. Dakle, ako ste ga konfigurirali na jednom hostu, trebat će vremena da promjene stupe na snagu na preostalim hostovima. U Ansibleu sve promjene stupaju na snagu u isto vrijeme.
Na kraju, pogledajmo sigurnosni modul. Ansible Tower ga implementira jednostavno neverovatno, sa velikom preciznošću i pažnjom. Korisnicima možete dodijeliti pristup određenim uslugama ili određenim hostovima. To radim sa svojim zaposlenicima koji su navikli da rade na Windows-u, ograničavajući im pristup Linux ljusci. Osiguravam im pristup Toweru tako da mogu obavljati samo posao i pokretati samo usluge koje su im relevantne.
Pogledajmo stvari koje trebate učiniti unaprijed kako biste olakšali prelazak na Ansible Tower. Prije svega, morate pripremiti svoju opremu. Ako neki elementi vaše infrastrukture već nisu u bazi podataka, morate ih tamo dodati. Postoje sistemi koji ne mijenjaju svoje karakteristike i stoga ih nema u bazi podataka Puppet, ali ako ih tamo ne dodate prije nego što pređete u Tower, izgubit ćete niz prednosti. Ovo može biti “prljava”, preliminarna baza podataka, ali bi trebala sadržavati informacije o svoj opremi koju imate. Stoga, trebali biste napisati dinamičku hardversku skriptu koja će automatski gurnuti sve promjene infrastrukture u bazu podataka, a onda će Ansible znati koji bi hostovi trebali biti prisutni na novom sistemu. Nećete morati da kažete ovom SCM-u koje ste hostove dodali, a koji više ne postoje, jer će on sve to automatski znati. Što više podataka ima u bazi podataka, to će Ansible biti korisniji i fleksibilniji. Radi kao da jednostavno čita bar kod statusa hardvera iz baze podataka.
Provedite neko vrijeme upoznajući se s komandnom linijom u Ansibleu. Pokrenite neke prilagođene komande da testirate hardversku skriptu, napišite i pokrenite neke jednostavne, ali korisne skripte, koristite Jinja2 šablone gdje je to prikladno. Pokušajte napisati ulogu i skriptu za složen proces u više koraka koristeći uobičajenu hardversku konfiguraciju koja se često sreće. Poigrajte se ovim stvarima, isprobajte kako funkcionira. Na ovaj način ćete naučiti kako koristiti alate za kreiranje biblioteke koji se koriste u Toweru. Već sam rekao da mi je trebalo oko 3 mjeseca da se pripremim za tranziciju. Mislim da ćete na osnovu mog iskustva to moći brže. Nemojte smatrati da je ovo vrijeme izgubljeno, jer ćete kasnije osjetiti sve prednosti obavljenog posla.
Zatim morate odlučiti šta očekujete od Ansible Tower-a, šta tačno ovaj sistem treba da uradi za vas.
Da li treba da implementirate sistem na golom hardveru, na golim virtuelnim mašinama? Ili želite da zadržite originalne uslove rada i postavke postojeće opreme? Ovo je veoma važan aspekt za javna preduzeća, tako da morate biti sigurni da ćete moći da migrirate i primenite Ansible na vašoj postojećoj konfiguraciji. Identificirajte rutinske administrativne procese koje želite automatizirati. Saznajte da li trebate implementirati određene aplikacije i usluge na novom sistemu. Napravite listu onoga što želite da radite i odredite prioritet.
Zatim počnite pisati kod skripte i uloge koje će omogućiti zadatke koje planirate izvršiti. Kombinirajte ih u projekte, logičnu kolekciju relevantnih priručnika. Svaki projekat će pripadati zasebnom Git spremištu ili drugom spremištu u zavisnosti od toga koji menadžer koda koristite. Možete upravljati playbook skriptama i imenicima playbook-a tako što ćete ih ručno postaviti na putanju baze projekta na Tower serveru, ili postavljanjem playbook-a u bilo koji sistem upravljanja izvornim kodom (SCM) koji podržava Tower, uključujući Git, Subversion, Mercurial i Red Hat Insights. Unutar jednog projekta možete postaviti onoliko skripti koliko želite. Na primjer, kreirao sam jedan osnovni projekat u koji sam postavio skriptu za RedHat osnovne elemente, skriptu za jezgru Linuxa i skripte za ostale osnovne linije. Dakle, u jednom projektu postojale su različite uloge i scenariji kojima se upravljalo iz jednog Git repozitorija.
Pokretanje svih ovih stvari kroz komandnu liniju je dobar način da se testira njihova funkcionalnost. Ovo će vas pripremiti za instalaciju Tower.
Hajde da pričamo malo o transkodiranju manifesta lutke, jer sam potrošio dosta vremena na ovo dok nisam shvatio šta zapravo treba da se uradi.
Kao što sam već rekao, Puppet pohranjuje sve postavke i hardverske opcije u jednom dugačkom manifestu, a ovaj manifest pohranjuje sve što ovaj SCM treba da radi. Kada vršite tranziciju, ne morate da trpate sve svoje zadatke u jednu listu; umjesto toga, razmislite o strukturi novog sistema: ulogama, skriptama, oznakama, grupama i šta bi tu trebalo ići. Neki od elemenata autonomne mreže trebali bi se grupirati u grupe za koje se mogu kreirati skripte. Složeniji elementi infrastrukture koji uključuju veliki broj resursa, uključujući samostalne klase, mogu se kombinirati u uloge. Prije migracije, morate odlučiti o tome. Ako kreirate velike uloge ili scenarije koji ne staju na jedan ekran, trebali biste koristiti oznake da biste mogli snimiti određene dijelove infrastrukture.
18:00
Neke reklame 🙂
Hvala vam što ste ostali s nama. Da li vam se sviđaju naši članci? Želite li vidjeti još zanimljivih sadržaja? Podržite nas naručivanjem ili preporukom prijateljima, , jedinstveni analog servera početnog nivoa, koji smo mi izmislili za vas: (dostupno sa RAID1 i RAID10, do 24 jezgra i do 40GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV data centru u Amsterdamu? Samo ovdje u Holandiji! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - od 99 USD! Pročitajte o
izvor: www.habr.com