Menu

Konfigurationsstyring i DevOps-praksis

configuration management devops practices

Prøv Vores Instrument Til At Fjerne Problemer

Hvad er konfigurationsstyring i DevOps-praksis?

Begrebet Kontinuerlig test i DevOps blev forklaret detaljeret i vores tidligere tutorial.

Det vigtigste højdepunkt i konfigurationsstyring i DevOps er at levere,

  1. Infrastruktur som kode
  2. Konfiguration som en kode

Skal læse igennem => Eksklusiv DevOps tutorial-serie

hvad er forskellen mellem testplan og teststrategi

Konfigurationsstyring i DevOps-praksis

Der er adskillige fordele ved 'Infrastruktur som kode' og 'Konfiguration som kode' i DevOps-praksis.

    • Konfigurationer er versionskontrollerede
    • Automatiseret og standardiseret
    • Fjerner afhængighed
    • Fejlfri infra opsætninger
    • Øger samarbejdet mellem Operations og Development team
    • Korrigering af konfigurationsdrift
    • Behandling af infrastruktur som en fleksibel ressource
    • Automatiseret skalering af infrastruktur
    • Opretholdelse af konsistens i opsætningerne

VIDEO Del 4 Blok 1: Konfigurationsstyring- 23 minutter og 7 sekunder

Udskrift:

I denne del vil vi lære om Konfigurationsstyring, Release management og Application Performance Monitoring i DevOps.

Her i blok 1 vil vi fokusere på Configuration Management og forstå, hvad der er konfigurationsstyring, og hvordan er det anderledes i DevOps og de traditionelle metoder.

Lad os starte med at vide, hvad der er konfigurationsstyring?

Konfigurationsstyring, som navnet selv forklarer, er intet andet end at styre alle de konfigurationer af de miljøer, som softwareapplikationen er vært for.

Som vi ved, har vi forskellige miljøer i hele SDLC i DevOps startende med enhedstest, integrationstest, systemtest, accepttest og slutbrugertest.

Og jeg har også forklaret i mine tidligere tutorials, at det miljø, der er indstillet til disse tests, gradvist vil blive mere komplekst, når det bevæger sig mod præproduktion og produktionsmiljø.

Så grundlæggende er konfigurationsstyring den automatiserede proces til at styre alle konfigurationer i hvert af disse miljøer.

Hvad er så forskellen mellem traditionel konfigurationsstyring og DevOps konfigurationsstyring?

I vores traditionelle konfigurationsstyringsmetoder brugte teamet til at administrere disse konfigurationer i forskellige miljøer via formel dokumentation, hvor hver af de konfigurationer, der tidligere blev registreret i dokumenterne, og konfigurationsteamet eller manager, der bruges til at håndtere versionskontrol af disse dokumenter.

Og når og når det gennemgår ændringer, ville han også tage ansvaret for at opsætte miljøet og styre konfigurationerne manuelt

Nu i DevOps er alle disse konfigurationsstyringsprocesser typisk ret godt automatiserede, og konfigurationerne er indkapslet i form af kode eller scripts og styres gennem versionskontrolværktøjet.

I denne sammenhæng kan vi kalde, at Operations-teamet er integreret med Udvikling i styring af miljøerne gennem kontrolværktøjet til den ene version.

Så det vigtigste højdepunkt i konfigurationsstyring i DevOps er at levere,

      1. Infrastruktur som kode
      2. Konfiguration som en kode

Hvad betyder egentlig 'infrastruktur som, som en kode'? Det definerer hele miljødefinitionen som en kode eller et script i stedet for at optage i et formelt dokument.

Hvad inkluderer så miljødefinition? Miljødefinition inkluderer generelt, opsætning af servere, konfiguration af netværk og opsætning af andre computerressourcer, som er en del af den oprettede it-infrastruktur. Så alle disse detaljer ville blive skrevet ud som en fil eller i form af en kode og kontrolleret i versionskontrolværktøjet.

Dette script eller kode, som kontrolleres i versionskontrollen, bliver den eneste kilde til at definere miljøet eller endda opdatere disse miljøer.

Bare for at give en simpel Eksempel , hvis vi er nødt til at tilføje en server til det specifikke miljø, er alt, hvad vi ville gøre, at opdatere disse oplysninger i miljøscriptene og køre leveringsrørledningen i stedet for manuelt at gå og spinne et nyt miljø med den tilføjede server eller søge hjælp fra systemadministratorerne til at gøre dette.

Så skønheden her er, at udvikleren eller testeren ikke behøver at være en systemadministratorekspert for at oprette deres servere til udvikling eller testaktivitet.

