De flesta av oss, när vi noterar ett nytt begrepp inom IT-bloggosfären eller på en konferens, ställer förr eller senare en liknande fråga: "Vad är det här? Är det bara ett modeord, ett 'buzzword', eller är det verkligen något värt att uppmärksamma, studera och som lovar nya horisonter?" Exakt samma sak hände mig med termen GitOps för en tid sedan. Beväpnad med en mängd redan existerande artiklar samt kunskapen från kollegor på företaget , försökte jag förstå vad det här var för något och hur det kan tillämpas i praktiken.
För övrigt visar också det nyligen genomförda vår undersökning att mer än hälften av de tillfrågade ännu inte har börjat arbeta med dess principer. GitOps Så problemet med infrastrukturhantering är inte nytt. Många molnleverantörer har redan varit tillgängliga för allmänheten i mer än ett decennium och borde, verkar det som, ha gjort arbetet för de som ansvarar för infrastruktur enkelt och okomplicerat. Men när man jämför med processen för applikationsutveckling (där automatiseringsnivån når nya höjder), involverar infrastrukturprojekt fortfarande ofta många manuellt utförda uppgifter och kräver speciell kunskap och experter, särskilt med hänsyn till moderna krav på tillförlitlighet, flexibilitet, skalbarhet och elastisk hantering.
Molntjänster har framgångsrikt uppfyllt dessa krav och det var just de som gav ett betydande uppsving till utvecklingen av detta angreppssätt.
Det är förståeligt. Det var de som möjliggjorde helt virtuella datacenter: inga fysiska servrar, hyllor eller nätverkskomponenter, hela infrastrukturen kan beskrivas med skript och konfigurationsfiler. IaCSå vad är egentligen skillnaden
All kod lagras i ett git-repository GitOps från IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Versionshantering av koden är valfri
Deklarativ kodbeskrivning / Idempotens
Både deklarativ och imperativ beskrivning är tillåtna
Ändringar träder i kraft med hjälp av Merge Request / Pull Request-mekanismer
Godkännande, bekräftelse och samarbete är valfria
Processen för att rulla ut uppdateringar är automatiserad
Processen för att rulla ut uppdateringar är inte standardiserad (automatiserad, manuell, filkopiering, med hjälp av kommandoraden osv.)
Med andra ord
kom till världen tack vare tillämpningen av principer GitOps появился на свет именно благодаря применению принципов IaC. För det första kan infrastruktur och konfigurationer nu lagras på samma sätt som applikationer. Koden är lätt att lagra, dela, jämföra och dra nytta av versionshantering. Versioner, grenar, historik. Allt detta på en plats som är tillgänglig för hela teamet. Därför var det en naturlig utveckling att börja använda versionshanteringssystem. Särskilt git, som är det mest populära.
Å andra sidan har möjligheten att automatisera infrastrukturna hanteringsprocesser uppstått. Nu kan detta göras snabbare, mer pålitligt och billigare. I synnerhet var principerna för CI/CD redan kända och populära bland mjukvaruutvecklare. Det handlade bara om att överföra och tillämpa dessa kända kunskaper och färdigheter till ett nytt område. Dessa metoder sträckte sig dock bortom den standarddefinition av Infrastruktur som kod, och därav föddes begreppet. GitOps.
Nyfikenhet GitOps, självklart, ligger också i att detta inte är en produkt, plugin eller plattform kopplad till någon leverantör. Det är snarare en paradigm och en uppsättning principer, jämförbar med ett annat bekant begrepp: DevOps.
På företaget Vi har utarbetat två definitioner av detta nya begrepp: teoretisk och praktisk. Låt oss börja med den teoretiska:
GitOps är en metodik som använder avancerade DevOps-principer som används för applikationsutveckling, såsom versionskontroll, samarbete, överenskommelser, CI/CD, och tillämpar dem för automatisering av infrastrukthantering.
Alla processer GitOps arbete med hjälp av redan befintliga verktyg. All infrastrukturkod lagras i det bekanta git-repositoriet, ändringar går genom samma överenskommelseprocess som vilken annan programkod som helst, och distributionsprocessen är automatiserad, vilket minimerar mänskliga fel, ökar pålitligheten och reproducerbarheten.
Ur praktisk synvinkel beskriver vi GitOps på följande sätt:
Infrastruktur som kod har vi redan diskuterat som en av de viktigaste delarna av denna formel. Låt oss presentera de andra aktörerna.
Merge Request (ett alternativt namn för Pull Request). I processen av MR är detta en begäran om att tillämpa kodändringar och efterföljande sammanslagning av grenar. Men när det kommer till verktygen vi använder så är detta mer en möjlighet för att få en helhetsbild av alla införda ändringar: inte bara code diff, samlat från ett visst antal commit, utan även kontext, testresultat och det slutliga förväntade resultatet. Om vi pratar om infrastrukturkod, så är vi intresserade av hur infrastrukturen kommer att förändras, hur många nya resurser som kommer att läggas till eller tas bort och vad som kommer att ändras. Förslagsvis i ett mer bekvämt och lättläst format. I fallet med molnleverantörer skulle det vara bra att veta vilka ekonomiska konsekvenser denna förändring kommer att få.
Men MR är också ett verktyg för samarbete, interaktion och kommunikation. Den plats där systemet av kontroll och motvikt träder i kraft. Från enkla kommentarer till formella godkännanden och bekräftelser.
Och den sista komponenten: CI/CD, som vi redan vet, ger möjlighet att automatisera processen för att införa infrastrukturella förändringar, testning (från enkel syntaxkontroll till mer komplex statisk kodanalys). Och även för att senare upptäcka driftsförskjutning: skillnader mellan det verkliga och önskade tillståndet av systemet. Till exempel, som ett resultat av obehöriga manuella förändringar eller systemsystemfel.
Ja, termen GitOps introducerar oss inte till något helt nytt, uppfinner inte hjulet på nytt, utan tillämpar bara den samlade erfarenheten på ett nytt område. Men det är just här som dess styrka ligger.
Och om du plötsligt skulle bli intresserad av hur allt detta ser ut i praktiken, så bjuder jag in dig att titta på vår , där jag steg för steg berättar hur man med hjälp av GitLab:
Implementerar de grundläggande principerna för GitOps
Skapar och gör förändringar i molninfrastrukturen (utifrån Yandex Cloud-exemplet)
Automatiserar upptäckten av systemets driftsförskjutning från det önskade tillståndet med aktiv övervakning
https://bit.ly/34tRpwZ
Källa: habr.com
