Meniu

Managementul configurației în practicile DevOps

  • Principal
  • Alte
  • Managementul configurației în practicile DevOps

configuration management devops practices

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Ce este managementul configurației în practicile DevOps?

Conceptul de Testare continuă în DevOps a fost explicat în detaliu în tutorialul nostru anterior.

Aspectul cheie al managementului configurației în DevOps este furnizarea,

  1. Infrastructura ca cod
  2. Configurare ca cod

Trebuie citit => Seria exclusivă de tutoriale DevOps

companii care oferă servicii de cloud computing

Managementul configurației în practicile DevOps

Există numeroase avantaje ale „Infrastructurii ca cod” și „Configurare ca cod” în practica DevOps.

    • Configurările sunt controlate de versiune
    • Automatizat și standardizat
    • Elimină dependența
    • Configurări infra fără erori
    • Stimulează colaborarea între echipa de operațiuni și dezvoltare
    • Corectarea derivei de configurație
    • Tratarea infrastructurii ca o resursă flexibilă
    • Scalare automată a infrastructurii
    • Menținerea consistenței în configurări

VIDEO Partea 4 Blocul 1: Managementul configurației- 23 minute 7 secunde

Transcriere:

În această parte, vom învăța despre Managementul configurației, gestionarea lansărilor și monitorizarea performanței aplicațiilor în DevOps.

Aici, în blocul 1, ne vom concentra pe Managementul configurației și vom înțelege ce este managementul configurației și cum este diferit în DevOps și metodele tradiționale.

Pentru început, să știm Ce este gestionarea configurației?

Gestionarea configurației, așa cum explică și numele, nu este altceva decât gestionarea tuturor configurațiilor mediilor pe care găzduiește aplicația software.

După cum știm, avem medii diferite în cadrul SDLC în DevOps începând cu testarea unității, testarea integrării, testarea sistemului, testarea acceptării și testarea utilizatorului final.

Și, de asemenea, am explicat în tutorialele mele anterioare că mediul configurat pentru aceste teste va deveni progresiv mai complex pe măsură ce se îndreaptă spre mediul de pre-producție și producție.

Deci, practic, gestionarea configurației este procesul automatizat de gestionare a tuturor configurațiilor fiecăruia dintre aceste medii.

Atunci care este diferența dintre managementul configurației tradițional și managementul configurației DevOps?

În metodele noastre tradiționale de gestionare a configurațiilor, echipa obișnuia să gestioneze aceste configurații ale diferitelor medii prin intermediul documentației formale în care fiecare dintre configurațiile obișnuite să fie înregistrate în documente și echipa de configurație sau managerul utilizat pentru controlul versiunii acestor documente.

Și când și când suferă modificări, el și-ar asuma responsabilitatea de a configura mediul și de a gestiona manual configurațiile

Acum, în DevOps, de obicei, toate aceste procese de gestionare a configurațiilor sunt destul de bine automatizate, iar configurațiile sunt încapsulate sub formă de cod sau scripturi și controlate prin instrumentul de control al versiunilor.

În acest context, putem numi că echipa de operațiuni este integrată cu dezvoltarea în gestionarea mediilor prin instrumentul de control al versiunii unice.

Deci, punctul culminant al managementului configurației în DevOps este livrarea,

      1. Infrastructura ca cod
      2. Configurare ca cod

Ce înseamnă de fapt „infrastructură ca și cod”? Acesta definește întreaga definiție a mediului ca un cod sau un script în loc să se înregistreze într-un document formal.

Atunci ce include definiția mediului? Definiția mediului include, în general, configurarea serverelor, configurarea rețelelor și configurarea altor resurse de calcul, care fac parte din infrastructura IT configurată. Deci, toate aceste detalii ar fi scrise ca fișier sau sub formă de cod și verificate în instrumentul de control al versiunilor.

Acest script sau cod, care este verificat în controlul versiunii, ar deveni singura sursă de definire a mediului sau chiar de actualizare a acestor medii.

Doar pentru a da un simplu Exemplu , dacă trebuie să adăugăm un server la mediul specific, tot ceea ce am face este să actualizăm aceste informații în scripturile de mediu și să rulăm conducta de livrare, în loc să mergem manual și să învârtim un mediu nou cu serverul adăugat sau să căutăm ajutorul oamenilor administratori de sistem pentru a face acest lucru.

Deci, frumusețea este că dezvoltatorul sau testerul nu trebuie să fie un expert în administrarea sistemului pentru a-și configura serverele pentru activități de dezvoltare sau testare.

