De flesta av oss, som lägger märke till en annan ny term inom IT-bloggsfären eller konferensen, ställer förr eller senare en liknande fråga: "Vad är det här? Bara ännu ett modeord, ett "buzzword" eller något som verkligen är värt att uppmärksammas, studeras och löfte om nya horisonter?" Samma sak hände mig med termen GitOps för en tid sedan. Beväpnad med många befintliga artiklar, samt kunskapen hos kollegor från företaget , Jag försökte ta reda på vilken sorts best detta är och hur dess användning kan se ut i praktiken.
Förresten, om begreppets nyhet GitOps Vår senaste undersökning säger också: mer än hälften av de tillfrågade har ännu inte 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 drygt dussin år och, verkar det som, borde ha gjort arbetet för de team som ansvarar för infrastrukturen enkelt och okomplicerat. Men jämfört med applikationsutvecklingsprocessen (där automatiseringen når ständigt nya nivåer) innebär infrastrukturprojekt fortfarande ofta många manuella uppgifter och kräver specialiserad kunskap och expertis, särskilt med tanke på dagens krav på feltolerans, flexibilitet, skalbarhet och elasticitet.
Molntjänster uppfyllde dessa krav mycket framgångsrikt och det var de som gav en betydande impuls till utvecklingen av tillvägagångssättet IaC. Detta är förståeligt. Trots allt gjorde de det möjligt att konfigurera ett helt virtuellt datacenter: det finns inga fysiska servrar, rack eller nätverkskomponenter, hela infrastrukturen kan beskrivas med skript och konfigurationsfiler.
Så exakt vad är skillnaden? GitOps från IaC? Det var med denna fråga som jag började min utredning. Efter att ha pratat med kollegor kunde jag komma på följande jämförelse:
GitOps
IaC
All kod lagras i ett git-förråd
Kodversionering är valfritt
Deklarativ kod Beskrivning / Idempotens
Både deklarativa och imperativa beskrivningar är acceptabla
Ändringar träder i kraft med mekanismerna Merge Request / Pull Request
Avtal, godkännande och samarbete är valfritt
Uppdateringsprocessen är automatiserad
Uppdateringsprocessen är inte standardiserad (automatisk, manuell, kopiering av filer, användning av kommandoraden, etc.)
Med andra ord GitOps föddes just genom tillämpningen av principerna IaC. För det första kan infrastruktur och konfigurationer nu lagras på samma sätt som applikationer. Koden är lätt att lagra, lätt att dela, jämföra och använda versionsfunktioner. Versioner, grenar, historia. Och allt detta på en plats som är allmänt tillgänglig för hela teamet. Därför blev användningen av versionskontrollsystem en helt naturlig utveckling. I synnerhet git, som den mest populära.
Å andra sidan blev det möjligt att automatisera infrastrukturhanteringsprocesser. 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ända kunskaper och färdigheter till ett nytt område. Dessa metoder gick dock längre än standarddefinitionen av Infrastruktur som kod, därav konceptet GitOps.
Nyfikenhet GitOps, naturligtvis också i det faktum att det inte är en produkt, plugin eller plattform som är associerad med någon leverantör. Det är mer ett paradigm och en uppsättning principer, liknande en annan term vi känner till: 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 tar de bästa DevOps-principerna som används för applikationsutveckling, såsom versionskontroll, samarbete, orkestrering, CI/CD, och tillämpar dem på utmaningarna med att automatisera infrastrukturhantering.
Alla processer GitOps Jag arbetar med befintliga verktyg. All infrastrukturkod lagras i det redan välbekanta git-förrådet, ändringar går igenom samma godkännandeprocess som alla andra programkoder, och utrullningsprocessen är automatiserad, vilket gör att vi kan minimera mänskliga fel, öka tillförlitligheten och reproducerbarheten.
Ur praktisk synvinkel 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.
Merge Request (alternativt namn Pull Request). I processtermer är MR en begäran om att tillämpa kodändringar och sedan slå samman grenar. Men när det gäller de verktyg vi använder är detta mer av en möjlighet att få en komplett bild av alla ändringar som görs: inte bara koddifferensen som samlas in från ett visst antal commits, utan också sammanhanget, testresultaten och slutligt förväntat resultat. Om vi pratar om infrastrukturkod, så ä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. För molnleverantörer är det en bra idé att veta vad den ekonomiska effekten av denna förändring kommer att bli.
Men MR är också ett sätt för samarbete, interaktion och kommunikation. Platsen där systemet med kontroller och avvägningar kommer in i bilden. Från enkla kommentarer till formella godkännanden och godkännanden.
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 testa (från enkel syntaxkontroll till mer komplex statisk kodanalys). Och även i den efterföljande detekteringen av drift: skillnader mellan det verkliga och önskade tillståndet i systemet. Till exempel till följd av obehöriga manuella ändringar eller systemfel.
Ja, termen GitOps introducerar oss inte för något helt nytt, uppfinner inte hjulet på nytt, utan tillämpar helt enkelt den redan samlade erfarenheten på ett nytt område. Men det är här hans styrka ligger.
Och om du plötsligt blir intresserad av hur det hela ser ut i praktiken, då inbjuder jag dig att titta på vår , där jag berättar steg för steg hur du använder GitLab:
-
Implementera de grundläggande principerna för GitOps
-
Skapa och gör ändringar i molninfrastrukturen (med exemplet Yandex Cloud)
-
Automatisera detektering av systemdrift från ett önskat tillstånd med hjälp av aktiv övervakning
https://bit.ly/34tRpwZ
Källa: will.com