CI/CD-arbetsflöde med GitOps (Flux v2)

  • Artikel

Moderna Kubernetes-distributioner innehåller flera program, kluster och miljöer. Med GitOps kan du hantera dessa komplexa installationer enklare och spåra det önskade tillståndet för Kubernetes-miljöerna deklarativt med Git. Med hjälp av vanliga Git-verktyg för att deklarera klustertillstånd kan du öka ansvarsskyldigheten, underlätta felundersökning och aktivera automatisering för att hantera miljöer.

Den här artikeln beskriver hur GitOps passar in i hela livscykeln för programändring med hjälp av Azure Arc, Azure Repos och Azure Pipelines. Det ger också ett exempel på en enda programändring till GitOps-kontrollerade Kubernetes-miljöer.

Arkitektur

Det här diagrammet visar CI/CD-arbetsflödet för ett program som distribuerats till en eller flera Kubernetes-miljöer.

Diagram som visar GitOps CI/CD-arkitektur.

Lagringsplats för programkod

Programlagringsplatsen innehåller den programkod som utvecklare arbetar med under sin inre loop. Programmets distributionsmallar finns på den här lagringsplatsen i ett allmänt format, till exempel Helm eller Kustomize. Miljöspecifika värden lagras inte på lagringsplatsen.

Ändringar av den här lagringsplatsen anropar en PR- eller CI-pipeline som startar distributionsprocessen.

Containerregister

Containerregistret innehåller alla avbildningar från första och tredje part som används i Kubernetes-miljöerna. Programbilder från första part taggas med läsbara taggar och Git-incheckningen som används för att skapa avbildningen. Bilder från tredje part kan cachelagras för att hjälpa till med säkerhet, hastighet och motståndskraft. Ange en plan för snabb testning och integrering av säkerhetsuppdateringar.

Mer information finns i Använda och underhålla offentligt innehåll med Azure Container Registry Tasks.

PR-pipeline

Pull-begäranden från utvecklare som görs till programlagringsplatsen är gated på en lyckad körning av PR-pipelinen. Den här pipelinen kör de grundläggande kvalitetsgrindarna, till exempel lintning och enhetstester i programkoden. Pipelinen testar programmet och lints Dockerfiles och Helm-mallar som används för distribution till en Kubernetes-miljö. Docker-avbildningar bör skapas och testas, men inte push-överföras. Håll pipelinens varaktighet relativt kort för att möjliggöra snabb iteration.

CI-pipeline

Program-CI-pipelinen kör alla PR-pipelinesteg och expanderar test- och distributionskontrollerna. Pipelinen kan köras för varje incheckning till huvudservern, eller så kan den köras regelbundet med en grupp incheckningar.

I det här skedet kan programtester som är för tidskrävande för PR-pipelinen utföras, inklusive:

  • Skicka avbildningar till containerregistret
  • Bildskapande, lintning och testning
  • Mallgenerering av råa YAML-filer

I slutet av CI-versionen genereras artefakter. Dessa artefakter kan användas av CD-steget för att använda inför distributionen.

Flux-klustertillägg

Flux är en agent som körs i varje kluster som ett klustertillägg. Det här Flux-klustertillägget ansvarar för att upprätthålla önskat tillstånd. Agenten avsöker GitOps-lagringsplatsen med ett användardefinierat intervall och avstämr sedan klustertillståndet med tillståndet som deklarerats i Git-lagringsplatsen.

Mer information finns i Självstudie: Distribuera program med GitOps med Flux v2.

CD-pipeline

CD-pipelinen utlöses automatiskt av lyckade CI-versioner. I den här pipelinemiljön ersätts miljöspecifika värden i de tidigare publicerade mallarna och en ny pull-begäran skickas mot GitOps-lagringsplatsen med dessa värden. Den här pull-begäran innehåller de föreslagna ändringarna i önskat tillstånd för ett eller flera Kubernetes-kluster. Klusteradministratörer granskar pull-begäran och godkänner kopplingen till GitOps-lagringsplatsen. Pipelinen väntar på att pull-begäran ska slås samman, varefter Flux synkroniserar och tillämpar tillståndsändringarna.

GitOps-lagringsplats

