Meny

Konfigurationshantering i DevOps-praxis

configuration management devops practices

Prova Vårt Instrument För Att Eliminera Problem

Vad är Configuration Management i DevOps Practices?

Konceptet av Kontinuerlig testning i DevOps förklarades i detalj i vår tidigare handledning.

Den viktigaste höjdpunkten för konfigurationshantering i DevOps är att leverera,

  1. Infrastruktur som kod
  2. Konfiguration som en kod

Måste läsa igenom => Exklusiv DevOps-handledningsserie

kopiera dvd-filmer till hårddisken gratis

Konfigurationshantering i DevOps-praxis

Det finns många fördelar med 'Infrastruktur som en kod' och 'Konfiguration som en kod' i DevOps-praxis.

    • Konfigurationer är versionskontrollerade
    • Automatiserad och standardiserad
    • Tar bort beroende
    • Felfria infra-inställningar
    • Ökar samarbetet mellan Operations and Development team
    • Korrigera konfigurationsdrift
    • Att behandla infrastruktur som en flexibel resurs
    • Automatiserad skalning av infrastruktur
    • Upprätthålla enhetlighet i inställningarna

VIDEO Del 4 Block 1: Konfigurationshantering- 23 minuter 7 sekunder

Transkript:

I den här delen kommer vi att lära oss mer om Konfigurationshantering, Release management och Application Performance Monitoring i DevOps.

Här, i block 1, kommer vi att fokusera på Configuration Management och förstå vad som är konfigurationshantering och hur är det annorlunda i DevOps och de traditionella metoderna.

Till att börja med, låt oss veta Vad är Configuration Management?

Konfigurationshantering, som namnet själv förklarar, är inget annat än att hantera alla konfigurationer av de miljöer som programvaran är värd för.

Som vi vet har vi olika miljöer i hela SDLC i DevOps som börjar med enhetstestning, integrationstestning, systemtestning, godkännandestestning och slutanvändartestning.

Och jag har också förklarat i mina tidigare självstudier att miljöns inställningar för dessa tester gradvis skulle bli mer komplexa när det rör sig mot förproduktion och produktionsmiljö.

Så i princip är konfigurationshantering den automatiserade processen för att hantera alla konfigurationer i var och en av dessa miljöer.

Vad är då skillnaden mellan traditionell konfigurationshantering och DevOps konfigurationshantering?

I våra traditionella konfigurationshanteringsmetoder använde teamet sig för att hantera dessa konfigurationer av olika miljöer via formell dokumentation där var och en av konfigurationerna spelades in i dokumenten och konfigurationsteamet eller chefen som används för att hantera versionskontrollen av dessa dokument.

Och när och när det genomgår förändringar tar han också ansvaret för att ställa in miljön och hantera konfigurationerna manuellt

Nu i DevOps är vanligtvis alla dessa konfigurationshanteringsprocesser ganska väl automatiserade och konfigurationerna inkapslas i form av kod eller skript och styrs via versionskontrollverktyget.

I det här sammanhanget kan vi ringa att Operations-teamet är integrerat med utveckling för att hantera miljöerna genom kontrollverktyget för en version.

Så, den viktigaste höjdpunkten för konfigurationshantering i DevOps är att leverera,

      1. Infrastruktur som kod
      2. Konfiguration som en kod

Vad betyder egentligen ”infrastruktur som, som en kod”? Det definierar hela miljödefinitionen som en kod eller ett skript istället för att spela in i ett formellt dokument.

Vad inkluderar då definitionen av miljö? Miljödefinition innefattar vanligtvis, konfigurering av servrar, konfigurering av nätverk och inställning av andra datorressurser, som ingår i IT-infrastrukturen. Så alla dessa detaljer skulle skrivas ut som en fil eller i form av en kod och kontrolleras i versionskontrollverktyget.

Det här skriptet eller koden som kontrolleras i versionskontrollen skulle bli den enda källan för att definiera miljön eller till och med uppdatera dessa miljöer.

Bara för att ge ett enkelt Exempel , om vi måste lägga till en server i den specifika miljön, är allt vi skulle göra att uppdatera informationen i miljöskript och köra leveranspipelinen istället för att manuellt gå och spinna ut en ny miljö med den tillagda servern eller söka hjälp av systemadministratörerna att göra detta.

Så skönheten här är att utvecklaren eller testaren inte behöver vara systemadministratörsexpert för att ställa in sina servrar för utveckling eller testaktivitet.

