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 AkS-kluster (Azure Kubernetes Service). Med azure vote-exempelappen gör du följande:

  • Skapa ett Azure Arc-aktiverat Kubernetes- eller AKS-kluster.
  • Anslut ditt program och GitOps-lagringsplatser till 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.

Azure Cloud Shell

Azure är värd för Azure Cloud Shell, en interaktiv gränssnittsmiljö som du kan använda via webbläsaren. Du kan använda antingen Bash eller PowerShell med Cloud Shell för att arbeta med Azure-tjänster. Du kan använda förinstallerade Cloud Shell-kommandon för att köra koden i den här artikeln, utan att behöva installera något i din lokala miljö.

Så här startar du Azure Cloud Shell:

Alternativ Exempel/länk
Välj Prova i det övre högra hörnet i en kod eller ett kommandoblock. Om du väljer Prova kopieras inte koden eller kommandot automatiskt till Cloud Shell. Screenshot that shows an example of Try It for Azure Cloud Shell.
Gå till https://shell.azure.com eller Välj knappen Starta Cloud Shell för att öppna Cloud Shell i webbläsaren. Button to launch Azure Cloud Shell.
Välj knappen Cloud Shell på menyn längst upp till höger i Azure-portalen. Screenshot that shows the Cloud Shell button in the Azure portal

Så här använder du Azure Cloud Shell:

  1. Starta Cloud Shell.

  2. Välj knappen Kopiera i ett kodblock (eller kommandoblock) för att kopiera koden eller kommandot.

  3. Klistra in koden eller kommandot i Cloud Shell-sessionen genom att välja Ctrl+Skift+V i Windows och Linux, eller genom att välja Cmd+Shift+V på macOS.

  4. Välj Retur för att köra koden eller kommandot.

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 dessa tillägg till den senaste versionen kör du följande kommandon:

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

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

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

Anslut 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 kommer 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 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-portalen.

    • Om det lyckas visas både dev och stage namnområden som skapats i klustret.
    • Du kan också bekräfta att på azure-portalsidan i klustret skapas en konfiguration cluster-config på fliken fGitOps .

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

Anslut 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 OK för att skapa anslutningen.

Konfigurera PR-tjänstanslutning

CD-pipelinen manipulerar PR:er på GitOps-lagringsplatsen. Den behöver en tjänstanslutning för att kunna göra detta. 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 OK för att skapa anslutningen.

Installera GitOps Anslut or

  1. Lägg till GitOps Anslut eller-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 Anslut eller-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-Anslut ion, 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 rikta in dig på en miljö.

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 pipelinen för att skapa en ny gren, push-ändringar och skapa pull-begäranden.

  1. Gå till från huvudsidan för Project settings Azure DevOps-projektet.
  2. Välj Repos/Repositories.
  3. Välj Security.
  4. <Project Name> Build Service (<Organization Name>) För och för Project Collection Build Service (<Organization Name>) (skriv i sökfältet, om det inte visas), tillåt Contribute, Contribute to pull requestsoch Create branch.
  5. Gå till Pipelines/Settings
  6. Inaktivera Protect access to repositories in YAML pipelines alternativ

Mer information finns i:

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

Under den första CI-pipelinekörningen kan du få ett resursauktoriseringsfel när du läser namnet på tjänstanslutningen.

  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 Git-incheckningsstatusen 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 inte bara göra ändringar i koden eller mallarna, utan du kan också oavsiktligt försätta klustret i ett felaktigt tillstånd.

Om utvecklingsmiljön visar en paus efter distributionen kan du förhindra att den går till senare miljöer med hjälp av miljögodkännanden.

  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 självstudien Definiera godkännande och kontroller .

Nästa gång CD-pipelinen körs pausas pipelinen efter att GitOps PR har skapats. Kontrollera att ändringen har synkroniserats korrekt och skickar 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 måste du ersätta värden som är ganska lika dem som används 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.

När pipelinekörningen är klar har du försäkrat dig om kvaliteten på programkoden och mallen som distribuerar den. Nu kan du godkänna och slutföra PR. CI körs igen och återskapar mallar och manifest innan CD-pipelinen utlöses.

Dricks

I en verklig miljö ska du inte glömma att ange avdelningsprinciper för att säkerställa att PR:en klarar dina kvalitetskontroller. Mer information finns i Ange grenprinciper.

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:

Anslut 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 kommer 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 Anslut or

  1. Lägg till GitOps Anslut eller-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 Anslut eller-lagringsplatsen.

Skapa GitHub-hemligheter

Skapa 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 ska användas 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.

  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 Git-incheckningsstatusen 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 Anslut or.

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-Anslut eller:

    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 har du konfigurerat 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.

Konceptuellt CI/CD-arbetsflöde med GitOps