Så infrastrukturen, der er oprettet i DevOps, bliver fuldstændig automatiseret og følger grundlæggende scriptet, der er tjekket ind i versionskontrol, startende fra installation af serverne, konfiguration af dem, installation af OS, indtil kommunikationskanalerne i disse instanser er etableret med den indsatte software.

Hvad er konfigurationen som en kode?

Konfiguration som en kode er intet andet end at definere alle konfigurationer af serverne eller andre ressourcer som en kode eller et script og kontrollere dem i versionskontrol.

Disse konfigurationsskripter, der kontrolleres i versionskontrollen, køres som en del af implementeringsrørledningen for at opsætte infrastrukturen og dens konfigurationer på en automatisk måde.

At definere konfigurationer inkluderer parametre, der definerer de anbefalede indstillinger for softwaren til at køre med succes. Eller et sæt kommandoer, der oprindeligt skal køres for at opsætte softwareapplikationen. Eller endda kunne det være konfigurationer af hver af komponenterne i softwaren, der skal indstilles, eller specifikke brugerroller, brugerrettigheder osv.,

Enkel Eksempel ville være at indstille funktionsskifter, hvor standardværdier er indstillet som en del af konfigurationsparameteren.

Tilføjelse af en anden port til en firewall ville være en anden Eksempel , som kan opdateres i scriptet, og senere køres disse scripts som en del af leveringsrørledningen.

Flere værktøjer er tilgængelige til at udføre infrastrukturautomatisering på markedet. Få af dem er Chef, Puppet, Terraform osv., Chef og Puppet er rubinbaseret konfigurationsstyringsværktøj, mens Terraform er et klargøringsværktøj.

Også i disse dage, da næsten alle applikationer vil være hostet i skyen, AWS, leverer de selv RESTAPI'er, som kan udnyttes til dette formål.

Jeg har en enorm liste over fordele ved konfigurationsstyring i DevOps snarere end at definere infrastrukturen og konfigurationerne som en kode.

Lad os gennemgå dem en efter en.

Alle konfigurationer og infrastrukturoplysninger er versionskontrollerede, hvilket er en stor fordel ved DevOps-implementering.

# 1) Dette hjælper teamet med at administrere ændringerne til serverne og konfigurationen på en automatisk måde og hjælper med at debugge hurtigt, hvis noget mislykkes inden for en kort tidsperiode og giver også mulighed for hurtigt at tilbageføre til den tidligere version uden at forårsage afbrydelser for kunderne.

#to) Da disse scripts er placeret på den centrale server, og alle i teamet ved, hvad der er i hvert af disse scripts, og hvad er ændringerne foretaget i hver af disse versioner. Dette gør det også muligt for teamet at gå tilbage til den ældre version, hvis der er noget problem i de nyeste versioner.

Forestil dig, hvis der er et servernedbrud, hvor lang tid det ville have taget at gendanne det manuelt. Og nu ved at definere infrastruktur som et script og versionskontrol, kan vi straks gendanne ved at gå til den tidligere version.

# 3) Håndtering af konfigurationerne som en kode forhindrer også nogen i at foretage ændringer i systemet ved et uheld og forhindrer skader, der forårsager senere i produktionen.

Da konfigurationsstyring er fuldstændig automatiseret, elimineres manuel indgriben enten til opsætning eller opdatering.

Forestil dig indvirkningen på omkostningerne, kvaliteten og tiden, når folk tidligere var afhængige af menneskelige ressourcer for at udføre disse konfigurationer manuelt, og når visse konfigurationer går glip af eller ikke indstilles efter behov.

Så automatisering af konfigurationsstyring har ikke kun haft gavn af tidsbesparende, men også for at eliminere sådanne menneskelige fejl og forbedre kvaliteten. Kodningsstandard har også hjulpet holdet med at følge den specificerede standard i kodning og automatisering i stedet for at følge fantasien hos hver af den person, der skriver konfigurationsvejledningen.

Som diskuteret tidligere har konfigurationer, der leveres som en kode, fjernet afhængigheden af ​​en enkelt person eller et team kaldet config manager eller config team. Udviklingsteam behøver ikke at vente på, at config-teamet kommer og løser ethvert infra- eller config-problem.

Eller endda til opsætning af infra og konfigurationer, som er fuldstændigt automatiserede og versionskontrollerede. Så enhver i teamet, hvad enten det er en udvikler eller tester, kan dreje en server og udføre konfigurationerne til deres udviklings- og testformål. Derfor er opsætning af serveren og konfigurationer blevet personuafhængig.

