Dela via

Självstudie: Implementera CI/CD med GitOps med Azure Arc-aktiverade Kubernetes-kluster

  • Artikel

Viktigt!

I den här självstudien används GitOps med Flux v1. GitOps med Flux v2 är nu tillgängligt för Azure Arc-aktiverade Kubernetes- och Azure Kubernetes Service-kluster (AKS). gå till självstudien som använder GitOps med Flux v2. Vi rekommenderar att du migrerar till Flux v2 så snart som möjligt.

Stöd för Flux v1-baserade klusterkonfigurationsresurser som skapats före den 1 januari 2024 upphör den 24 maj 2025. Från och med den 1 januari 2024 kan du inte skapa nya Flux v1-baserade klusterkonfigurationsresurser.

I den här självstudien konfigurerar du en CI/CD-lösning med GitOps med Azure Arc-aktiverade Kubernetes-kluster. Med azure vote-exempelappen gör du följande:

  • Skapa ett Azure Arc-aktiverat Kubernetes-kluster.
  • Anslut ditt program och GitOps-lagringsplatser till Azure-lagringsplatser.
  • Importera CI/CD-pipelines.
  • Anslut Azure Container Registry (ACR) till Azure DevOps och Kubernetes.
  • Skapa miljövariabelgrupper.
  • 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. Skärmbild som visar ett exempel på 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. Knapp för att starta Azure Cloud Shell.
Välj knappen Cloud Shell på menyn längst upp till höger i Azure-portalen. Skärmbild som visar Cloud Shell-knappen i Azure-portalen

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.

Innan du börjar

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

  • Logga in på Azure DevOps Services.

  • 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 följande Azure Arc-aktiverade Kubernetes CLI-tillägg för versioner >= 1.0.0:

    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

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

Läs mer om att importera 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 din app kontinuerligt ansluter du programrepoen 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 bara 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 lagringsplats arc-cicd-demo-gitops i Azure Repos.

    az k8s-configuration create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --resource-group myResourceGroup \
   --operator-instance-name cluster-config \
   --operator-namespace cluster-config \
   --repository-url 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 \
   --operator-params='--git-readonly --git-path=arc-cicd-cluster/manifests'

  2. Kontrollera att Flux endast använder arc-cicd-cluster/manifests katalogen som bassökväg. Definiera sökvägen med hjälp av följande operatorparameter:

    --git-path=arc-cicd-cluster/manifests

    Kommentar

    Om du använder en HTTPS-niska veze och har anslutningsproblem kontrollerar du att du utelämnar användarnamnprefixet i URL:en. Till exempel https://alice@dev.azure.com/contoso/project/_git/arc-cicd-demo-gitops måste ha alice@ tagits bort. --https-user Anger användaren i stället, till exempel --https-user alice.

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

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

Importera CI/CD-pipelines

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

Programrepo innehåller en .pipeline mapp med de pipelines som du ska använda för PR, CI och CD. Importera och byt namn på de tre pipelines som finns i exempeldatabasen:

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 din ACR

Både dina pipelines och kluster använder ACR för att lagra och hämta Docker-avbildningar.

Ansluta ACR 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.

Ansluta ACR till Kubernetes

Aktivera kubernetes-klustret för att hämta avbildningar från din ACR. Om den är privat krävs autentisering.

Ansluta ACR till befintliga AKS-kluster

Integrera en befintlig ACR med befintliga AKS-kluster med 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 din ACR skapar du en avbildningshämtningshemlighet. 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 Kubernetes-självstudien .

Skapa miljövariabelgrupper

Apprepovariabelgrupp

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

Variabel Värde
AZ_ACR_NAME (din ACR-instans, till exempel azurearctest.azurecr.io)
AZURE_SUBSCRIPTION (Din Azure Service-anslutning, som ska vara arc-demo-acr från tidigare i självstudien)
AZURE_VOTE_IMAGE_REPO Den fullständiga sökvägen till Lagringsplatsen för Azure Vote-appen, till exempel azurearctest.azurecr.io/azvote
ENVIRONMENT_NAME Utv
MANIFESTS_BRANCH master
MANIFESTS_FOLDER azure-vote-manifests
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

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 .

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 Repositories.
  3. Välj <GitOps Repo Name>.
  4. Välj Security.
  5. <Project Name> Build Service (<Organization Name>)För , tillåt Contribute, Contribute to pull requestsoch Create branch.

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 uppmanas du att 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 på GitOps-lagringsplatsen har genererats skapar CD-pipelinen en incheckning, push-överför den och skapar en PR för godkännande.

  1. Öppna PR-länken som anges i aktivitetens Create PR utdata.

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

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

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

    • Det här ä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 hittades under lintningsintervallet från:

  • Felaktigt formaterade YAML-filer till
  • Förslag på bästa praxis, till exempel att ställa in 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 ska distribuera 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 artikeln Ange grenprinciper .

Godkännanden av CD-processer

En lyckad CI-pipelinekörning utlöser CD-pipelinen för att slutföra distributionsprocessen. Precis som första gången du kan cd-pipelinen distribuerar du till varje miljö stegvis. 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 på GitOps-lagringsplatsen har genererats skapar CD-pipelinen en incheckning, push-överför den och skapar en PR för godkännande.
  3. Öppna PR-länken som anges i uppgiften.
  4. 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.
  5. Om allt ser bra ut godkänner du och slutför pr.en.
  6. Vänta tills distributionen har slutförts.
  7. 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.
  8. Upprepa steg 1–7 för stage miljön.

Distributionen är nu klar. Detta avslutar CI/CD-arbetsflödet.

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 delete \
--name cluster-config \
--cluster-name arc-cicd-cluster \
--resource-group myResourceGroup \
--cluster-type connectedClusters

  2. dev Ta bort namnområdet:

    • kubectl delete namespace dev

  3. stage Ta bort namnområdet:

    • kubectl delete namespace stage

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.

CI/CD-arbetsflöde med GitOps – Azure Arc-aktiverade Kubernetes