CI/CD-werkstroom met GitOps (Flux v2)

Moderne Kubernetes-implementaties bevatten meerdere toepassingen, clusters en omgevingen. Met GitOps kunt u deze complexe instellingen eenvoudiger beheren, waarbij u de gewenste status van de Kubernetes-omgevingen declaratief bijhoudt met Git. Met behulp van veelgebruikte Git-hulpprogramma's om de clusterstatus te declareren, kunt u de verantwoordelijkheid vergroten, foutonderzoek vergemakkelijken en automatisering inschakelen voor het beheren van omgevingen.

In dit artikel wordt beschreven hoe GitOps past in de volledige levenscyclus van toepassingswijziging met behulp van Azure Arc, Azure-opslagplaatsen en Azure Pipelines. Het biedt ook een voorbeeld van één toepassingswijziging in door GitOps beheerde Kubernetes-omgevingen.

Architectuur

In dit diagram ziet u de CI/CD-werkstroom voor een toepassing die is geïmplementeerd in een of meer Kubernetes-omgevingen.

Als u architectuurdiagrammen in hoge resolutie wilt downloaden, gaat u naar Jumpstart Gems.

Opslagplaats voor toepassingscode

De toepassingsopslagplaats bevat de toepassingscode waaraan ontwikkelaars werken tijdens hun interne lus. De implementatiesjablonen van de toepassing bevinden zich in deze opslagplaats in een algemene vorm, zoals Helm of Kustomize. Omgevingsspecifieke waarden worden niet opgeslagen in de opslagplaats.

Wijzigingen in deze repository roepen een PR- of CI-pijplijn aan die het implementatieproces start.

Containerregistratie

Het containerregister bevat alle eerste- en derde-partij afbeeldingen die worden gebruikt in de Kubernetes-omgevingen. Eersteklas toepassingsafbeeldingen worden getagd met voor mensen leesbare tags en de Git commit die is gebruikt om de afbeelding te bouwen. Afbeeldingen van derden kunnen in de cache worden opgeslagen om u te helpen bij beveiliging, snelheid en tolerantie. Stel een plan in voor tijdige tests en integratie van beveiligingsupdates.

Zie Openbare inhoud gebruiken en onderhouden met Azure Container Registry-taken voor meer informatie.

PR-pijplijn

Pull-aanvragen van ontwikkelaars aan het applicatierepository zijn afhankelijk van een succesvolle uitvoering van de PR-pijplijn. Met deze pijplijn worden de basiskwaliteitspoorten uitgevoerd, zoals linting en eenheidstests voor de toepassingscode. De pijplijn test de toepassing en controleert op linting van Helm-sjablonen en Dockerfiles die worden gebruikt voor de implementatie in een Kubernetes-omgeving. Docker-images moeten worden gebouwd en getest, maar niet doorgestuurd. Houd de duur van de pijplijn relatief kort om snelle iteratie mogelijk te maken.

CI-pijplijn

De CI-pijplijn van de applicatie voert alle stappen van de pull request-pijplijn uit, waarbij tests en implementatiecontroles worden uitgebreid en geoptimaliseerd. De pijplijn kan worden uitgevoerd voor elke commit naar de hoofdtak, of kan worden uitgevoerd met regelmatige tussenpozen met een groep commits.

In deze fase kunnen toepassingstests die te veel worden gebruikt voor de PULL-pijplijn worden uitgevoerd, waaronder:

• Installatiekopieën naar containerregister pushen
• Afbeeldingen bouwen, linten en testen
• Sjabloongeneratie van onbewerkte YAML-bestanden

Aan het einde van de CI-build worden artefacten gegenereerd. Deze artefacten kunnen door de CD-stap worden gebruikt om te gebruiken ter voorbereiding op de implementatie.

Flux-clusterextensie

Flux is een agent die in elk cluster wordt uitgevoerd als clusterextensie. Deze Flux-clusterextensie is verantwoordelijk voor het onderhouden van de gewenste status. De agent peilt de GitOps-opslagplaats met een door de gebruiker gedefinieerd interval en past vervolgens de clusterstatus af met de status die is gedeclareerd in de Git-opslagplaats.

Zie Zelfstudie: Toepassingen implementeren met GitOps met Flux v2 voor meer informatie.

CD-pipeline

De CD-pijplijn wordt automatisch geactiveerd door geslaagde CI-builds. In deze pijplijnomgeving worden omgevingsspecifieke waarden vervangen door de eerder gepubliceerde sjablonen en wordt er een nieuwe pull-aanvraag gegenereerd voor de GitOps-opslagplaats met deze waarden. Deze pull-aanvraag bevat de voorgestelde wijzigingen in de gewenste status van een of meer Kubernetes-clusters. Clusterbeheerders controleren de pull-aanvraag en keuren de samenvoeging goed naar de GitOps-opslagplaats. De pijplijn wacht totdat de pull-aanvraag is samengevoegd, waarna Flux wordt gesynchroniseerd en de statuswijzigingen toepast.

GitOps-opslagplaats

