CI/CD-werkstroom met Behulp van GitOps - Kubernetes met Azure Arc

Belangrijk

De werkstroom die in dit document wordt beschreven, maakt gebruik van GitOps met Flux v1. GitOps met Flux v2 is nu beschikbaar voor Azure Arc-clusters met Kubernetes en Azure Kubernetes Service (AKS). meer informatie over CI/CD-werkstroom met GitOps met Flux v2. U wordt aangeraden zo snel mogelijk naar Flux v2 te migreren.

Ondersteuning voor op Flux v1 gebaseerde clusterconfiguratiebronnen die vóór 1 januari 2024 zijn gemaakt, eindigt op 24 mei 2025. Vanaf 1 januari 2024 kunt u geen nieuwe op Flux v1 gebaseerde clusterconfiguratiebronnen maken.

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 voor het bijhouden van de clusterstatus kunt u de verantwoordelijkheid vergroten, foutonderzoek vergemakkelijken en automatisering inschakelen voor het beheren van omgevingen.

In dit conceptuele overzicht wordt GitOps uitgelegd als een realiteit in de volledige levenscyclus van toepassingswijziging met behulp van Azure Arc, Azure Repos en Azure Pipelines. Ga naar een voorbeeld van een wijziging van één toepassing in door GitOps beheerde Kubernetes-omgevingen.

Architectuur

Overweeg een toepassing die is geïmplementeerd in een of meer Kubernetes-omgevingen.

Toepassingsopslagplaats

De toepassingsopslagplaats bevat de toepassingscode waaraan ontwikkelaars werken tijdens hun binnenste lus. De implementatiesjablonen van de toepassing bevinden zich in deze opslagplaats in een algemene vorm, zoals Helm of Kustomize. Omgevingsspecifieke waarden worden niet opgeslagen. Wijzigingen in deze opslagplaats roepen een PULL- of CI-pijplijn aan waarmee het implementatieproces wordt gestart.

Container Registry

Het containerregister bevat alle installatiekopieën van derden die worden gebruikt in de Kubernetes-omgevingen. Tag first party application images with human readable tags and the Git commit used to build the image. Cache-installatiekopieën van derden voor beveiliging, snelheid en tolerantie. Stel een plan in voor tijdige tests en integratie van beveiligingsupdates. Zie de handleiding voor openbare inhoud gebruiken en onderhouden voor meer informatie.

PR-pijplijn

Pull-aanvragen naar de opslagplaats van de toepassing worden gated 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 de PULL-pijplijn uit en breidt de tests en implementatiecontroles uit. De pijplijn kan worden uitgevoerd voor elke doorvoering of met een regelmatige frequentie met een groep doorvoeringen. Voer in deze fase toepassingstests uit die te lang zijn voor een PULL-pijplijn. Push Docker-installatiekopieën naar het Container Registry nadat u de implementatie hebt voorbereid. De vervangen sjabloon kan worden voorzien van een set testwaarden. Installatiekopieën die tijdens de serviceruntime worden gebruikt, moeten op dit moment worden ontworpen, gebouwd en getest. In de CI-build worden artefacten gepubliceerd voor de CD-stap die moet worden gebruikt ter voorbereiding op de implementatie.

Flux

Flux is een service die in elk cluster wordt uitgevoerd en verantwoordelijk is voor het onderhouden van de gewenste status. De service controleert regelmatig de GitOps-opslagplaats op wijzigingen in het cluster en past deze toe.

CD-pijplijn

De CD-pijplijn wordt automatisch geactiveerd door geslaagde CI-builds. Deze maakt gebruik van de eerder gepubliceerde sjablonen, vervangt omgevingswaarden en opent een pull-aanvraag naar de GitOps-opslagplaats om een wijziging aan te vragen in de gewenste status van een of meer Kubernetes-clusters. Clusterbeheerders controleren de pull-aanvraag voor statuswijziging en keuren de samenvoeging goed naar de GitOps-opslagplaats. De pijplijn wacht vervolgens totdat de pull-aanvraag is voltooid, waardoor Flux de statuswijziging kan ophalen.

GitOps-opslagplaats

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

Kubernetes-clusters

Ten minste één Kubernetes-cluster met Azure Arc biedt 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.

Hoewel Alice weet dat de toepassing de mogelijkheid nodig heeft om in meerdere omgevingen te kunnen worden uitgevoerd, weet ze niet welke specifieke instellingen voor elke omgeving er zijn.

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 in de toepassingsopslagplaats en opent een pull-aanvraag voor controle.
2. Alice vraagt haar team om de wijziging te controleren.
   • De PULL-pijplijn voert validatie uit.
   • Nadat de pijplijn is uitgevoerd, meldt het team zich af en wordt de wijziging samengevoegd.
3. De CI-pijplijn valideert de wijziging van Alice en is voltooid.
   • De wijziging is veilig om te implementeren in het cluster en de artefacten worden opgeslagen in de CI-pijplijnuitvoering.
4. De wijzigingssamenvoegingen van Alice en 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 in de bestaande clusterstatus in de GitOps-opslagplaats.
   • De CD-pijplijn maakt een pull-aanvraag voor 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.
7. Alice test het toepassingseindpunt om te controleren of de implementatie is voltooid.

   Notitie

   Voor meer omgevingen die zijn gericht op implementatie, herhaalt de CD-pijplijn 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. Zodra alle omgevingen geslaagde implementaties hebben ontvangen, wordt de pijplijn voltooid.

Volgende stappen

Meer informatie over het maken van verbindingen tussen uw cluster en een Git-opslagplaats als een configuratieresource met Kubernetes met Azure Arc