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.

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 opslagplaats roepen een PULL- of CI-pijplijn aan waarmee het implementatieproces wordt gestart.

Containerregister

Het containerregister bevat alle installatiekopieën van derden die worden gebruikt in de Kubernetes-omgevingen. Eigen toepassingsinstallatiekopieën worden getagd met door mensen leesbare tags en de Git-doorvoering die wordt gebruikt om de installatiekopieën 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 die naar de toepassingsopslagplaats worden verzonden, worden gegateed bij een geslaagde uitvoering van de PULL-pijplijn. Met deze pijplijn worden de basiskwaliteitspoorten uitgevoerd, zoals linting en eenheidstests voor de toepassingscode. De pijplijn test de toepassing en lints Dockerfiles en Helm-sjablonen die worden gebruikt voor implementatie in een Kubernetes-omgeving. Docker-installatiekopieën moeten worden gebouwd en getest, maar niet gepusht. Houd de duur van de pijplijn relatief kort om snelle iteratie mogelijk te maken.

CI-pijplijn

De CI-pijplijn van de toepassing voert alle stappen voor pull-aanvragen uit, zodat de tests en implementatiecontroles worden uitgebreid. De pijplijn kan worden uitgevoerd voor elke doorvoering naar de hoofdmap of kan worden uitgevoerd met een regelmatige frequentie met een groep doorvoeringen.

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-pijplijn

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 Verbinding maken or 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 toepassingswijziging wil aanbrengen die de Docker-installatiekopieën wijzigt die worden gebruikt in de toepassingsimplementatiesjabloon.

1. Alice wijzigt de implementatiesjabloon, pusht deze naar een externe vertakking die wordt aangeroepen alice in de toepassingsopslagplaats en opent een pull-aanvraag voor controle op basis van de main vertakking.

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

   • De PULL-pijplijn voert validatie uit.
   • Na een geslaagde pull-pijplijnuitvoering en goedkeuring van het team wordt de wijziging samengevoegd.

3. De CI-pijplijn wordt vervolgens gestart en valideert de wijziging van Alice en wordt voltooid.

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

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-aanvraag voor de productievertakking 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-installatiekopieën vereist de toepassingspod een update.
   • Flux past de wijziging toe op het cluster.
   • Flux rapporteert de implementatiestatus terug naar de GitOps-opslagplaats via GitOps Verbinding maken or.

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

   Notitie

   Voor aanvullende omgevingen die zijn gericht op implementatie, wordt de CD-pijplijn herhaald door een pull-aanvraag voor de volgende omgeving te maken en herhaalt u stap 4-7. 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.