Självstudie: Implementera CI/CD med GitOps (Flux v2)

I den här självstudien konfigurerar du en CI/CD-lösning med GitOps genom Flux v2 och Azure Arc-anpassade Kubernetes- eller Azure Kubernetes Service-kluster (AKS). Med azure vote-exempelappen kan du:

Om du inte har en Azure-prenumeration, skapa ett gratis konto innan du börjar.

Prerequisites

• Slutför den föregående självstudien för att lära dig hur du distribuerar GitOps för din CI/CD-miljö.

• Förstå fördelarna och arkitekturen för den här funktionen.

• Kontrollera att du har:

  • Ett anslutet Azure Arc-aktiverat Kubernetes-kluster med namnet arc-cicd-cluster.
  • Ett anslutet Azure Container Registry med antingen AKS-integrering eller icke-AKS-klusterautentisering.

• Installera de senaste versionerna av dessa Azure Arc-aktiverade Kubernetes- och Kubernetes Configuration CLI-tillägg:

  az extension add --name connectedk8s
  az extension add --name k8s-configuration
  

• Om du vill uppdatera tilläggen till den senaste versionen kör du följande kommandon:

  az extension update --name connectedk8s
  az extension update --name k8s-configuration
  

Ansluta Azure Container Registry till Kubernetes

Aktivera Kubernetes-klustret för att hämta avbildningar från Azure Container Registry. Om den är privat krävs autentisering.

Ansluta Azure Container Registry till befintliga AKS-kluster

Integrera ett befintligt Azure Container Registry med befintliga AKS-kluster med hjälp av följande kommando:

az aks update -n arc-cicd-cluster -g myResourceGroup --attach-acr arc-demo-acr

Skapa en avbilddragningshemlighet

Om du vill ansluta kluster som inte är AKS samt lokala kluster till Azure Container Registry, skapar du ett image pull secret. Kubernetes använder avbildningshämtningshemligheter för att lagra information som behövs för att autentisera registret.

Skapa en avbildningshämtningshemlighet med följande kubectl kommando. Upprepa för både namnrymderna dev och stage .

kubectl create secret docker-registry <secret-name> \
    --namespace <namespace> \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<service-principal-ID> \
    --docker-password=<service-principal-password>

Om du vill undvika att behöva ange en imagePullSecret för varje podd kan du överväga att lägga till imagePullSecret till tjänstekontot i namnrymderna dev och stage. Mer information finns i självstudien om Kubernetes.

Beroende på vilken CI/CD-orkestrerare du föredrar kan du fortsätta med instruktioner för Antingen Azure DevOps eller GitHub.

Implementera CI/CD med Azure DevOps

Självstudien utgår från att du har kunskap om Azure DevOps, Azure Repos och Pipelines samt Azure CLI.

Slutför följande steg först:

• Logga in på Azure DevOps Services.
• Kontrollera att du har behörigheten "Skapa administratör" och "Projektadministratör" för Azure Repos och Azure Pipelines.

Importera program- och GitOps-lagringsplatser till Azure-lagringsplatser

Importera en programlagringsplats och en GitOps-lagringsplats till Azure Repos. I den här självstudien använder du följande exempeldatabaser:

• arc-cicd-demo-src-programlagringsplats

  • URL: https://github.com/Azure/arc-cicd-demo-src
  • Innehåller exemplet azure vote app som ska distribueras med GitOps.
  • Importera lagringsplatsen med namnet arc-cicd-demo-src

• arc-cicd-demo-gitops GitOps-lagringsplats

  • URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Fungerar som bas för dina klusterresurser som rymmer Azure Vote-appen.
  • Importera lagringsplatsen med namnet arc-cicd-demo-gitops

Läs mer om hur du importerar Git-lagringsplatser.

Ansluta GitOps-förvaret

Om du vill distribuera appen kontinuerligt ansluter du programlagringsplatsen till klustret med GitOps. GitOps-lagringsplatsen arc-cicd-demo-gitops innehåller de grundläggande resurserna för att få igång appen på ditt arc-cicd-cluster-kluster.

Den första GitOps-lagringsplatsen innehåller endast ett manifest som skapar de utvecklings- och fasnamnområden som motsvarar distributionsmiljöerna.

