Menú

Gestió de la configuració a les pràctiques de DevOps

configuration management devops practices

Proveu El Nostre Instrument Per Eliminar Problemes

Què és la gestió de la configuració a les pràctiques de DevOps?

Concepte de Proves contínues en DevOps es va explicar amb detall al nostre tutorial anterior.

El més destacat de la gestió de configuracions a DevOps és el lliurament,

  1. La infraestructura com a codi
  2. Configuració com a codi

Heu de llegir-lo => Sèrie de tutorials exclusius de DevOps

Preguntes i respostes d’entrevistes informatica durant 5 anys d’experiència

Gestió de la configuració a les pràctiques de DevOps

A la pràctica de DevOps hi ha nombrosos avantatges de 'Infraestructura com a codi' i 'Configuració com a codi'.

    • Les configuracions estan controlades per versions
    • Automatitzat i estandarditzat
    • Elimina la dependència
    • Instal·lacions d'infracció sense errors
    • Potencia la col·laboració entre l’equip d’Operacions i Desenvolupament
    • Corregint la deriva de configuració
    • Tractar la infraestructura com un recurs flexible
    • Escala automàtica d’infraestructures
    • Mantenir la coherència en les configuracions

VÍDEO Part 4 Bloc 1: Gestió de la configuració- 23 minuts 7 segons

Transcripció:

En aquesta part, coneixerem Gestió de configuracions, gestió de versions i supervisió del rendiment de les aplicacions a DevOps.

Aquí, al bloc 1, ens centrarem en la gestió de la configuració i entendreem què és la gestió de la configuració i en què es diferencia en DevOps i en els mètodes tradicionals.

Per començar, informeu-nos Què és la gestió de configuracions?

La gestió de la configuració, tal com explica el propi nom, no és altra cosa que gestionar totes les configuracions dels entorns que allotja l’aplicació de programari.

Com sabem, tenim diferents entorns al SDLC a DevOps, començant per la prova d’unitat, la prova d’integració, la prova del sistema, la prova d’acceptació i la prova de l’usuari final.

I també he explicat en els meus tutorials anteriors que l’entorn configurat per a aquestes proves es tornaria progressivament més complex a mesura que avança cap a un entorn de preproducció i producció.

Així, bàsicament, la gestió de la configuració és el procés automatitzat per gestionar totes les configuracions de cadascun d’aquests entorns.

Llavors, quina diferència hi ha entre la gestió de configuracions tradicionals i la gestió de configuracions de DevOps?

En els nostres mètodes tradicionals de gestió de configuracions, l’equip solia gestionar aquestes configuracions de diversos entorns mitjançant documentació formal on cadascuna de les configuracions solia enregistrar-se als documents i l’equip de configuració o gestor que s’utilitzava per gestionar el control de versions d’aquests documents.

I quan es produeixin canvis, també assumiria la responsabilitat de configurar l'entorn i gestionar les configuracions manualment

Ara a DevOps, normalment, tots aquests processos de gestió de configuracions estan força automatitzats i les configuracions s’encapsulen en forma de codi o scripts i es controlen mitjançant l’eina de control de versions.

En aquest context, podem anomenar que l’equip d’Operacions s’integra amb el desenvolupament en la gestió dels entorns mitjançant l’eina de control de versió única.

Per tant, el més destacat de la gestió de configuracions a DevOps és el lliurament,

      1. La infraestructura com a codi
      2. Configuració com a codi

Què significa realment 'infraestructura com a codi'? Està definint tota la definició de l’entorn com un codi o un script en lloc de gravar-lo en un document formal.

Llavors, què inclou la definició d’entorn? La definició de l'entorn inclou generalment, la configuració de servidors, la configuració de xarxes i la configuració d'altres recursos informàtics, que formen part de la infraestructura de TI configurada. Per tant, tots aquests detalls s’escriurien com a fitxer o en forma de codi i es comprovarien a l’eina de control de versions.

Aquest script o codi, que es comprova al control de versions, esdevindria l’única font de definició de l’entorn o fins i tot d’actualització d’aquests entorns.

Només per donar un simple Exemple , si hem d'afegir un servidor a l'entorn específic, tot el que faríem és actualitzar aquesta informació als scripts d'entorn i executar la canonada de lliurament, en lloc d'anar manualment i crear un entorn nou amb el servidor afegit o buscar l'ajut dels administradors del sistema per fer-ho.

Per tant, el millor aquí és que el desenvolupador o el comprovador no ha de ser un expert administrador del sistema per configurar els seus servidors per desenvolupar-los o provar-los.

