Delen via

Zelfstudie: CI/CD implementeren met GitOps (Flux v2)

  • Artikel

In deze zelfstudie stelt u een CI/CD-oplossing in met Behulp van GitOps met Flux v2- en Kubernetes- of AKS-clusters (Azure Kubernetes Service). Met behulp van de Azure Vote-voorbeeld-app gaat u het volgende doen:

  • Maak een Kubernetes- of AKS-cluster met Azure Arc.
  • Verbind uw toepassing en GitOps-opslagplaatsen met Azure-opslagplaatsen of GitHub.
  • Implementeer CI/CD-stroom met Azure Pipelines of GitHub.
  • Verbind uw Azure Container Registry met Azure DevOps en Kubernetes.
  • Maak omgevingsvariabelegroepen of geheimen.
  • Implementeer de dev en stage omgevingen.
  • Test de toepassingsomgevingen.

Als u geen Azure-abonnement hebt, maakt u een gratis account voordat u begint.

Azure Cloud Shell

Azure host Azure Cloud Shell, een interactieve shell-omgeving die u via uw browser kunt gebruiken. U kunt Bash of PowerShell gebruiken met Cloud Shell om met Azure-services te werken. U kunt de vooraf geïnstalleerde Cloud Shell-opdrachten gebruiken om de code in dit artikel uit te voeren zonder dat u iets hoeft te installeren in uw lokale omgeving.

Om Azure Cloud Shell op te starten:

Optie Voorbeeld/koppeling
Selecteer Uitproberen in de rechterbovenhoek van een code- of opdrachtblok. Als u Try It selecteert, wordt de code of opdracht niet automatisch gekopieerd naar Cloud Shell. Schermopname van een voorbeeld van Probeer het nu voor Azure Cloud Shell.
Ga naar https://shell.azure.com, of selecteer de knop Cloud Shell starten om Cloud Shell in uw browser te openen. Knop om Azure Cloud Shell te starten.
Klik op de knop Cloud Shell in het menu in de balk rechtsboven in de Azure-portal. Schermopname van de knop Cloud Shell in Azure Portal

Azure Cloud Shell gebruiken:

  1. Start Cloud Shell.

  2. Selecteer de knop Kopiëren op een codeblok (of opdrachtblok) om de code of opdracht te kopiëren.

  3. Plak de code of opdracht in de Cloud Shell-sessie door Ctrl+Shift+V in Windows en Linux te selecteren of door Cmd+Shift+V te selecteren in macOS.

  4. Selecteer Enter om de code of opdracht uit te voeren.

Vereisten

  • Voltooi de vorige zelfstudie voor meer informatie over het implementeren van GitOps voor uw CI/CD-omgeving.

  • Inzicht in de voordelen en architectuur van deze functie.

  • Controleer of u het volgende hebt:

  • Installeer de nieuwste versies van deze Kubernetes- en Kubernetes Configuration CLI-extensies met Azure Arc:

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

    • Voer de volgende opdrachten uit om deze extensies bij te werken naar de nieuwste versie:

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

Azure Container Registry verbinden met Kubernetes

Schakel uw Kubernetes-cluster in om installatiekopieën op te halen uit uw Azure Container Registry. Als het privé is, is verificatie vereist.

Azure Container Registry verbinden met bestaande AKS-clusters

Integreer een bestaand Azure Container Registry met bestaande AKS-clusters met behulp van de volgende opdracht:

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

Een pull-geheim voor afbeeldingen maken

Als u niet-AKS en lokale clusters wilt verbinden met uw Azure Container Registry, maakt u een pull-geheim voor installatiekopieën. Kubernetes maakt gebruik van pull-geheimen voor installatiekopieën om informatie op te slaan die nodig is om uw register te verifiëren.

Maak een pull-geheim voor een installatiekopie met de volgende kubectl opdracht. Herhaal dit voor zowel de dev stage als de naamruimten.

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 te voorkomen dat u voor elke pod een imagePullSecret moet instellen, kunt u overwegen om de imagePullSecret toe te voegen aan het serviceaccount in de dev en stage naamruimten. Zie de Kubernetes-zelfstudie voor meer informatie.

