CI/CD-arbetsflöde med GitOps – Azure Arc-aktiverade Kubernetes

Viktigt!

Arbetsflödet som beskrivs i det här dokumentet använder GitOps med Flux v1. GitOps med Flux v2 är nu tillgängligt för Azure Arc-aktiverade Kubernetes- och Azure Kubernetes Service-kluster (AKS). lär dig mer om CI/CD-arbetsflöde med GitOps med Flux v2. Vi rekommenderar att du migrerar till Flux v2 så snart som möjligt.

Stöd för Flux v1-baserade klusterkonfigurationsresurser som skapats före den 1 januari 2024 upphör den 24 maj 2025. Från och med den 1 januari 2024 kan du inte skapa nya Flux v1-baserade klusterkonfigurationsresurser.

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 spåra klustertillstånd kan du öka ansvarsskyldigheten, underlätta felundersökning och aktivera automatisering för att hantera miljöer.

Den här konceptuella översikten förklarar GitOps som en verklighet i hela livscykeln för programändring med hjälp av Azure Arc, Azure Repos och Azure Pipelines. Hoppa till ett exempel på en enda programändring till GitOps-kontrollerade Kubernetes-miljöer.

Arkitektur

Överväg att distribuera ett program till en eller flera Kubernetes-miljöer.

Programrepo

Programlagringsplatsen innehåller programkoden som utvecklare arbetar med under sin inre loop. Programmets distributionsmallar finns i den här lagringsplatsen i ett allmänt format, till exempel Helm eller Kustomize. Miljöspecifika värden lagras inte. Ändringar av den här lagringsplatsen anropar en PR- eller CI-pipeline som startar distributionsprocessen.

Container Registry

Containerregistret innehåller alla avbildningar från första och tredje part som används i Kubernetes-miljöerna. Tagga programbilder från första part med läsbara taggar och Git-incheckningen som används för att skapa avbildningen. Cachelagrade bilder från tredje part för säkerhet, hastighet och motståndskraft. Ange en plan för snabb testning och integrering av säkerhetsuppdateringar. Mer information finns i guiden för att använda och underhålla offentligt innehåll i ACR för ett exempel.

PR-pipeline

PR:er till programrepo ä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 utökar test- och distributionskontrollerna. Pipelinen kan köras för varje incheckning eller vid en regelbunden takt med en grupp incheckningar. I det här skedet utför du programtestning som är för lång för en PR-pipeline. Skicka Docker-avbildningar till Container Registry när du har skapat inför distributionen. Den ersatta mallen kan linteras med en uppsättning testvärden. Avbildningar som används vid tjänstkörning ska vara lintade, byggda och testade i det här läget. I CI-versionen publiceras artefakter för CD-steget som ska användas inför distributionen.

Flux

Flux är en tjänst som körs i varje kluster och ansvarar för att upprätthålla önskat tillstånd. Tjänsten avsöker ofta GitOps-lagringsplatsen efter ändringar i klustret och tillämpar dem.

CD-pipeline

CD-pipelinen utlöses automatiskt av lyckade CI-versioner. Den använder tidigare publicerade mallar, ersätter miljövärden och öppnar en PR till GitOps-lagringsplatsen för att begära en ändring av önskat tillstånd för ett eller flera Kubernetes-kluster. Klusteradministratörer granskar tillståndsändrings-PR och godkänner kopplingen till GitOps-lagringsplatsen. Pipelinen väntar sedan på att PR:en ska slutföras, vilket gör att Flux kan hämta tillståndsändringen.

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. PR skapas med ändringar i önskat tillstånd, granskas och sammanfogas. Dessa pr:er innehåller ändringar i både distributionsmallar och resulterande renderade Kubernetes-manifest. Lågnivåmanifest gör det möjligt att noggrant granska ändringar som vanligtvis inte visas på mallnivå.

Kubernetes-kluster

Minst ett Azure Arc-aktiverat Kubernetes-kluster 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 vet att programmet behöver funktionen för 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 på programdatabasen och öppnar en PR för granskning.
2. Alice ber sitt team att granska ändringen.
   • PR-pipelinen kör validering.
   • Efter en lyckad pipelinekörning loggar teamet ut och ändringen sammanfogas.
3. CI-pipelinen validerar Alices ändring och slutförs.
   • Ändringen är säker att distribuera till klustret och artefakterna sparas i CI-pipelinekörningen.
4. Alice ändring sammanfogas och 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 PR till GitOps-lagringsplatsen med önskade ändringar i klustertillståndet.
5. Alice team granskar och godkänner hennes PR.
   • Ä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.
7. Alice testar programslutpunkten för att verifiera att distributionen har slutförts.

   Kommentar

   För fler miljöer som är avsedda för distribution itererar CD-pipelinen genom att skapa en PR 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

Läs mer om att skapa anslutningar mellan klustret och en Git-lagringsplats som en konfigurationsresurs med Azure Arc-aktiverade Kubernetes