De GitOps-opslagplaats vertegenwoordigt de huidige gewenste status van alle omgevingen in clusters. Elke wijziging in deze opslagplaats wordt door de Flux-service in elk cluster opgehaald en geïmplementeerd. Wijzigingen in de gewenste status van de clusters worden weergegeven als pull-aanvragen, die vervolgens worden gecontroleerd en uiteindelijk worden samengevoegd na goedkeuring van de wijzigingen. Deze pull-aanvragen bevatten wijzigingen in implementatiesjablonen en de resulterende Kubernetes-manifesten. Met weergavemanifesten op laag niveau is een zorgvuldigere controle mogelijk van wijzigingen die doorgaans niet zichtbaar zijn op sjabloonniveau.

GitOps-connector

GitOps Connector maakt een verbinding tussen de Flux-agent en de GitOps-opslagplaats/CD-pijplijn. Terwijl wijzigingen worden toegepast op het cluster, meldt Flux de GitOps-connector van elke fasewijziging en statuscontrole die wordt uitgevoerd. Dit onderdeel fungeert als een adapter. Het begrijpt hoe u communiceert met een Git-opslagplaats en de Git-doorvoerstatus wordt bijgewerkt, zodat de synchronisatievoortgang zichtbaar is in de GitOps-opslagplaats. Wanneer de implementatie is voltooid (of deze nu slaagt of mislukt), meldt de connector de CD-pijplijn om door te gaan, zodat de pijplijn na de implementatie activiteiten kan uitvoeren, zoals integratietests.

Kubernetes-clusters

Ten minste één Kubernetes- of AKS-cluster (Azure Kubernetes Service) met Azure Arc fungeert voor de verschillende omgevingen die nodig zijn voor de toepassing. Eén cluster kan bijvoorbeeld zowel een ontwikkelomgeving als een QA-omgeving leveren via verschillende naamruimten. Een tweede cluster kan een eenvoudigere scheiding van omgevingen en meer verfijnde controle bieden.

Voorbeeldwerkstroom

Als toepassingsontwikkelaar, Alice:

• Hiermee schrijft u toepassingscode.
• Bepaalt hoe u de toepassing uitvoert in een Docker-container.
• Definieert de sjablonen die de container en afhankelijke services uitvoeren in een Kubernetes-cluster.

Alice wil ervoor zorgen dat de toepassing de mogelijkheid heeft om in meerdere omgevingen uit te voeren, maar ze weet de specifieke instellingen voor elke omgeving niet.

Stel dat Alice een wijziging aan de applicatie wil doorvoeren die het Docker-image wijzigt dat wordt gebruikt in het applicatiedeploymentsjabloon.

1. Alice wijzigt de implementatiesjabloon, pusht deze naar een externe vertakking genaamd alice in de toepassingsopslagplaats en opent een pull request voor controle tegen de main vertakking.

2. Alice vraagt haar team om de wijziging te controleren.

   • De PR-pijplijn doorloopt validatie.
   • Na een geslaagde PR-pijplijnuitvoering en goedkeuring van het team, wordt de wijziging doorgevoerd.

3. De CI-pijplijn start vervolgens op, valideert de wijziging van Alice en wordt succesvol afgerond.

   • De wijziging is veilig te implementeren in het cluster en de artefacten worden opgeslagen in de CI-pijplijnrun.

4. De geslaagde CI-pijplijnuitvoering activeert de CD-pijplijn.

   • De CD-pijplijn haalt de artefacten op die zijn opgeslagen door de CI-pijplijnuitvoering van Alice.
   • De CD-pijplijn vervangt de sjablonen door omgevingsspecifieke waarden en faseert eventuele wijzigingen ten opzichte van de bestaande clusterstatus in de GitOps-opslagplaats.
   • De CD-pijplijn maakt een pull request aan voor de productietak van de GitOps-opslagplaats met de gewenste wijzigingen in de clusterstatus.

5. Het team van Alice beoordeelt en keurt haar pull-aanvraag goed.

   • De wijziging wordt samengevoegd in de doelbranch die overeenkomt met de omgeving.

6. Binnen enkele minuten ziet Flux een wijziging in de GitOps-opslagplaats en haalt de wijziging van Alice op.

   • Vanwege de wijziging van de Docker-image moet de toepassingspod een update krijgen.
   • Flux past de wijziging toe op het cluster.
   • Flux rapporteert de implementatiestatus terug naar de GitOps-opslagplaats via GitOps Connector.

7. De CD-pijplijn voert geautomatiseerde tests uit om te controleren of de nieuwe implementatie is voltooid en werkt zoals verwacht.

   Notitie

   Voor extra omgevingen die zijn bestemd voor implementatie, herhaalt de CD-pijplijn door een pull-verzoek voor de volgende omgeving aan te maken en stap 4-7 te herhalen. Het proces heeft veel extra goedkeuring nodig voor riskante implementaties of omgevingen, zoals een beveiligingsgerelateerde wijziging of een productieomgeving.

8. Wanneer alle omgevingen geslaagde implementaties hebben ontvangen, wordt de pijplijn voltooid.

Volgende stappen

• Doorloop onze zelfstudie voor het implementeren van CI/CD met GitOps.
• Meer informatie over het maken van verbindingen tussen uw cluster en een Git-opslagplaats met Flux-configuraties.