Afhankelijk van de CI/CD-orchestrator die u wilt gebruiken, kunt u doorgaan met instructies voor Azure DevOps of voor GitHub.

CI/CD implementeren met Azure DevOps

In deze zelfstudie wordt ervan uitgegaan dat u bekend bent met Azure DevOps, Azure-opslagplaatsen en -pijplijnen en Azure CLI.

Zorg ervoor dat u eerst de volgende stappen uitvoert:

Toepassings- en GitOps-opslagplaatsen importeren in Azure-opslagplaatsen

Importeer een toepassingsopslagplaats en een GitOps-opslagplaats in Azure-opslagplaatsen. Gebruik voor deze zelfstudie de volgende voorbeeldopslagplaatsen:

  • arc-cicd-demo-src-toepassingsopslagplaats

  • Arc-cicd-demo-gitops GitOps-opslagplaats

Meer informatie over het importeren van Git-opslagplaatsen.

Notitie

Het importeren en gebruiken van twee afzonderlijke opslagplaatsen voor toepassings- en GitOps-opslagplaatsen kan de beveiliging en eenvoud verbeteren. De machtigingen en zichtbaarheid van de toepassings- en GitOps-opslagplaatsen kunnen afzonderlijk worden afgestemd. De clusterbeheerder kan bijvoorbeeld de wijzigingen in de toepassingscode niet vinden die relevant zijn voor de gewenste status van het cluster. Een toepassingsontwikkelaar hoeft daarentegen niet de specifieke parameters voor elke omgeving te kennen: een set testwaarden die dekking bieden voor de parameters kan voldoende zijn.

Verbinding maken met de GitOps-opslagplaats

Als u uw app continu wilt implementeren, verbindt u de toepassingsopslagplaats met uw cluster met behulp van GitOps. De GitOps-opslagplaats arc-cicd-demo-gitops bevat de basisresources om uw app actief te maken op uw arc-cicd-clustercluster .

De eerste GitOps-opslagplaats bevat alleen een manifest waarmee de dev - en fasenaamruimten worden gemaakt die overeenkomen met de implementatieomgevingen.

De GitOps-verbinding die u maakt, wordt automatisch:

  • Synchroniseer de manifesten in de manifestmap.
  • Werk de clusterstatus bij.

De CI/CD-werkstroom vult de manifestmap met extra manifesten om de app te implementeren.

  1. Maak een nieuwe GitOps-verbinding met uw zojuist geïmporteerde arc-cicd-demo-gitops-opslagplaats in Azure-opslagplaatsen.

    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

    Gebruik voor een AKS-cluster (in plaats van een cluster met Arc).-cluster-type managedClusters

  2. Controleer de status van de implementatie in Azure Portal.

    • Als dit lukt, ziet u zowel dev stage de naamruimten als de naamruimten die in uw cluster zijn gemaakt.
    • U kunt ook bevestigen dat op de azure-portalpagina van uw cluster een configuratie cluster-config wordt gemaakt op het tabblad fGitOps .

De CI/CD-pijplijnen importeren

Nu u een GitOps-verbinding hebt gesynchroniseerd, moet u de CI/CD-pijplijnen importeren waarmee de manifesten worden gemaakt.

De toepassingsopslagplaats bevat een .pipeline map met pijplijnen die worden gebruikt voor PULL's, CI en CD. Importeer en wijzig de naam van de drie pijplijnen in de voorbeeldopslagplaats:

Naam van pijplijnbestand Beschrijving
.pipelines/az-vote-pr-pipeline.yaml De pr-pijplijn van de toepassing, met de naam arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml De CI-pijplijn van de toepassing, met de naam arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml De cd-pijplijn van de toepassing, met de naam arc-cicd-demo-src CD

Azure Container Registry verbinden met Azure DevOps

