Een CI/CD-pijplijn bouwen voor microservices in Kubernetes met behulp van Azure DevOps en Helm

Het maken van een betrouwbaar CI/CD-proces (continue integratie en continue levering) voor een microservicesarchitectuur kan lastig zijn. Elk team moet services snel en betrouwbaar vrijgeven, zonder dat andere teams worden verstoord of de toepassing als geheel wordt gedestabiliseerd.

In dit artikel wordt een voorbeeld van een CI/CD-pijplijn beschreven voor het implementeren van microservices in Azure Kubernetes Service (AKS). Elk team en project zijn anders, dus neem dit artikel niet als een set hard-and-fast regels. Gebruik het als uitgangspunt voor het ontwerpen van uw eigen CI/CD-proces.

De volgende lijst bevat een overzicht van de doelstellingen van een CI/CD-pijplijn voor door Kubernetes gehoste microservices:

• Teams kunnen hun services onafhankelijk bouwen en implementeren.
• Codewijzigingen die het CI-proces doorgeven, worden automatisch geïmplementeerd in een productieachtige omgeving.
• Elke fase van de pijplijn dwingt kwaliteitspoorten af.
• Een nieuwe versie van een service kan naast de vorige versie worden geïmplementeerd.

Zie CI/CD voor microservicesarchitecturen voor meer informatie.

Aannamen

In dit voorbeeld vindt u enkele veronderstellingen over het ontwikkelteam en de codebasis:

• De codeopslagplaats is een monorepo, met mappen die zijn georganiseerd door microservice.
• De vertakkingsstrategie van het team is gebaseerd op trunk-based development.
• Het team gebruikt releasebranches om releases te beheren. Voor elke microservice worden afzonderlijke releases gemaakt.
• Het CI/CD-proces maakt gebruik van Azure-pipelines voor het bouwen, testen en implementeren van de microservices in AKS.
• De containerinstallatiekopieën voor alle microservices worden opgeslagen in één, gedeeld Azure Container Registry exemplaar, met een afzonderlijke opslagplaats voor elke microservice. Gebruik Container Registry Azure ABAC-opslagplaatsmachtigingen om elke pijplijnidentiteit te beperken tot een eigen opslagplaats of gebruik afzonderlijke registers waar sterkere vertrouwensgrenzen vereist zijn.
• Het team gebruikt Helm-grafieken om elke microservice te verpakken.
• Er wordt een push-implementatiemodel gebruikt, waarbij Azure-pipelines en bijbehorende agents implementaties uitvoeren door rechtstreeks verbinding te maken met het AKS-cluster.

Deze veronderstellingen sturen veel van de specifieke details van de CI/CD-pijplijn aan. U kunt echter de hier beschreven basisbenadering aanpassen voor andere processen, hulpprogramma's en services, zoals GitHub Actions, Jenkins of Docker Hub.

Alternatives

Wanneer u een CI/CD-strategie met AKS kiest, moet u rekening houden met de volgende algemene alternatieven:

• In plaats van Helm te gebruiken als pakketbeheer- en implementatieprogramma, kunt u Kustomize gebruiken, een systeemeigen hulpprogramma voor configuratiebeheer van Kubernetes waarmee een sjabloonvrije manier wordt geïntroduceerd om de toepassingsconfiguratie aan te passen en te parameteriseren.

• In plaats van Azure DevOps te gebruiken voor Git-opslagplaatsen en -pijplijnen, kunt u GitHub opslagplaatsen gebruiken voor privé- en openbare Git-opslagplaatsen en GitHub Actions voor CI/CD-pijplijnen.

  GitHub Actions biedt integratie met AKS met starterwerkstromen en ondersteunt OpenID Connect (OIDC) voor veilige, geheimloze verificatie voor Azure.