GitOps-anslutningen som du skapar synkroniserar automatiskt manifesten i manifestkatalogen och uppdaterar klustertillståndet.

CI/CD-arbetsflödet fyller manifestkatalogen med extra manifest för att distribuera appen.

1. Skapa en ny GitOps-anslutning till din nyligen importerade arc-cicd-demo-gitops-lagringsplats i Azure Repos.

   az k8s-configuration flux create \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --namespace flux-system \
      --resource-group myResourceGroup \
      -u https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
      --https-user <Azure Repos username> \
      --https-key <Azure Repos PAT token> \
      --scope cluster \
      --cluster-type connectedClusters \
      --branch master \
      --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
   

   Tip

   För ett AKS-kluster (i stället för ett Arc-aktiverat kluster) använder du -cluster-type managedClusters.

2. Kontrollera tillståndet för distributionen i Azure-portalen.

   • Om det lyckas visas både dev och stage namnområden som skapats i klustret.
   • Du kan också bekräfta att en konfiguration cluster-config skapas på fliken på Azure-portalsidan för ditt kluster GitOps.

Importera CI/CD-pipelines

Nu när du har synkroniserat en GitOps-anslutning måste du importera CI/CD-pipelines som skapar manifesten.

Programlagringsplatsen innehåller en .pipeline mapp med pipelines som används för PR, CI och CD. Importera och byt namn på de tre pipelines som anges i exempellagringsplatsen:

Ansluta Azure Container Registry till Azure DevOps

Under CI-processen distribuerar du dina programcontainrar till ett register. Börja med att skapa en Azure-tjänstanslutning:

1. I Azure DevOps öppnar du sidan Tjänstanslutningar från sidan projektinställningar. I TFS öppnar du sidan Tjänster från inställningsikonen i den översta menyraden.
2. Välj + Ny tjänstanslutning och välj den typ av tjänstanslutning som du behöver.
3. Fyll i parametrarna för tjänstanslutningen. För den här självstudien:
   • Ge tjänstanslutningen namnet arc-demo-acr.
   • Välj myResourceGroup som resursgrupp.
4. Välj Bevilja åtkomstbehörighet till alla pipelines.
   • Det här alternativet auktoriserar YAML-pipelinefiler för tjänstanslutningar.
5. Välj Spara för att skapa anslutningen.

Konfigurera PR-tjänstanslutning

CD-pipeline hanterar pull-begäranden (PRs) i GitOps-repositoriet, vilket kräver en tjänstanslutning. Så här konfigurerar du den här anslutningen:

1. I Azure DevOps öppnar du sidan Tjänstanslutningar från sidan projektinställningar. I TFS öppnar du sidan Tjänster från inställningsikonen i den översta menyraden.
2. Välj + Ny tjänstanslutning och välj Generic typ.
3. Fyll i parametrarna för tjänstanslutningen. För den här självstudien:
   • Server-URL https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
   • Lämna Användarnamn och Lösenord tomt.
   • Namnge tjänstanslutningen azdo-pr-connection.
4. Välj Bevilja åtkomstbehörighet till alla pipelines.
   • Det här alternativet auktoriserar YAML-pipelinefiler för tjänstanslutningar.
5. Välj Spara för att skapa anslutningen.

Installera GitOps Connector

1. Lägg till GitOps Connector-lagringsplats i Helm-lagringsplatser:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

2. Installera kontakten i klustret.

      helm upgrade -i gitops-connector gitops-connector/gitops-connector \
         --namespace flux-system \
         --set gitRepositoryType=AZDO \
         --set ciCdOrchestratorType=AZDO \
         --set gitOpsOperatorType=FLUX \
         --set azdoGitOpsRepoName=arc-cicd-demo-gitops \
         --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \
         --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
         --set orchestratorPAT=<Azure Repos PAT token>
   

   Note

   Azure Repos PAT token bör ha Build: Read & execute och Code: Full behörigheter.

