Opmerking. vert.: Na een recente publicatie over pull- en push-methoden in GitOps zagen we interesse in dit model in het algemeen, maar er waren maar heel weinig Russischtalige publicaties over dit onderwerp (er zijn er simpelweg geen op Habré). Daarom bieden wij u graag een vertaling van een ander artikel onder uw aandacht - zij het bijna een jaar geleden! – van Weaveworks, waarvan het hoofd de term ‘GitOps’ bedacht. De tekst legt de essentie van de aanpak uit en de belangrijkste verschillen met de bestaande aanpak.
Een jaar geleden publiceerden we . Destijds deelden we hoe het Weaveworks-team een SaaS lanceerde die volledig op Kubernetes was gebaseerd en een reeks voorgeschreven best practices ontwikkelde voor de implementatie, het beheer en de monitoring in een cloud-native omgeving.
Het artikel bleek populair. Andere mensen begonnen over GitOps te praten en begonnen nieuwe tools te publiceren , , , , enzovoort. Verschijnt op onze website publicaties en GitOps-use cases. Maar sommige mensen hebben nog vragen. Hoe verschilt het model van het traditionele? en continue levering ()? Is het nodig om Kubernetes te gebruiken?
We beseften al snel dat er een nieuwe beschrijving nodig was, die het volgende bood:
- Een groot aantal voorbeelden en verhalen;
- Specifieke definitie van GitOps;
- Vergelijking met traditionele continue levering.
In dit artikel hebben we geprobeerd al deze onderwerpen te behandelen. Het biedt een bijgewerkte introductie tot GitOps en een ontwikkelaars- en CI/CD-perspectief. We richten ons primair op Kubernetes, hoewel het model generaliseerbaar is.
Maak kennis met GitOps
Stel je Alice voor. Ze beheert Family Insurance, een ziektekosten-, auto-, woning- en reisverzekering voor mensen die het te druk hebben om zelf de ins en outs van contracten uit te zoeken. Haar bedrijf begon als een bijproject toen Alice als datawetenschapper bij een bank werkte. Op een dag besefte ze dat ze geavanceerde computeralgoritmen kon gebruiken om gegevens effectiever te analyseren en verzekeringspakketten samen te stellen. Investeerders financierden het project, en nu brengt haar bedrijf ruim twintig miljoen dollar per jaar op en groeit het snel. Momenteel zijn er 20 mensen werkzaam in verschillende functies. Dit omvat een technologieteam dat de website en database ontwikkelt, onderhoudt en het klantenbestand analyseert. Het team van 180 mensen wordt geleid door Bob, de technisch directeur van het bedrijf.
Het team van Bob implementeert productiesystemen in de cloud. Hun kernapplicaties draaien op GKE en profiteren van Kubernetes op Google Cloud. Daarnaast gebruiken ze in hun werk verschillende data- en analysetools.
Family Insurance was niet van plan om containers te gebruiken, maar raakte verstrikt in het Docker-enthousiasme. Het bedrijf ontdekte al snel dat GKE het eenvoudig en moeiteloos maakte om clusters te implementeren om nieuwe functies te testen. Jenkins voor CI en Quay werden toegevoegd om het containerregister te organiseren, er werden scripts geschreven voor Jenkins die nieuwe containers en configuraties naar GKE pushten.
Er is enige tijd verstreken. Alice en Bob waren teleurgesteld over de prestaties van hun gekozen aanpak en de impact ervan op het bedrijf. De introductie van containers verbeterde de productiviteit niet zo veel als het team had gehoopt. Soms mislukten implementaties en was het onduidelijk of codewijzigingen hiervan de oorzaak waren. Het bleek ook moeilijk om configuratiewijzigingen bij te houden. Vaak was het nodig om een nieuw cluster te maken en applicaties daarnaartoe te verplaatsen, omdat dit de gemakkelijkste manier was om de puinhoop die het systeem was geworden te elimineren. Alice was bang dat de situatie zou verergeren naarmate de applicatie zich ontwikkelde (bovendien was er een nieuw project op basis van machine learning in de maak). Bob had het meeste werk geautomatiseerd en begreep niet waarom de pijplijn nog steeds instabiel was, niet goed schaalde en periodiek handmatige tussenkomst nodig had?
Toen leerden ze over GitOps. Deze beslissing bleek precies wat ze nodig hadden om vol vertrouwen verder te gaan.
Alice en Bob horen al jaren over Git, DevOps en infrastructuur als codeworkflows. Het unieke aan GitOps is dat het een reeks best practices biedt (zowel definitief als normatief) voor het implementeren van deze ideeën in de context van Kubernetes. Dit thema , inclusief in .
Family Insurance besluit GitOps te implementeren. Het bedrijf beschikt nu over een geautomatiseerd bedrijfsmodel dat compatibel is met Kubernetes en combineert snelheid met stabiliteitomdat ze:
- ontdekte dat de productiviteit van het team verdubbelde zonder dat iemand gek werd;
- gestopt met het weergeven van scripts. In plaats daarvan kunnen ze zich nu concentreren op nieuwe functies en technische technieken verbeteren, bijvoorbeeld door canary-implementaties te implementeren en het testen te verbeteren;
- we hebben het implementatieproces verbeterd zodat het zelden kapot gaat;
- kreeg de kans om implementaties te herstellen na gedeeltelijke mislukkingen zonder handmatige tussenkomst;
- tweedehands gekochtоMeer vertrouwen in bezorgsystemen. Alice en Bob ontdekten dat ze het team konden opsplitsen in microserviceteams die parallel werkten;
- kan elke dag 30 tot 50 wijzigingen in het project aanbrengen door de inspanningen van elke groep en nieuwe technieken uitproberen;
- het is gemakkelijk om nieuwe ontwikkelaars voor het project aan te trekken, die de mogelijkheid hebben om binnen een paar uur updates voor de productie uit te rollen met behulp van pull-requests;
- gemakkelijk slagen voor de audit in het kader van SOC2 (voor het voldoen van dienstverleners aan eisen voor veilig databeheer; lees bijvoorbeeld meer — ca. vert.).
Wat is er gebeurd?
GitOps bestaat uit twee dingen:
- Operationeel model voor Kubernetes en cloud native. Het biedt een reeks best practices voor het implementeren, beheren en monitoren van gecontaineriseerde clusters en applicaties. Elegante definitie in de vorm van :
- De weg naar het creëren van een op ontwikkelaars gerichte applicatiebeheeromgeving. We passen de Git-workflow toe op zowel operaties als ontwikkeling. Houd er rekening mee dat dit niet alleen over Git push gaat, maar over het organiseren van de hele set CI/CD- en UI/UX-tools.
Een paar woorden over Git
Als je niet bekend bent met versiebeheersystemen en de op Git gebaseerde workflow, raden we je ten zeerste aan om er meer over te leren. Het werken met branches en pull-aanvragen lijkt in eerste instantie misschien zwarte magie, maar de voordelen zijn de moeite waard. Hier beginnen.
Hoe Kubernetes werkt
In ons verhaal wendden Alice en Bob zich tot GitOps nadat ze een tijdje met Kubernetes hadden gewerkt. GitOps is nauw verwant aan Kubernetes: het is een operationeel model voor infrastructuur en applicaties gebaseerd op Kubernetes.
Wat biedt Kubernetes gebruikers?
Hier zijn enkele belangrijke kenmerken:
- In het Kubernetes-model kan alles in declaratieve vorm worden beschreven.
- De Kubernetes API-server neemt deze declaratie als invoer en probeert vervolgens voortdurend het cluster in de staat te brengen die in de declaratie wordt beschreven.
- Verklaringen zijn voldoende om een grote verscheidenheid aan werklasten (‘applicaties’) te beschrijven en te beheren.
- Als gevolg hiervan vinden er wijzigingen in de applicatie en het cluster plaats als gevolg van:
- veranderingen in containerimages;
- wijzigingen in de declaratieve specificatie;
- fouten in de omgeving, bijvoorbeeld containercrashes.
De grote convergentiemogelijkheden van Kubernetes
Wanneer een beheerder configuratiewijzigingen aanbrengt, past de Kubernetes-orkestrator deze toe op het cluster zolang de status ervan is zal niet in de buurt komen van de nieuwe configuratie. Dit model werkt voor elke Kubernetes-resource en is uitbreidbaar met Custom Resource Definitions (CRD's). Daarom hebben Kubernetes-implementaties de volgende prachtige eigenschappen:
- Automatisering: Kubernetes-updates bieden een mechanisme om het proces van het correct en tijdig toepassen van wijzigingen te automatiseren.
- Convergentie: Kubernetes zal updates blijven proberen totdat dit succesvol is.
- Idempotentie: Herhaalde toepassingen van convergentie leiden tot hetzelfde resultaat.
- Determinisme: Wanneer er voldoende bronnen zijn, hangt de status van het bijgewerkte cluster alleen af van de gewenste status.
Hoe GitOps werkt
We hebben genoeg over Kubernetes geleerd om uit te leggen hoe GitOps werkt.
Laten we terugkeren naar de microservicesteams van Family Insurance. Wat moeten ze meestal doen? Kijk eens naar de onderstaande lijst (als er items in de lijst vreemd of onbekend voorkomen, aarzel dan niet om kritiek te leveren en blijf bij ons). Dit zijn slechts voorbeelden van op Jenkins gebaseerde workflows. Er zijn veel andere processen bij het werken met andere tools.
Het belangrijkste is dat we zien dat elke update eindigt met wijzigingen in de configuratiebestanden en Git-repository's. Deze wijzigingen in Git zorgen ervoor dat de "GitOps-operator" het cluster bijwerkt:
1.Werkproces: "Jenkins build - master-branch.
Takenlijst:
- Jenkins pusht getagde afbeeldingen naar Quay;
- Jenkins pusht configuratie- en Helm-diagrammen naar de hoofdopslagbucket;
- De cloudfunctie kopieert de configuratie en grafieken van de masteropslagbucket naar de master Git-repository;
- De GitOps-operator werkt het cluster bij.
2. Jenkins build - release of hotfix-branch:
- Jenkins pusht niet-gelabelde afbeeldingen naar Quay;
- Jenkins pusht configuratie- en Helm-diagrammen naar de staging-opslagbucket;
- De cloudfunctie kopieert de configuratie en grafieken van de staging-opslagbucket naar de staging Git-repository;
- De GitOps-operator werkt het cluster bij.
3. Jenkins build - ontwikkel of feature branch:
- Jenkins pusht niet-gelabelde afbeeldingen naar Quay;
- Jenkins pusht configuratie- en Helm-diagrammen naar de ontwikkelopslagbucket;
- De cloudfunctie kopieert de configuratie en grafieken van de ontwikkelopslagbucket naar de ontwikkel Git-repository;
- De GitOps-operator werkt het cluster bij.
4. Een nieuwe klant toevoegen:
- De manager of beheerder (LCM/ops) belt Gradle om in eerste instantie netwerkload balancers (NLB's) te implementeren en te configureren;
- LCM/ops voert een nieuwe configuratie uit om de implementatie voor te bereiden op updates;
- De GitOps-operator werkt het cluster bij.
Korte beschrijving van GitOps
- Beschrijf de gewenste staat van het hele systeem met behulp van declaratieve specificaties voor elke omgeving (in ons verhaal definieert het team van Bob de volledige systeemconfiguratie in Git).
- De Git-repository is de enige bron van waarheid over de gewenste staat van het hele systeem.
- Alle wijzigingen in de gewenste status worden aangebracht via commits in Git.
- Alle gewenste clusterparameters zijn ook in het cluster zelf waarneembaar. Op deze manier kunnen we bepalen of ze samenvallen (convergeren, convergeren) of verschillen (divergeren, afwijken) gewenste en waargenomen toestanden.
- Als de gewenste en waargenomen toestanden verschillen, dan:
- Er bestaat een convergentiemechanisme dat vroeg of laat automatisch de doel- en waargenomen toestanden synchroniseert. Binnen het cluster doet Kubernetes dit.
- Het proces start onmiddellijk met een ‘change commited’-waarschuwing.
- Na een configureerbare tijdsperiode kan er een "diff"-waarschuwing worden verzonden als de statussen verschillend zijn.
- Op deze manier veroorzaken alle commits in Git verifieerbare en idempotente updates voor het cluster.
- Terugdraaien is convergentie naar een eerder gewenste toestand.
- De convergentie is definitief. Het voorkomen ervan wordt aangegeven door:
- Geen diff-waarschuwingen gedurende een bepaalde periode.
- "geconvergeerde" waarschuwing (bijv. webhook, Git-terugschrijfgebeurtenis).
Wat is divergentie?
Laten we het nog een keer herhalen: alle gewenste clustereigenschappen moeten waarneembaar zijn in het cluster zelf.
Enkele voorbeelden van divergentie:
- Wijziging in configuratiebestand vanwege het samenvoegen van branches in Git.
- Een wijziging in het configuratiebestand als gevolg van een Git-commit gemaakt door de GUI-client.
- Meerdere wijzigingen in de gewenste status als gevolg van PR in Git, gevolgd door het bouwen van de containerimage en configuratiewijzigingen.
- Een verandering in de status van het cluster als gevolg van een fout, een bronconflict dat resulteert in "slecht gedrag", of eenvoudigweg een willekeurige afwijking van de oorspronkelijke staat.
Wat is het mechanisme van convergentie?
Een paar voorbeelden:
- Voor containers en clusters wordt het convergentiemechanisme geleverd door Kubernetes.
- Hetzelfde mechanisme kan worden gebruikt voor het beheren van op Kubernetes gebaseerde applicaties en ontwerpen (zoals Istio en Kubeflow).
- Een mechanisme voor het beheren van de operationele interactie tussen Kubernetes, beeldopslagplaatsen en Git , dat deel uitmaakt .
- Voor basismachines moet het convergentiemechanisme declaratief en autonoom zijn. Uit eigen ervaring kunnen wij dat zeggen die het dichtst bij deze definitie ligt, maar nog steeds menselijke controle vereist. In die zin breidt GitOps de traditie van Infrastructure as Code uit.
GitOps combineert Git met de uitstekende convergentie-engine van Kubernetes om een exploitatiemodel te bieden.
Met GitOps kunnen we zeggen: Alleen die systemen die kunnen worden beschreven en waargenomen, kunnen worden geautomatiseerd en gecontroleerd.
GitOps is bedoeld voor de gehele cloud-native stack (bijvoorbeeld Terraform, etc.)
GitOps is niet alleen Kubernetes. We willen dat het hele systeem declaratief wordt aangestuurd en gebruik maakt van convergentie. Met het hele systeem bedoelen we een verzameling omgevingen die met Kubernetes werken, bijvoorbeeld ‘dev cluster 1’, ‘productie’, enz. Elke omgeving omvat machines, clusters, applicaties, maar ook interfaces voor externe services die gegevens en monitoring leveren. en enz.
Merk op hoe belangrijk Terraform in dit geval is voor het bootstrapping-probleem. Kubernetes moet ergens worden ingezet, en met behulp van Terraform kunnen we dezelfde GitOps-workflows toepassen om de controlelaag te creëren die ten grondslag ligt aan Kubernetes en applicaties. Dit is een nuttige best practice.
Er is een sterke focus op het toepassen van GitOps-concepten op lagen bovenop Kubernetes. Op dit moment zijn er oplossingen van het GitOps-type voor Istio, Helm, Ksonnet, OpenFaaS en Kubeflow, maar ook bijvoorbeeld voor Pulumi, die een laag creëren voor het ontwikkelen van applicaties voor cloud-native.
Kubernetes CI/CD: GitOps vergelijken met andere benaderingen
Zoals gezegd bestaat GitOps uit twee dingen:
- Het hierboven beschreven besturingsmodel voor Kubernetes en cloud native.
- Het pad naar een op ontwikkelaars gerichte applicatiebeheeromgeving.
Voor velen is GitOps vooral een workflow gebaseerd op Git-pushes. Wij vinden hem ook leuk. Maar dat is nog niet alles: laten we nu eens kijken naar CI/CD-pijplijnen.
GitOps maakt continue implementatie (CD) voor Kubernetes mogelijk
GitOps biedt een mechanisme voor continue implementatie dat de noodzaak voor afzonderlijke ‘implementatiebeheersystemen’ elimineert. Kubernetes doet al het werk voor u.
- Voor het updaten van de applicatie is een update in Git vereist. Dit is een transactionele update naar de gewenste status. “Deployment” wordt vervolgens binnen het cluster door Kubernetes zelf gedaan op basis van de bijgewerkte beschrijving.
- Vanwege de aard van de manier waarop Kubernetes werkt, zijn deze updates convergent. Dit biedt een mechanisme voor continue implementatie waarbij alle updates atomair zijn.
- Opmerking: biedt een GitOps-operator die Git en Kubernetes integreert en het mogelijk maakt CD uit te voeren door de gewenste en huidige status van het cluster op elkaar af te stemmen.
Zonder kubectl en scripts
U moet voorkomen dat u Kubectl gebruikt om uw cluster bij te werken, en vooral voorkomen dat u scripts gebruikt om kubectl-opdrachten te groeperen. In plaats daarvan kan een gebruiker met de GitOps-pijplijn zijn Kubernetes-cluster updaten via Git.
Voordelen zijn onder meer:
- Rechts. Een groep updates kan worden toegepast, geconvergeerd en uiteindelijk gevalideerd, waardoor we dichter bij het doel van atomaire inzet komen. Daarentegen biedt het gebruik van scripts geen enkele garantie voor convergentie (meer hierover hieronder).
- veiligheid. Kelsey Hightower: “Beperk de toegang tot uw Kubernetes-cluster tot automatiseringstools en beheerders die verantwoordelijk zijn voor het debuggen of onderhouden ervan.” zie ook over veiligheid en naleving van technische specificaties, evenals door inloggegevens te stelen uit een achteloos geschreven Jenkins-script.
- Gebruikerservaring. Kubectl legt de werking van het Kubernetes-objectmodel bloot, die behoorlijk complex zijn. Idealiter zouden gebruikers op een hoger abstractieniveau met het systeem moeten communiceren. Hier zal ik opnieuw naar Kelsey verwijzen en aanbevelen om te kijken .
Verschil tussen CI en CD
GitOps verbetert bestaande CI/CD-modellen.
Een moderne CI-server is een orkestratietool. Het is met name een hulpmiddel voor het orkestreren van CI-pijplijnen. Deze omvatten bouwen, testen, samenvoegen met trunk, enz. CI-servers automatiseren het beheer van complexe meerstapspijplijnen. Een veel voorkomende verleiding is om een set Kubernetes-updates te scripten en deze uit te voeren als onderdeel van een pijplijn om wijzigingen naar het cluster te pushen. Dit is inderdaad wat veel experts doen. Dit is echter niet optimaal, en dit is de reden.
CI moet worden gebruikt om updates naar de trunk te pushen, en het Kubernetes-cluster moet zichzelf veranderen op basis van die updates om de CD intern te beheren. We noemen het , in tegenstelling tot het CI-pushmodel. Cd is onderdeel runtime-orkestratie.
Waarom CI-servers geen cd's zouden moeten maken via directe updates in Kubernetes
Gebruik geen CI-server om directe updates naar Kubernetes te orkestreren als een set CI-taken. Dit is het antipatroon waar we het over hebben op je blog.
Laten we teruggaan naar Alice en Bob.
Met welke problemen werden zij geconfronteerd? De CI-server van Bob past de wijzigingen toe op het cluster, maar als deze daarbij crasht, weet Bob niet in welke staat het cluster zich bevindt (of zou moeten zijn) of hoe hij dit kan repareren. Hetzelfde geldt bij succes.
Laten we aannemen dat het team van Bob een nieuwe image heeft gebouwd en vervolgens hun implementaties heeft gepatcht om de image te implementeren (allemaal vanuit de CI-pijplijn).
Als het beeld normaal wordt opgebouwd, maar de pijplijn faalt, zal het team het volgende moeten uitzoeken:
- Is de update uitgerold?
- Gaan we een nieuwbouw lanceren? Zal dit tot onnodige bijwerkingen leiden - met de mogelijkheid om twee builds van hetzelfde onveranderlijke beeld te hebben?
- Moeten we wachten op de volgende update voordat we de build uitvoeren?
- Wat ging er precies mis? Welke stappen moeten worden herhaald (en welke kunnen veilig worden herhaald)?
Het opzetten van een op Git gebaseerde workflow garandeert niet dat Bobs team deze problemen niet zal tegenkomen. Ze kunnen nog steeds een fout maken met de commit push, de tag of een andere parameter; deze benadering ligt echter nog steeds veel dichter bij een expliciete alles-of-niets-benadering.
Samenvattend is dit de reden waarom CI-servers niet met CD zouden moeten omgaan:
- Updatescripts zijn niet altijd deterministisch; Het is gemakkelijk om daarin fouten te maken.
- CI-servers convergeren niet naar het declaratieve clustermodel.
- Idempotentie is moeilijk te garanderen. Gebruikers moeten de diepe semantiek van het systeem begrijpen.
- Het is moeilijker om te herstellen van een gedeeltelijke storing.
Opmerking over Helm: Als je Helm wilt gebruiken, raden we je aan deze te combineren met een GitOps-operator zoals . Dit zal de convergentie helpen waarborgen. Helm zelf is noch deterministisch, noch atomair.
GitOps als de beste manier om Continuous Delivery voor Kubernetes te implementeren
Het team van Alice en Bob implementeert GitOps en ontdekt dat het veel eenvoudiger is geworden om met softwareproducten te werken en hoge prestaties en stabiliteit te behouden. Laten we dit artikel afsluiten met een illustratie die laat zien hoe hun nieuwe aanpak eruit ziet. Houd er rekening mee dat we het vooral over applicaties en services hebben, maar GitOps kan worden gebruikt om een heel platform te beheren.
Bedrijfsmodel voor Kubernetes
Kijk naar het volgende diagram. Het presenteert Git en de containerimagerepository als gedeelde bronnen voor twee georkestreerde levenscycli:
- Een continue integratiepijplijn die bestanden leest en schrijft naar Git en een repository met containerimages kan bijwerken.
- Een Runtime GitOps-pijplijn die implementatie combineert met beheer en observatie. Het leest en schrijft bestanden naar Git en kan containerimages downloaden.
Wat zijn de belangrijkste bevindingen?
- Scheiding van zorgen: Houd er rekening mee dat beide pijplijnen alleen kunnen communiceren door Git of de afbeeldingsrepository bij te werken. Met andere woorden: er is een firewall tussen CI en de runtime-omgeving. We noemen het de ‘onveranderlijkheidsfirewall’ (onveranderlijkheid firewall), aangezien alle repository-updates nieuwe versies creëren. Voor meer informatie over dit onderwerp, zie slides 72-87 .
- U kunt elke CI- en Git-server gebruiken: GitOps werkt met elk onderdeel. U kunt uw favoriete CI- en Git-servers, beeldopslagplaatsen en testsuites blijven gebruiken. Bijna alle andere Continuous Delivery-tools op de markt vereisen hun eigen CI/Git-server of beeldrepository. Dit kan een beperkende factor worden in de ontwikkeling van cloud native. Met GitOps kun je gebruik maken van bekende tools.
- Evenementen als integratietool: Zodra gegevens in Git worden bijgewerkt, meldt Weave Flux (of de Weave Cloud-operator) de runtime. Telkens wanneer Kubernetes een wijzigingsset accepteert, wordt Git bijgewerkt. Dit biedt een eenvoudig integratiemodel voor het organiseren van workflows voor GitOps, zoals hieronder weergegeven.
Conclusie
GitOps biedt de sterke updategaranties die vereist zijn voor elke moderne CI/CD-tool:
- automatisering;
- convergentie;
- idempotentie;
- determinisme.
Dit is belangrijk omdat het een operationeel model biedt voor cloud-native ontwikkelaars.
- Traditionele tools voor het beheren en monitoren van systemen worden geassocieerd met operationele teams die binnen een runbook opereren (een reeks routinematige procedures en operaties - ca. vert.), gekoppeld aan een specifieke implementatie.
- Bij cloud-native beheer zijn observatietools de beste manier om de resultaten van implementaties te meten, zodat het ontwikkelteam snel kan reageren.
Stel je voor dat er veel clusters verspreid zijn over verschillende clouds en veel services met hun eigen teams en implementatieplannen. GitOps biedt een schaal-invariant model voor het beheren van al deze overvloed.
PS van vertaler
Lees ook op onze blog:
- «";
- «";
- «.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Kende jij al van GitOps voordat deze twee vertalingen op Habré verschenen?
-
Ja, ik wist alles
-
Alleen oppervlakkig
-
Geen
35 gebruikers hebben gestemd. 10 gebruikers onthielden zich van stemming.
Bron: www.habr.com