National Environmental Satellite Data Information Service (NESDIS) și-a redus costurile de gestionare a configurației pentru Red Hat Enterprise Linux (RHEL) cu 35% prin migrarea de la Puppet Enterprise la Ansible Tower. În acest videoclip „cum am făcut-o”, inginerul de sisteme Michael Rau explică cazul acestei migrări, împărtășind sfaturi utile și lecții învățate din trecerea de la un SCM la altul.
În acest videoclip vei învăța:
- cum se justifică conducerii fezabilitatea trecerii de la Puppet Enterprise la Ansible Tower;
- ce strategii să folosiți pentru a face tranziția cât mai lină posibil;
- sfaturi pentru transcodarea manifestelor PE în Ansible Playbook;
- Recomandări pentru instalarea optimă a Ansible Tower.
Salutare tuturor, numele meu este Michael Rau, sunt inginer senior de sisteme la ActioNet, care lucrează pentru serviciul NESDIS al Administrației Naționale a Oceanic și Atmosferic (NOAA). Astăzi vom vorbi despre tăierea șirurilor - propria mea experiență de migrare de la Puppet Enterprise la Ansible Tower. Tema acestei prezentări este „să aruncăm o privire la cicatricile mele” rămase după ce am făcut această tranziție la începutul anului. Vreau să împărtășesc ceea ce am învățat prin acest proces. Așa că, atunci când abordezi așa ceva, folosind experiența mea, poți face tranziția fără nicio muncă suplimentară.
Vedeți diapozitive similare cu acesta la începutul fiecărei prezentări la Ansible Fest. Acest slide prezintă istoria automatizării companiei mele. Nu sunt nou în acest sens, deoarece folosesc Puppet/Puppet Enterprise din 2007. Am început să lucrez cu Ansible în 2016 și, la fel ca mulți alți utilizatori ai acestui produs, am fost atras de posibilitatea unor „trucuri” folosind linia de comandă și scripturi simple (playbooks). La sfârșitul anului 2017, mi-am abordat conducerea cu privire la motivele puternice ale mutării la Ansible Tower. Într-un minut vă voi spune despre motivele care m-au determinat să fac acest pas. După ce am primit acordul conducerii, a mai durat câteva luni pentru a finaliza planul și am făcut tranziția în ianuarie-februarie a acestui an. Deci, am abandonat complet Puppet în favoarea lui Ansible și este un lucru grozav.
Ceea ce mă atrage cel mai mult la Ansible este capacitatea de a scrie și de a folosi roluri și manuale. Rolurile sunt excelente pentru a crea sarcini distincte, dar înrudite și pentru a pune toate datele legate de acele sarcini într-un singur loc. Un playbook este o sintaxă YAML, un fișier script care descrie acțiuni pentru una sau mai multe gazde. Le spun utilizatorilor despre aceste caracteristici, în primul rând dezvoltatorilor de software. Ansible Tower vă oferă posibilitatea de a spune „nu, nu aveți acces la shell, dar vă ofer posibilitatea de a rula toate procesele Tower și de a reporni serviciul atunci când aveți nevoie”. Vă voi povesti despre mediul de lucru și echipamentele pe care le folosim.
Acesta este un LAN federal, 7 site-uri fizice conectate prin cloud MPLS, 140 de servere RHEL, dintre care 99% sunt virtuale (vSphere), hardware SuperMicro, stocare în rețea NexentaStore, un set de switch-uri Cisco, Arista și Cumulus și gestionarea unificată a amenințărilor Fortinet UTM instrumente de pe fiecare site.
Rețeaua federală înseamnă că trebuie să folosesc toate măsurile de securitate a informațiilor prevăzute de lege. Trebuie să rețineți că Puppet Enterprise nu acceptă majoritatea hardware-ului pe care îl folosim. Suntem forțați să folosim hardware bugetar deoarece agențiile guvernamentale au probleme în finanțarea acestui articol de cheltuieli. De aceea cumpărăm hardware SuperMicro și ne asamblam echipamentele din piese individuale, a căror întreținere este garantată prin contracte guvernamentale. Folosim Linux și acesta este unul dintre motivele importante pentru a trece la Ansible.
Istoria noastră cu Puppet este următoarea.
În 2007, aveam o rețea mică de 20-25 de noduri, în care am implementat Puppet. Practic, aceste noduri erau doar „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ă, am trecut la PE 2014 în 3.3, făcând o tranziție completă cu o rescriere a manifestului pentru 75 de noduri. Acest lucru trebuia făcut pentru că lui Puppet îi place să schimbe regulile jocului, iar în acest caz au schimbat complet limba. Un an mai târziu, când s-a încheiat suportul pentru versiunea 3 a Puppet Enterprise, am fost forțați să migrăm la PE 2015.2. A trebuit să rescriem din nou manifestul pentru noile servere și să achiziționăm o licență cu o rezervă de 100 de noduri, deși la momentul respectiv aveam doar 85 de noduri.
Au trecut doar 2 ani și a trebuit din nou să muncim mult pentru a migra 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 majore la manifest deoarece noua versiune a limbajului avea o sintaxă diferită de limba versiunii din 2015. Ca urmare, SCM-ul nostru a trecut de la controlul versiunii SVN la Bitbucket (Git). Aceasta a fost „relația” noastră cu Puppet.
Așadar, a trebuit să explic managementului de ce a trebuit să trecem la un CSM diferit folosind următoarele argumente. Primul este prețul ridicat al serviciului. Am vorbit cu băieții de la RedHat și mi-au spus că costul rulării 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ții decât PE. Întrucât suntem o companie de stat finanțată de la bugetul federal, acesta este un argument destul de puternic.
Al doilea argument este versatilitatea. Puppet acceptă doar hardware-ul care are un agent Puppet. Aceasta înseamnă că un agent trebuie să fie instalat pe toate comutatoarele și trebuie să fie cea mai recentă versiune. Și dacă unele dintre comutatoarele dvs. acceptă o versiune, iar unele acceptă alta, va trebui să instalați o nouă versiune a agentului PE pe ele, astfel încât să poată funcționa toate în același sistem SCM.
Sistemul Ansible Tower funcționează diferit, deoarece nu are agenți, dar are module care acceptă comutatoarele Cisco și toate celelalte comutatoare. Acest SCM acceptă Qubes OS, Linux și 4.NET UTM. Ansible Tower acceptă, de asemenea, controlere de stocare în rețea NexentaStore bazate pe nucleul Illumos, un sistem de operare open-source bazat pe Unix. Acesta este foarte puțin suport, dar Ansible Tower o face oricum.
Al treilea argument, care este foarte important atât pentru mine, cât și pentru administrația noastră, este ușurința în utilizare. Am petrecut 10 ani stăpânind modulele Puppet și codul manifest, dar am învățat Ansible într-o săptămână, deoarece acest SCM este mult mai ușor de lucrat. Dacă rulați fișiere executabile, desigur, cu excepția cazului în care faceți acest lucru în mod inutil, atunci manevrei inteligenți și receptivi lucrează cu ele. Registrele bazate pe YAML sunt ușor de învățat și rapid de utilizat. Cei care nu au auzit niciodată de YAML înainte pot citi pur și simplu scripturile și pot înțelege cu ușurință cum funcționează.
Sincer să fiu, Puppet vă face munca de dezvoltator mult mai dificilă, deoarece se bazează pe utilizarea Puppet Master. Este singura mașină autorizată să comunice cu agenții Puppet. Dacă ați făcut modificări manifestului și doriți să vă testați codul, trebuie să rescrieți codul pentru Puppet Master, adică să configurați fișierul Puppet Master /etc/hosts pentru a conecta toți clienții și a porni serviciul Puppet Server. Numai după aceasta veți putea testa funcționarea echipamentelor de rețea pe o singură gazdă. Aceasta este o procedură destul de dureroasă.
Totul este mult mai simplu în Ansible. Tot ce trebuie să faceți este să dezvoltați cod pentru o mașină care poate comunica prin SSH cu gazda testată. Este mult mai ușor de lucrat cu asta.
Următorul mare avantaj al Ansible Tower este capacitatea de a vă valorifica sistemul de asistență existent și de a vă menține configurația hardware existentă. Acest SCM folosește toate informațiile disponibile despre infrastructura și hardware-ul dvs., mașinile virtuale, servere etc. fără pași suplimentari. Poate vorbi cu serverele dumneavoastră RH Satellite, dacă aveți unul, și vă oferă integrări pe care nu le veți obține niciodată cu Puppet.
Un alt lucru 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 tuturor mașinilor dumneavoastră într-un singur manifest lung. În acest caz, 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 te salvează de asta. Puteți rula o varietate de procese pe o varietate de echipamente fără restricții; puteți efectua lucrări de bază, puteți rula alte procese importante, puteți configura un sistem de securitate și puteți lucra cu baze de date. Puteți face tot ce este dificil în Puppet Enterprise. Deci, dacă l-ați configurat pe o singură gazdă, va dura timp până când modificările vor avea efect asupra gazdelor rămase. În Ansible, toate modificările intră în vigoare în același timp.
În cele din urmă, să ne uităm la modulul de securitate. Ansible Tower îl implementează pur și simplu uimitor, cu mare precizie și grijă. Puteți acorda utilizatorilor acces la anumite servicii sau la anumite gazde. Fac asta cu angajații mei care sunt obișnuiți să lucreze pe Windows, limitându-le accesul la shell-ul Linux. Mă asigur că au acces la Tower, astfel încât să poată face doar munca și să ruleze numai serviciile care sunt relevante pentru ei.
Să ne uităm la lucrurile pe care trebuie să le faci din timp pentru a face tranziția la Ansible Tower mai ușoară. În primul rând, trebuie să vă pregătiți echipamentul. Dacă unele elemente ale infrastructurii dvs. nu sunt deja în baza de date, trebuie să le adăugați acolo. Există sisteme care nu își schimbă caracteristicile și, prin urmare, nu se află în baza de date Puppet, dar dacă nu le adaugi acolo înainte de a te muta în Tower, vei pierde o serie de avantaje. Aceasta poate fi o bază de date preliminară „murdară”, dar ar trebui să conțină informații despre toate echipamentele pe care le aveți. Prin urmare, ar trebui să scrieți un script hardware dinamic care va împinge automat toate modificările de infrastructură în baza de date, apoi Ansible va ști ce gazde ar trebui să fie prezente pe noul sistem. Nu va trebui să spuneți acestui SCM ce gazde ați adăugat și ce gazde nu mai există, deoarece va ști toate acestea automat. Cu cât există mai multe date în baza de date, cu atât Ansible va fi mai util și mai flexibil. Funcționează ca și cum ar citi pur și simplu codul de bare de stare hardware dintr-o bază de date.
Petreceți ceva timp familiarizandu-vă cu linia de comandă din Ansible. Rulați câteva comenzi personalizate pentru a testa scriptul hardware, scrieți și rulați câteva scripturi simple, dar utile, folosiți șabloane Jinja2 acolo unde este cazul. Încercați să scrieți un rol și un script pentru un proces complex, în mai mulți pași, folosind o configurație hardware comună, întâlnită frecvent. Joacă-te cu aceste lucruri, testează cum funcționează. În acest fel, veți învăța cum să utilizați instrumentele de creare a bibliotecii utilizate în Tower. Am spus deja că mi-a luat vreo 3 luni să mă pregătesc pentru tranziție. Cred că, pe baza experienței mele, vei putea face asta mai repede. Nu considera acest timp pierdut, pentru ca mai tarziu vei experimenta toate beneficiile muncii depuse.
În continuare, trebuie să decideți la ce vă așteptați de la Ansible Tower, ce anume ar trebui să facă acest sistem pentru dvs.
Trebuie să implementați sistemul pe hardware complet, pe mașini virtuale goale? Sau doriți să mențineți condițiile și setările originale de funcționare ale echipamentelor existente? Acesta este un aspect foarte important pentru companiile publice, așa că trebuie să fiți sigur că veți putea migra și implementa Ansible pe configurația dvs. existentă. Identificați procesele administrative de rutină pe care doriți să le automatizați. Aflați dacă trebuie să implementați anumite aplicații și servicii pe noul sistem. Faceți o listă cu ceea ce doriți să faceți și acordați-o prioritate.
Apoi începeți să scrieți codul de script și rolurile care vor permite sarcinile pe care intenționați să le finalizați. Combină-le în Projects, o colecție logică de manuale relevante. Fiecare proiect va aparține unui depozit Git separat sau unui depozit diferit, în funcție de managerul de cod pe care îl utilizați. Puteți gestiona scripturile de playbook și directoarele playbook-ului plasându-le manual în Project Base Path pe serverul Tower sau plasând playbook-ul în orice sistem de gestionare a codului sursă (SCM) acceptat de Tower, inclusiv Git, Subversion, Mercurial și Red Hat. Perspective. În cadrul unui proiect puteți plasa câte scripturi doriți. De exemplu, am creat un proiect de bază în care am plasat un script pentru elementele de bază RedHat, un script pentru nucleul Linux și scripturi pentru restul liniilor de bază. Astfel, într-un proiect au existat o varietate de roluri și scenarii care au fost gestionate dintr-un singur depozit Git.
Rularea tuturor acestor lucruri prin linia de comandă este o modalitate bună de a le testa funcționalitatea. Acest lucru vă va pregăti pentru instalarea Tower.
Să vorbim puțin despre transcodarea manifestului Puppet, pentru că am petrecut mult timp pe asta până mi-am dat seama ce trebuie de fapt făcut.
După cum am spus mai devreme, Puppet stochează toate setările și opțiunile hardware într-un singur manifest lung, iar acest manifest stochează tot ce ar trebui să facă acest SCM. Când faceți tranziția, nu trebuie să vă înghesuiți toate sarcinile într-o singură listă; în schimb, gândiți-vă la structura noului sistem: roluri, scripturi, etichete, grupuri și ce ar trebui să meargă acolo. Unele dintre elementele rețelei autonome ar trebui grupate în grupuri pentru care pot fi create scripturi. Elementele de infrastructură mai complexe care implică un număr mare de resurse, inclusiv clase autonome, pot fi combinate în roluri. Înainte de a migra, trebuie să decideți asupra acestui lucru. Dacă creați roluri mari sau scenarii care nu se potrivesc pe un ecran, ar trebui să utilizați etichete pentru a putea captura anumite părți ale infrastructurii.
18:00
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com