Så infrastrukturen som är inställd i DevOps kommer att bli helt automatiserad och följer i princip skriptet som är kontrollerat till versionskontroll från och med installation av servrarna, konfigurering av dem, installation av operativsystemet tills kommunikationskanalerna för dessa instanser har etablerats med den distribuerade programvara.

Vad är konfigurationen som en kod?

Konfiguration som kod är inget annat än att definiera alla konfigurationer på servrarna eller andra resurser som en kod eller ett skript och kontrollera dem i versionskontroll.

Dessa konfigurationsskript som kontrolleras i versionskontrollen körs som en del av distributionens pipeline för att konfigurera infrastrukturen och dess konfigurationer på ett automatiserat sätt.

Definitioner av konfigurationer inkluderar parametrar som definierar de rekommenderade inställningarna för att programvaran ska kunna köras framgångsrikt. Eller en uppsättning kommandon som ska köras initialt för att ställa in programvaran. Eller till och med kan det vara konfigurationer av var och en av komponenterna i programvaran som ska ställas in, eller specifika användarroller, användarbehörigheter etc.,

Enkel Exempel skulle vara att ställa in funktionsväxlar, där standardvärden ställs in som en del av konfigurationsparametern.

Att lägga till en annan port i en brandvägg skulle vara en annan Exempel , som kan uppdateras i skriptet och senare körs dessa skript som en del av leveransrörledningen.

Flera verktyg finns tillgängliga för att genomföra infrastrukturautomatisering på marknaden. Få av dem är Chef, Puppet, Terraform, etc., Chef och Puppet är ett rubinbaserat konfigurationshanteringsverktyg, medan Terraform är ett provisioneringsverktyg.

Idag, eftersom nästan alla applikationer kommer att vara värd på molnet, AWS, tillhandahåller de själva RESTAPI, som kan utnyttjas för detta ändamål.

Jag har en enorm lista över fördelar med konfigurationshantering i DevOps, snarare än att definiera infrastruktur och konfigurationer som en kod.

Låt oss gå igenom dem en efter en.

Alla konfigurationer och infrastruktur detaljer är versionskontrollerade vilket är en stor fördel i DevOps implementering.

# 1) Detta hjälper teamet att hantera ändringarna i servrarna och konfigurationen på ett automatiserat sätt och hjälper till att felsöka snabbt om något misslyckas, inom en kort tidsperiod och gör det också möjligt att snabbt återgå till den tidigare versionen utan att orsaka några avbrott för kunderna.

#två) Eftersom dessa skript finns på centralservern och alla i teamet vet vad som finns i vart och ett av dessa skript och vilka ändringar som gjorts i var och en av dessa versioner. Detta gör det också möjligt för teamet att gå tillbaka till den äldre versionen om det finns några problem i de senaste versionerna.

Tänk dig, om det är en serverkrasch, hur mycket tid det skulle ha tagit för att manuellt återställa den. Och nu genom att definiera infrastruktur som ett skript och versionskontroll, kan vi omedelbart återställa genom att gå till den tidigare versionen.

# 3) Att hantera konfigurationerna som en kod hindrar också någon från att göra ändringar i systemet av misstag och förhindrar skador som orsakas senare i produktionen.

Eftersom konfigurationshanteringen är helt automatiserad elimineras manuellt ingripande antingen för att ställa in eller uppdatera.

Föreställ dig inverkan på kostnaden, kvaliteten och tiden när människor tidigare var beroende av mänskliga resurser för att utföra dessa konfigurationer manuellt och när vissa konfigurationer missades eller inte ställts in efter behov.

Så, automatisering av konfigurationshantering har inte bara gynnats av tidsbesparing utan också av att eliminera sådana mänskliga fel och förbättra kvaliteten. Kodningsstandard har också hjälpt teamet att följa den angivna standarden för kodning och automatisering istället för att följa fantasin hos var och en av den person som skriver konfigurationsguiden.

Som diskuterats tidigare har konfigurationer som levereras som en kod tagit bort beroendet av en enskild person eller ett team som heter config manager eller config team. Utvecklingsteamet behöver inte vänta på att config-teamet ska komma och fixa eventuella infra- eller config-problem.

Eller till och med för att ställa in infra och konfigurationer, som är helt automatiserade och versionskontrollerade. Så vem som helst i teamet, vare sig det är en utvecklare eller testare, kan snurra en server och utföra konfigurationerna för deras utvecklings- och teständamål. Därför har installationen av servern och konfigurationer blivit personoberoende.

