Dela via

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

  • Artikel

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

  • Anslut ditt program och GitOps-lagringsplatser till Azure Devops (Azure Repos) eller GitHub.
  • Implementera CI/CD-flöde med antingen Azure Pipelines eller GitHub.
  • Anslut Ditt Azure Container Registry till Azure DevOps och Kubernetes.
  • Skapa miljövariabelgrupper eller hemligheter.
  • Distribuera miljöerna dev och stage .
  • Testa programmiljöerna.

Om du inte har någon Azure-prenumeration skapar du ett kostnadsfritt konto innan du börjar.

Förutsättningar

  • 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:

  • 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 avbildningshämtningshemlighet

Om du vill ansluta icke-AKS- och lokala kluster till Azure Container Registry skapar du en pull-hemlighet för avbildningar. 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änstkontot i dev namnrymderna 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

Den här självstudien förutsätter att du är bekant med Azure DevOps, Azure Repos och Pipelines samt Azure CLI.

Slutför följande steg först:

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

  • arc-cicd-demo-gitops GitOps-lagringsplats

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

Kommentar

Att importera och använda två separata lagringsplatser för program- och GitOps-lagringsplatser kan förbättra säkerheten och enkelheten. Program- och GitOps-lagringsplatsernas behörigheter och synlighet kan justeras individuellt. Klusteradministratören kanske till exempel inte hittar ändringarna i programkoden som är relevanta för klustrets önskade tillstånd. Omvänt behöver en programutvecklare inte känna till de specifika parametrarna för varje miljö – en uppsättning testvärden som ger täckning för parametrarna kan vara tillräckliga.

Ansluta GitOps-lagringsplatsen

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

    Dricks

    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 Portal.

    • 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 Portal sidan i GitOps klustret.

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:

Namn på pipelinefil beskrivning
.pipelines/az-vote-pr-pipeline.yaml Program-PR-pipelinen med namnet arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml Program-CI-pipelinen med namnet arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml Program-CD-pipelinen med namnet arc-cicd-demo-src CD

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-pipelinen manipulerar pull-begäranden (PR) på GitOps-lagringsplatsen, 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 anslutningsappen 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>

    Kommentar

    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/v1beta1
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/v1beta1
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.

Variabel Värde
AZURE_SUBSCRIPTION (Din Azure Service-anslutning, som ska vara arc-demo-acr från tidigare i självstudien)
AZ_ACR_NAME Azure ACR-namn, till exempel arc-demo-acr
ENVIRONMENT_NAME Utv
MANIFESTS_BRANCH master
MANIFESTS_REPO arc-cicd-demo-gitops
ORGANIZATION_NAME Namnet på Azure DevOps-organisationen
PROJECT_NAME Namn på GitOps-projekt i Azure DevOps
REPO_URL Fullständig URL för GitOps-lagringsplats
SRC_FOLDER azure-vote
TARGET_CLUSTER arc-cicd-cluster
TARGET_NAMESPACE dev
VOTE_APP_TITLE Röstningsprogram
AKS_RESOURCE_GROUP AKS-resursgrupp. Behövs för automatiserad testning.
AKS_NAME AKS-namn. Behövs för automatiserad testning.

Scenmiljövariabelgrupp

  1. Klona variabelgruppen az-vote-app-dev.

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

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

    Variabel Värde
    ENVIRONMENT_NAME Fas
    TARGET_NAMESPACE stage

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

Skapa miljöer

Skapa och Stage miljöer i ditt Azure DevOps-projektDev. 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, push-överföra ändringar och skapa PR:er. Så här aktiverar du följande behörigheter:

  1. I Azure DevOps, öppna Projektinställningar.
  2. Under Lagringsplatser väljer du Lagringsplatser.
  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 pipelinen igen.

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.

Dricks

Om CD-pipelinen inte utlöses automatiskt:

  1. Kontrollera att namnet matchar grenutlösaren i .pipelines/az-vote-cd-pipeline.yaml
    • Den bör vara arc-cicd-demo-src CI.
  2. Kör CI-pipelinen igen.