3. Konfigurera Flux för att skicka meddelanden till GitOps-anslutningsprogrammet:

   cat <<EOF | kubectl apply -f -
   apiVersion: notification.toolkit.fluxcd.io/v1beta2
   kind: Alert
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     eventSeverity: info
     eventSources:
     - kind: GitRepository
       name: cluster-config
     - kind: Kustomization
       name: cluster-config-cluster-config 
     providerRef:
       name: gitops-connector
   ---
   apiVersion: notification.toolkit.fluxcd.io/v1beta2
   kind: Provider
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     type: generic
     address: http://gitops-connector:8080/gitopsphase
   EOF
   

Mer information om installationen finns i GitOps Connector-lagringsplatsen .

Skapa miljövariabelgrupper

Variabelgrupp för applagringsplats

Skapa en variabelgrupp med namnet az-vote-app-dev. Ange följande värden.

Scenmiljövariabelgrupp

1. Klona gruppen för variabler az-vote-app-dev.

2. Ändra namnet till az-vote-app-stage.

3. Kontrollera följande värden för motsvarande variabler:

   Variable	Value
   ENVIRONMENT_NAME	Stage
   TARGET_NAMESPACE	stage

Nu är du redo att distribuera till miljöerna dev och stage .

Skapa miljöer

Skapa Dev- och Stage-miljöer i ditt Azure DevOps-projekt. Mer information finns i Skapa och målmiljöer.

Ge fler behörigheter till byggtjänsten

CD-pipelinen använder säkerhetstoken för den version som körs för att autentisera till GitOps-lagringsplatsen. Det krävs fler behörigheter för att pipelinen ska kunna skapa en ny gren, pusha ändringar och skapa pull requests (PR). Så här aktiverar du följande behörigheter:

1. I Azure DevOps, öppna Projektinställningar.
2. Under Lagringsplatser, välj Repo.
3. Välj Säkerhet.
4. Sök <Project Name> Build Service (<Organization Name>) och Project Collection Build Service (<Organization Name>) (använd sök om du inte ser dem) och tillåt Contribute, Bidra till pull-begäranden och Skapa gren.
5. Under Pipelines väljer du Inställningar.
6. Inaktivera alternativet Skydda åtkomst till lagringsplatser i YAML-pipelines .

Mer information finns i Bevilja behörigheter för versionskontroll till byggtjänsten och Hantera behörigheter för versionstjänstens konto.

Distribuera utvecklingsmiljön för första gången

När CI- och CD-pipelines har skapats kör du CI-pipelinen för att distribuera appen för första gången.

CI-pipeline

Om du ser ett resursauktoriseringsfel vid läsning av tjänstens anslutningsnamn under den första CI-pipelinekörningen gör du följande:

1. Kontrollera att variabeln som används är AZURE_SUBSCRIPTION.
2. Auktorisera användningen.
3. Kör rörledningen på nytt.

CI-pipelinen:

• Säkerställer att programändringen klarar alla automatiserade kvalitetskontroller för distribution.
• Gör någon extra validering som inte kunde slutföras i PR-pipelinen. Pipelinen är specifik för GitOps och publicerar även artefakterna för incheckningen som ska distribueras av CD-pipelinen.
• Verifierar att Docker-avbildningen har ändrats och att den nya avbildningen skickas.

CD-pipeline

Under den första CD-pipelinekörningen måste du ge pipelineåtkomst till GitOps-lagringsplatsen. Välj Visa när du uppmanas att pipelinen behöver behörighet att komma åt en resurs. Välj sedan Tillåt för att bevilja behörighet att använda GitOps-lagringsplatsen för aktuella och framtida körningar av pipelinen.

Den lyckade CI-pipelinekörningen utlöser CD-pipelinen för att slutföra distributionsprocessen. Du distribuerar till varje miljö stegvis.

När mallen och manifeständringarna till GitOps-lagringsplatsen har genererats skapar CD-pipelinen en commit, pushar den och skapar en pull request för godkännande.

1. Hitta den PR som skapats av pipelinen till GitOps-lagringsplatsen.

2. Kontrollera ändringarna i GitOps-lagringsplatsen. Du bör se:

   • Övergripande ändringar i Helm-mallar.
   • Kubernetes-manifest på låg nivå som visar de underliggande ändringarna i önskat tillstånd. Flux distribuerar dessa manifest.

3. Om allt ser bra ut, godkänn och slutför PR.