Tijdens het CI-proces implementeert u uw toepassingscontainers in een register. Begin met het maken van een Azure-serviceverbinding:

  1. Open in Azure DevOps de pagina Serviceverbindingen vanaf de pagina met projectinstellingen. Open in TFS de pagina Services via het instellingenpictogram in de bovenste menubalk.
  2. Kies + Nieuwe serviceverbinding en selecteer het type serviceverbinding dat u nodig hebt.
  3. Vul de parameters voor de serviceverbinding in. Voor deze zelfstudie:
    • Noem de serviceverbinding arc-demo-acr.
    • Selecteer myResourceGroup als de resourcegroep.
  4. Selecteer de machtiging Toegang verlenen aan alle pijplijnen.
    • Met deze optie worden YAML-pijplijnbestanden geautoriseerd voor serviceverbindingen.
  5. Kies OK om de verbinding te maken.

PR-serviceverbinding configureren

Cd-pijplijn bewerkt PULL's in de GitOps-opslagplaats. Hiervoor is een serviceverbinding vereist. Ga als volgt te werk om deze verbinding te configureren:

  1. Open in Azure DevOps de pagina Serviceverbindingen vanaf de pagina met projectinstellingen. Open in TFS de pagina Services via het instellingenpictogram in de bovenste menubalk.
  2. Kies + Nieuwe serviceverbinding en selecteer Generic het type.
  3. Vul de parameters voor de serviceverbinding in. Voor deze zelfstudie:
    • Server-URL https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
    • Laat de gebruikersnaam en het wachtwoord leeg.
    • Geef de serviceverbinding de naam azdo-pr-connection.
  4. Selecteer de machtiging Toegang verlenen aan alle pijplijnen.
    • Met deze optie worden YAML-pijplijnbestanden geautoriseerd voor serviceverbindingen.
  5. Kies OK om de verbinding te maken.

GitOps Connector installeren

  1. GitOps Connector-opslagplaats toevoegen aan Helm-opslagplaatsen:

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

  2. Installeer de connector in het cluster:

       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>

    Notitie

    Azure Repos PAT tokenmoet beschikken over en Code: Full machtigingen hebbenBuild: Read & execute.

  3. Flux configureren voor het verzenden van meldingen naar de GitOps-connector:

    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

Raadpleeg de GitOps Connector-opslagplaats voor meer informatie over de installatie.

Omgevingsvariabelegroepen maken

Variabele groep app-opslagplaats

Maak een variabelegroep met de naam az-vote-app-dev. Stel de volgende waarden in:

Variabele Weergegeven als
AZURE_SUBSCRIPTION (uw Azure-serviceverbinding, die arc-demo-acr moet zijn van eerder in de zelfstudie)
AZ_ACR_NAME Azure ACR-naam, bijvoorbeeld arc-demo-acr
ENVIRONMENT_NAME Dev
MANIFESTS_BRANCH master
MANIFESTS_REPO arc-cicd-demo-gitops
ORGANIZATION_NAME Naam van Azure DevOps-organisatie
PROJECT_NAME Naam van GitOps-project in Azure DevOps
REPO_URL Volledige URL voor GitOps-opslagplaats
SRC_FOLDER azure-vote
TARGET_CLUSTER arc-cicd-cluster
TARGET_NAMESPACE dev
VOTE_APP_TITLE Stemtoepassing
AKS_RESOURCE_GROUP AKS-resourcegroep. Vereist voor geautomatiseerd testen.
AKS_NAME AKS-naam. Vereist voor geautomatiseerd testen.

Omgevingsvariabelegroep fase

  1. Kloon de variabelegroep az-vote-app-dev .
  2. Wijzig de naam in az-vote-app-stage.
  3. Zorg ervoor dat de volgende waarden voor de bijbehorende variabelen zijn:
Variabele Weergegeven als
ENVIRONMENT_NAME Fase
TARGET_NAMESPACE stage

U bent nu klaar om te implementeren in de dev en stage omgevingen.

Omgevingen maken

Maak Dev en Stage omgevingen in uw Azure DevOps-project. Zie Een omgeving maken en instellen voor meer informatie.

Meer machtigingen geven voor de buildservice

De CD-pijplijn gebruikt het beveiligingstoken van de actieve build om te verifiëren bij de GitOps-opslagplaats. Er zijn meer machtigingen nodig voor de pijplijn om een nieuwe vertakking te maken, wijzigingen te pushen en pull-aanvragen te maken.

  1. Ga naar Project settings de hoofdpagina van het Azure DevOps-project.
  2. Selecteer Repos/Repositories.
  3. Selecteer Security.
  4. Voor de <Project Name> Build Service (<Organization Name>) en voor de Project Collection Build Service (<Organization Name>) (typ in het zoekveld, als dit niet wordt weergegeven), staat Contributeu toe , Contribute to pull requestsen Create branch.
  5. Ga naar Pipelines/Settings
  6. Optie uitschakelen Protect access to repositories in YAML pipelines