När mallen och manifeständringarna till GitOps-lagringsplatsen har genererats skapar CD-pipelinen en incheckning, push-överför den och skapar en PR 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:

    • Helm-malländringar på hög nivå.
    • 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änner du och slutför pr.en.

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

  5. Övervaka statusen git commit på fliken Incheckningshistorik . När det är succeededdet 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 en paus efter distributionen hjälper aktivering av miljögodkännanden till att hålla problemet från 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 Söker efter 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 kontrollen från pipelinen för att låta ändringsflödet till nästa miljö.

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. Redigera filen på lagringsplatsen azure-vote/src/azure-vote-front/config_file.cfg arc-cicd-demo-src.

  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, push-överför den och skapa en pull-begäran. Den här stegsekvensen är det typiska utvecklarflödet som startar CI/CD-livscykeln.

PR-valideringspipeline

PR-pipelinen är den 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.

Kommentar

För att få bästa täckning från Helm-lintning i ett verkligt program ersätter du värden som är ganska lika värden som skulle användas i en verklig miljö.

Fel som påträffas under pipelinekörningen visas i testresultatavsnittet i körningen. Här kan du göra följande:

  • Spåra användbar statistik för feltyperna.
  • Hitta den första incheckningen som de identifierades på.
  • 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.

Dricks

I en verklig miljö måste du ange avdelningsprinciper för att säkerställa att PR:en klarar kvalitetskontrollerna. Mer information finns i Grenprinciper och inställningar.

Godkännanden av CD-processer

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 dev till miljön.
  2. När mallen och manifeständringarna till GitOps-lagringsplatsen har genererats skapar CD-pipelinen en incheckning, push-överför den och skapar en PR för godkännande.
  3. Kontrollera ändringarna i GitOps-lagringsplatsen. Du bör se:
    • Helm-malländringar på hög nivå.
    • Kubernetes-manifest på låg nivå som visar de underliggande ändringarna i önskat tillstånd.
  4. Om allt ser bra ut godkänner du och slutför pr.en.
  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 flikar kontra blanksteg.
    • 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 självstudien förutsätter att du är bekant med GitHub, 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:

Ansluta GitOps-lagringsplatsen

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 Portal.

    • 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 anslutningsappen 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/v1beta1
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/v1beta1
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:

Hemlig Värde
AZURE_CREDENTIALS Autentiseringsuppgifter för Azure i följande format {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","tenantId":"GUID"}
AZ_ACR_NAME Azure ACR-namn, till exempel arc-demo-acr
MANIFESTS_BRANCH master
MANIFESTS_FOLDER arc-cicd-cluster
MANIFESTS_REPO https://github.com/your-organization/arc-cicd-demo-gitops
VOTE_APP_TITLE Röstningsprogram
AKS_RESOURCE_GROUP AKS-resursgrupp. Behövs för automatiserad testning.
AKS_NAME AKS-namn. Behövs för automatiserad testning.
PAT GitHub PAT-token med behörighet till PR till GitOps-lagringsplatsen

Skapa GitHub-miljöhemligheter

  1. Skapa az-vote-app-dev en miljö med följande hemligheter:
Hemlig Värde
ENVIRONMENT_NAME Utv
TARGET_NAMESPACE dev
  1. Skapa az-vote-app-stage en miljö med följande hemligheter:
Hemlig Värde
ENVIRONMENT_NAME Fas
TARGET_NAMESPACE stage

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ärden i filen på .azure-vote/src/azure-vote-front/config_file.cfg 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:

    • Helm-malländringar på hög nivå.
    • 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änner du och slutför pr.en.

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

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

  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-fas

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 fasmiljö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. Ändringar i appen utlöser automatiskt validering och distribution, gated 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.

Koncept: CD-process med GitOps-exempelimplementering: Utforska CI/CD-flöde med GitOps