Bewerken

CI/CD voor AKS-apps met GitHub Actions en GitFlow

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

GitOps is een operationeel model voor cloudtoepassingen waarin toepassings- en declaratieve infrastructuurcode in Git wordt opgeslagen om te worden gebruikt als de bron van waarheid voor geautomatiseerde continue levering. Met GitOps beschrijft u de gewenste status van uw hele systeem in een Git-opslagplaats en implementeert een GitOps-operator deze in uw omgeving. Dit is vaak een Kubernetes-cluster. Ga voor meer informatie over GitOps voor Kubernetes in Azure naar GitOps voor Azure Kubernetes Service of CI/CD- en GitOps-disciplines met Kubernetes met Azure Arc.

Het voorbeeldscenario in dit artikel is van toepassing op bedrijven die end-to-end-toepassingsontwikkeling willen moderniseren met behulp van containers, continue integratie (CI) voor build en GitOps voor continue implementatie (CD). In dit scenario wordt een Flask-app gebruikt als voorbeeld. Deze web-app bestaat uit een front-end die is geschreven met behulp van Python en het Flask-framework.

Architectuur

De volgende opties verkennen push- en pull-gebaseerde CI/CD-benaderingen.

Optie 1: Pushgebaseerde CI/CD

Diagram of the push-based architecture with GitHub Actions.

Architectuur op basis van push met GitHub Actions voor CI en CD.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom

In dit scenario wordt een op push gebaseerde DevOps-pijplijn voor een webtoepassing met twee lagen behandeld, met een front-endwebonderdeel en een back-end die gebruikmaakt van Redis. Deze pijplijn maakt gebruik van GitHub Actions voor het bouwen en implementeren. De gegevens stromen als volgt door het scenario:

  1. De app-code is ontwikkeld.
  2. De app-code wordt doorgevoerd in een GitHub Git-opslagplaats.
  3. GitHub Actions bouwt een containerinstallatiekopieën van de app-code en pusht de containerinstallatiekopieën naar Azure Container Registry.
  4. Een GitHub Actions-taak implementeert of pusht de app, zoals beschreven in de manifestbestanden, naar het AKS-cluster (Azure Kubernetes Service) met behulp van kubectl of de actie Implementeren naar Kubernetes-cluster .

Optie 2: Op pull gebaseerde CI/CD (GitOps)

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

Architectuur op basis van pull met GitHub Actions voor CI en Argo CD voor CD.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom

In dit scenario wordt een op pull gebaseerde DevOps-pijplijn voor een webtoepassing met twee lagen behandeld, met een front-endwebonderdeel en een back-end die gebruikmaakt van Redis. Deze pijplijn maakt gebruik van GitHub Actions voor het bouwen. Voor implementatie wordt Argo CD gebruikt als GitOps-operator om de app op te halen/te synchroniseren. De gegevens stromen als volgt door het scenario:

  1. De app-code is ontwikkeld.
  2. De app-code wordt doorgevoerd in een GitHub-opslagplaats.
  3. GitHub Actions bouwt een containerinstallatiekopieën van de app-code en pusht de containerinstallatiekopieën naar Azure Container Registry.
  4. GitHub Actions werkt een Kubernetes-manifestimplementatiebestand bij met de huidige installatiekopieënversie op basis van het versienummer van de containerinstallatiekopieën in Azure Container Registry.
  5. Argo CD wordt gesynchroniseerd met, of pulls uit, de Git-opslagplaats.
  6. Argo CD implementeert de app in het AKS-cluster.