• In plaats van een push-implementatiemodel te gebruiken, kunt u overwegen om de Kubernetes-configuratie op grote schaal te beheren met behulp van een GitOps (pull-implementatiemodel). Een Kubernetes-operator in het cluster, zoals Flux of Argo CD , synchroniseert de clusterstatus op basis van de configuratie die is opgeslagen in een Git-opslagplaats. GitOps elimineert de noodzaak voor pijplijnen om directe clustertoegang te hebben, vermindert de kwetsbaarheid voor aanvallen en biedt zelfherstel- en driftdetectiemogelijkheden.

  Tip

  Houd bij het evalueren van push-gebaseerde versus pull-gebaseerde implementatiemodellen (GitOps) rekening met uw workloadvereisten. Push-gebaseerde implementaties bieden deterministische updates en directe pijplijnbeheer, die geschikt zijn voor veilige implementatieprocedures. Pull-implementaties (GitOps) bieden consistentie, controlebaarheid en zelfherstel, waardoor ze ideaal zijn voor omgevingen waarbij clusters moeten worden afgestemd op een gewenste status zonder directe toegang tot pijplijn naar cluster.

Validatieversies

Stel dat een ontwikkelaar werkt aan een microservice met de naam Delivery Service. Bij het ontwikkelen van een nieuwe functie controleert de ontwikkelaar code in een functiebranch. Volgens conventie hebben functiebranches de naam feature/*.

Het build-definitie bestand bevat een trigger die filtert op de branchnaam en het bronpad:

trigger:
  batch: true
  branches:
    include:
    # for new release to production: release flow strategy
    - release/delivery/v*
    - refs/release/delivery/v*
    - main
    - feature/delivery/*
    - topic/delivery/*
  paths:
    include:
    - /src/shipping/delivery/

Wanneer u deze benadering gebruikt, kan elk team een eigen build-pijplijn hebben. Alleen code die is ingecheckt in de /src/shipping/delivery map activeert een build van Delivery Service. Commits pushen naar een tak die overeenkomt met het filter lanceert een CI-build. Op dit moment in de werkstroom voert de CI-build een minimale codeverificatie uit:

1. Bouw de code.
2. Eenheidstests uitvoeren.

Het doel is om de buildtijden kort te houden, zodat de ontwikkelaar snel feedback kan krijgen. Wanneer de functie klaar is om samen te voegen in de hoofdmap, opent de ontwikkelaar een pull-aanvraag. Met deze bewerking wordt een andere CI-build geactiveerd waarmee een aantal extra controles worden uitgevoerd:

1. Bouw de code.
2. Eenheidstests uitvoeren.
3. Voer SAST (Static Application Security Testing) uit op de broncode.
4. Bouw de installatiekopieën van de runtimecontainer.
5. Voer beveiligingsscans uit op de installatiekopie.

Volledige CI/CD-build

Wanneer het team klaar is om een nieuwe versie van Delivery Service te implementeren, maakt de releasemanager een vertakking van de hoofdvertakking met behulp van dit naamgevingspatroon: release/<microservice name>/<semver>. Bijvoorbeeld: release/delivery/v1.0.2.

Als u deze vertakking maakt, wordt een volledige CI-build geactiveerd die alle vorige stappen uitvoert en deze stappen:

1. Push de containerinstallatiekopieën naar Container Registry. De installatiekopieën worden getagd met het versienummer in de naam van de vertakking.
2. Voer deze opdracht uit helm package om de Helm-grafiek voor de service te verpakken. De grafiek wordt ook getagd met een versienummer.
3. Push het Helm-pakket naar Container Registry.

Als deze build slaagt, wordt een implementatieproces (CD) geactiveerd met behulp van een Azure-pipelines release-pijplijn. Deze pijplijn bevat de volgende stappen:

1. Implementeer de Helm-grafiek in een QA-omgeving.
2. Een fiatteur keurt goed voordat het pakket naar productie gaat. Zie Release-implementatiebeheer met behulp van goedkeuringen.
3. Tag de Docker-installatiekopieën voor de productienaamruimte in Container Registry. Als de huidige tag bijvoorbeeld myrepo.azurecr.io/delivery:v1.0.2 is, is de productietag myrepo.azurecr.io/prod/delivery:v1.0.2.
4. Implementeer de Helm-grafiek in de productieomgeving.

Zelfs in een monorepo kunt u deze taken toepassen op afzonderlijke microservices, zodat teams onafhankelijk van elkaar kunnen implementeren. Het proces bevat enkele handmatige stappen: goedkeuring van PULL's, het maken van release-vertakkingen en het goedkeuren van implementaties in het productiecluster. Workloadteams kunnen deze stappen desgewenst automatiseren.

Isolatie van omgevingen

U implementeert services in meerdere omgevingen, waaronder omgevingen voor ontwikkeling, betrouwbaarheidstests, integratietests, belastingstests en productie. Deze omgevingen hebben enige isolatie nodig. In Kubernetes kunt u kiezen tussen fysieke isolatie en logische isolatie. Fysieke isolatie wordt geïmplementeerd in afzonderlijke clusters. Logische isolatie maakt gebruik van naamruimten en beleidsregels.

We raden u aan om een toegewezen productiecluster samen met een afzonderlijk cluster te maken voor uw ontwikkel-/testomgevingen. Gebruik logische isolatie om omgevingen binnen het ontwikkel-/testcluster te scheiden. Services die zijn geïmplementeerd in het ontwikkel-/testcluster, mogen nooit toegang hebben tot gegevensarchieven die zakelijke gegevens bevatten.

Voer de volgende stappen uit om isolatie binnen een cluster af te dwingen:

• Naamruimten: Kubernetes-naamruimten gebruiken om logische omgevingen te scheiden (bijvoorbeeld dev, staging, qa).
• Netwerkbeleid: Pas Kubernetes-netwerkbeleid toe om pod-naar-pod-communicatie tussen naamruimten te weigeren.
• Resourcequota: Pas resourcequota per naamruimte toe om problemen met ruis in gedeelde clusters te voorkomen.
• Microsoft Entra ID integratie: combineer Microsoft Entra ID verificatie met Kubernetes RBAC en Microsoft Entra ID om te bepalen welke Microsoft Entra gebruikers en groepen toegang hebben tot elke naamruimte.

Verificatie en autorisatie

Gebruik waar mogelijk geheime verificatie, zowel voor de pijplijnen die uw microservices implementeren als voor de workloads die deze pijplijnen implementeren:

• Federatie van workloadidentiteit voor pijplijnen: gebruik voor Azure-pipelines een federatieve serviceverbinding voor workloadidentiteit om te verifiëren bij Azure zonder dat er langlevende service-principalgeheimen worden opgeslagen. Voor GitHub Actions configureert u OIDC om dezelfde geheime verificatie te bereiken.
• Microsoft Entra Workload-id voor geïmplementeerde workloads: configureer de microservices die uw pijplijn implementeert om Microsoft Entra Workload-id te gebruiken in plaats van referenties te injecteren via manifesten, Helm-waarden of Kubernetes-geheimen. Met de workload-id worden Kubernetes-serviceaccounts gefedereerd met Microsoft Entra ID, zodat pods kunnen worden geverifieerd bij Azure services (zoals Azure Key Vault, Container Registry of Azure SQL) zonder dat de pijplijn geheimen beheert.

Geheimenbeheer

Sluit nooit geheimen (verbindingsreeksen, API-sleutels, databasewachtwoorden) rechtstreeks in de broncode, Dockerfiles, Helm-waardenbestanden of pijplijndefinities in. In plaats van:

• Geheimen opslaan in Key Vault.
• Gebruik de Key Vault Provider for Secrets Store CSI Driver om geheimen rechtstreeks in pods te koppelen als volumes of omgevingsvariabelen. Met deze methode blijven geheimen buiten Kubernetes-objecten Secret , die base64-gecodeerd zijn, niet standaard versleuteld.
• Gebruik voor pijplijngeheimen Key Vault-integratie met Azure-pipelines of GitHub Actions geheimen.
• Schakel Key Vault voorlopig verwijderen en opschonen in om bescherming te bieden tegen onbedoelde of schadelijke verwijdering van geheimen.

Bouwproces

Indien mogelijk moet u uw buildproces verpakken in een Docker-container. Met deze configuratie kunt u codeartefacten bouwen met behulp van Docker zonder dat u een buildomgeving op elke buildcomputer hoeft te configureren. Een containerbuildproces vereenvoudigt het uitschalen van de CI-pijplijn door nieuwe buildagents toe te voegen. Bovendien kan elke ontwikkelaar in het team de code bouwen door de buildcontainer uit te voeren.

Met behulp van builds met meerdere fases in Docker kunt u de buildomgeving en de runtime-installatiekopieën definiëren in één Dockerfile. Met de volgende Dockerfile wordt bijvoorbeeld een .NET 10-toepassing gebouwd:

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS base
USER app
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src/Fabrikam.Workflow.Service

COPY Fabrikam.Workflow.Service/Fabrikam.Workflow.Service.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.csproj

COPY Fabrikam.Workflow.Service/. .
RUN dotnet build Fabrikam.Workflow.Service.csproj -c Release -o /app/build --no-restore

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

FROM build AS publish
RUN dotnet publish Fabrikam.Workflow.Service.csproj -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Fabrikam.Workflow.Service.dll"]

Dit Dockerfile definieert verschillende buildfasen. U ziet dat de fase met de naam base gebruikmaakt van de .NET 10 ASP.NET runtime-installatiekopieën, terwijl de fase met de naam build gebruikmaakt van de volledige .NET 10 SDK. In build de fase wordt het .NET project gebouwd. Maar de uiteindelijke runtimecontainer is gebouwd op basis van base, die alleen de runtime bevat en aanzienlijk kleiner is dan de volledige SDK-installatiekopie.

Een testloper bouwen

Een andere goede gewoonte is het uitvoeren van eenheidstests in de container. De volgende code toont bijvoorbeeld een deel van een Dockerfile waarmee een testrunner wordt gebouwd:

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

Een ontwikkelaar kan dit Dockerfile gebruiken om de tests lokaal uit te voeren:

docker build . -t delivery-test:1 --target=testrunner
docker run delivery-test:1

De CI-pijplijn moet ook de tests uitvoeren als onderdeel van de build-verificatiestap.

Dit bestand maakt gebruik van de Docker-opdracht ENTRYPOINT , niet de Docker-opdracht RUN , om de tests uit te voeren.

• Als u de RUN opdracht gebruikt, worden de tests elke keer uitgevoerd bij het bouwen van het image. Als u deze gebruikt ENTRYPOINT, worden de tests aangemeld. Ze worden alleen uitgevoerd wanneer u expliciet de fase testrunner richt.
• Een mislukte test zorgt er niet voor dat de Docker-opdracht build mislukt. Met dit gedrag kunt u buildfouten van containers onderscheiden van testfouten.
• Testresultaten kunnen worden opgeslagen op een gekoppeld volume.

Best practices voor containers

Hier volgen enkele andere aanbevolen procedures voor containers:

• Definieer organisatiebrede conventies voor containertags, versiebeheer en naamconventies voor resources die zijn geïmplementeerd in het cluster (bijvoorbeeld pods en services). Door deze conventies te gebruiken, kunt u eenvoudiger implementatieproblemen vaststellen.
• Tijdens de ontwikkelings- en testcyclus bouwt het CI/CD-proces tal van containerafbeeldingen. Slechts enkele van deze installatiekopieën zijn kandidaten voor release en slechts enkele van deze releasekandidaten worden gepromoveerd naar productie. U hebt een duidelijke versiebeheerstrategie, zodat u weet welke installatiekopieën momenteel in productie zijn geïmplementeerd en indien nodig eenvoudig kunt terugdraaien naar een eerdere versie.
• Implementeer altijd specifieke tags voor containerversies, niet latest.
• Gebruik naamruimten in Container Registry om installatiekopieën te isoleren die zijn goedgekeurd voor productie van installatiekopieën die nog worden getest. Verplaats een image pas naar de productienamespace als u klaar bent om deze naar productie te implementeren. Als u deze procedure combineert met semantische versiebeheer van containerinstallatiekopieën, kunt u de kans verminderen dat er per ongeluk een versie wordt geïmplementeerd die niet is goedgekeurd voor de release.
• Volg het principe van minste rechten door containers uit te voeren als een niet-bevoorrechte gebruiker. Gebruik in Kubernetes Pod Security Standards met Pod Security-toegang (waardoor het afgeschafte podbeveiligingsbeleid in Kubernetes 1.25 is vervangen) om beperkingen af te dwingen, zoals voorkomen dat containers als hoofdmap worden uitgevoerd. Gebruik het restricted profiel voor productieworkloads.
• Gebruik minimale of distributieloze basisinstallatiekopieën (bijvoorbeeld installatiekopieën op basis van Alpine, Azure Linux-basisinstallatiekopieën of distributieloze installatiekopieën, of beitelde .NET-installatiekopieën) om het aanvalsoppervlak van uw containerinstallatiekopieën te verminderen.
• Voor Premium-registers configureert u een bewaarbeleid voor Container Registry om niet-gemarkeerde manifesten te verwijderen. Als u tags wilt opschonen op leeftijd of naam, plant u een Container Registry-taak waarop een opschoonbewerking wordt uitgevoerd. Bewaar installatiekopieën die actieve implementaties en terugdraaiplannen raadplegen.

Helm-grafieken

Overweeg het gebruik van Helm om het bouwen en implementeren van services te beheren. De volgende Helm-functies ondersteunen een CI/CD-pijplijn:

• Een enkele microservice wordt vaak gedefinieerd door meerdere Kubernetes-objecten. Met Helm kunnen deze objecten worden verpakt in één Helm-grafiek.
• U kunt een grafiek implementeren met behulp van één Helm-opdracht in plaats van een reeks kubectl-opdrachten.
• Grafieken worden expliciet voorzien van een versie. Gebruik Helm om een versie vrij te geven, releases weer te geven en terug te keren naar een vorige versie. Helm maakt gebruik van semantische versiebeheer om updates en revisies bij te houden.
• Helm-grafieken gebruiken sjablonen om te voorkomen dat gegevens, zoals labels en selectors, in veel bestanden worden gedupliceerd.
• Helm kan afhankelijkheden tussen grafieken beheren.
• U kunt grafieken opslaan in een Helm-opslagplaats, zoals Container Registry, en deze integreren in de build-pijplijn.

Zie Container Registry gebruiken als helm-opslagplaats voor uw toepassingsgrafieken voor meer informatie.

Voor één microservice zijn mogelijk meerdere Kubernetes-configuratiebestanden vereist. Als u een service wilt bijwerken, moet u mogelijk al deze bestanden bewerken om selectors, labels en afbeeldingstags bij te werken. Helm behandelt deze bestanden als één pakket dat een grafiek wordt genoemd en maakt het eenvoudig om de YAML-bestanden bij te werken met behulp van variabelen. Helm maakt gebruik van een sjabloontaal (op basis van Go-sjablonen) waarmee u geparameteriseerde YAML-configuratiebestanden kunt schrijven.

Hier is een voorbeeld van een YAML-bestand dat een deployment definieert:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "package.fullname" . | replace "." "" }}
  labels:
    app.kubernetes.io/name: {{ include "package.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

...

spec:
  template:
    spec:
      containers:
      - name: &package-container_name fabrikam-package
        image: {{ .Values.dockerregistry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        env:
        - name: LOG_LEVEL
          value: {{ .Values.log.level }}

U kunt zien dat de implementatienaam, labels en containerspecificaties allemaal sjabloonparameters gebruiken, die u opgeeft tijdens de implementatie. Bijvoorbeeld vanaf de opdrachtregel:

helm install <release-name> oci://<registry>/<repository>/<package-chart-name> --version <desiredVersion> \
     --set image.tag=0.1.0 \
     --set image.repository=package \
     --set dockerregistry=$ACR_SERVER \
     --namespace backend

Hoewel een CI/CD-pijplijn een grafiek rechtstreeks naar Kubernetes kan installeren, maakt u een grafiekarchief (.tgz-bestand) en pusht u de grafiek naar een Helm-opslagplaats, zoals Container Registry. Zie Helm-grafieken (HelmDeploy-taak) verpakken en implementeren voor meer informatie.

Revisions

Helm-grafieken hebben altijd een versienummer dat semantische versiebeheer moet gebruiken. Een grafiek kan ook een appVersion. Dit veld is optioneel en hoeft niet gerelateerd te zijn aan de grafiekversie. Sommige teams willen mogelijk toepassingen afzonderlijk van updates naar de grafieken versieren. Een eenvoudigere benadering is om één versienummer te gebruiken, dus er is een 1:1-relatie tussen de grafiekversie en de toepassingsversie. Op die manier kunt u één grafiek per release opslaan en eenvoudig de gewenste release implementeren:

helm install <package-chart-name> --version <desiredVersion>

Een andere goede gewoonte is om een wijzigingsoorzaakaantekening op te geven in de implementatiesjabloon:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "delivery.fullname" . | replace "." "" }}
  labels:
     ...
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

Met deze aantekening kunt u het wijzigingsoorzaakveld voor elke revisie weergeven met behulp van de kubectl rollout history opdracht. In het voorgaande voorbeeld wordt de wijzigingsoorzaak opgegeven als een Helm-grafiekparameter.

kubectl rollout history deployments/delivery-v010 -n backend

deployment.apps/delivery-v010
REVISION  CHANGE-CAUSE
1         Initial deployment

U kunt ook de helm list opdracht gebruiken om de revisiegeschiedenis weer te geven:

helm list -n backend

NAME              NAMESPACE   REVISION    UPDATED                                 STATUS      CHART               APP VERSION
delivery-v0.1.0   backend     1           2024-04-07 00:25:30.000000 +0000 UTC    deployed    delivery-v0.1.0     v0.1.0

Azure-pipelines

Azure-pipelines heeft een service in Azure DevOps twee pijplijntypen: pijplijnen bouwen en release-pijplijnen. De build-pijplijn voert de CI-procedure uit en maakt bouwartefacten. Voor een microservicesarchitectuur op Kubernetes zijn deze artefacten de containerinstallatiekopieën en Helm-charts die elke microservice definiëren. De release-pijplijn voert het CD-proces uit waarmee een microservice in een cluster wordt geïmplementeerd.

Op basis van de CI-werkstroom die eerder in dit artikel is beschreven, kan een build-pijplijn bestaan uit de volgende taken:

1. Bouw de testrunnercontainer met behulp van de Docker taak.
2. Voer de tests uit door de testrunnercontainer aan te docker run roepen met behulp van de Docker taak.
3. Publiceer de testresultaten met behulp van de PublishTestResults taak. Zie Een installatiekopieën bouwen voor meer informatie.
4. Voer SAST uit op de broncode.
5. Bouw de runtimecontainer met behulp van lokale docker build en de Docker taak of met behulp van Container Registry-builds en de AzureCLI taak. Genereer een softwarefactuur van materialen (SBOM) voor de installatiekopieën, bijvoorbeeld met behulp van het hulpprogramma Microsoft SBOM, en publiceer het als een pijplijnartefact dat is gekoppeld aan de samenvatting van de installatiekopieën of koppel deze aan de installatiekopieën in Container Registry.
6. Voer het scannen van beveiligingsproblemen in de containerinstallatiekopie uit (bijvoorbeeld met behulp van Microsoft Defender voor containers of een hulpprogramma dat niet Microsoft zoals Trivy) om bekende beveiligingsproblemen te detecteren voordat de installatiekopie wordt gepubliceerd.
7. Push de containerinstallatiekopieën naar Container Registry (of een ander containerregister) met behulp van de Docker of AzureCLI taak.
8. Onderteken de gepushte afbeelding door onveranderbare digest om de integriteit en authenticiteit ervan te garanderen. Volg de richtlijnen voor notatieondertekening voor Azure-pipelines.
9. Pak de Helm-grafiek in met behulp van de HelmDeploy taak.
10. Push het Helm-pakket naar Container Registry (of een andere Helm-opslagplaats) met behulp van de HelmDeploy taak.

De output van de CI-pijplijn is een productiegereede containerimage en een bijgewerkte Helm chart voor de microservice. Op dit moment kan de release-pijplijn het overnemen. Er is een unieke release-pijplijn voor elke microservice. De releasepijplijn is geconfigureerd om een triggerbron te hebben die is gekoppeld aan de CI-pijplijn die het artefact heeft gepubliceerd. Met deze pijplijn kunt u elke microservice onafhankelijk implementeren. De release-pijplijn voert de volgende stappen uit:

1. Implementeer de Helm-grafiek in ontwikkel-/QA-/faseringsomgevingen. U kunt de helm upgrade opdracht met de --install vlag gebruiken ter ondersteuning van de eerste installatie en volgende upgrades.
2. Wacht totdat een goedkeurder het uitrollen goedkeurt of afwijst.
3. De containerinstallatiekopieën opnieuw tagen voor release.
4. Push de release-tag naar het containerregister.
5. Implementeer de Helm-grafiek in het productiecluster. Gebruik Ratificeren met Azure Policy om afbeeldingshandtekeningen tijdens de toegang te valideren en afzonderlijk een beleid voor toegestane installatiekopieën te configureren om afbeeldingen te beperken tot vertrouwde registers.

Zie Release-pijplijnen, conceptversies en releaseopties voor meer informatie over het maken van een release-pijplijn.

In het volgende diagram ziet u het end-to-end CI/CD-proces dat in dit artikel wordt beschreven:

GitHub Actions alternatief

Als uw team GitHub gebruikt voor broncodebeheer, biedt GitHub Actions een gelijkwaardig CI/CD-platform. Naast de starterswerkstromen en OIDC-verificatie die u eerder hebt genoteerd, kunt u deze GitHub-specifieke mogelijkheden overwegen wanneer u zich richt op AKS:

• Omgevingen en beveiligingsregels. Als uw GitHub zichtbaarheid van plannen en opslagplaatsen deze ondersteunen, gebruikt u GitHub omgevingen met vereiste revisoren, wachttimers en implementatiebranches om goedkeuringspoorten te implementeren.
• Containerscans. Gebruik GitHub Actions Marketplace-acties voor Trivy, Microsoft Defender voor DevOps of vergelijkbare hulpprogramma's voor het scannen van containerinstallatiekopieën rechtstreeks in uw werkstroom.

Waarneembaarheid en bewaking

Implementeer waarneembaarheid in de gehele CI/CD-pijplijn en runtime-omgeving:

• Pijplijnbewaking. Houd buildduur bij, testpasfrequenties, implementatiefrequentie en foutpercentages. Azure DevOps biedt ingebouwde analyses. GitHub Actions kunt niet-Microsoft dashboards gebruiken.
• Runtime-bewaking. Gebruik Azure Monitor beheerde service voor Prometheus en Azure Managed Grafana om metrische gegevens van AKS-clusters en workload te bewaken.
• Toepassingstelemetrie. Instrumenteer uw microservices met Azure Monitor Application Insights voor gedistribueerde tracering, aanvraagregistratie en afhankelijkheidstracering.
• Waarschuwing. Configureer waarschuwingen voor implementatiefouten, opnieuw opstarten van pods, hoge foutpercentages en resourceverzadiging om snelle reactie op incidenten mogelijk te maken.

Well-Architected Framework-uitlijning

Wanneer u uw CI/CD-pijplijn ontwerpt voor microservices in Kubernetes, moet u rekening houden met de pijlers van het Azure Well-Architected Framework:

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

• Ray Kao | Principal Solutions Engineer

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

Volgende stappen 

• Een Git-vertakkingsstrategie aannemen
• Wat is Azure-pipelines?
• Release-pijplijnen, conceptversies en releaseopties
• Implementatiebeheer met behulp van goedkeuringen
• Inleiding tot Azure Container Registry
• Microsoft Entra Workload-id met AKS
• Azure Key Vault-provider voor Secrets Store CSI-driver
• DevSecOps in AKS

Gerelateerde bronnen

• CI/CD voor microservices
• Microservices-architectuur op AKS
• GitOps voor Azure Kubernetes Service
• Basislijnarchitectuur voor een AKS-cluster
• CI/CD-basislijnarchitectuur met Azure-pipelines