Redigera

CI/CD för AKS-appar med GitHub Actions och GitFlow

Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Monitor
Azure Pipelines

GitOps är en driftsmodell för molnbaserade program som lagrar kod för program och deklarativ infrastruktur i Git som ska användas som sanningskälla för automatisk kontinuerlig leverans. Med GitOps beskriver du det önskade tillståndet för hela systemet på en git-lagringsplats och en GitOps-operatör distribuerar det till din miljö, vilket ofta är ett Kubernetes-kluster. Mer information om GitOps för Kubernetes i Azure finns i GitOps för Azure Kubernetes Service eller CI/CD- och GitOps-discipliner med Azure Arc-aktiverade Kubernetes.

Exempelscenariot i den här artikeln gäller för företag som vill modernisera programutveckling från slutpunkt till slutpunkt med hjälp av containrar, kontinuerlig integrering (CI) för build och GitOps för kontinuerlig distribution (CD). I det här scenariot används en Flask-app som exempel. Den här webbappen består av en klientdel som skrivits med Python och Flask-ramverket.

Arkitektur

Följande alternativ utforskar push-baserade och pull-baserade CI/CD-metoder.

Alternativ 1: Push-baserad CI/CD

Diagram of the push-based architecture with GitHub Actions.

Push-baserad arkitektur med GitHub Actions för CI och CD.

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde

Det här scenariot omfattar en push-baserad DevOps-pipeline för ett webbprogram med två nivåer, med en klientdelswebbkomponent och en serverdel som använder Redis. Den här pipelinen använder GitHub Actions för att skapa och distribuera. Data flödar genom scenariot på följande sätt:

  1. Appkoden har utvecklats.
  2. Appkoden checkas in på en GitHub git-lagringsplats.
  3. GitHub Actions skapar en containeravbildning från appkoden och skickar containeravbildningen till Azure Container Registry.
  4. Ett GitHub Actions-jobb distribuerar eller push-överför appen enligt beskrivningen i manifestfilerna till AKS-klustret (Azure Kubernetes Service) med kubectl eller klusteråtgärden Distribuera till Kubernetes.

Alternativ 2: Pull-baserad CI/CD (GitOps)

Diagram of the pull-based architecture with GitHub Actions and Argo CD.

Pull-baserad arkitektur med GitHub Actions för CI och Argo CD för CD.

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde

Det här scenariot omfattar en pull-baserad DevOps-pipeline för ett webbprogram med två nivåer, med en klientdelswebbkomponent och en serverdel som använder Redis. Den här pipelinen använder GitHub Actions för att skapa. För distribution använder den Argo CD som GitOps-operator för att hämta/synkronisera appen. Data flödar genom scenariot på följande sätt:

  1. Appkoden har utvecklats.
  2. Appkoden checkas in på en GitHub-lagringsplats.
  3. GitHub Actions skapar en containeravbildning från appkoden och skickar containeravbildningen till Azure Container Registry.
  4. GitHub Actions uppdaterar en Kubernetes-manifestdistributionsfil med den aktuella avbildningsversionen baserat på versionsnumret för containeravbildningen i Azure Container Registry.
  5. Argo CD synkroniserar med, eller hämtar från, Git-lagringsplatsen.
  6. Argo CD distribuerar appen till AKS-klustret.

Komponenter

  • GitHub Actions är en automatiseringslösning som kan integreras med Azure-tjänster för kontinuerlig integrering (CI). I det här scenariot samordnar GitHub Actions skapandet av nya containeravbildningar baserat på incheckningar till källkontroll, push-överför avbildningarna till Azure Container Registry och uppdaterar sedan Kubernetes-manifestfilerna på GitHub-lagringsplatsen.
  • Azure Kubernetes Service (AKS) är en hanterad Kubernetes-plattform som gör att du kan distribuera och hantera containerbaserade program utan kunskaper om containerorkestrering. Som Kubernetes-värdtjänst hanterar Azure viktiga uppgifter som övervakning av hälsotillstånd och underhåll åt dig.
  • Azure Container Registry lagrar och hanterar containeravbildningar som används av AKS-klustret. Avbildningar lagras säkert och kan replikeras till andra regioner av Azure-plattformen för att påskynda distributionstiderna.
  • GitHub är ett webbaserat källkontrollsystem som körs på Git och som används av utvecklare för att lagra och versionshantera sin programkod. I det här scenariot används GitHub för att lagra källkoden på en Git-lagringsplats. Sedan används GitHub Actions för att skapa och push-överföra containeravbildningen till Azure Container Registry i den push-baserade metoden.
  • Argo CD är en GitOps-operator med öppen källkod som integreras med GitHub och AKS. Argo CD stöder kontinuerlig distribution (CD). Flux kunde ha använts för detta ändamål, men Argo CD visar hur ett appteam kan välja ett separat verktyg för sina specifika programlivscykelproblem, jämfört med att använda samma verktyg som klusteroperatorerna använder för klusterhantering.
  • Azure Monitor hjälper dig att spåra prestanda, upprätthålla säkerhet och identifiera trender. Mått som hämtas av Azure Monitor kan användas av andra resurser och verktyg, till exempel Grafana.