Onderdelen

  • GitHub Actions is een automatiseringsoplossing die kan worden geïntegreerd met Azure-services voor continue integratie (CI). In dit scenario organiseert GitHub Actions het maken van nieuwe containerinstallatiekopieën op basis van doorvoeringen voor broncodebeheer, pusht deze installatiekopieën naar Azure Container Registry en werkt u vervolgens de Kubernetes-manifestbestanden bij in de GitHub-opslagplaats.
  • Azure Kubernetes Service (AKS) is een beheerd Kubernetes-platform waarmee u toepassingen in containers kunt implementeren en beheren zonder kennis van containerindeling. Azure handelt als een gehoste Kubernetes-service cruciale taken voor u af zoals statuscontrole en onderhoud.
  • In Azure Container Registry worden containerinstallatiekopieën opgeslagen en beheerd die worden gebruikt door het AKS-cluster. Installatiekopieën worden veilig opgeslagen en kunnen worden gerepliceerd naar andere regio's door het Azure-platform om de implementatietijden te versnellen.
  • GitHub is een op het web gebaseerd broncodebeheersysteem dat wordt uitgevoerd op Git en wordt gebruikt door ontwikkelaars om hun toepassingscode op te slaan en te versien. In dit scenario wordt GitHub gebruikt om de broncode op te slaan in een Git-opslagplaats. Vervolgens wordt GitHub Actions gebruikt om de containerinstallatiekopieën te bouwen en naar Azure Container Registry te pushen in de push-benadering.
  • Argo CD is een opensource GitOps-operator die kan worden geïntegreerd met GitHub en AKS. Argo CD ondersteunt continue implementatie (CD). Flux kan hiervoor worden gebruikt, maar Argo CD laat zien hoe een app-team een afzonderlijk hulpprogramma kan kiezen voor hun specifieke problemen met de levenscyclus van toepassingen, vergeleken met het gebruik van hetzelfde hulpprogramma dat de clusteroperators gebruiken voor clusterbeheer.
  • Azure Monitor helpt u bij het bijhouden van prestaties, het onderhouden van beveiliging en het identificeren van trends. Metrische gegevens die door Azure Monitor worden verkregen, kunnen worden gebruikt door andere resources en hulpprogramma's, zoals Grafana.

Alternatieven

  • Azure Pipelines helpt u bij het implementeren van een CI/DC en het testen van een pijplijn voor elke app.
  • Jenkins is een opensource-automatiseringsserver die kan worden geïntegreerd met Azure-services voor CI/CD.
  • Flux kan worden gebruikt als de GitOps-operator. Het kan dezelfde taken uitvoeren als Argo CD en werkt op dezelfde manier met AKS.

Scenariodetails

In dit scenario maakt de geautomatiseerde build en implementatie van uw app gebruik van verschillende technologieën. De code wordt ontwikkeld in VS Code en opgeslagen in een GitHub-opslagplaats. GitHub Actions wordt gebruikt om de app als een container te bouwen en vervolgens de containerinstallatiekopieën naar een Azure Container Registry te pushen. GitHub Actions wordt gebruikt om het benodigde Kubernetes-manifestimplementatiebestand bij te werken, ook opgeslagen in de Git-opslagplaats, terwijl de GitOps-operator Argo CD de Kubernetes-manifestbestanden van daaruit ophaalt en de app implementeert in het AKS-cluster.

Andere voorbeelden zijn het bieden van een geautomatiseerde ontwikkelomgeving, het valideren van nieuwe codedoorvoeringen en het pushen van nieuwe implementaties naar faserings- of productieomgevingen. Normaal gesproken moesten bedrijven handmatig toepassingen en updates bouwen en compileren en een grote monolithische codebasis onderhouden. Met een moderne benadering van toepassingsontwikkeling die gebruikmaakt van CI en GitOps voor CD, kunt u snel services bouwen, testen en implementeren. Met deze moderne benadering kunt u sneller toepassingen en updates voor uw klanten vrijgeven en reageren op veranderende bedrijfsbehoeften op een flexibelere manier.

Met behulp van Azure- en GitHub-services zoals AKS, Container Registry, GitHub en GitHub Actions kunnen bedrijven de nieuwste technieken en hulpprogramma's voor het ontwikkelen van toepassingen gebruiken om het implementeren van hoge beschikbaarheid te vereenvoudigen. Door gebruik te maken van opensourcetechnologieën, zoals Flux of Argo CD voor GitOps, vereenvoudigen bedrijven de implementatie en dwingt u de gewenste status van toepassingen af.

Potentiële gebruikscases

Andere relevante use cases zijn:

  • Moderniseer de ontwikkelprocedures voor toepassingen door gebruik te maken van een microservice, op containers gebaseerde benadering.
  • De ontwikkelings- en implementatielevenscycli van toepassingen versnellen.
  • Automatiseer implementaties voor het testen of accepteren van omgevingen voor validatie.
  • Zorg voor configuraties en de gewenste status van de toepassing.
  • Beheer van de levenscyclus van clusters automatiseren.

CI/CD-opties

Dit document toont het gebruik van GitOps voor een moderne benadering voor het verwerken van continue implementatie in een CI/CD-pijplijn. Elke organisatie is echter anders. Wanneer u toepassingen implementeert in Kubernetes-clusters via geautomatiseerde leveringspijplijnen, is het belangrijk om inzicht te hebben in de verschillende manieren waarop dit kan worden gedaan.

