Nacionalna informacijska služba satelitskih podataka o okolišu (NESDIS) smanjila je svoje troškove upravljanja konfiguracijom Red Hat Enterprise Linux (RHEL) za 35% prelaskom s Puppet Enterprise na Ansible Tower. U ovom videu iz kategorije 'kako smo to učinili', sistemski inženjer Michael Rau opravdava ovu migraciju, dijeli korisne savjete i iskustva stečena prijelazom s jednog SCM-a na drugi.
Iz ovog videa saznat ćete:
- kako opravdati vođstvu razloženost prijelaza s Puppet Enterprise na Ansible Tower;
- koje strategije koristiti za maksimalno glatki prijelaz;
- savjete za transkodiranje PE manifesta u Ansible Playbook;
- preporuke za optimalnu instalaciju Ansible Tower.
Pozdrav svima, moje ime je Michael Rau, ja sam viši sistemski inženjer tvrtke ActioNet koja radi za Nacionalnu upravu za oceanske i atmosferske istraživanja (NOAA) službe NESDIS. Danas ćemo govoriti o rezanjem linija – moje vlastito iskustvo migracije s Puppet Enterprise na Ansible Tower. Tema ove prezentacije je 'pogledajte moje ožiljke', koji su ostali nakon što sam izvršio ovaj prijelaz početkom godine. Želim reći što sam naučio tijekom tog procesa. Dakle, kada se odlučite na sličan korak, koristeći moje iskustvo, moći ćete obaviti prijelaz bez puno muke.
Vidite slajdove poput ovog na početku svake prezentacije na Ansible Festu. Ovaj slajd ilustrira priču o automatizaciji moje tvrtke. Nisam početnik u tome, jer koristim Puppet/Puppet Enterprise od 2007. godine. Počeo sam raditi s Ansible-om 2016. godine, i kao mnogi drugi korisnici ovog proizvoda, privukla me mogućnost 'trikova' putem komandne linije i jednostavnih skripti (playbooks). Krajem 2017. godine obratio sam se svom vođstvu s ozbiljnim razlozima za prijelaz na Ansible Tower. Za minutu ću govoriti o razlozima koji su me potaknuli na ovaj korak. Nakon dobivanja suglasnosti vođstva, prošlo je još nekoliko mjeseci da se izvrši plan, a ja sam izvršio prijelaz u siječnju i veljači ove godine. Dakle, potpuno smo se odrekli Puppeta u korist Ansible-a, i to je sjajna stvar.
Najviše me u Ansibleu privlači mogućnost pisanja i korištenja uloga (roles) i skripti (playbooks). Uloge su izvrsne za kreiranje raznih, ali međusobno povezanih zadataka (tasks) i za smještanje svih podataka vezanih uz te zadatke na jednom mjestu. Playbook je YAML sintaksa, datoteka-skripta koja opisuje radnje za jedan ili više hostova. O tim mogućnostima govorim korisnicima, prvenstveno programerima. Ansible Tower omogućava reći: „ne, nemate pristup shell access-u, ali vam dajem mogućnost da pokrenete sve procese Towera i ponovno pokrenete uslugu kad god vam zatreba“. O tome ću vam pričati o radnom okruženju i opremi koju koristimo.
To je federalna LAN, 7 fizičkih lokacija povezanih putem oblačnog MPLS-a, 140 RHEL poslužitelja, od kojih je 99% virtualizirano (vSphere), oprema SuperMicro, mrežno pohranjivanje NexentaStore, skup prekidača Cisco, Arista i Cumulus, i alati za sveobuhvatno upravljanje prijetnjama Fortinet UTM na svakoj lokaciji.
Federalna mreža znači da moram koristiti sve mjere zaštite informacija predviđene zakonskim aktima. Trebali biste imati na umu da Puppet Enterprise ne podržava većinu opreme koju koristimo. Prinuđeni smo koristiti proračunsku opremu jer državne strukture imaju problema s financiranjem ovog stavka troškova. Stoga kupujemo hardver klase SuperMicro i sastavljamo našu opremu iz pojedinačnih dijelova, čije je održavanje garantirano vladinim ugovorima. Koristimo Linux, i to je jedan od važnih razloga za prelazak na Ansible.
Naša povijest rada s Puppetom je sljedeća.
U 2007. smo imali malu mrežu od 20-25 čvorova, gdje smo implementirali Puppet. Uglavnom su ti čvorovi bili samo „kutije“ RedHat. U 2010. smo počeli koristiti web sučelje Puppet Dashboard za 45 čvorova. Kako se mreža nastavila širiti, 2014. smo prešli na PE 3.3, izvršivši potpunu migraciju prepisivanjem manifesta za 75 čvorova. To smo morali učiniti jer Puppet voli mijenjati pravila igre, a u ovom slučaju su potpuno promijenili jezik. Godinu dana kasnije, kada je prestala podrška za 3. verziju Puppet Enterprise, morali smo migrirati na PE 2015.2. Ponovno smo morali prepisati manifest za nove poslužitelje i nabaviti licencu s opcijom za 100 čvorova, iako smo tada imali samo 85 čvorova.
Prošla su samo 2 godine, a opet smo morali obaviti veliki posao prelaska na novu verziju PE 2016.4. Kupili smo licencu za 300 čvorova, iako smo imali samo 130. Ponovno smo morali napraviti značajne promjene u manifestu, jer je nova verzija jezika imala sintaksu koja se razlikovala od jezika iz 2015. Na kraju je naš SCM prešao s sustava za upravljanje verzijama SVN na Bitbucket (Git). Takve su bile naše „relacije“ s Puppet-om.
Dakle, morao sam objasniti menadžmentu zašto trebamo preći na drugi SCM, koristeći sljedeće argumente. Prvi je – visoka cijena usluge. Razgovarao sam s ljudima iz RedHat-a i rekli su mi da trošak održavanja mreže od 300 čvorova uz pomoć Ansible Tower-a iznosi polovicu troška Puppet Enterprise-a. Ako nabavite još Ansible Engine-a, trošak će otprilike biti jednak, ali s tim ćete dobiti daleko više funkcija nego s PE-om. Budući da smo državna kompanija koja se financira iz federalnog proračuna, to je prilično jak argument.
Drugi argument je univerzalnost. Puppet podržava samo onaj hardver na kojem je instaliran Puppet agent. To znači da na sve switcheve treba instalirati agenta, a on mora biti najnovija verzija. Ako dio vaših switcheva podržava jednu verziju, a dio drugu, trebat ćete instalirati novu verziju agenta PE kako bi svi mogli raditi unutar istog SCM sustava.
Sustav Ansible Tower djeluje drugačije jer nema agente, ali sadrži module koji podržavaju Cisco switcheve i sve ostale switcheve. Ova SCM podržava Qubes OS, Linux i 4.NET UTM. Ansible Tower također podržava kontrolere mrežnih pohrana NexentaStore, koji se temelje na jezgru Illumos – open-source operacijskom sustavu temeljenom na Unixu. Ovo je vrlo ograničena podrška, ali Ansible Tower to ipak pruža.
Treći argument, izuzetno važan za mene i našu administraciju, je jednostavnost u učenju. Deset godina sam učio module i manifest koda Puppet, ali Ansible sam svladao u tjedan dana, jer je rad s ovom SCM znatno lakši. Ako pokrećete izvršne datoteke, naravno, ako to ne radite bez potrebe, radit će s razumnim i osjetljivim handlerima. Skripte playbooka, temeljene na YAML-u, karakteriziraju se lakim učenjem i brzinom korištenja. Oni koji nikada prije nisu čuli za YAML mogu jednostavno pročitati skripte i lako razumjeti kako to funkcionira.
Iskreno govoreći, Puppet znatno otežava vaš rad kao programeru jer se oslanja na korištenje Puppet Mastera. To je jedini stroj kojem je dozvoljeno komunicirati s agentima Puppet. Ako unesete bilo kakve promjene u manifest i želite testirati svoj kod, morate prepisati kod za Puppet Master, što znači konfigurirati datoteku Puppet-mastera /etc/hosts za povezivanje svih klijenata i pokrenuti uslugu Puppet Server. Tek nakon toga moći ćete testirati rad mrežne opreme na jednom hostu. To je prilično neugodan postupak.
U Ansible-u je sve puno jednostavnije. Sve što trebate učiniti je razviti kod za stroj koji može komunicirati putem SSH s testiranim hostom. S tim je mnogo lakše raditi.
Sljedeća velika prednost Ansible Towera je mogućnost angažiranja već postojećeg sustava podrške i očuvanja postojeće konfiguracije opreme. Ova SCM bez dodatnih radnji koristi sve dostupne informacije o vašoj infrastrukturi i opremi, virtualnim strojevima, serverima itd. Može komunicirati s vašim RH Satellite serverima, ako ih imate, i pruža integraciju koju nikada nećete dobiti radeći s Puppet-om.
Još jedna važna stvar je detaljna kontrola. Znate da je Puppet modularni sustav, klijent-server aplikacija, stoga trebate definirati postojeće aspekte rada svih vaših strojeva u jednom dugom manifestu. Pri tome, stanje svakog pojedinog elementa sustava treba se testirati svako pola sata – to je zadani period. Tako Puppet funkcionira.
Tower vas oslobađa toga. Možete neograničeno izvršavati razne procese na različitim uređajima, raditi osnovne zadatke, pokretati druge važne procese, postavljati sigurnosne sustave, raditi s bazama podataka. Možete raditi sve ono što je u Puppet Enterprise povezano s određenim poteškoćama. Naime, ako ste izvršili konfiguraciju na jednom hostu, trebat će vremena da se promjene primjene na ostalim hostovima. U Ansibleu sve promjene stupaju na snagu istovremeno.
Na kraju, razmotrimo sigurnosni modul. U Ansible Toweru je implementiran jednostavno nevjerojatno, s velikom preciznošću i pažnjom. Možete davati korisnicima pristup određenim uslugama ili određenim hostovima. Tako postupam i sa svojim zaposlenicima koji su navikli raditi na Windowsima, ograničavajući im pristup Linux ljusci. Osiguravam im takav pristup Toweru da mogu obavljati samo one zadatke i pokretati samo one usluge koje se odnose na njihovu stručnost.
Pogledajmo stvari koje trebate učiniti unaprijed kako biste olakšali prijelaz na Ansible Tower. Prvo je potrebno pripremiti vašu opremu. Ako neki elementi vaše infrastrukture nedostaju u bazi podataka, trebate ih dodati. Postoje sustavi koji ne mijenjaju svoje karakteristike i stoga nedostaju u Puppet bazi podataka, ali ako ih ne unesete tamo prije prijelaza na Tower, izgubit ćete niz prednosti. To može biti „prljava“ preliminarna baza podataka, ali ona bi trebala sadržavati informacije o svemu što imate. Stoga biste trebali napisati dinamički skript za opremu koji će automatski unositi sve promjene infrastrukture u bazu podataka, tako da će Ansible znati koji bi poslužitelji trebali biti u novom sustavu. Nećete morati obavještavati ovaj SCM koji ste poslužitelji dodali i kojih više nema, jer će sve to automatski saznati. Što više podataka bude u bazi podataka, to će Ansible biti korisniji i fleksibilniji. On radi kao da jednostavno skenira stanje opreme iz baze podataka.
Odvojite malo vremena da se upoznate s radom komandne linije u Ansibleu. Pokrenite neke posebne naredbe kako biste provjerili rad skripte za opremu, napišite i pokrenite neke jednostavne, ali korisne playbook skripte, koristite Jinja2 predloške gdje je to prikladno. Pokušajte napisati ulogu i skriptu za složen višestepeni proces, koristeći standardnu, često korištenu konfiguraciju opreme. Igrajte se s tim stvarima, testirajte kako funkcioniraju. Tako ćete naučiti raditi s alatima za izradu knjižnica koje se koriste u Toweru. Već sam spomenuo da mi je priprema za prijelaz trajala oko 3 mjeseca. Mislim da se oslanjajući se na moje iskustvo, to možete napraviti brže. Ne smatrate to izgubljenim vremenom, jer ćete kasnije osjetiti sve prednosti obavljenog posla.
Nakon toga, trebate odrediti što očekujete od Ansible Towera, što točno ovaj sustav treba učiniti za vas.
Trebate li postaviti sustav na praznim uređajima ili praznim virtualnim strojevima? Ili želite zadržati izvorne uvjete rada i postavke postojećih uređaja? To je vrlo važan aspekt rada državnih tvrtki, stoga se morate uvjeriti da ćete moći izvršiti migraciju i implementirati Ansible na postojećoj konfiguraciji. Odredite rutinske administrativne procese koje želite automatizirati. Utvrdite trebate li implementirati specifične aplikacije i usluge na novom sustavu. Sastavite popis onoga što želite učiniti i odredite prioritete.
Zatim, počnite pisati kod skripti i uloga koje će osigurati izvršavanje zadataka koje ste planirali. Grupirajte ih u projekte, logičku kolekciju relevantnih playbook skripti. Svaki projekt će se odnositi na zasebni Git repozitorij ili drugi repozitorij, ovisno o tome koji alat za upravljanje kodom koristite. Možete upravljati playbook skriptama i direktorijima playbooka stavljajući ih ručno u osnovnu putanju projekta na Tower serveru, ili ih pohranjujući u bilo koji sustav upravljanja izvorom (SCM) koji Tower podržava, uključujući Git, Subversion, Mercurial i Red Hat Insights. Unutar jednog projekta možete staviti koliko god želite skripti. Na primjer, stvorio sam jedan osnovni projekt u kojem sam smjestio skriptu za osnovne komponente RedHat, skriptu za osnovu Linuxa i skripte za ostale osnovne pokazatelje. Tako su u jednom projektu bile prisutne razne uloge i skripte koje su se upravljale iz jednog Git repozitorija.
Pokrenite sve te stvari putem naredbenog retka, to je dobar način za provjeru njihove funkcionalnosti. Tako ćete se pripremiti za instalaciju Towera.
Hajde da malo porazgovaramo o transkodiranju Puppet manifesta, jer sam na tome proveo puno vremena dok nisam shvatio što zapravo treba učiniti.
Kao što sam već spomenuo, Puppet pohranjuje sve postavke i parametre opreme u jednom dugom manifestu, a u tom manifestu je pohranjeno sve što ta SCM mora raditi. Tijekom prelaska, ne morate gurnuti sve svoje zadatke u jedan popis, umjesto toga razmislite o strukturi novog sustava: ulogama, scenarijima, oznakama, grupama i što sve to treba obuhvatiti. Neke od autonomnih elemenata mreže treba spojiti u grupe za koje se mogu izraditi scenariji. Složeniji elementi infrastrukture, koji zahtijevaju mnogo resursa, uključujući i autonomne klase, mogu se spojiti u uloge. Prije migracije trebate to razjasniti. Ako kreirate obimne uloge ili scenarije koji ne stanu na jedan ekran, trebate koristiti oznake kako biste mogli uhvatiti pojedine dijelove infrastrukture.
18:00
Malo reklame 🙂
Hvala što ostajete s nama. Sviđa li vam se naše članke? Želite li vidjeti više zanimljivih materijala? Podržite nas narudžbom ili preporučite prijateljima, , jedinstveni analog entry-level servera koji smo razvili za vas: (dostupne opcije s RAID1 i RAID10, do 24 jezgre i do 40GB DDR4).
Dell R730xd je 2 puta jeftiniji u data centaru Equinix Tier IV u Amsterdamu? Samo kod nas u Nizozemskoj! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Pročitajte o tome
Izvor: habr.com