Zie voor meer informatie:

De ontwikkelomgeving voor de eerste keer implementeren

Wanneer de CI- en CD-pijplijnen zijn gemaakt, voert u de CI-pijplijn uit om de app voor het eerst te implementeren.

CI-pijplijn

Tijdens de eerste CI-pijplijnuitvoering krijgt u mogelijk een resourceautorisatiefout bij het lezen van de naam van de serviceverbinding.

  1. Controleer of de variabele die wordt geopend, is AZURE_SUBSCRIPTION.
  2. Autoriseren van het gebruik.
  3. Voer de pijplijn opnieuw uit.

De CI-pijplijn:

  • Zorgt ervoor dat de wijziging van de toepassing alle geautomatiseerde kwaliteitscontroles voor implementatie doorstaat.
  • Voert een extra validatie uit die niet kan worden voltooid in de pull-aanvraagpijplijn.
    • Specifiek voor GitOps publiceert de pijplijn ook de artefacten voor de doorvoer die door de CD-pijplijn wordt geïmplementeerd.
  • Controleert of de Docker-installatiekopieën zijn gewijzigd en de nieuwe installatiekopieën worden gepusht.

CD-pijplijn

Tijdens de eerste cd-pijplijnuitvoering moet u de pijplijn toegang geven tot de GitOps-opslagplaats. Selecteer Weergeven wanneer u wordt gevraagd of de pijplijn toestemming nodig heeft voor toegang tot een resource. Selecteer vervolgens Toestaan om toestemming te verlenen voor het gebruik van de GitOps-opslagplaats voor de huidige en toekomstige uitvoeringen van de pijplijn.

De geslaagde CI-pijplijnuitvoering activeert de CD-pijplijn om het implementatieproces te voltooien. U implementeert stapsgewijs in elke omgeving.

Tip

Als de CD-pijplijn niet automatisch wordt geactiveerd:

  1. Controleer of de naam overeenkomt met de vertakkingtrigger in .pipelines/az-vote-cd-pipeline.yaml
    • Dit moet arc-cicd-demo-src CI zijn.
  2. Voer de CI-pijplijn opnieuw uit.

Zodra de sjabloon en het manifest zijn gewijzigd in de GitOps-opslagplaats, maakt de CD-pijplijn een doorvoer, pusht deze en wordt er een pull-aanvraag voor goedkeuring gemaakt.

  1. Zoek de pull-aanvraag die door de pijplijn is gemaakt naar de GitOps-opslagplaats.

  2. Controleer de wijzigingen in de GitOps-opslagplaats. U ziet het volgende:

    • Wijzigingen in Helm-sjablonen op hoog niveau.
    • Kubernetes-manifesten op laag niveau die de onderliggende wijzigingen in de gewenste status weergeven. Flux implementeert deze manifesten.

  3. Als alles er goed uitziet, keurt u de pull-aanvraag goed en voltooit u deze.

  4. Na een paar minuten wordt de wijziging door Flux opgehaald en de implementatie gestart.

  5. Controleer de Git Commit-status op het tabblad Doorvoergeschiedenis. Zodra dit het is succeeded, start de CD-pijplijn met geautomatiseerd testen.

  6. Stuur de poort lokaal door met behulp van kubectl en zorg ervoor dat de app correct werkt met:

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

  7. Bekijk de Azure Vote-app in uw browser op http://localhost:8080/.

  8. Stem op uw favorieten en bereid u voor om enkele wijzigingen aan te brengen in de app.

Omgevingsgoedkeuringen instellen

Bij de implementatie van de app kunt u niet alleen wijzigingen aanbrengen in de code of sjablonen, maar u kunt het cluster ook onbedoeld in een slechte status plaatsen.