De twee meest voorkomende CI/CD-opties voor het implementeren van een toepassing in een AKS-cluster zijn push- en pull-gebaseerde. De pushoptie maakt gebruik van GitHub Actions voor continue implementatie en de pull-optie maakt gebruik van GitOps voor continue implementatie.

Optie 1: Architectuur op basis van pushen met GitHub Actions voor CI en CD

Bij deze benadering begint code met het CI-deel van de pijplijn dat op de manier werkt om wijzigingen die worden gepusht als implementaties naar het Kubernetes-cluster te pushen. De implementaties zijn gebaseerd op een trigger. Er zijn verschillende triggers waarmee de implementatie kan worden gestart, bijvoorbeeld doorvoeringen naar de opslagplaats of een trigger vanuit een andere CI-pijplijn. Met deze methode heeft het pijplijnsysteem toegang tot het Kubernetes-cluster. De push-gebaseerde module is het meest voorkomende model dat momenteel wordt gebruikt door CI/CD-hulpprogramma's.

Redenen om een push-gebaseerde benadering te gebruiken:

  • Flexibiliteit: de meeste GitOps-operators worden momenteel alleen uitgevoerd in Kubernetes. Als uw organisatie toepassingen wil implementeren in iets anders dan Kubernetes, moet u de toepassing naar die omgeving pushen via andere CI/CD-hulpprogramma's, zoals met GitHub Actions.

  • Efficiëntie: Een gestandaardiseerde benadering voor het implementeren van uw cloudeigen en traditionele toepassingen is efficiënter. GitOps is momenteel het meest geschikt voor cloudtoepassingen die worden uitgevoerd op Kubernetes.

  • Eenvoud: Push-gebaseerde CI/CD is bekend onder de breedste set technici in veel organisaties. Een push-gebaseerde benadering is mogelijk eenvoudiger dan een combinatie van push- en pull-gebaseerde CI/CD-benaderingen.

  • Structuur: De huidige opslagplaatsstructuur die voor uw toepassing wordt gebruikt, is mogelijk niet geschikt voor GitOps, wat betekent dat aanzienlijke planning en herstructurering nodig zijn om geschikt te zijn voor GitOps.

Optie 2: Pull-architectuur met GitHub Actions voor CI- en GitOps-operator Argo CD voor CD

Deze aanpak is een oplossing voor het toepassen van wijzigingen vanuit een Kubernetes-cluster. Het Kubernetes-cluster bevat een operator die een Git-opslagplaats scant op de gewenste status van het cluster, wijzigingen ophaalt en toepast die moeten worden aangebracht. In dit model heeft geen externe client referenties op beheerdersniveau voor het Kubernetes-cluster. Het pull-model is niet nieuw, maar wordt niet veel gebruikt door CI/CD-hulpprogramma's. Onlangs, met de introductie van GitOps, is het pull-model in gebruik genomen. Veel organisaties gebruiken GitOps om continue implementatie in hun CD/CD-pijplijnen te vergemakkelijken.

Redenen om een pull-benadering te gebruiken:

  • Consistentie: Met GitOps vergelijkt een operator de status van uw Kubernetes-clusters met de gewenste status van uw configuratie en toepassingen in een Git-opslagplaats. Als er sprake is van afwijkingen in de configuratie of toepassingen, wordt het Kubernetes-cluster automatisch teruggezet door de GitOps-operator.

  • Beveiliging: Met een pull-benadering voor CI/CD met GitOps kunt u beveiligingsreferenties naar uw Kubernetes-cluster verplaatsen, waardoor de beveiliging en het risicooppervlak worden verminderd door referenties te verwijderen uit uw externe CI-hulpprogramma's. U kunt ook toegestane binnenkomende verbindingen verminderen en de toegang op beheerdersniveau tot uw Kubernetes-clusters beperken.

  • Versiebeheer: Omdat GitOps gebruikmaakt van een Git-opslagplaats als de bron van waarheid, heeft uw continue implementatie inherent versiebeheer, terugdraaien en controlemogelijkheden.

  • Multitenancy: Een pull-benadering met GitOps is geschikt voor gedistribueerde teams en of multitenancy. Met GitOps kunt u afzonderlijke Git-opslagplaatsen, afzonderlijke toegangsrechten gebruiken en implementaties distribueren over verschillende naamruimten.

  • Cloudeigen: Meer toepassingen worden gemoderniseerd of gebouwd om cloudeigen te zijn. Voor elke organisatie met de meeste toepassingen die worden uitgevoerd in Kubernetes, is het gebruik van een GitOps-operator voor continue implementatie eenvoudiger en efficiënter dan een traditionele pushgebaseerde benadering van CI/CD.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

