Meni

Upravljanje konfiguracije v praksi DevOps

  • Glavni
  • Drugo
  • Upravljanje konfiguracije v praksi DevOps

configuration management devops practices

Preizkusite Naš Instrument Za Odpravo Težav

Kaj je upravljanje konfiguracije v praksi DevOps?

Koncept Neprekinjeno testiranje v DevOps je bilo podrobno razloženo v prejšnji vadnici.

Ključni poudarek upravljanja konfiguracije v DevOps je zagotavljanje,

  1. Infrastruktura kot koda
  2. Konfiguracija kot koda

Mora prebrati => Ekskluzivna vadnica DevOps

top 50 sql zapletenih vprašanj za intervju pdf

Upravljanje konfiguracije v praksi DevOps

V praksi DevOps obstajajo številne prednosti „Infrastruktura kot koda“ in „Konfiguracija kot koda“.

    • Konfiguracije so pod nadzorom različice
    • Avtomatizirano in standardizirano
    • Odstrani odvisnost
    • Infra nastavitve brez napak
    • Spodbuja sodelovanje med operativno in razvojno ekipo
    • Popravljanje premika konfiguracije
    • Obravnavanje infrastrukture kot prilagodljivega vira
    • Avtomatizirano skaliranje infrastrukture
    • Ohranjanje doslednosti v nastavitvah

VIDEO 4. del Blok 1: Upravljanje konfiguracije- 23 minut 7 sekund

Prepis:

V tem delu bomo spoznali Upravljanje konfiguracije, upravljanje izdaj in spremljanje delovanja aplikacij v DevOps.

Tu se bomo v bloku 1 osredotočili na upravljanje konfiguracije in razumeli, kaj je upravljanje konfiguracije in kako se razlikuje v DevOpsu in tradicionalnih metodah.

Za začetek povejmo, kaj je upravljanje konfiguracije?

Upravljanje konfiguracij, kot že samo ime razlaga, ni nič drugega kot upravljanje vseh konfiguracij okolij, na katerih gostuje programska aplikacija.

Kot vemo, imamo v okolju SDLC v DevOpsu različna okolja, začenši s preizkušanjem enot, preskušanjem integracije, sistemom, sprejemom in preskusom končnega uporabnika.

V svojih prejšnjih vajah sem tudi pojasnil, da bi okolje, nastavljeno za te teste, postopoma postajalo bolj zapleteno, ko se premika v predprodukcijsko in produkcijsko okolje.

V bistvu je upravljanje konfiguracij avtomatiziran postopek za upravljanje vseh konfiguracij vsakega od teh okolij.

Kakšna je potem razlika med tradicionalnim upravljanjem konfiguracije in upravljanjem konfiguracije DevOps?

V naših tradicionalnih metodah upravljanja konfiguracije je skupina nekoč upravljala te konfiguracije različnih okolij s pomočjo formalne dokumentacije, pri čemer je bila vsaka od konfiguracij zabeležena v dokumentih, konfiguracijska skupina ali upravitelj pa za nadzor različic teh dokumentov.

In ko se spremembe spremenijo, bi prevzel tudi odgovornost za nastavitev okolja in ročno upravljanje konfiguracij

Zdaj so v DevOpsu vsi ti postopki upravljanja konfiguracije precej dobro avtomatizirani, konfiguracije pa so v obliki kode ali skript in nadzorovane z orodjem za nadzor različic.

V tem kontekstu lahko imenujemo, da je operacijska skupina integrirana z razvojem pri upravljanju okolij prek orodja za nadzor ene različice.

Torej, ključni poudarek upravljanja konfiguracije v DevOps je zagotavljanje,

      1. Infrastruktura kot koda
      2. Konfiguracija kot koda

Kaj pravzaprav pomeni „infrastruktura kot koda“? Opredeljuje celotno definicijo okolja kot kodo ali skript, namesto da bi zapisovali v formalni dokument.

Kaj potem vključuje opredelitev okolja? Opredelitev okolja na splošno vključuje, nastavitev strežnikov, konfiguriranje omrežij in nastavitev drugih računalniških virov, ki so del postavljene IT infrastrukture. Vse te podrobnosti bi torej zapisali v datoteko ali v obliki kode in preverili v orodje za nadzor različic.

Ta skript ali koda, ki je preverjena v nadzoru različic, bi postala edini vir določanja okolja ali celo posodobitve teh okolij.

Samo preprosto Primer , če moramo dodati strežnik v določeno okolje, vse, kar bi storili, je, da te podatke posodobimo v skripte okolja in zaženemo dostavni cevovod, namesto da bi ročno odpirali in zavrteli novo okolje z dodanim strežnikom ali iskali pomoč ljudi sistemskega skrbnika za to.

Lepota je torej v tem, da razvijalcu ali preizkuševalcu ni treba biti skrbnik sistemskega skrbnika za nastavitev svojih strežnikov za razvoj ali preizkušanje.