GitOps-lagringsplatsen representerar det aktuella önskade tillståndet för alla miljöer i kluster. Alla ändringar av den här lagringsplatsen hämtas av Flux-tjänsten i varje kluster och distribueras. Ändringar i det önskade tillståndet för klustren visas som pull-begäranden, som sedan granskas och slutligen sammanfogas när ändringarna godkänns. Dessa pull-begäranden innehåller ändringar i distributionsmallar och resulterande renderade Kubernetes-manifest. Lågnivåmanifest gör det möjligt att noggrant granska ändringar som vanligtvis inte visas på mallnivå.

GitOps-anslutningsprogram

GitOps Connector skapar en anslutning mellan Flux-agenten och GitOps-lagringsplatsen/CD-pipelinen. Medan ändringar tillämpas på klustret meddelar Flux GitOps-anslutningsappen för varje fasändring och hälsokontroll som utförs. Den här komponenten fungerar som ett kort. Den förstår hur du kommunicerar till en Git-lagringsplats och uppdaterar Git-incheckningsstatusen så att synkroniseringsförloppet visas på GitOps-lagringsplatsen. När distributionen är klar (oavsett om den lyckas eller misslyckas) meddelar anslutningsappen CD-pipelinen att fortsätta så att pipelinen kan utföra aktiviteter efter distributionen, till exempel integreringstestning.

Kubernetes-kluster

Minst ett Azure Arc-aktiverat Kubernetes- eller Azure Kubernetes Service-kluster (AKS) hanterar de olika miljöer som krävs av programmet. Ett enskilt kluster kan till exempel hantera både en utvecklings- och QA-miljö via olika namnområden. Ett andra kluster kan ge enklare separation av miljöer och mer detaljerad kontroll.

Exempelarbetsflöde

Som programutvecklare: Alice:

  • Skriver programkod.
  • Avgör hur programmet ska köras i en Docker-container.
  • Definierar de mallar som kör containern och beroende tjänster i ett Kubernetes-kluster.

Alice vill se till att programmet har möjlighet att köras i flera miljöer, men hon känner inte till de specifika inställningarna för varje miljö.

Anta att Alice vill göra en programändring som ändrar Docker-avbildningen som används i programdistributionsmallen.

  1. Alice ändrar distributionsmallen, push-överför den till en fjärrgren som heter alice i programdatabasen och öppnar en pull-begäran om granskning mot grenen main .

  2. Alice ber sitt team att granska ändringen.

    • PR-pipelinen kör validering.
    • Efter en lyckad PR-pipelinekörning och teamgodkännande sammanfogas ändringen.

  3. CI-pipelinen startar sedan och validerar Alices ändring och slutförs.

    • Ändringen är säker att distribuera till klustret och artefakterna sparas i CI-pipelinekörningen.

  4. Den lyckade CI-pipelinekörningen utlöser CD-pipelinen.

    • CD-pipelinen hämtar artefakterna som lagras av Alice CI-pipelinekörning.
    • CD-pipelinen ersätter mallarna med miljöspecifika värden och fasar eventuella ändringar mot det befintliga klustertillståndet på GitOps-lagringsplatsen.
    • CD-pipelinen skapar en pull-begäran mot produktionsgrenen för GitOps-lagringsplatsen med önskade ändringar i klustertillståndet.

  5. Alice team granskar och godkänner hennes pull-begäran.

    • Ändringen sammanfogas till målgrenen som motsvarar miljön.

  6. Inom några minuter märker Flux en ändring i GitOps-lagringsplatsen och hämtar Alices ändring.

    • På grund av Docker-avbildningsändringen kräver programpodden en uppdatering.
    • Flux tillämpar ändringen på klustret.
    • Flux rapporterar distributionsstatusen tillbaka till GitOps-lagringsplatsen via GitOps Connector.

  7. CD-pipelinen kör automatiserade tester för att verifiera att den nya distributionen har slutförts och fungerar som förväntat.

    Kommentar

    För ytterligare miljöer som är avsedda för distribution itererar CD-pipelinen genom att skapa en pull-begäran för nästa miljö och upprepar steg 4–7. Processen många behöver extra godkännande för mer riskfyllda distributioner eller miljöer, till exempel en säkerhetsrelaterad ändring eller en produktionsmiljö.

  8. När alla miljöer har fått lyckade distributioner slutförs pipelinen.

Nästa steg