Per tant, la infraestructura configurada a DevOps s’automatitzarà completament i bàsicament segueix l’escript que es registra al control de versions a partir d’instal·lar els servidors, configurar-los, instal·lar el SO, fins que s’estableixin els canals de comunicació d’aquestes instàncies amb el desplegat programari.

Quina és la configuració com a codi?

La configuració com a codi no és altra cosa que definir totes les configuracions dels servidors o qualsevol altre recurs com a codi o script i comprovar-les al control de versions.

Aquests scripts de configuració que es comproven al control de versions s’executen com a part de la canalització de desplegament per configurar la infraestructura i les seves configuracions de manera automatitzada.

Bé, la definició de configuracions inclou paràmetres que defineixen la configuració recomanada perquè el programari s'executi amb èxit. O bé un conjunt d’ordres que s’executaran inicialment per configurar l’aplicació de programari. O fins i tot, podrien ser configuracions de cadascun dels components del programari que s’han d’establir, o rols d’usuari específics, privilegis d’usuari, etc.,

simple Exemple seria configurar els commutadors de funcions, on els valors predeterminats es configuren com a part del paràmetre de configuració.

Afegir un altre port a un tallafoc seria un altre Exemple , que es pot actualitzar a l'script i, posteriorment, aquests scripts s'executen com a part de la canalització de lliurament.

Hi ha diverses eines disponibles per dur a terme l'automatització de la infraestructura al mercat. Poques són Chef, Puppet, Terraform, etc., Chef i Puppet són una eina de gestió de configuracions basades en rubí, mentre que Terraform és una eina de subministrament.

A més, aquests dies, ja que gairebé totes les aplicacions s’allotjaran al núvol, AWS, elles mateixes proporcionen RESTAPI’s, que es poden aprofitar per a aquest propòsit.

Tinc una enorme llista d’avantatges de la gestió de configuracions a DevOps, en lloc de definir la infraestructura i les configuracions com a codi.

Anem a revisar-los un per un.

Totes les configuracions i els detalls de la infraestructura estan controlats per versions, cosa que suposa un gran avantatge en la implementació de DevOps.

# 1) Això ajuda l’equip a gestionar els canvis als servidors i a la configuració de manera automatitzada i ajuda a depurar-se ràpidament si falla alguna cosa, en un lapse de temps curt i també permet tornar ràpidament a la versió anterior, sense causar interrupcions als clients.

# 2) Atès que aquests scripts es troben al servidor central i tothom de l’equip sap què hi ha en cadascun d’aquests scripts i quins són els canvis realitzats en cadascuna d’aquestes versions. Això també permet a l'equip tornar a la versió anterior, si hi ha algun problema a les versions més recents.

Imagineu, si hi ha un bloqueig del servidor, quant de temps hauria trigat a restaurar-lo manualment. I ara, definint la infraestructura com a script i control de versions, podem restaurar immediatament anant a la versió anterior.

# 3) La gestió de les configuracions com a codi també impedeix que algú pugui fer canvis al sistema de manera accidental i evita els danys que puguin produir-se més endavant en la producció.

Atès que la gestió de la configuració està totalment automatitzada, s'elimina completament la intervenció manual per configurar o actualitzar.

Imagineu l’impacte en el cost, la qualitat i el temps quan abans, la gent depenia de recursos humans per dur a terme aquestes configuracions manualment i quan algunes configuracions es perden o no s’estableixen com cal.

Per tant, l’automatització de la gestió de configuracions no només s’ha beneficiat en estalviar temps, sinó també en eliminar aquests errors humans i millorar la qualitat. A més, l'estàndard de codificació ha ajudat l'equip a seguir l'estàndard especificat en codificació i automatització en lloc de seguir la fantasia de cadascuna de les persones que escriu la guia de configuració.

Com s'ha comentat anteriorment, les configuracions que es lliuren com a codi han eliminat la dependència d'una sola persona o d'un equip anomenat administrador de configuració o equip de configuració. L’equip de desenvolupament no ha d’esperar que l’equip de configuració vingui a solucionar cap problema d’infra-configuració.

O fins i tot per configurar infraestructures i configuracions, totalment automatitzades i controlades per versió. Per tant, qualsevol persona de l’equip, ja sigui desenvolupador o provador, pot fer girar un servidor i dur a terme les configuracions per al seu desenvolupament i proves. Per tant, la configuració del servidor i les configuracions ha esdevingut independent de la persona.