Als de ontwikkelomgeving na de implementatie een onderbreking laat zien, moet u ervoor zorgen dat deze niet naar latere omgevingen gaat met behulp van omgevingsgoedkeuringen.

  1. Ga in uw Azure DevOps-project naar de omgeving die moet worden beveiligd.
  2. Navigeer naar Goedkeuringen en Controles voor de resource.
  3. Selecteer Maken.
  4. Geef de goedkeurders en een optioneel bericht op.
  5. Selecteer Opnieuw maken om de toevoeging van de handmatige goedkeuringscontrole te voltooien.

Zie de zelfstudie Goedkeuring en controles definiëren voor meer informatie.

De volgende keer dat de CD-pijplijn wordt uitgevoerd, wordt de pijplijn onderbroken nadat de GitOps-pull-aanvraag is gemaakt. Controleer of de wijziging correct is gesynchroniseerd en of de basisfunctionaliteit is doorgegeven. Keur de controle van de pijplijn goed om de wijziging naar de volgende omgeving te laten stromen.

Een toepassingswijziging aanbrengen

Met deze basislijnset met sjablonen en manifesten die de status in het cluster vertegenwoordigen, gaat u een kleine wijziging aanbrengen in de app.

  1. Bewerk azure-vote/src/azure-vote-front/config_file.cfg het bestand in de arc-cicd-demo-src-opslagplaats.

  2. Aangezien "Cats vs Dogs" niet genoeg stemmen krijgt, wijzigt u deze in Tabs vs Spaces om het aantal stemmen te verhogen.

  3. Voer de wijziging door in een nieuwe vertakking, push deze en maak een pull-aanvraag. Deze reeks stappen is de typische ontwikkelaarsstroom waarmee de CI/CD-levenscyclus wordt gestart.

PR-validatiepijplijn

De PULL-pijplijn is de eerste verdedigingslinie tegen een foutieve wijziging. Gebruikelijke kwaliteitscontroles voor toepassingscode omvatten linting en statische analyse. Vanuit gitOps-perspectief moet u ook dezelfde kwaliteit garanderen voor de resulterende infrastructuur die moet worden geïmplementeerd.

De Dockerfile- en Helm-grafieken van de toepassing kunnen linting op een vergelijkbare manier gebruiken als de toepassing.

Fouten die zijn aangetroffen tijdens linting variëren van onjuist opgemaakte YAML-bestanden tot suggesties voor aanbevolen procedures, zoals het instellen van CPU- en geheugenlimieten voor uw toepassing.

Notitie

Als u de beste dekking wilt krijgen van Helm linting in een echte toepassing, moet u waarden vervangen die redelijk vergelijkbaar zijn met die in een echte omgeving.

Fouten die zijn gevonden tijdens de uitvoering van de pijplijn, worden weergegeven in de sectie met testresultaten van de uitvoering. Van hieruit kunt u het volgende doen:

  • Houd de nuttige statistieken bij voor de fouttypen.
  • Zoek de eerste doorvoering waarop ze zijn gedetecteerd.
  • Stacktraceringsstijlkoppelingen naar de codesecties die de fout hebben veroorzaakt.

Zodra de pijplijnuitvoering is voltooid, hebt u de kwaliteit van de toepassingscode en de sjabloon die deze implementeert verzekerd. U kunt nu de pull-aanvraag goedkeuren en voltooien. De CI wordt opnieuw uitgevoerd, waarbij de sjablonen en manifesten opnieuw worden geactiveerd voordat de CD-pijplijn wordt geactiveerd.

Tip

Vergeet in een echte omgeving geen vertakkingsbeleid in te stellen om ervoor te zorgen dat de pull-aanvraag uw kwaliteitscontroles doorstaat. Zie Vertakkingsbeleid instellen voor meer informatie.

Cd-procesgoedkeuringen