Torej, infrastruktura, nastavljena v DevOps, bo popolnoma avtomatizirana in v bistvu sledi skriptu, ki se prijavi v nadzor različic, vse od namestitve strežnikov, njihove konfiguracije in namestitve operacijskega sistema, dokler se ne vzpostavijo komunikacijski kanali teh primerkov z razporejenim programske opreme.

Kakšna je konfiguracija kot koda?

Konfiguracija kot koda ni nič drugega kot definiranje vseh konfiguracij strežnikov ali drugih virov kot kode ali skripta in njihovo preverjanje v nadzoru različic.

Ti konfiguracijski skripti, ki so preverjeni v nadzoru različic, se izvajajo kot del cevovoda za razmestitev, da se avtomatizirano nastavi infrastruktura in njene konfiguracije.

No, definiranje konfiguracij vključuje parametre, ki določajo priporočene nastavitve za uspešno izvajanje programske opreme. Ali nabor ukazov, ki jih je treba najprej zagnati za nastavitev programske aplikacije. Lahko pa gre tudi za konfiguracije vsake komponente programske opreme, ki jo je treba nastaviti, ali posebne uporabniške vloge, uporabniške privilegije itd.,

Preprosto Primer bi bila nastavitev preklopnih funkcij, pri čemer so privzete vrednosti nastavljene kot del konfiguracijskega parametra.

Če bi požarnemu zidu dodali še eno vrata, bi bilo to še eno Primer , ki ga je mogoče posodobiti v skriptu, pozneje pa se te skripte izvajajo kot del dostavnega traku.

Za izvedbo avtomatizacije infrastrukture na trgu je na voljo več orodij. Le malo jih je Chef, Lutka, Terraform itd., Chef in Lutka so orodje za upravljanje konfiguracij na osnovi rubyja, medtem ko je Terraform orodje za zagotavljanje.

Tudi danes bodo skoraj vse aplikacije gostovane v oblaku, AWS, same pa ponujajo RESTAPI-je, ki jih je mogoče v ta namen izkoristiti.

Imam ogromen seznam prednosti upravljanja konfiguracij v DevOpsu, namesto da definiram infrastrukturo in konfiguracije kot kodo.

Pojdimo skozi enega po enega.

Vse konfiguracije in podrobnosti o infrastrukturi so pod nadzorom različic, kar je velika prednost pri implementaciji DevOps.

# 1) To ekipi pomaga avtomatizirano upravljati spremembe strežnikov in konfiguracije ter pomaga v hitrem odpravljanju napak, če kaj odpove, v kratkem časovnem obdobju in omogoča hiter povratek na prejšnjo različico, ne da bi pri tem povzročal prekinitve strankam.

#two) Ker se ti skripti nahajajo na osrednjem strežniku in vsi v skupini vedo, kaj je v vsaki od teh skript in kakšne spremembe so bile narejene v vsaki od teh različic. To tudi omogoča ekipi, da se vrne na starejšo različico, če je v najnovejših različicah težava.

Predstavljajte si, če pride do zrušitve strežnika, koliko časa bi trajalo, da bi ga ročno obnovili. Zdaj, ko definiramo infrastrukturo kot nadzor skriptov in različic, jo lahko takoj obnovimo s prejšnjo različico.

# 3) Upravljanje konfiguracij kot kode tudi preprečuje, da bi nekdo nenamerno spreminjal sistem in preprečuje škodo, ki bi nastala kasneje v proizvodnji.

Ker je upravljanje konfiguracije popolnoma avtomatizirano, je ročno posredovanje bodisi za nastavitev bodisi za posodobitev popolnoma odpravljeno.

Predstavljajte si vpliv na stroške, kakovost in čas, ko so bili ljudje prej odvisni od človeških virov, da so te konfiguracije izvajali ročno in ko so nekatere konfiguracije zamujene ali niso nastavljene po potrebi.

Torej je avtomatizacija upravljanja konfiguracije koristila ne le prihranku časa, temveč tudi odpravi takšnih človeških napak in izboljšanju kakovosti. Tudi standard kodiranja je ekipi pomagal pri sledenju določenemu standardu pri kodiranju in avtomatizaciji, namesto da bi sledil domišljiji vsake osebe, ki piše konfiguracijski vodnik.

Kot smo že omenili, so konfiguracije, ki so dostavljene kot koda, odstranile odvisnost od ene osebe ali skupine, imenovane config manager ali config team. Razvojni skupini ni treba čakati, da pride skupina za konfiguriranje in odpravi morebitne težave z infra ali konfiguracijo.

Ali celo za nastavitev infrardeče opreme in konfiguracij, ki so popolnoma avtomatizirane in pod nadzorom različic. Torej, kdor koli v skupini, naj bo razvijalec ali preizkuševalec, lahko zavrti strežnik in izvede konfiguracije za svoje razvojne in preizkusne namene. Tako je nastavitev strežnika in konfiguracij postala neodvisna od osebe.