Alternativ

  • Azure Pipelines hjälper dig att implementera en CI/DC och testpipeline för alla appar.
  • Jenkins är en automationsserver med öppen källkod som kan integreras med Azure-tjänster för CI/CD.
  • Flux kan användas som GitOps-operator. Den kan utföra samma uppgifter som Argo CD och fungerar på samma sätt med AKS.

Information om scenario

I det här scenariot använder den automatiserade versionen och distributionen av din app flera tekniker. Koden utvecklas i VS Code och lagras på en GitHub-lagringsplats. GitHub Actions används för att skapa appen som en container och sedan skicka containeravbildningen till ett Azure Container Registry. GitHub Actions används för att uppdatera den nödvändiga Kubernetes-manifestdistributionsfilen, som också lagras på Git-lagringsplatsen, medan GitOps-operatören Argo CD hämtar Kubernetes-manifestfilerna därifrån och distribuerar appen till AKS-klustret.

Andra exempel är att tillhandahålla en automatiserad utvecklingsmiljö, validera nya kodincheckningar och push-överföra nya distributioner till mellanlagrings- eller produktionsmiljöer. Traditionellt var företag tvungna att manuellt skapa och kompilera program och uppdateringar och underhålla en stor, monolitisk kodbas. Med en modern metod för programutveckling som använder CI och GitOps för CD kan du snabbt skapa, testa och distribuera tjänster. Med den här moderna metoden kan du släppa program och uppdateringar till dina kunder snabbare och svara på föränderliga affärsbehov på ett mer agilt sätt.

Genom att använda Azure- och GitHub-tjänster som AKS, Container Registry, GitHub och GitHub Actions kan företag använda de senaste teknikerna och verktygen för programutveckling för att förenkla implementeringen av hög tillgänglighet. Genom att använda tekniker med öppen källkod, till exempel Flux eller Argo CD för GitOps, förenklar företag distributionen och framtvingar önskat tillstånd för program.

Potentiella användningsfall

Andra relevanta användningsfall är:

  • Modernisera programutvecklingsmetoder genom att använda en mikrotjänstbaserad, containerbaserad metod.
  • Påskynda programutveckling och distributionslivscykler.
  • Automatisera distributioner för att testa eller godkänna miljöer för validering.
  • Kontrollera konfigurationer och önskat tillstånd för programmet.
  • Automatisera livscykelhantering för kluster.

CI/CD-alternativ

Det här dokumentet visar användningen av GitOps för en modern metod för att hantera kontinuerlig distribution i en CI/CD-pipeline. Alla organisationer är dock olika. När du distribuerar program till Kubernetes-kluster via automatiserade leveranspipelines är det viktigt att förstå de olika sätt som det kan göras på.

De två vanligaste CI/CD-alternativen för att distribuera ett program till ett AKS-kluster är push-baserade och pull-baserade. Push-alternativet använder GitHub Actions för kontinuerlig distribution och pull-alternativet använder GitOps för kontinuerlig distribution.

Alternativ 1: Push-baserad arkitektur med GitHub Actions för CI och CD

I den här metoden börjar koden med att CI-delen av pipelinen arbetar sig fram till ändringar som skickas som distributioner till Kubernetes-klustret. Distributionerna baseras på en utlösare. Det finns olika utlösare som kan starta distributionen, till exempel incheckningar till lagringsplatsen eller en utlösare från en annan CI-pipeline. Med den här metoden har pipelinesystemet åtkomst till Kubernetes-klustret. Den push-baserade modulen är den vanligaste modellen som används idag av CI/CD-verktyg.

Anledningar till att använda en push-baserad metod:

  • Flexibilitet: De flesta GitOps-operatorer körs för närvarande endast i Kubernetes. Om din organisation vill distribuera program till något annat än Kubernetes måste du skicka programmet till den miljön via andra CI/CD-verktyg, till exempel med GitHub Actions.

  • Effektivitet: En standardiserad metod för att distribuera dina molnbaserade och traditionella program är effektivare. För närvarande passar GitOps bäst för molnbaserade program som körs på Kubernetes.

  • Enkelhet: Push-baserad CI/CD är välkänd bland de bredaste teknikerna i många organisationer. En push-baserad metod kan vara enklare än en blandning av push-baserade och pull-baserade CI/CD-metoder.

  • Struktur: Den aktuella lagringsplatsens struktur som används för ditt program kanske inte passar bra för GitOps, vilket innebär att betydande planering och omstrukturering krävs för att passa för GitOps.

Alternativ 2: Pull-baserad arkitektur med GitHub Actions för CI- och GitOps-operatorn Argo CD för CD

Den här metoden handlar om att tillämpa ändringar inifrån ett Kubernetes-kluster. Kubernetes-klustret innehåller en operator som söker igenom en git-lagringsplats efter det önskade tillståndet för klustret, plockar upp och tillämpar eventuella ändringar som behöver göras. I den här modellen har ingen extern klient autentiseringsuppgifter på administratörsnivå för Kubernetes-klustret. Pull-modellen är inte ny men har inte använts i stor utsträckning av CI/CD-verktyg. Nyligen, med introduktionen av GitOps, har pull-modellen börjat implementeras. Många organisationer har använt GitOps för att underlätta kontinuerlig distribution i sina CD/CD-pipelines.