Dette sikrer også, at de samme servere ikke bruges af både udviklings- og QA-holdene til deres aktiviteter, hvilket normalt plejede at være tilfældet tidligere.

Infrastruktur og konfigurationer defineret som en fælles kode sammen med automatisering og versionskontrol standardiserer alle miljøer og opsætninger. Så dette gør ikke kun fejlfindingsopgaven let for udviklerne, men eliminerer også de menneskelige fejl, der resulterer i fejlfri infra-opsætninger, ellers ville det forårsage enorme skader, hvis de ikke blev opdaget tidligt.

Her kan vi tydeligt se det klare samarbejde mellem Dev og Ops, hvor begge er afhængige af en enkelt kilde til at udføre infra-opsætningen, og begge hold er aktivt involveret i automatisering og opsætning af hele konfigurationsadministrationen.

Dette arbejde sammen om at nå et fælles mål øger samarbejdet mellem begge teams, udvikling og operationer.

Korrigering af konfigurationsdrift

Hvad er Configuration Drift?

Små forskelle og uoverensstemmelser mellem serverne, hvilket undertiden sker på grund af manuel opdatering, som akkumuleres over en periode kaldes Configuration drift.

Dette er ikke en god situation, fordi denne inkonsekvens i serverne efterlader bestemte programfiler som manifest, playbook for ikke at køre pålideligt på alle serverne og dermed fører til automatiseringsfejl. Så dette skal undgås for at få teamet til at bruge automatisering af konfigurationer effektivt.

Håndtering af infra og konfiguration som en kode og version, der styrer dem, har hjulpet teamet med at undgå eller rette enhver form for konfigurationsdrift mellem forskellige miljøer eller mellem dev- og produktionsopsætninger ved konsekvent at opretholde konfigurationerne på tværs af alle serverne.

Således kan et hold være bedst forsikret om lignende konfigurationsopsætninger på den udvikling, der er oprettet som i produktionen. Dette hjælper dem også med at simulere produktionsproblemer i udviklingsmiljøet.

Så dette hjælper med at forhindre enhver form for uventede ændringer, som nogen af ​​teammedlemmerne kan prøve at gøre på infraen, hvilket kan bryde opsætningen og også tvinger teamet til ikke at foretage ændringer i opsætningen, medmindre de er logget ind som en kode til lageret.

At levere infrastruktur og dens konfiguration som en kode har gjort det muligt for teamet at administrere den som en fleksibel ressource til at imødekomme kundens dynamiske forretningsbehov.

Det er en slags plug and play nu. Et team kan specifikt komme ind på den bestemte server eller netværk og foretage ændringer i dem. Det kan bare være at opdatere klargøringsserveren eller tilføje eller ændre lageret i et bestemt netværk eller endda opdatere operativsystemet, og alt kan opdateres uafhængigt som en fleksibel ressource.

Tidligere, for at ændre en konfigurationsparameter, brugte det virkelig meget tid, især mens det var nødvendigt at opdatere på alle serverne, men nu er det bare en gang. Opdater scriptet og upload til versionskontrolværktøjet, og det er gjort.

Der er en fleksibilitet til fuldstændigt at skrotte den eksisterende infrastruktur og helt opdrage en anden. Så det er blevet ret nemt at administrere infrastrukturen og konfigurationerne nu. Nå, de skybaserede løsninger har gjort det muligt for infrastrukturen at skalere op automatisk ved at tilføje de ekstra computer- eller lagerressourcer efter behov og skalere ned, når de ikke er påkrævet.

Dette har muliggjort optimering af ressourceforbrug baseret på efterspørgslen. Hvis vi ønsker at skalere infrastrukturen op ved at øge maskinens størrelse, kan vi gøre det med det samme. Tilsvarende, hvis vi vil skalere ud eller måske tilføje en anden opsætning eller tilføje flere frontendere, kan vi bare gøre det på få sekunder ved blot at opdatere det i koden og køre den automatiserede pipeline.

Sidst, men ikke mindst, infrastruktur, der leverer som en kode under et kontrolleret miljø, hjælper med at opretholde konsistensen af ​​miljøerne på tværs af forskellige opsætninger. Dette hjælper også med at debugge problemet. Dette punkt har jeg også dækket tidligere til en vis grad, mens jeg talte om konfigurationsdrift.

Det er det, og dette afslutter vores tale om konfigurationsstyring i DevOps, hvad der er infrastruktur og konfigurationer som kode, og hvad er fordelene ved det.

I vores kommende tutorial vil vi diskutere Release Management-aspekterne i DevOps.

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^