Detta säkerställer också att samma servrar inte används av både utvecklings- och QA-team för sina aktiviteter, vilket vanligtvis brukade vara fallet tidigare.

Infrastruktur och konfigurationer definierade som en vanlig kod tillsammans med automatisering och versionskontroll standardiserar alla miljöer och inställningar. Så detta gör inte bara felsökningsuppgiften lätt för utvecklarna utan eliminerar också de mänskliga felen som resulterar i felfria infra-inställningar, annars skulle det orsaka enorma skador om de inte upptäcks tidigt.

Här kan vi tydligt se det tydliga samarbetet mellan Dev och Ops, där båda förlitar sig på en enda källa för att genomföra infrauppsättningen och båda lagen är aktivt involverade i att automatisera och konfigurera hela konfigurationshanteringen.

Detta samarbete för att uppnå ett gemensamt mål ökar samarbetet mellan både team, utveckling och verksamhet.

Korrigera konfigurationsdrift

Vad är Configuration Drift?

Små skillnader och inkonsekvenser mellan servrarna, vilket ibland händer på grund av manuell uppdatering, som ackumuleras under en tidsperiod kallas Configuration drift.

Detta är inte en bra situation, eftersom denna inkonsekvens i servrarna lämnar vissa programfiler som manifest, playbook att inte köras pålitligt på alla servrar och därmed leder till automatiseringsfel. Så detta måste undvikas för att teamet ska kunna använda automatiseringen av konfigurationer effektivt.

Att hantera infra och konfigurera som en kod och version som kontrollerar dem har hjälpt teamet att undvika eller korrigera någon form av konfigurationsdrift mellan olika miljöer eller mellan dev- och produktionsinställningar genom att konsekvent behålla konfigurationerna på alla servrar.

Således kan ett team bäst försäkra sig om liknande konfigurationsinställningar för utvecklingen som den som är i produktion. Detta hjälper dem också att simulera produktionsfrågor i utvecklingsmiljön.

Så detta hjälper till att förhindra alla typer av oväntade förändringar som någon av teammedlemmarna kan försöka göra på infra, vilket kan bryta uppställningen och också tvinga laget att göra några ändringar i inställningen såvida de inte är inloggade som en kod till förvaret.

Att leverera infrastruktur och dess konfiguration som en kod har gjort det möjligt för teamet att hantera den som en flexibel resurs för att möta kundens dynamiska affärsbehov.

Det är ett slags plug and play nu. Ett team kan specifikt komma in på den specifika servern eller nätverket och göra ändringarna i dem. Det kan bara vara att uppdatera provisioneringsservern eller lägga till eller modifiera lagringen i ett visst nätverk eller till och med uppdatera operativsystemet, och allt kan uppdateras oberoende som en flexibel resurs.

Tidigare, för att ändra en konfigurationsparameter, brukade det verkligen ta mycket tid, speciellt medan det krävdes uppdatering på alla servrar, men nu är det bara en gång. Uppdatera skriptet och ladda upp det till versionskontrollverktyget så är allt klart.

Det finns en flexibilitet att helt skrota den befintliga infrastrukturen och helt ta upp en annan. Så att hantera infrastrukturen och konfigurationerna har blivit ganska enkelt nu. De molnbaserade lösningarna har gjort det möjligt för infrastrukturen att automatiskt skala upp genom att lägga till ytterligare dator- eller lagringsresurser efter behov och minska när de inte behövs.

Detta har möjliggjort optimering av resursanvändning baserat på efterfrågan. Om vi ​​vill skala upp infrastrukturen genom att öka maskinens storlek kan vi göra det omedelbart. På samma sätt, om vi vill skala ut eller kanske lägga till en ny installation eller lägga till fler frontend, kan vi bara göra det på några sekunder genom att helt enkelt uppdatera det i koden och köra den automatiska pipelinen.

Sist, men inte minst, infrastruktur, som levereras som en kod under en kontrollerad miljö, hjälper till att upprätthålla enhetligheten i miljöerna i olika inställningar. Detta hjälper till att felsöka problemet också. Den här punkten har jag också täckt tidigare till viss del när jag pratade om konfigurationsdrift.

Det är det och detta kompletterar vårt samtal om konfigurationshantering i DevOps, vad gäller infrastruktur och konfigurationer som en kod och vad är fördelarna med det.

I vår kommande handledning kommer vi att diskutera Release Management-aspekterna i DevOps.

PREV-handledning | NÄSTA självstudie

Rekommenderad läsning

^