Een geslaagde CI-pijplijnuitvoering activeert de CD-pijplijn om het implementatieproces te voltooien. Deze keer moet u voor de pijplijn elke implementatieomgeving goedkeuren.

  1. Keur de implementatie goed voor de dev omgeving.
  2. Zodra de sjabloon en het manifest zijn gewijzigd in de GitOps-opslagplaats, maakt de CD-pijplijn een doorvoer, pusht deze en wordt er een pull-aanvraag voor goedkeuring gemaakt.
  3. Controleer de wijzigingen in de GitOps-opslagplaats. U ziet het volgende:
    • Wijzigingen in Helm-sjablonen op hoog niveau.
    • Kubernetes-manifesten op laag niveau die de onderliggende wijzigingen in de gewenste status weergeven.
  4. Als alles er goed uitziet, keurt u de pull-aanvraag goed en voltooit u deze.
  5. Wacht totdat de installatie is voltooid.
  6. Als eenvoudige betrouwbaarheidstest gaat u naar de toepassingspagina en controleert u of de stem-app nu Tabs versus Spaces weergeeft.
    • Stuur de poort lokaal door met behulp van kubectl en zorg ervoor dat de app correct werkt met: kubectl port-forward -n dev svc/azure-vote-front 8080:80
    • Bekijk de Azure Vote-app in uw browser op http://localhost:8080/ en controleer of de stemopties zijn gewijzigd in Tabs versus Spaces.
  7. Herhaal stap 1-7 voor de stage omgeving.

De implementatie is nu voltooid.

Zie het Azure DevOps GitOps-stroomdiagram voor een gedetailleerd overzicht van alle stappen en technieken die zijn geïmplementeerd in de CI/CD-werkstromen die in deze zelfstudie worden gebruikt.

CI/CD implementeren met GitHub

In deze zelfstudie wordt ervan uitgegaan dat u bekend bent met GitHub, GitHub Actions.

Fork-toepassing en GitOps-opslagplaatsen

Een toepassingsopslagplaats en een GitOps-opslagplaats splitsen. Gebruik voor deze zelfstudie de volgende voorbeeldopslagplaatsen:

Verbinding maken met de GitOps-opslagplaats

Als u uw app continu wilt implementeren, verbindt u de toepassingsopslagplaats met uw cluster met behulp van GitOps. De GitOps-opslagplaats arc-cicd-demo-gitops bevat de basisresources om uw app actief te maken op uw arc-cicd-clustercluster .

De eerste GitOps-opslagplaats bevat alleen een manifest waarmee de dev - en fasenaamruimten worden gemaakt die overeenkomen met de implementatieomgevingen.

De GitOps-verbinding die u maakt, wordt automatisch:

  • Synchroniseer de manifesten in de manifestmap.
  • Werk de clusterstatus bij.

De CI/CD-werkstroom vult de manifestmap met extra manifesten om de app te implementeren.

  1. Maak een nieuwe GitOps-verbinding met uw zojuist gesplitste arc-cicd-demo-gitops-opslagplaats in 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. Controleer de status van de implementatie in Azure Portal.

    • Als dit lukt, ziet u zowel dev stage de naamruimten als de naamruimten die in uw cluster zijn gemaakt.

GitOps Connector installeren

  1. GitOps Connector-opslagplaats toevoegen aan Helm-opslagplaatsen:

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

  2. Installeer de connector in het cluster:

       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. Flux configureren voor het verzenden van meldingen naar de GitOps-connector:

    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

Raadpleeg de GitOps Connector-opslagplaats voor meer informatie over de installatie.

GitHub-geheimen maken

Geheimen voor GitHub-opslagplaats maken