Això també garanteix que els equips de desenvolupament i QA no facin servir els mateixos servidors per a les seves activitats, cosa que solia ser anterior.

La infraestructura i les configuracions definides com a codi comú juntament amb l’automatització i el control de versions normalitzen tots els entorns i configuracions. Per tant, això no només fa que la tasca de depuració sigui fàcil per als desenvolupadors, sinó que també elimina els errors humans que donen lloc a configuracions d'infraccions lliures d'errors, que en cas contrari causarien un gran dany si no es detecten abans.

Aquí podem veure clarament la clara col·laboració entre el Dev i Ops, on tots dos confien en una única font per dur a terme la configuració d’infra i els dos equips participen activament en l’automatització i configuració de tota la gestió de la configuració.

El fet de treballar junts per aconseguir un objectiu comú potencia la col·laboració entre els equips, el desenvolupament i les operacions.

Corregint la deriva de configuració

Què és Configuration Drift?

Les petites diferències i inconsistències entre els servidors, que de vegades es produeixen a causa de l’actualització manual, que s’acumula en un període de temps, s’anomenen derivació de la configuració.

Aquesta no és una bona situació, perquè aquesta inconsistència als servidors deixa que determinats fitxers de programa com ara manifest, el llibre de reproducció no s’executin de manera fiable a tots els servidors i, per tant, provoca un error en l’automatització. Per tant, cal evitar-ho per fer que l’equip pugui utilitzar l’automatització de configuracions de manera eficaç.

La gestió d'infra i config com a codi i versió que els controla ha ajudat l'equip a evitar o corregir qualsevol tipus de derivacions de configuració entre diversos entorns o entre configuracions de desenvolupament i producció mantenint les configuracions de manera constant a tots els servidors.

Per tant, un equip pot tenir la millor garantia de configuracions de configuració similars en el desenvolupament configurat com el de la producció. Això també els ajuda a simular els problemes de producció a l'entorn de desenvolupament.

Per tant, això ajuda a evitar qualsevol tipus de canvis inesperats que qualsevol membre de l’equip pugui provar de fer a la infra, cosa que pot trencar la configuració i obligar l’equip a no fer canvis a la configuració tret que estiguin connectats com un codi al dipòsit.

La distribució de la infraestructura i la seva configuració com a codi ha permès a l’equip gestionar-la com a recurs flexible per satisfer les necessitats empresarials dinàmiques del client.

Ara és una mena de plug and play. Un equip pot entrar específicament al servidor o xarxa concret i fer-hi els canvis. Podria ser només actualitzar el servidor de subministrament o afegir o modificar l’emmagatzematge en una xarxa concreta, o fins i tot actualitzar el sistema operatiu, i tot es pot actualitzar independentment com a recurs flexible.

Anteriorment, per canviar un paràmetre de configuració, solia trigar molt de temps, sobretot mentre es requeria actualitzar-lo a tots els servidors, però ara només és un cop d’ull. Actualitzeu l'script i pengeu-lo a l'eina de control de versions i ja està.

Hi ha una flexibilitat per desfer completament la infraestructura existent i crear una altra totalment. Per tant, ara la gestió de la infraestructura i les configuracions s’ha convertit en molt fàcil. Doncs bé, les solucions basades en el núvol han permès que la infraestructura es pugui ampliar automàticament afegint recursos informàtics o d’emmagatzematge addicionals segons sigui necessari i reduint la mida quan no siguin necessaris.

Això ha permès optimitzar l'ús de recursos en funció de la demanda. Si volem ampliar la infraestructura augmentant la mida de la màquina, ho podem fer immediatament. De la mateixa manera, si volem reduir la mida o afegir una altra configuració o afegir més portades, només podem fer-ho en qüestió de segons simplement actualitzant-lo al codi i executant la canonada automatitzada.

La darrera, però no menys important, infraestructura, que es distribueix com a codi en un entorn controlat ajuda a mantenir la coherència dels entorns en diverses configuracions. Això també ajuda a depurar el problema. Aquest punt també ho he tractat anteriorment fins a cert punt mentre parlava de la deriva de la configuració.

Això és tot i això completa la nostra xerrada sobre la gestió de configuracions a DevOps, sobre què és la infraestructura i les configuracions com a codi i quins són els seus avantatges.

Al nostre proper tutorial, en parlarem els aspectes de Gestió de Versions a DevOps.

PREV Tutorial | NEXT Tutorial

Lectura recomanada

^