Voor het bewaken van de prestaties van uw toepassing en het rapporteren van problemen, maakt dit scenario gebruik van Azure Monitor. Hiermee kunt u prestatieproblemen bewaken en oplossen waarvoor mogelijk code-updates zijn vereist, die vervolgens kunnen worden geïmplementeerd met de CI/CD-pijplijn.

Als onderdeel van het AKS-cluster distribueert een load balancer toepassingsverkeer naar een of meer containers of pods waarop uw toepassing wordt uitgevoerd. Deze benadering voor het uitvoeren van containertoepassingen in Kubernetes biedt een maximaal beschikbare infrastructuur voor uw klanten.

Notitie

Dit artikel heeft niet rechtstreeks betrekking op hoge beschikbaarheid van CI/CD-pijplijnen. Ga voor meer informatie naar Hoge beschikbaarheid voor GitHub Actions en Argo CD declaratieve GitOps CD voor Kubernetes.

Tolerantieonderdelen zijn ingebouwd in Kubernetes. Deze onderdelen bewaken containers of pods en starten deze opnieuw als er een probleem is. Wanneer meerdere Kubernetes-knooppunten worden gecombineerd, kan uw toepassing tolereren dat een pod of knooppunt niet beschikbaar is.

Zie Betrouwbare Azure-toepassingen ontwerpen voor algemene richtlijnen voor het ontwerpen van flexibele oplossingen.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Voor het scheiden van referenties en machtigingen maakt dit scenario gebruik van een toegewezen Microsoft Entra-service-principal. De referenties voor deze service-principal worden opgeslagen als een beveiligd referentieobject in GitHub, als GitHub Actions Secrets, zodat ze niet rechtstreeks worden weergegeven en zichtbaar zijn in scripts of de build-pijplijn.

Zie Beveiligingsconcepten voor toepassingen en clusters in AKS voor algemene richtlijnen voor het beveiligen van toepassingen in AKS.

Voor het scheiden van problemen is de richtlijnen het scheiden van de rekenkracht waarmee de bedrijfstoepassing wordt uitgevoerd van de CD-agents of GitOps-operator, door de bedrijfstoepassing en de GitOps-operator uit te voeren in afzonderlijke naamruimten in het Kubernetes-cluster. Voor verdere scheiding van problemen kan de GitOps-operator worden uitgevoerd op een Kubernetes-cluster dat is toegewezen aan het GitOps-exemplaar, gescheiden van het kubernetes-productiecluster waarop de bedrijfstoepassing wordt uitgevoerd.

Notitie

In dit artikel wordt niet rechtstreeks uitgelegd hoe u een CI/CD-pijplijn beveiligt.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.

Met AKS kunt u het aantal clusterknooppunten schalen om te voldoen aan de vereisten van uw toepassingen. Naarmate uw toepassing groeit, kunt u het aantal Kubernetes-knooppunten omhoog schalen waarop uw service wordt uitgevoerd.

Met GitHub Actions wordt het aantal hardlopers automatisch geschaald door de cloudprovider. Als zelf-hostende runners worden gebruikt, is de host van de runner verantwoordelijk om ze naar behoefte te schalen.

Zie de controlelijst voor prestatie-efficiëntie voor andere onderwerpen over schaalbaarheid.

Dit scenario implementeren

Volg de stappen in de referentie-implementatie voor AKS-basislijnautomatisering om het scenario te implementeren. De referentieimplementatieopslagplaats bevat begeleide instructies voor zowel het op push gebaseerde CI/CD-scenario als het op pull gebaseerde CI/CD-scenario (GitOps).

Bijdragers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

In dit scenario zijn Azure Container Registry en AKS gebruikt om een toepassing op basis van containers op te slaan en uit te voeren. Azure Container Apps of Azure Container Instances kunnen ook worden gebruikt voor het uitvoeren van toepassingen op basis van containers, zonder dat u indelingsonderdelen hoeft in te richten. Zie het overzicht van Azure Container Instances en overzicht van Azure Container Apps voor meer informatie.

Productdocumentatie:

Microsoft Learn-modules: