Menu

Configuratiebeheer in DevOps-praktijken

configuration management devops practices

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is configuratiebeheer in DevOps-praktijken?

Concept van Continu testen in DevOps werd in onze vorige tutorial in detail uitgelegd.

Het belangrijkste hoogtepunt van configuratiemanagement in DevOps is het leveren van,

  1. Infrastructuur als code
  2. Configuratie als een code

Moet doorlezen => Exclusieve DevOps-tutorialserie

beste adblocker voor mac chrome

Configuratiebeheer in DevOps-praktijken

Er zijn tal van voordelen van ‘Infrastructuur als een code’ en ‘Configuratie als een code’ in de DevOps-praktijk.

    • Configuraties zijn versiegestuurd
    • Geautomatiseerd en gestandaardiseerd
    • Verwijdert afhankelijkheid
    • Foutloze infra-instellingen
    • Verbetert de samenwerking tussen Operations en Development-team
    • Configuratiedrift corrigeren
    • Infrastructuur behandelen als een flexibele bron
    • Geautomatiseerde schaalvergroting van infrastructuur
    • Consistentie in de opstellingen behouden

VIDEO Deel 4 Blok 1: Configuratiebeheer- 23 minuten 7 seconden

Vertaling:

In dit deel zullen we meer leren over Configuratiebeheer, releasebeheer en monitoring van applicatieprestaties in DevOps.

Hier, in blok 1, zullen we ons concentreren op configuratiebeheer en begrijpen wat configuratiebeheer is en hoe het verschilt in DevOps en de traditionele methoden.

Laten we om te beginnen weten wat is configuratiebeheer?

Configuratiebeheer, zoals de naam al aangeeft, is niets anders dan het beheren van alle configuraties van de omgevingen waarop de softwaretoepassing host.

Zoals we weten, hebben we verschillende omgevingen in de SDLC in DevOps, te beginnen met het testen van eenheden, integratietests, systeemtests, acceptatietests en testen door eindgebruikers.

En ik heb in mijn eerdere tutorials ook uitgelegd dat de omgeving die voor deze tests is opgezet, steeds complexer zou worden naarmate deze evolueert naar de pre-productie- en productieomgeving.

Configuratiebeheer is dus in feite het geautomatiseerde proces om alle configuraties van elk van deze omgevingen te beheren.

Wat is dan het verschil tussen traditioneel configuratiebeheer en DevOps-configuratiebeheer?

In onze traditionele configuratiebeheermethoden beheerde het team deze configuraties van verschillende omgevingen via formele documentatie, waarbij elk van de configuraties vroeger werd vastgelegd in de documenten en het configuratieteam of de manager die werd gebruikt om de versiebeheer van deze documenten af ​​te handelen.

En als het verandert, neemt hij ook de verantwoordelijkheid voor het opzetten van de omgeving en het manueel beheren van de configuraties

Nu in DevOps zijn al deze configuratiebeheerprocessen doorgaans behoorlijk geautomatiseerd en zijn de configuraties ingekapseld in de vorm van code of scripts en beheerd via de versiebeheertool.

In deze context kunnen we noemen dat het Operations-team is geïntegreerd met Development bij het beheren van de omgevingen via de tool voor enkele versiebeheer.

Het belangrijkste hoogtepunt van configuratiemanagement in DevOps is dus:

      1. Infrastructuur als code
      2. Configuratie als een code

Wat betekent eigenlijk ‘Infrastructuur als een code’? Het definieert de volledige omgevingsdefinitie als een code of een script in plaats van vast te leggen in een formeel document.

Wat houdt de omgevingsdefinitie dan in? Omgevingsdefinitie omvat over het algemeen het opzetten van servers, het configureren van netwerken en het opzetten van andere computerbronnen, die deel uitmaken van de opgezette IT-infrastructuur. Al deze details zouden dus worden weggeschreven als een bestand of in de vorm van een code en ingecheckt in het versiebeheerprogramma.

Dit script of deze code, die wordt ingecheckt in het versiebeheer, zou de enige bron worden voor het definiëren van de omgeving of zelfs het bijwerken van die omgevingen.

Om het simpel te geven Voorbeeld , als we een server aan de specifieke omgeving moeten toevoegen, hoeven we alleen deze informatie bij te werken in de omgevingsscripts en de bezorgingspijplijn uit te voeren, in plaats van handmatig een nieuwe omgeving te gaan en uit te draaien met de toegevoegde server of om te zoeken de hulp van de systeembeheerders om dit te doen.

Het mooie hier is dus dat de ontwikkelaar of tester geen systeembeheerder hoeft te zijn om hun servers in te stellen voor ontwikkelings- of testactiviteiten.

De infrastructuur die in DevOps is opgezet, wordt dus volledig geautomatiseerd en volgt in feite het script dat is ingecheckt voor versiebeheer, beginnend bij het installeren van de servers, het configureren ervan, het installeren van het besturingssysteem, totdat de communicatiekanalen van deze instanties tot stand zijn gebracht met de geïmplementeerde software.

Wat is de configuratie als code?

Configuratie als een code is niets anders dan het definiëren van alle configuraties van de servers of andere bronnen als een code of script en deze in versiebeheer controleren.

Deze configuratiescripts die worden ingecheckt in versiebeheer, worden uitgevoerd als onderdeel van de implementatiepijplijn om de infrastructuur en de bijbehorende configuraties op een geautomatiseerde manier op te zetten.

Het definiëren van configuraties omvat parameters die de aanbevolen instellingen definiëren om de software succesvol te laten werken. Of een reeks opdrachten die in eerste instantie moeten worden uitgevoerd om de softwareapplicatie in te stellen. Of het kunnen zelfs configuraties zijn van elk van de componenten van de software die moeten worden ingesteld, of specifieke gebruikersrollen, gebruikersrechten enz.,

Gemakkelijk Voorbeeld zou zijn om de functie-schakelaars in te stellen, waarbij standaardwaarden worden ingesteld als onderdeel van de configuratieparameter.

Het toevoegen van een andere poort aan een firewall zou een andere zijn Voorbeeld , die kan worden bijgewerkt in het script en later worden deze scripts uitgevoerd als onderdeel van de bezorgingspijplijn.

Er zijn verschillende tools beschikbaar om de infrastructuurautomatisering in de markt uit te voeren. Weinigen van hen zijn Chef, Puppet, Terraform, etc., Chef en Puppet zijn op ruby ​​gebaseerde configuratiebeheertools, terwijl Terraform een ​​provisioning-tool is.

Omdat tegenwoordig bijna alle applicaties worden gehost in de cloud, AWS, bieden ze zelf RESTAPI's aan, die voor dit doel kunnen worden gebruikt.

Ik heb een enorme lijst met voordelen van configuratiebeheer in DevOps, in plaats van de infrastructuur en configuraties als code te definiëren.

Laten we ze een voor een doornemen.

Alle configuraties en infrastructuurdetails zijn versiegestuurd, wat een groot voordeel is bij DevOps-implementatie.

# 1) Dit helpt het team om de wijzigingen aan de servers en configuratie op een geautomatiseerde manier te beheren en helpt om snel te debuggen als er iets mislukt, binnen een korte tijdspanne en maakt het ook mogelijk om snel terug te keren naar de vorige versie, zonder onderbrekingen voor de klanten.

#twee) Omdat deze scripts zich op de centrale server bevinden en iedereen in het team weet wat er in elk van deze scripts staat en wat de wijzigingen zijn die in elk van deze versies zijn aangebracht. Hierdoor kan het team ook teruggaan naar de oudere versie als er een probleem is met de nieuwste versies.

Stel je voor, als er een servercrash is, hoeveel tijd het zou hebben gekost om het handmatig te herstellen. En nu door infrastructuur te definiëren als een script en versiebeheer, kunnen we onmiddellijk herstellen door naar de eerdere versie te gaan.

# 3) Het beheren van de configuraties als een code voorkomt ook dat iemand per ongeluk wijzigingen in het systeem aanbrengt en voorkomt schade die later in de productie ontstaat.

Aangezien het configuratiebeheer volledig geautomatiseerd is, is handmatige tussenkomst voor het instellen of bijwerken volledig geëlimineerd.

Stelt u zich de impact op de kosten, kwaliteit en tijd eens voor toen mensen vroeger afhankelijk waren van menselijke hulpbronnen om deze configuraties handmatig uit te voeren en wanneer bepaalde configuraties werden gemist of niet waren ingesteld zoals vereist.

Automatisering van configuratiemanagement heeft dus niet alleen gezorgd voor tijdwinst, maar ook voor het elimineren van dergelijke menselijke fouten en het verbeteren van de kwaliteit. Ook heeft de coderingsstandaard het team geholpen bij het volgen van de gespecificeerde standaard bij het coderen en automatiseren in plaats van de fantasie te volgen van elk van de persoon die de configuratiegids schrijft.

Zoals eerder besproken, hebben configuraties die als code worden afgeleverd, de afhankelijkheid van één persoon of een team met de naam configuratiemanager of configuratieteam opgeheven. Het ontwikkelteam hoeft niet te wachten tot het configuratieteam komt om een ​​infra- of configuratieprobleem op te lossen.

Of zelfs voor het opzetten van de infra en configuraties, die volledig geautomatiseerd en versiegestuurd zijn. Dus iedereen in het team, of het nu een ontwikkelaar of tester is, kan een server draaien en de configuraties uitvoeren voor hun ontwikkelings- en testdoeleinden. Daarom is het opzetten van de server en configuraties persoononafhankelijk geworden.

Dit zorgt er ook voor dat niet dezelfde servers worden gebruikt door zowel het Development- als het QA-team voor hun activiteiten, wat vroeger over het algemeen het geval was.

Infrastructuur en configuraties gedefinieerd als een gemeenschappelijke code, samen met automatisering en versiebeheer standaardiseren alle omgevingen en instellingen. Dit maakt dus niet alleen de foutopsporingstaak gemakkelijk voor de ontwikkelaars, maar elimineert ook de menselijke fouten die resulteren in foutloze infra-setups, die anders enorme schade zouden veroorzaken als ze niet vroegtijdig worden ontdekt.

Hier zien we duidelijk de duidelijke samenwerking tussen de Dev en Ops, waar ze allebei vertrouwen op één enkele bron voor het uitvoeren van de infra-setup en beide teams actief betrokken zijn bij het automatiseren en opzetten van het volledige configuratiebeheer.

Dit samenwerken om een ​​gemeenschappelijk doel te bereiken, stimuleert de samenwerking tussen zowel de teams, Development als Operations.

Configuratiedrift corrigeren

Wat is configuratiedrift?

Kleine verschillen en inconsistenties tussen de servers, die soms optreden als gevolg van handmatige updates, die zich in de loop van de tijd ophopen, worden configuratiedrift genoemd.

Dit is geen goede situatie, omdat deze inconsistentie in de servers ervoor zorgt dat bepaalde programmabestanden, zoals manifest, playbook, niet betrouwbaar op alle servers draaien en dus leidt tot automatiseringsstoringen. Dit moet dus worden vermeden om ervoor te zorgen dat het team de automatisering van configuraties effectief gebruikt.

Het beheren van infra en config als een code en versiebeheer ervan heeft het team geholpen om elke vorm van configuratie-afwijkingen tussen verschillende omgevingen of tussen dev- en productie-setups te voorkomen of te corrigeren door de configuraties op alle servers consequent te behouden.

Zo kan een team het best verzekerd zijn van vergelijkbare configuratie-instellingen voor de ontwikkelingsopstelling als die van de productie. Dit helpt hen ook om de productieproblemen in de ontwikkelomgeving te simuleren.

Dit helpt dus om elke vorm van onverwachte veranderingen te voorkomen die een van de teamleden zou kunnen proberen uit te voeren op de infra, waardoor de set-up zou kunnen breken en het team ook zou kunnen dwingen om geen wijzigingen aan de set-up aan te brengen, tenzij ze zijn ingelogd als een code naar de repository.

Door de infrastructuur en de configuratie ervan als code te leveren, heeft het team deze kunnen beheren als een flexibele bron om te voldoen aan de dynamische zakelijke behoeften van de klant.

Het is nu een soort plug-and-play. Een team kan specifiek in de betreffende server of netwerk komen en de wijzigingen daarin aanbrengen. Het kan gewoon het updaten van de provisioning-server zijn of het toevoegen of wijzigen van de opslag in een bepaald netwerk, of zelfs het updaten van het besturingssysteem, en alles kan onafhankelijk worden bijgewerkt als een flexibele bron.

Voorheen kostte het wijzigen van één configuratieparameter echt veel tijd, vooral omdat het nodig was om op alle servers bij te werken, maar nu is het slechts één keer. Werk het script bij en upload het naar de versiebeheer-tool en het is allemaal klaar.

Er is een flexibiliteit om de bestaande infrastructuur volledig te schrappen en een nieuwe volledig op te zetten. Het beheer van de infrastructuur en configuraties is nu dus vrij eenvoudig geworden. Welnu, de cloudgebaseerde oplossingen hebben het mogelijk gemaakt de infrastructuur automatisch op te schalen door de benodigde extra computer- of opslagbronnen toe te voegen en te verkleinen wanneer ze niet nodig zijn.

Dit heeft de optimalisatie van het gebruik van hulpbronnen mogelijk gemaakt op basis van de vraag. Als we de infrastructuur willen opschalen door de grootte van de machine te vergroten, kunnen we dat direct doen. Evenzo, als we willen opschalen of misschien een andere setup willen toevoegen, of meer frontends willen toevoegen, kunnen we dit binnen enkele seconden doen door het simpelweg bij te werken in de code en de geautomatiseerde pijplijn uit te voeren.

Als laatste, maar niet de minste, helpt infrastructuur, die als code wordt geleverd onder een gecontroleerde omgeving, bij het handhaven van de consistentie van de omgevingen tussen verschillende opstellingen. Dit helpt ook bij het debuggen van het probleem. Dit punt heb ik eerder ook tot op zekere hoogte behandeld toen ik het had over configuratiedrift.

Dat is het en hiermee is ons gesprek over configuratiebeheer in DevOps voltooid, wat betreft wat is infrastructuur en configuraties als een code en wat zijn de voordelen ervan.

In onze aanstaande tutorial zullen we bespreken de Release Management aspecten in DevOps.

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^