4. Efter några minuter hämtar Flux ändringen och startar distributionen.

5. Övervaka statusen git commit på fliken Incheckningshistorik. När statusen är succeeded startar CD-pipelinen automatiserad testning.

6. Vidarebefordra porten lokalt med hjälp av kubectl och se till att appen fungerar korrekt med:

   kubectl port-forward -n dev svc/azure-vote-front 8080:80
   

7. Visa Azure Vote-appen i webbläsaren på http://localhost:8080/.

8. Rösta på dina favoriter och gör dig redo att göra några ändringar i appen.

Konfigurera miljögodkännanden

Vid appdistribution kan du göra ändringar i koden eller mallarna, men du kan också oavsiktligt placera klustret i ett felaktigt tillstånd.

Om utvecklingsmiljön visar ett avbrott efter distributionen hjälper aktivering av miljögodkännanden till att förhindra att problemet når senare miljöer.

1. I ditt Azure DevOps-projekt går du till den miljö som måste skyddas.
2. Gå till Godkännanden och kontroller för resursen.
3. Välj Skapa.
4. Ange godkännarna och ett valfritt meddelande.
5. Välj Skapa igen för att slutföra tillägget av den manuella godkännandekontrollen.

Mer information finns i Definiera godkännande och kontroller.

Nästa gång CD-pipelinen körs pausas pipelinen efter att GitOps PR har skapats. Kontrollera att ändringen är korrekt synkroniserad och klarar grundläggande funktioner. Godkänn granskningen från pipelinen så att ändringen kan flytta till nästa system.

Göra en programändring

Med den här baslinjeuppsättningen med mallar och manifest som representerar tillståndet i klustret gör du en liten ändring i appen.

1. I arc-cicd-demo-src arkiven, redigera azure-vote/src/azure-vote-front/config_file.cfg filen.

2. Eftersom "Cats vs Dogs" inte får tillräckligt med röster ändrar du det till "Tabs vs Spaces" för att öka röstantalet.

3. Genomför ändringen i en ny gren, pusha den och skapa en pull-förfrågan. Den här stegsekvensen är det typiska utvecklarflödet som startar CI/CD-livscykeln.

PR-valideringsflöde

PR-pipelinen utgör första försvarslinjen mot en felaktig ändring. Vanliga kvalitetskontroller av programkod omfattar lintning och statisk analys. Ur ett GitOps-perspektiv måste du också säkerställa samma kvalitet för den resulterande infrastrukturen som ska distribueras.

Programmets Dockerfile- och Helm-diagram kan använda lintning på ett liknande sätt som programmet.

Fel som påträffas under lintning sträcker sig från felaktigt formaterade YAML-filer till förslag på bästa praxis, till exempel inställning av cpu- och minnesgränser för ditt program.

Fel som hittas under pipelinekörningen visas i körningens testresultat. Här kan du göra följande:

• Spåra användbar statistik för feltyperna.
• Hitta det första åtagandet där de identifierades.
• Stackspårningsformat länkar till kodavsnitten som orsakade felet.

Pipelinekörningen är klar och bekräftar kvaliteten på programkoden och mallen som distribuerar den. Nu kan du godkänna och slutföra PR. CI:n körs igen och återskapar mallar och manifest innan CD-pipelinen utlöses.

CD-processgodkännanden

En lyckad CI-pipelinekörning utlöser CD-pipelinen för att slutföra distributionsprocessen. Den här gången kräver pipelinen att du godkänner varje distributionsmiljö.

1. Godkänn distributionen till dev-miljön.
2. När mallen och manifeständringarna till GitOps-lagringsplatsen har genererats skapar CD-pipeline en commit, pushar den och skapar en PR för godkännande.
3. Kontrollera ändringarna i GitOps-lagringsplatsen. Du bör se:
   • Övergripande ändringar i Helm-mallar.
   • Kubernetes-manifest på låg nivå som visar de underliggande ändringarna i önskat tillstånd.