To tudi zagotavlja, da ekipe za razvoj in zagotavljanje kakovosti ne uporabljajo istih strežnikov za svoje dejavnosti, kar je bilo včasih prej.

Infrastruktura in konfiguracije, opredeljene kot skupna koda, skupaj z avtomatizacijo in nadzorom različic standardizirajo vsa okolja in nastavitve. To razvijalcem ne samo olajša naloge za odpravljanje napak, temveč tudi odpravlja človeške napake, ki povzročajo brezhibne infra nastavitve, sicer pa bi lahko povzročile veliko škodo, če ne bi bile odkrite zgodaj.

Tu lahko jasno vidimo jasno sodelovanje med Dev in Ops, kjer se oba za izvajanje infrardeče nastavitve zanašata na en sam vir, obe skupini pa aktivno sodelujejo pri avtomatizaciji in nastavitvi celotnega upravljanja konfiguracije.

To skupno delo za dosego skupnega cilja pospešuje sodelovanje med obema ekipama, razvojem in operacijami.

Popravljanje konfiguracijskega zamaha

Kaj je konfiguracijski premik?

Majhne razlike in nedoslednosti med strežniki, ki se včasih zgodijo zaradi ročne posodobitve, ki se kopiči v določenem obdobju, se imenujejo konfiguracijski zamik.

To ni dobro, ker ta nedoslednost v strežnikih pušča, da nekatere programske datoteke, kot so manifest, playbook, ne delujejo zanesljivo na vseh strežnikih in zato vodijo do okvare avtomatizacije. Temu se je torej treba izogniti, da bi ekipa učinkovito uporabila avtomatizacijo konfiguracij.

Upravljanje infrardečega in konfiguracijskega sistema kot kode in različice, ki ju nadzirata, je ekipi pomagalo, da se je izognilo ali popravilo kakršne koli konfiguracijske premike med različnimi okolji ali med razvojnimi in razvojnimi nastavitvami z doslednim vzdrževanjem konfiguracij na vseh strežnikih.

Tako lahko ekipo najbolje zagotovimo za podobne nastavitve konfiguracije na postavljenem razvoju kot pri proizvodnji. To jim pomaga tudi pri simulaciji produkcijskih težav v okolju razvijalcev.

Torej to pomaga preprečiti kakršne koli nepričakovane spremembe, ki bi jih lahko poskusil narediti kateri koli od članov ekipe na infrardeči povezavi, kar bi lahko prekinilo nastavitev in tudi prisililo ekipo, da ne bo spremenilo nastavitve, razen če so prijavljeni kot kodo v repozitorij.

Zagotavljanje infrastrukture in njene konfiguracije kot kode je skupini omogočilo, da jo upravlja kot prilagodljiv vir, ki ustreza dinamičnim poslovnim potrebam kupca.

To je neke vrste plug and play zdaj. Skupina lahko posebej vstopi v določen strežnik ali omrežje in jih spremeni. Lahko gre le za posodabljanje strežnika za zagotavljanje ali dodajanje ali spreminjanje pomnilnika v določenem omrežju ali celo za posodobitev operacijskega sistema, vse pa je mogoče neodvisno posodobiti kot prilagodljiv vir.

Prej je za spremembo enega konfiguracijskega parametra v resnici vzelo veliko časa, zlasti medtem ko je bilo treba posodobiti vse strežnike, zdaj pa je to samo en korak. Posodobite skript in naložite v orodje za nadzor različic in vse je končano.

Obstaja fleksibilnost za popolno opustitev obstoječe infrastrukture in popolno vzpostavitev druge. Tako je upravljanje infrastrukture in konfiguracij zdaj postalo dokaj enostavno. No, rešitve v oblaku so omogočile, da se je infrastruktura samodejno povečala, tako da je dodala dodatne računalniške ali pomnilniške vire, kot je bilo potrebno, in zmanjšala, ko niso potrebna.

To je omogočilo optimizacijo porabe virov glede na povpraševanje. Če želimo povečati infrastrukturo s povečanjem velikosti stroja, lahko to storimo takoj. Podobno, če želimo razširiti ali morda dodati drugo nastavitev ali dodati več čelnih koncev, lahko to storimo v nekaj sekundah, tako da ga preprosto posodobimo v kodi in zaženemo avtomatiziran cevovod.

In nenazadnje, infrastruktura, ki zagotavlja kot kodo v nadzorovanem okolju, pomaga ohranjati skladnost okolij v različnih nastavitvah. To pomaga tudi pri odpravljanju napak. Tudi to točko sem do neke mere že obravnaval, ko sem govoril o premiku konfiguracije.

To je to in to zaključuje naš pogovor o upravljanju konfiguracije v DevOpsu o tem, kaj je infrastruktura in konfiguracije kot koda in kakšne so njene prednosti.

V naši prihajajoči vadnici bomo razpravljali vidike upravljanja izdaje v DevOps.

PREV Vadnica | NASLEDNJA Vadnica

Priporočeno branje

^