Anledningar till att använda en pull-baserad metod:

  • Konsekvens: Med GitOps jämför en operatör tillståndet för dina Kubernetes-kluster med det önskade tillståndet för konfigurationen och programmen på en git-lagringsplats. Om det finns någon avvikelse till konfigurationen eller programmen, tar GitOps-operatorn Kubernetes-klustret tillbaka till önskat tillstånd automatiskt.

  • Säkerhet: Med en pull-baserad metod för CI/CD med GitOps kan du flytta säkerhetsautentiseringsuppgifter till Ditt Kubernetes-kluster, vilket minskar säkerhets- och riskytan genom att ta bort autentiseringsuppgifter från att lagras i dina externa CI-verktyg. Du kommer också att kunna minska tillåtna inkommande anslutningar och begränsa åtkomsten på administratörsnivå till dina Kubernetes-kluster.

  • Versionshantering: Eftersom GitOps använder en git-lagringsplats som sanningskälla har din kontinuerliga distribution i sig versions-, återställnings- och granskningsfunktioner.

  • Flera innehavare: En pull-baserad metod med GitOps passar bra för distribuerade team och eller flera innehavare. Med GitOps kan du använda separata git-lagringsplatser, separata åtkomsträttigheter och distribuera distributioner mellan olika namnområden.

  • Molnbaserat: Fler program moderniseras eller byggs för att vara molnbaserade. För alla organisationer som har de flesta av sina program som körs i Kubernetes är det enklare och effektivare att använda en GitOps-operatör för kontinuerlig distribution än en traditionell push-baserad metod för CI/CD.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

För att övervaka programmets prestanda och rapportera om problem använder det här scenariot Azure Monitor. Med den kan du övervaka och felsöka prestandaproblem som kan kräva koduppdateringar, som sedan kan distribueras med CI/CD-pipelinen.

Som en del av AKS-klustret distribuerar en lastbalanserare programtrafik till en eller flera containrar eller poddar som kör ditt program. Den här metoden för att köra containerbaserade program i Kubernetes tillhandahåller en infrastruktur med hög tillgänglighet för dina kunder.

Kommentar

Den här artikeln tar inte direkt upp hög tillgänglighet för CI/CD-pipeline. Mer information finns i Hög tillgänglighet för GitHub Actions och Argo CD Deklarativ GitOps CD för Kubernetes.

Återhämtningskomponenter är inbyggda i Kubernetes. Dessa komponenter övervakar och startar om containrar, eller poddar, om det finns ett problem. När flera Kubernetes-noder kombineras kan programmet tolerera att en podd eller nod inte är tillgänglig.

Allmän vägledning om hur du utformar motståndskraftiga lösningar finns i Designa tillförlitliga Azure-program.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

För separation av autentiseringsuppgifter och behörigheter använder det här scenariot ett dedikerat Microsoft Entra-tjänsthuvudnamn. Autentiseringsuppgifterna för tjänstens huvudnamn lagras som ett säkert autentiseringsobjekt i GitHub, som GitHub Actions-hemligheter, så att de inte exponeras direkt och syns i skript eller bygg-pipelinen.

Allmän vägledning om hur du skyddar program i AKS-kluster finns i Säkerhetsbegrepp för program och kluster i AKS.

Vid separation av problem är vägledningen att separera den beräkning som kör affärsprogrammet från CD-agenterna eller GitOps-operatorn genom att köra affärsprogrammet och GitOps-operatorn i separata namnområden i Kubernetes-klustret. För ytterligare separation av problem kan GitOps-operatorn köras på ett Kubernetes-kluster som är dedikerat till GitOps-instansen separat från kubernetes-produktionsklustret som kör affärsprogrammet.

Kommentar

Den här artikeln beskriver inte direkt hur du skyddar en CI/CD-pipeline.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

Med AKS kan du skala antalet klusternoder för att uppfylla kraven i dina program. När programmet växer kan du skala upp antalet Kubernetes-noder som kör tjänsten.

Med GitHub Actions skalar molnleverantören automatiskt antalet löpare. Om egenvärdade löpare används, skulle värden för löparen vara ansvarig för att skala dem efter behov.

Andra avsnitt om skalbarhet finns i checklistan för prestandaeffektivitet.

Distribuera det här scenariot

Följ stegen i referensimplementeringen aks-baseline-automation för att distribuera scenariot. Referensimplementeringslagringsplatsen har guidade genomgångar för både det push-baserade CI/CD-scenariot och det pull-baserade CI/CD-scenariot (GitOps).

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Det här scenariot använde Azure Container Registry och AKS för att lagra och köra ett containerbaserat program. Azure Container Apps eller Azure Container Instances kan också användas för att köra containerbaserade program, utan att behöva etablera några orkestreringskomponenter. Mer information finns i Översikt över Azure Container Instances och Översikt över Azure Container Apps.

Produktdokumentation:

Microsoft Learn-moduler: