De flesta av oss, som lägger märke till ytterligare en ny term i IT-bloggosfären eller på konferenser, ställer oss förr eller senare en liknande fråga: ”Vad är detta? Ännu ett trendigt ord, ett ”modeord” eller något som verkligen är värt att uppmärksamma, studera och lova nya horisonter?” Samma sak hände mig med termen GitOps för en tid sedan. Beväpnad med en mängd befintliga artiklar och kunskap från kollegor från företaget , Jag försökte lista ut vad det här är för slags odjur och hur dess tillämpning skulle kunna se ut i praktiken.
Förresten, om termens nyhet GitOps Vår senaste undersökning visar också att mer än hälften av de tillfrågade ännu inte har börjat arbeta med dess principer.
Så problemet med infrastrukturförvaltning är inte nytt. Många molnleverantörer har varit tillgängliga för allmänheten i ett bra decennium nu och man skulle kunna tro att de borde göra arbetet för de team som ansvarar för infrastrukturen enkelt och okomplicerat. Jämfört med applikationsutvecklingsprocessen (där automatiseringsnivån når allt nya horisonter) involverar infrastrukturprojekt dock fortfarande ofta många manuella uppgifter och kräver specialiserad kunskap och specialister, särskilt med tanke på moderna krav på feltolerans, flexibilitet, skalbarhet och elasticitet.
Molntjänster har varit mycket framgångsrika med att uppfylla dessa krav och har gett betydande drivkraft åt utvecklingen av metoden. IaC. Det är förståeligt. Det var trots allt de som gjorde det möjligt att konfigurera ett helt virtuellt databehandlingscenter: det finns inga fysiska servrar, rack, nätverkskomponenter, hela infrastrukturen kan beskrivas med hjälp av skript och konfigurationsfiler.
Så vad är den faktiska skillnaden? GitOps från IaC? Det var med denna fråga som jag började min undersökning. Efter att ha pratat med kollegor kunde jag göra följande jämförelse:
GitOps
IaC
All kod lagras i ett git-repository.
Kodversionering är valfritt
Deklarativ kodbeskrivning / Idempotens
Både deklarativa och imperativa beskrivningar är tillåtna.
Ändringar implementeras med hjälp av mekanismer för sammanslagningsbegäran/pull-begäran.
Samordning, godkännande och samarbete är valfria
Processen att lansera uppdateringar är automatiserad
Processen för att lansera uppdateringar är inte standardiserad (automatisk, manuell, kopiering av filer, användning av kommandoraden, etc.)
Med andra ord GitOps uppstod just på grund av tillämpningen av principer IaC. För det första kunde infrastruktur och konfigurationer nu lagras på samma sätt som applikationer. Koden är enkel att lagra, dela, jämföra och dra nytta av versionshanteringsfunktioner. Versioner, grenar, historik. Och allt detta på en plats som är tillgänglig för hela teamet. Därför blev användandet av versionshanteringssystem en helt naturlig utveckling. Särskilt git, som den mest populära.
Å andra sidan blev det möjligt att automatisera processer för infrastrukturhantering. Nu kan detta göras snabbare, mer tillförlitligt och billigare. Dessutom var principerna för CI/CD redan kända och populära bland mjukvaruutvecklare. Det var bara nödvändigt att överföra och tillämpa redan känd kunskap och färdigheter på ett nytt område. Dessa metoder gick dock utöver standarddefinitionen av infrastruktur som kod, därav konceptet föddes. GitOps.
Nyfikenhet GitOps, naturligtvis också i det faktum att det inte är en produkt, plugin eller plattform som är kopplad till någon leverantör. Det är mer ett paradigm och en uppsättning principer, liknande en annan term vi är bekanta med: DevOps.
Företaget Vi har utvecklat två definitioner av denna nya term: teoretisk och praktisk. Låt oss börja med det teoretiska:
GitOps är en metod som använder de bästa metoderna från DevOps som används för applikationsutveckling, såsom versionshantering, samarbete, orkestrering och CI/CD, och tillämpar dem på utmaningarna med att automatisera infrastrukturhantering.
Alla processer GitOps Jag arbetar med befintliga verktyg. All infrastrukturkod lagras i ett välbekant git-arkiv, ändringar går igenom samma godkännandeprocess som all annan programkod och utrullningsprocessen är automatiserad, vilket hjälper till att minimera mänskliga fel och förbättra tillförlitlighet och reproducerbarhet.
Ur ett praktiskt perspektiv beskriver vi GitOps enligt följande:
Vi har redan diskuterat infrastruktur som kod som en av nyckelkomponenterna i denna formel. Låt oss presentera resten av deltagarna.
Sammanfogningsbegäran (alternativt namn Pull Request). I processtermer är en MR en begäran om att tillämpa kodändringar och sedan sammanfoga grenar. Men när det gäller de verktyg vi använder är det snarare en möjlighet att få en fullständig bild av alla ändringar som görs: inte bara en koddiff sammanställd från ett visst antal commits, utan även kontexten, testresultaten och det slutliga förväntade resultatet. Om vi pratar om infrastrukturkod är vi intresserade av hur exakt infrastrukturen kommer att förändras, hur många nya resurser som kommer att läggas till eller tas bort, ändras. Gärna i något mer bekvämt och lättläst format. När det gäller molnleverantörer vore det bra att veta vilka ekonomiska konsekvenser denna förändring kommer att få.
Men MR är också ett medel för samarbete, interaktion och kommunikation. Det är här systemet med maktfördelning kommer in i bilden. Från enkla kommentarer till formella godkännanden och uttalanden.
Jo, den sista komponenten: CI/CD, som vi redan vet, gör det möjligt att automatisera processen att göra infrastrukturförändringar och tester (från enkel syntaxkontroll till mer komplex statisk kodanalys). Och även i den efterföljande detekteringen av drift: skillnader mellan systemets faktiska och önskade tillstånd. Till exempel till följd av obehöriga manuella ändringar eller systemfel.
Ja, termen GitOps introducerar oss inte till något helt nytt, uppfinner inte hjulet på nytt, utan tillämpar helt enkelt redan ackumulerad erfarenhet inom ett nytt område. Men däri ligger dess styrka.
Och om du plötsligt blir intresserad av hur allt detta ser ut i praktiken, då inbjuder jag dig att titta på vår , där jag steg för steg förklarar hur man använder GitLab:
Implementera de grundläggande principerna för GitOps
Skapa och göra ändringar i molninfrastruktur (med Yandex Cloud som exempel)
Automatisera detektering av systemavvikelser från önskat tillstånd med hjälp av aktiv övervakning
https://bit.ly/34tRpwZ
Källa: will.com
