Serviciul Național de Informații Satelitar al Datelor de Mediu (NESDIS) a redus cheltuielile cu 35% pentru gestionarea configurației Red Hat Enterprise Linux (RHEL), trecând de la Puppet Enterprise la Ansible Tower. În acest video din categoria „cum am făcut asta”, inginerul sistemului Michael Rau justifică efectuarea acestei migrații, oferind sfaturi utile și experiența acumulată în urma trecerii de la un SCM la altul.
Din acest video veți afla:
- cum să justificați conducerea privind oportunitatea tranziției de la Puppet Enterprise la Ansible Tower;
- ce strategii să folosiți pentru a face tranziția cât mai lină;
- sfaturi pentru transcodarea manifestelor PE în Ansible Playbook;
- recomandări pentru instalarea optimă a Ansible Tower.
Salut tuturor, mă numesc Michael Rau, sunt inginer sistem senior la ActioNet, care lucrează pentru Administrația Națională Oceanică și Atmosferică (NOAA) în cadrul serviciului NESDIS. Astăzi vom vorbi despre tăierea firelor – propria mea experiență în migrarea de la Puppet Enterprise la Ansible Tower. Tema acestei prezentări este să „ne uităm la cicatricile mele”, lăsate după ce am efectuat această tranziție la începutul anului. Vreau să împărtășesc ce am învățat pe parcursul acestui proces. Așa că, atunci când vă implicați în așa ceva, folosind experiența mea, veți putea realiza tranziția fără niciun efort inutil.
Veți vedea slide-uri asemănătoare cu acesta la începutul fiecărei prezentări de la Ansible Fest. Acest slide conturează povestea automatizării companiei mele. Nu sunt nou în acest domeniu, deoarece folosesc Puppet/Puppet Enterprise din 2007. Am început să lucrez cu Ansible din 2016 și, ca mulți alți utilizatori ai acestui produs, am fost atras de posibilitățile „trucurilor” prin intermediul liniei de comandă și a scenariilor simple (playbooks). La sfârșitul anului 2017, am discutat cu conducerea mea despre motivele serioase pentru a trece la Ansible Tower. Într-o minută voi vorbi despre motivele care m-au determinat să fac acest pas. După ce am obținut aprobarea conducerii, au mai trecut câteva luni pentru a implementa planul, iar eu am realizat tranziția în ianuarie-februarie a acestui an. Așadar, am renunțat complet la Puppet în favoarea Ansible, și este ceva extraordinar.
Ceea ce mă atrage cel mai mult la Ansible este posibilitatea de a scrie și utiliza roluri (roles) și scenarii (playbooks). Rolurile sunt excelente pentru a crea sarcini (tasks) diverse, dar interconectate, și pentru a plasa toate datele referitoare la aceste sarcini într-un singur loc. Playbook-ul este un fișier de tip YAML, un scenariu care descrie acțiuni pentru unul sau mai multe gazde. Le explic aceste funcționalități utilizatorilor, în special dezvoltatorilor de software. Ansible Tower oferă posibilitatea de a spune: „nu, nu ai acces la shell, dar îți ofer posibilitatea de a lansa toate procesele Tower și de a reporni serviciul când ai nevoie.” Voi vorbi despre mediu de lucru și echipamentele utilizate.
Aceasta este o rețea LAN federală, cu 7 site-uri fizice conectate prin MPLS cloud, 140 de servere RHEL, 99% dintre acestea fiind virtuale (vSphere), hardware SuperMicro, stocare de rețea NexentaStore, un set de switch-uri Cisco, Arista și Cumulus și soluții de management unificat pentru amenințări Fortinet UTM pe fiecare site.
Rețeaua federală înseamnă că trebuie să folosesc toate mijloacele de protecție a informațiilor prevăzute de legislație. Trebuie să ai în vedere că Puppet Enterprise nu suportă majoritatea echipamentelor utilizate de noi. Suntem nevoiți să utilizăm hardware de buget, deoarece structurile guvernamentale se confruntă cu probleme de finanțare în acest sens. De aceea, achiziționăm „hardware” de clasă SuperMicro și ne construim echipamentele din componente separate, a căror întreținere este garantată prin contracte guvernamentale. Folosim Linux, iar aceasta este una dintre motivele importante pentru tranziția la Ansible.
Povestea noastră cu Puppet este următoarea.
În 2007 aveam o mică rețea de 20-25 de noduri, unde am implementat Puppet. În principal, aceste noduri erau pur și simplu „cutii” RedHat. În 2010, am început să folosim interfața web Puppet Dashboard pentru 45 de noduri. Pe măsură ce rețeaua a continuat să se extindă, în 2014 am trecut la PE 3.3, efectuând o migrare completă cu rescrierea manifestului pentru 75 de noduri. A fost necesar, deoarece Puppet îi place să schimbe regulile jocului, iar în acest caz au schimbat complet limbajul. Un an mai târziu, când suportul pentru versiunea 3 a Puppet Enterprise a încetat, a trebuit să migrăm la PE 2015.2. A fost necesar din nou să rescriem manifestul pentru noile servere și să achiziționăm o licență cu un plus pentru 100 de noduri, deși la acel moment aveam doar 85 de noduri.
Au trecut doar 2 ani și a trebuit din nou să facem o migrare semnificativă la noua versiune PE 2016.4. Am cumpărat o licență pentru 300 de noduri, având doar 130. Din nou, a trebuit să facem modificări importante în manifest, deoarece noua versiune a limbajului avea o sintaxă diferită de cea a versiunii 2015. În cele din urmă, SCM-ul nostru a trecut de la sistemul de control al versiunilor SVN la Bitbucket (Git). Asta au fost „relațiile” noastre cu Puppet.
Așadar, a trebuit să explic conducerii de ce trebuie să trecem la un alt SCM, folosind următoarele argumente. Primul - costul ridicat al serviciului. Am discutat cu reprezentanți de la RedHat, iar aceștia au spus că costul întreținerii unei rețele de 300 de noduri cu Ansible Tower este jumătate din costul Puppet Enterprise. Dacă achiziționați și Ansible Engine, costul va fi aproximativ același, dar veți obține mult mai multe funcționalități decât cu PE. Deoarece suntem o companie de stat finanțată din bugetul federal, acesta este un argument destul de solid.
Al doilea argument este versatilitatea. Puppet suportă doar echipamentele pe care este instalat agentul Puppet. Asta înseamnă că pe toate switch-urile trebuie să fie instalat agentul, iar acesta trebuie să fie de ultima versiune. Și dacă o parte din switch-uri suportă o versiune, iar alte switch-uri suportă alta, va fi necesar să instalați pe ele noua versiune a agentului PE, astfel încât toate să poată funcționa într-un singur sistem SCM.
Sistemul Ansible Tower funcționează diferit, deoarece nu are agenți, dar are module care suportă switch-urile Cisco și toate celelalte switch-uri. Această SCM suportă Qubes OS, Linux și 4.NET UTM. Ansible Tower suportă, de asemenea, controlerele de stocare a rețelei NexentaStore, bazate pe nucleul Illumos – un sistem de operare open-source bazat pe Unix. Aceasta este o suport foarte limitat, dar Ansible Tower îl oferă totuși.
Al treilea argument, foarte important atât pentru mine, cât și pentru administrația noastră, este ușurința în învățare. Am învățat modulele și codul manifestelor Puppet timp de 10 ani, dar am studiat Ansible într-o săptămână, deoarece este mult mai ușor de utilizat această SCM. Dacă rulezi fișiere executabile, desigur, dacă nu o faci fără nevoie, atunci cu ele lucrează gestionare rezonabile și receptive. Scripturile playbooks, bazate pe YAML, se caracterizează printr-o învățare ușoară și o utilizare rapidă. Cei care nu au auzit niciodată de YAML pot pur și simplu să citească scripturile și să înțeleagă ușor cum funcționează.
Sincer, Puppet complică foarte mult munca ta ca dezvoltator, deoarece se bazează pe utilizarea Puppet Master. Aceasta este singura mașină care are dreptul să comunice cu agenții Puppet. Dacă ai făcut vreo modificare în manifest și vrei să testezi codul tău, trebuie să rescrii codul pentru Puppet Master, adică să configurezi fișierul Puppet-master /etc/hosts pentru a conecta toți clienții și să pornești serviciul Puppet Server. Numai după aceea poți testa funcționarea echipamentului de rețea pe un singur host. Este o procedură destul de dureroasă.
În Ansible, totul este mult mai simplu. Tot ce trebuie să faci este să dezvolți cod pentru o mașină care poate comunica prin protocol SSH cu host-ul de testat. Este mult mai ușor de utilizat.
Următorul mare avantaj al Ansible Tower este posibilitatea de a utiliza sistemul de suport pe care îl ai deja și de a păstra configurația existentă a echipamentului. Această SCM folosește fără nicio acțiune suplimentară toate informațiile disponibile despre infrastructura ta și echipamente, mașini virtuale, servere etc. Poate comunica cu serverele tale RH Satellite, dacă le ai, și îți oferă o integrare pe care nu o vei obține niciodată lucrând cu Puppet.
O altă problemă importantă este controlul detaliat. Știți că Puppet este un sistem modular, este o aplicație client-server, așa că trebuie să definiți aspectele existente ale funcționării tuturor mașinilor dumneavoastră într-un singur manifest lung. În plus, starea fiecărui element individual al sistemului trebuie testată la fiecare jumătate de oră – aceasta este perioada implicită. Așa funcționează Puppet.
Tower vă scapă de această problemă. Puteți executa fără restricții cele mai variate procese pe diferite echipamente, puteți efectua lucrări esențiale, rula alte procese importante, configura sistemul de securitate, lucra cu baze de date. Puteți face tot ce în Puppet Enterprise este legat de dificultăți specifice. Așadar, dacă ați realizat configurația pe un host, va fi nevoie de timp pentru ca modificările să aibă efect pe celelalte host-uri. În Ansible, toate modificările intră în vigoare simultan.
În cele din urmă, să examinăm modul de securitate. În Ansible Tower, acesta este implementat într-un mod uimitor, cu o mare precizie și atenție. Puteți oferi utilizatorilor acces la servicii specifice sau la anumite host-uri. Eu procedez astfel cu angajații mei, care sunt obișnuiți să lucreze pe Windows, limitându-le accesul la shell-ul Linux. Le ofer un astfel de acces la Tower, încât să poată efectua doar acele sarcini și să ruleze doar acele servicii care țin de competența lor.
Să luăm în considerare lucrurile pe care trebuie să le faceți înainte de a facilita tranziția la Ansible Tower. În primul rând, trebuie să vă pregătiți echipamentele. Dacă anumite elemente ale infrastructurii dvs. lipsesc în baza de date, trebuie adăugate acolo. Există sisteme care nu își modifică caracteristicile și, prin urmare, lipsesc din baza de date Puppet, dar dacă nu le aduceți acolo înainte de tranziția la Tower, veți pierde o serie de avantaje. Aceasta poate fi o bază de date „brută” preliminară, dar trebuie să conțină informații despre tot echipamentul pe care îl aveți. Prin urmare, ar trebui să scrieți un script dinamic pentru echipamente, care să aducă automat toate modificările infrastructurii în baza de date, astfel încât Ansible să știe ce gazde ar trebui să existe în noul sistem. Nu va trebui să informați această SCM despre ce gazde ați adăugat și care gazde nu mai există, deoarece toate acestea le va învăța automat. Cu cât mai multe date vor fi în baza de date, cu atât Ansible va fi mai util și mai flexibil. Lucrează ca și cum ar citi pur și simplu din baza de date codul de bare al stării echipamentului.
Petreceți ceva timp familiarizându-vă cu funcționarea liniei de comandă în Ansible. Rulați câteva comenzi speciale pentru a verifica funcționarea scriptului pentru echipamente, scrieți și rulați câteva scenarii playbook simple, dar utile, folosiți șabloane Jinja2 acolo unde este cazul. Încercați să scrieți un rol și un scenariu pentru un proces complex în mai multe etape, folosind o configurație standard, des întâlnită a echipamentului. Jucați-vă cu aceste lucruri, testați cum funcționează. Astfel, veți învăța cum să utilizați instrumentele pentru a crea bibliotecile care sunt folosite în Tower. Am spus deja că pregătirea mea pentru tranziție a durat aproximativ 3 luni. Cred că, bazându-vă pe experiența mea, veți reuși să faceți asta mai repede. Nu considerați acest timp pierdut, deoarece mai târziu veți simți toate avantajele muncii realizate.
Apoi, trebuie să decideți ce așteptați de la Ansible Tower, ce anume ar trebui să facă acest sistem pentru dvs.
Aveți nevoie de desfășurarea unui sistem pe echipamente goale, pe mașini virtuale goale? Sau doriți să păstrați condițiile inițiale de funcționare și configurația echipamentelor existente? Acesta este un aspect foarte important pentru activitatea companiilor de stat, așa că trebuie să fiți siguri că veți putea efectua migrarea și desfășura Ansible pe configurația existentă. Definiți procesele administrative de rutină pe care doriți să le automatizați. Clarificați dacă aveți nevoie să desfășurați aplicații și servicii specifice pe noul sistem. Elaborați o listă cu ceea ce doriți să faceți și ordonați prioritățile.
Apoi, începeți să scrieți codul scripturilor și rolurilor care vor asigura îndeplinirea sarcinilor planificate de dumneavoastră. Combinați-le în Projects, o colecție logică a scripturilor playbook corespunzătoare. Fiecare Project va corespunde unui depozit Git separat sau altui depozit, în funcție de managerul de cod pe care îl utilizați. Puteți gestiona scripturile playbook și directoarele playbook, plasându-le manual în Project Base Path pe serverul Tower sau plasând playbook în orice sistem de gestionare a codului sursă (SCM) acceptat de Tower, inclusiv Git, Subversion, Mercurial și Red Hat Insights. În interiorul unui singur Project, puteți plasa câte scripturi doriți. De exemplu, am creat un Project de bază, în care am plasat un script pentru elementele de bază RedHat, un script pentru baza Linux, scripturi pentru celelalte metrici de bază. Astfel, într-un singur proiect erau prezente cele mai diverse roluri și scripturi, gestionate dintr-un singur depozit Git.
Rulați toate aceste lucruri prin linia de comandă, este o modalitate bună de a verifica funcționalitatea lor. Astfel, vă veți pregăti pentru instalarea Tower.
Hai să discutăm puțin despre transcodificarea manifestului Puppet, deoarece am petrecut mult timp cu asta, până nu mi-am dat seama ce este cu adevărat necesar să fac.
Așa cum am spus, Puppet stochează toate setările și parametrii hardware-ului într-un singur manifest lung, iar în acest manifest se află tot ceea ce trebuie să facă acest SCM. Când faceți migrarea, nu trebuie să introduceți toate sarcinile într-o singură listă; în schimb, gândiți-vă la structura noului sistem: roluri, scenarii, etichete, grupuri și ceea ce ar trebui să includă. Unele dintre elementele autonome ale rețelei ar trebui grupate în grupuri pentru care pot fi create scenarii. Elementele mai complexe ale infrastructurii, care implică un număr mare de resurse, inclusiv clasele autonome, pot fi integrate în roluri. Înainte de migrare, trebuie să clarificați acest lucru. Dacă creați roluri sau scenarii voluminoase, care nu se încadrează pe un singur ecran, ar trebui să folosiți etichete pentru a putea capta părți individuale ale infrastructurii.
18:00
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