Geheim Weergegeven als
AZURE_CREDENTIALS Referenties voor Azure in de volgende indeling {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","tenantId":"GUID"}
AZ_ACR_NAME Azure ACR-naam, bijvoorbeeld 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 Stemtoepassing
AKS_RESOURCE_GROUP AKS-resourcegroep. Vereist voor geautomatiseerd testen.
AKS_NAME AKS-naam. Vereist voor geautomatiseerd testen.
TIKKEN GitHub PAT-token met de machtiging voor pull-aanvraag voor de GitOps-opslagplaats

GitHub-omgevingsgeheimen maken

  1. Maak az-vote-app-dev een omgeving met de volgende geheimen:
Geheim Weergegeven als
ENVIRONMENT_NAME Dev
TARGET_NAMESPACE dev
  1. Maak az-vote-app-stage een omgeving met de volgende geheimen:
Geheim Weergegeven als
ENVIRONMENT_NAME Fase
TARGET_NAMESPACE stage

U bent nu klaar om te implementeren in de dev en stage omgevingen.

CI/CD Dev-werkstroom

Als u de CI/CD Dev-werkstroom wilt starten, wijzigt u de broncode. Werk in de toepassingsopslagplaats waarden in .azure-vote/src/azure-vote-front/config_file.cfg het bestand bij en push de wijzigingen naar de opslagplaats.

De CI/CD Dev-werkstroom:

  • Zorgt ervoor dat de wijziging van de toepassing alle geautomatiseerde kwaliteitscontroles voor implementatie doorstaat.
  • Voert een extra validatie uit die niet kan worden voltooid in de pull-aanvraagpijplijn.
  • Controleert of de Docker-installatiekopieën zijn gewijzigd en de nieuwe installatiekopieën worden gepusht.
  • Hiermee publiceert u de artefacten (Docker-installatiekopieën, manifestsjablonen, Utils) die door de volgende CD-fasen worden gebruikt.
  • Hiermee wordt de toepassing geïmplementeerd in de ontwikkelomgeving.
    • Genereert manifesten naar de GitOps-opslagplaats.
    • Hiermee maakt u een pull-aanvraag voor de GitOps-opslagplaats voor goedkeuring.

  1. Zoek de pull-aanvraag die door de pijplijn is gemaakt naar de GitOps-opslagplaats.

  2. Controleer de wijzigingen in de GitOps-opslagplaats. U ziet het volgende:

    • Wijzigingen in Helm-sjablonen op hoog niveau.
    • Kubernetes-manifesten op laag niveau die de onderliggende wijzigingen in de gewenste status weergeven. Flux implementeert deze manifesten.

  3. Als alles er goed uitziet, keurt u de pull-aanvraag goed en voltooit u deze.

  4. Na een paar minuten wordt de wijziging door Flux opgehaald en de implementatie gestart.

  5. Controleer de Git Commit-status op het tabblad Doorvoergeschiedenis. Zodra dit is succeeded, wordt de CD Stage werkstroom gestart.

  6. Stuur de poort lokaal door met behulp van kubectl en zorg ervoor dat de app correct werkt met:

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

  7. Bekijk de Azure Vote-app in uw browser op http://localhost:8080/.

  8. Stem op uw favorieten en bereid u voor om enkele wijzigingen aan te brengen in de app.

Werkstroom cd-fase

De cd-fasewerkstroom wordt automatisch gestart zodra Flux de toepassing in de ontwikkelomgeving heeft geïmplementeerd en GitHub-acties via GitOps Connector op de hoogte stelt.

De werkstroom cd-fase:

  • Voert betrouwbaarheidstests van toepassingen uit op dev-omgeving
  • Hiermee wordt de toepassing geïmplementeerd in de faseomgeving.
    • Genereert manifesten naar de GitOps-opslagplaats
    • Hiermee maakt u een pull-aanvraag voor de GitOps-opslagplaats voor goedkeuring

Zodra de manifestgegevens voor de faseomgeving zijn samengevoegd en Flux alle wijzigingen heeft toegepast, wordt de Git-doorvoerstatus bijgewerkt in de GitOps-opslagplaats. De implementatie is nu voltooid.

Zie het GitHub GitOps-stroomdiagram voor een gedetailleerd overzicht van alle stappen en technieken die zijn geïmplementeerd in de CI/CD-werkstromen die in deze zelfstudie worden gebruikt.

Resources opschonen

Als u deze toepassing niet wilt blijven gebruiken, verwijdert u resources met de volgende stappen:

  1. Verwijder de Azure Arc GitOps-configuratieverbinding:

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

  2. GitOps-connector verwijderen:

    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

Volgende stappen

In deze zelfstudie hebt u een volledige CI/CD-werkstroom ingesteld waarmee DevOps wordt geïmplementeerd vanuit de ontwikkeling van toepassingen via implementatie. Wijzigingen in de app activeren automatisch validatie en implementatie, die worden gated door handmatige goedkeuringen.

Ga naar ons conceptuele artikel voor meer informatie over GitOps en configuraties met Kubernetes met Azure Arc.

Concept: CD-proces met GitOpsSample-implementatie: CI/CD-stroom verkennen met GitOps