Deci, infrastructura configurată în DevOps va fi complet automatizată și urmează practic scriptul care este verificat pentru controlul versiunii începând de la instalarea serverelor, configurarea acestora, instalarea sistemului de operare, până când canalele de comunicații ale acestor instanțe sunt stabilite odată cu implementarea software.

Care este configurația ca cod?

Configurarea ca cod nu este altceva decât definirea tuturor configurațiilor serverelor sau a oricăror alte resurse ca cod sau script și verificarea acestora în controlul versiunilor.

Aceste scripturi de configurare care sunt verificate în controlul versiunii sunt rulate ca parte a conductei de implementare pentru a configura infrastructura și configurațiile acesteia într-un mod automat.

Ei bine, definirea configurațiilor include parametri care definesc setările recomandate pentru ca software-ul să ruleze cu succes. Sau un set de comenzi care trebuie executate inițial pentru a configura aplicația software. Sau chiar ar putea fi configurații ale fiecăreia dintre componentele software-ului care urmează să fie setate, sau roluri specifice de utilizator, privilegii de utilizator etc.,

Simplu Exemplu ar fi să setați comutarea caracteristicii, unde valorile implicite sunt configurate ca parte a parametrului de configurare.

Adăugarea unui alt port la un firewall ar fi un alt Exemplu , care poate fi actualizat în script și ulterior aceste scripturi sunt rulate ca parte a conductei de livrare.

Sunt disponibile mai multe instrumente pentru realizarea automatizării infrastructurii pe piață. Puțini dintre ei sunt Chef, Puppet, Terraform etc., Chef și Puppet sunt un instrument de gestionare a configurației bazat pe rubin, în timp ce Terraform este un instrument de aprovizionare.

De asemenea, în aceste zile, deoarece aproape toate aplicațiile vor fi găzduite pe cloud, AWS, ele însele oferă RESTAPI, care pot fi pârghiate în acest scop.

Am o listă imensă de avantaje ale gestionării configurațiilor în DevOps, mai degrabă decât să definesc infrastructura și configurațiile ca un cod.

Să le parcurgem pe rând.

Toate configurațiile și detaliile infrastructurii sunt controlate de versiune, ceea ce reprezintă un mare beneficiu în implementarea DevOps.

# 1) Acest lucru ajută echipa să gestioneze automat modificările aduse serverelor și configurației și ajută la depanarea rapidă în cazul în care ceva nu reușește, într-un interval scurt de timp și, de asemenea, permite revenirea rapidă la versiunea anterioară, fără a provoca nicio întrerupere a clienților.

#Două) Întrucât aceste scripturi sunt localizate pe serverul central și toată lumea din echipă știe ce există în fiecare dintre aceste scripturi și care sunt modificările făcute în fiecare dintre aceste versiuni. Acest lucru permite, de asemenea, echipei să revină la versiunea mai veche, dacă există vreo problemă în ultimele versiuni.

Imaginați-vă, dacă există un server de blocare, cât timp ar fi luat pentru a-l restaura manual. Și acum, definind infrastructura ca un script și controlul versiunii, putem restaura imediat accesând versiunea anterioară.

# 3) Gestionarea configurațiilor ca un cod împiedică, de asemenea, pe cineva să efectueze modificări accidentale ale sistemului și previne orice daune cauzate ulterior în producție.

Deoarece gestionarea configurației este complet automatizată, intervenția manuală fie pentru configurare, fie pentru actualizare este complet eliminată.

Imaginați-vă impactul asupra costului, calității și timpului, când mai devreme oamenii depindeau de resursele umane pentru a realiza aceste configurații manual și când anumite configurații sunt omise sau nu sunt setate după cum este necesar.

Deci, automatizarea gestionării configurației a beneficiat nu numai de economisirea timpului, ci și de eliminarea unor astfel de erori umane și îmbunătățirea calității. De asemenea, standardul de codare a ajutat echipa să urmeze standardul specificat în codificare și automatizare, în loc să urmeze fantezia fiecărei persoane care scrie ghidul de configurare.

După cum sa discutat mai devreme, configurațiile care se livrează ca cod au eliminat dependența de o singură persoană sau de o echipă numită manager config sau echipă config. Echipa de dezvoltare nu trebuie să aștepte ca echipa de configurare să vină și să remedieze orice problemă de infra sau de configurare.

Sau chiar și pentru configurarea infra și a configurațiilor, care sunt complet automatizate și controlate de versiune. Deci, oricine din echipă, fie el dezvoltator sau tester, poate învârti un server și poate efectua configurațiile în scopul dezvoltării și testării lor. Prin urmare, configurarea serverului și a configurațiilor a devenit independentă de persoană.