4. Om allt ser bra ut, godkänn och slutför PR.
5. Vänta tills distributionen har slutförts.
6. Som ett grundläggande röktest går du till programsidan och kontrollerar att röstningsappen nu visar Tabs vs Spaces.
   • Vidarebefordra porten lokalt med hjälp av kubectl och se till att appen fungerar korrekt med: kubectl port-forward -n dev svc/azure-vote-front 8080:80
   • Visa Azure Vote-appen i webbläsaren på http://localhost:8080/ och kontrollera att röstningsalternativen har ändrats till Tabs vs Spaces.
7. Upprepa steg 1–7 för stage miljön.

Distributionen är nu klar.

En detaljerad översikt över alla steg och tekniker som implementeras i CI/CD-arbetsflöden som används i den här självstudien finns i Azure DevOps GitOps Flow-diagrammet.

Implementera CI/CD med GitHub

Den här handledningen förutsätter att du är bekant med GitHub och GitHub Actions.

Förgreningsprogram och GitOps-lagringsplatser

Förgrena en programlagringsplats och en GitOps-lagringsplats. I den här självstudien använder du följande exempeldatabaser:

• arc-cicd-demo-src-programlagringsplats

  • URL: https://github.com/Azure/arc-cicd-demo-src
  • Innehåller exemplet azure vote app som ska distribueras med GitOps.

• arc-cicd-demo-gitops GitOps-lagringsplats

  • URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Fungerar som bas för dina klusterresurser som rymmer Azure Vote-appen.

Ansluta GitOps-förvaret

Om du vill distribuera appen kontinuerligt ansluter du programlagringsplatsen till klustret med GitOps. GitOps-lagringsplatsen arc-cicd-demo-gitops innehåller de grundläggande resurserna för att få igång appen på ditt arc-cicd-cluster-kluster.

Den första GitOps-lagringsplatsen innehåller endast ett manifest som skapar de utvecklings- och fasnamnområden som motsvarar distributionsmiljöerna.

GitOps-anslutningen som du skapar automatiskt:

• Synkronisera manifesten i manifestkatalogen.
• Uppdatera klustertillståndet.

CI/CD-arbetsflödet fyller manifestkatalogen med extra manifest för att distribuera appen.

1. Skapa en ny GitOps-anslutning till din nyligen förgrenade arc-cicd-demo-gitops-lagringsplats i GitHub.

   az k8s-configuration flux create \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --namespace cluster-config \
      --resource-group myResourceGroup \
      -u  https://github.com/<Your organization>/arc-cicd-demo-gitops.git \
      --https-user <Azure Repos username> \
      --https-key <Azure Repos PAT token> \
      --scope cluster \
      --cluster-type connectedClusters \
      --branch master \
      --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
   

2. Kontrollera tillståndet för distributionen i Azure-portalen.

   • Om det lyckas visas både dev och stage namnområden som skapats i klustret.

Installera GitOps Connector

1. Lägg till GitOps Connector-lagringsplats i Helm-lagringsplatser:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

2. Installera kontakten i klustret.

      helm upgrade -i gitops-connector gitops-connector/gitops-connector \
         --namespace flux-system \
         --set gitRepositoryType=GITHUB \
         --set ciCdOrchestratorType=GITHUB \
         --set gitOpsOperatorType=FLUX \
         --set gitHubGitOpsRepoName=arc-cicd-demo-src \
         --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \
         --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \
         --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \
         --set orchestratorPAT=<GitHub PAT token>
   

3. Konfigurera Flux för att skicka meddelanden till GitOps-anslutningsprogrammet:

   cat <<EOF | kubectl apply -f -
   apiVersion: notification.toolkit.fluxcd.io/v1beta2
   kind: Alert
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     eventSeverity: info
     eventSources:
     - kind: GitRepository
       name: cluster-config
     - kind: Kustomization
       name: cluster-config-cluster-config
     providerRef:
       name: gitops-connector
   ---
   apiVersion: notification.toolkit.fluxcd.io/v1beta2
   kind: Provider
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     type: generic
     address: http://gitops-connector:8080/gitopsphase
   EOF
   

Mer information om installationen finns i GitOps Connector-lagringsplatsen .

Skapa GitHub-hemligheter

Nästa steg är att skapa GitHub-lagringsplats och miljöhemligheter.

Skapa GitHub-lagringsplatshemligheter

Använd följande värden för dina GitHub-lagringsplatshemligheter:

Skapa GitHub-miljöhemligheter

1. Skapa az-vote-app-dev en miljö med följande hemligheter:

1. Skapa az-vote-app-stage en miljö med följande hemligheter:

Nu är du redo att distribuera till miljöerna dev och stage .

CI/CD Dev-arbetsflöde

Om du vill starta CI/CD Dev-arbetsflödet ändrar du källkoden. Uppdatera värdena i .azure-vote/src/azure-vote-front/config_file.cfg-filen i programlagringsplatsen och skicka ändringarna till lagringsplatsen.

CI/CD Dev-arbetsflödet:

• Säkerställer att programändringen klarar alla automatiserade kvalitetskontroller för distribution.
• Gör någon extra validering som inte kunde slutföras i PR-pipelinen.
• Verifierar att Docker-avbildningen har ändrats och att den nya avbildningen skickas.
• Publicerar artefakterna (Docker-avbildningstaggar, Manifestmallar, Utils) som används av följande CD-steg.
• Distribuerar programmet till Dev-miljön.
  • Genererar manifest till GitOps-lagringsplatsen.
  • Skapar en PR till GitOps-lagringsplatsen för godkännande.

När de här stegen har slutförts:

1. Hitta den PR som skapats av pipelinen till GitOps-lagringsplatsen.

2. Kontrollera ändringarna i GitOps-lagringsplatsen. Du bör se:

   • Övergripande ändringar i Helm-mallar.
   • Kubernetes-manifest på låg nivå som visar de underliggande ändringarna i önskat tillstånd. Flux distribuerar dessa manifest.

3. Om allt ser bra ut, godkänn och slutför PR.

4. Efter några minuter hämtar Flux ändringen och startar distributionen.

5. Övervaka statusen på fliken git commit Incheckningshistorik. När det är succeeded startar arbetsflödet CD Stage.

6. Vidarebefordra porten lokalt med hjälp av kubectl och se till att appen fungerar korrekt med:

   kubectl port-forward -n dev svc/azure-vote-front 8080:80
   

7. Visa Azure Vote-appen i webbläsaren på http://localhost:8080/.

8. Rösta på dina favoriter och gör dig redo att göra några ändringar i appen.

arbetsflöde för CD-steg

Arbetsflödet för CD-fas startar automatiskt när Flux har distribuerat programmet till utvecklingsmiljön och meddelar GitHub-åtgärder via GitOps Connector.

Arbetsflödet för CD-stadiet:

• Kör röktester för program mot Dev-miljön
• Distribuerar programmet till stagingmiljön.
  • Genererar manifest till GitOps-lagringsplatsen
  • Skapar en PR till GitOps-lagringsplatsen för godkännande

När manifest-PR för stage-miljön har sammanfogats och Flux har tillämpat alla ändringar uppdateras Git-incheckningsstatusen på GitOps-lagringsplatsen. Distributionen är nu klar.

En detaljerad översikt över alla steg och tekniker som implementeras i CI/CD-arbetsflöden som används i den här självstudien finns i GitHub GitOps Flow-diagrammet.

Rensa resurser

Om du inte kommer att fortsätta att använda det här programmet tar du bort alla resurser med följande steg:

1. Ta bort Azure Arc GitOps-konfigurationsanslutningen:

   az k8s-configuration flux delete \
         --name cluster-config \
         --cluster-name arc-cicd-cluster \
         --resource-group myResourceGroup \
         -t connectedClusters --yes
   

2. Ta bort GitOps-anslutningsprogram:

   helm uninstall gitops-connector -n flux-system
   kubectl delete alerts.notification.toolkit.fluxcd.io gitops-connector -n flux-system
   kubectl delete providers.notification.toolkit.fluxcd.io  gitops-connector -n flux-system
   

Nästa steg

I den här självstudien konfigurerar du ett fullständigt CI/CD-arbetsflöde som implementerar DevOps från programutveckling till distribution. När ändringar görs i appen utlöses automatiskt validering och distribution, som är beroende av manuella godkännanden.

Gå vidare till vår konceptuella artikel om du vill veta mer om GitOps och konfigurationer med Azure Arc-aktiverade Kubernetes.