Acest lucru asigură, de asemenea, că aceleași servere nu sunt utilizate atât de echipele de dezvoltare, cât și de echipele de asigurare a calității pentru activitățile lor, ceea ce a fost în general cazul anterior.

Infrastructura și configurațiile definite ca un cod comun împreună cu automatizarea și controlul versiunilor standardizează toate mediile și configurările. Deci, acest lucru nu numai că face sarcina de depanare ușoară pentru dezvoltatori, ci elimină și erorile umane care rezultă în instalări de infracțiuni fără erori, altfel care ar provoca daune uriașe, dacă nu sunt detectate devreme.

Aici, putem vedea în mod clar colaborarea clară dintre Dev și Ops, în care ambii se bazează pe o singură sursă pentru realizarea infrastructurii și ambele echipe sunt implicate activ în automatizarea și configurarea întregului management al configurației.

Această colaborare pentru a atinge un obiectiv comun stimulează colaborarea dintre ambele echipe, dezvoltare și operațiuni.

Corectarea derivei de configurare

Ce este Configuration Drift?

Mici diferențe și neconcordanțe între servere, care uneori se întâmplă din cauza actualizării manuale, care se acumulează într-o perioadă de timp, se numesc deriva de configurare.

Aceasta nu este o situație bună, deoarece această inconsecvență în servere lasă anumite fișiere de program, cum ar fi manifest, playbook să nu ruleze în mod fiabil pe toate serverele și, prin urmare, duce la eșecul automatizării. Deci, acest lucru trebuie evitat pentru ca echipa să utilizeze automat automatizarea configurațiilor în mod eficient.

Gestionarea infra și config ca cod și versiune care le controlează a ajutat echipa să evite sau să corecteze orice fel de derivații de configurație între diferite medii sau între setările de producție și producție, menținând în mod constant configurațiile pe toate serverele.

Astfel, o echipă poate fi asigurată cel mai bine de configurări de configurare similare în dezvoltarea configurată ca cea din producție. Acest lucru îi ajută, de asemenea, să simuleze problemele de producție pe mediul de dezvoltare.

Deci, acest lucru ajută la prevenirea oricărui tip de schimbări neașteptate pe care oricare dintre membrii echipei ar putea încerca să le facă pe infra, ceea ce ar putea întrerupe configurarea și, de asemenea, va impune echipei să nu facă modificări la configurare decât dacă sunt conectați ca un cod către depozit.

Furnizarea infrastructurii și configurarea acesteia ca un cod a permis echipei să o gestioneze ca o resursă flexibilă pentru a satisface nevoile dinamice de afaceri ale clientului.

Este un fel de plug and play acum. O echipă poate intra în mod specific în serverul sau rețeaua respectivă și să le facă modificări. Ar putea fi doar actualizarea serverului de aprovizionare sau adăugarea sau modificarea stocării într-o anumită rețea sau chiar actualizarea sistemului de operare și totul poate fi actualizat independent ca o resursă flexibilă.

Anterior, pentru a schimba un parametru de configurare, obișnuia să dureze mult timp, mai ales când era necesar să se actualizeze pe toate serverele, dar acum este doar o singură încercare. Actualizați scriptul și încărcați-l în instrumentul de control al versiunilor și totul este gata.

Există o flexibilitate de a elimina complet infrastructura existentă și de a aduce complet alta. Deci, gestionarea infrastructurii și a configurațiilor a devenit destul de ușoară acum. Ei bine, soluțiile bazate pe cloud au permis infrastructurii să se extindă automat prin adăugarea resurselor suplimentare de calcul sau de stocare, după cum este necesar și reducerea redusă atunci când acestea nu sunt necesare.

Acest lucru a permis optimizarea utilizării resurselor pe baza cererii. Dacă vrem să extindem infrastructura prin mărirea dimensiunii mașinii, o putem face imediat. În mod similar, dacă dorim să redimensionăm sau să adăugăm o altă configurație sau să adăugăm mai multe front-end-uri, o putem face doar în câteva secunde, pur și simplu actualizând-o în cod și executând conducta automată.

Nu în ultimul rând, infrastructura, livrarea sub formă de cod într-un mediu controlat ajută la menținerea consistenței mediilor în diferite configurări. Acest lucru ajută și la depanarea problemei. Acest punct l-am abordat mai devreme, într-o oarecare măsură, în timp ce vorbeam despre deriva de configurare.

Gata și asta completează discuția noastră despre gestionarea configurației în DevOps, despre ceea ce este infrastructura și configurațiile ca cod și care sunt beneficiile sale.

În viitorul nostru tutorial, vom discuta aspectele Management Release în DevOps.

PREV Tutorial | NEXT Tutorial

Lectură recomandată

^