Oefening: een oplossing met meerdere containers implementeren in een Kubernetes-cluster

15 minuten

De release-pijplijn die bij uw project wordt geleverd, is ontworpen om de oplossing te bouwen als een Docker-container en deze te implementeren in Azure App Service. Als u de implementatie van meerdere containers naar een Kubernetes-cluster wilt ondersteunen, moet u deze pijplijn wijzigen.

In deze les leert u het volgende:

Stel de pijplijn in om te activeren bij een commit naar de hoofdbranch.
Definieer variabelen die in de pijplijn moeten worden gedeeld.
Docker-images bouwen en publiceren.
Kubernetes-manifesten publiceren.
Voeg een taak toe om een image pull secret te maken voor gebruik tussen uw Kubernetes- en containerregister-instanties.
Geüpdatete images implementeren in een Kubernetes-cluster.

De pijplijn bijwerken om triggers te ondersteunen

Meld u aan bij uw Azure DevOps-organisatie en navigeer vervolgens naar uw project.
Selecteer Pijplijnen en selecteer vervolgens uw pijplijn.
Selecteer Bewerken om uw azure-pipelines.yml te bewerken.

Andy: Dit was de buildfase die we hadden voor de vorige oplossing met één container. Ik wist dat het niet goed zou lopen, dus ik heb het uitgeschakeld. We kunnen beginnen met het opnieuw inschakelen van triggers voor commits naar de main vertakking.
Vervang de bestaande trigger regel boven aan het bestand door het volgende codefragment. Dit triggert een pipeline-operatie telkens wanneer een commit wordt gemaakt naar de hoofdtak.
```
trigger:
- 'main'
```

Variabelen definiëren die toegankelijk zijn voor meerdere pijplijnen

Andy: We moeten twee pijplijnvariabelen toevoegen. Een voor het opgeven van de naam van de leaderboard-opslagplaats, die leaderboard is. De andere is voor de naam van de image pull secret die wordt gebruikt voor het delen tussen AKS- en ACR-instances tijdens de implementatie.

Voeg de volgende gemarkeerde code toe aan de sectie variables.

variables:
  buildConfiguration: 'Release'
  leaderboardRepository: 'leaderboard'
  webRepository: 'web'
  tag: '$(Build.BuildId)'
  imagePullSecret: 'secret'

Docker-afbeelding bouwen en publiceren in Azure Container Registry

Andy: We hebben al een taak voor het bouwen van de web-app als een Docker-container, die we publiceren naar ons containerregister. We kunnen gewoon een tweede taak gebruiken om hetzelfde te doen voor ons leaderboard.

Voeg een tweede Docker@2 taak toe om de leaderboardcontainer te bouwen en te publiceren met behulp van het volgende gemarkeerde fragment. Voeg deze taak toe direct na de webcontainertaak.

- task: Docker@2
  displayName: 'Build and push the web image to container registry'
  inputs:
    command: buildAndPush
    buildContext: $(Build.Repository.LocalPath)
    repository: $(webRepository)
    dockerfile: '$(Build.SourcesDirectory)/Tailspin.SpaceGame.Web/Dockerfile'
    containerRegistry: 'Container Registry Connection'
    tags: |
      $(tag)

- task: Docker@2
  displayName: 'Build and push the leaderboard image to container registry'
  inputs:
    command: buildAndPush
    buildContext: $(Build.Repository.LocalPath)
    repository: $(leaderboardRepository)
    dockerfile: '$(Build.SourcesDirectory)/Tailspin.SpaceGame.LeaderboardContainer/Dockerfile'
    containerRegistry: 'Container Registry Connection'
    tags: |
      $(tag)

Aanbeveling

Zorg ervoor dat de taak die u hier toevoegt dezelfde inspringing gebruikt als de vorige taak, omdat spaties belangrijk zijn in een YAML-bestand.

De Kubernetes-manifesten publiceren

Andy: Ik denk dat we verder kunnen gaan met de volgende fase. Zie je iets ontbreekt?

Mara: U hebt gezegd dat er enkele manifestbestanden in het bronproject waren die de implementatie definiëren en services die Kubernetes nodig heeft bij de implementatie. We moeten deze publiceren voordat we deze fase voltooien.

Andy: Moeten we dat doen? Zijn ze niet nog steeds op de lokale schijf?

Mara: Ze zouden zijn als we de implementatietaken in dezelfde fase als de build zouden toevoegen. Omdat onze implementatietaken echter plaatsvinden in hun eigen implementatiefase , wordt deze uitgevoerd in een nieuwe omgeving, waarschijnlijk zelfs op een andere agent. We moeten alles publiceren wat deze fase produceert dat de andere fase nodig heeft.

Andy: Dat is een goed punt. Is het eenvoudig te doen? We moeten ervoor zorgen dat de map manifesten naar de nieuwe agent wordt gekopieerd.

Mara: Dat is waar de PublishBuildArtifacts@1 taak voor is. Het is zo gebruikelijk dat er zelfs een afkorting voor is, publish.

Voeg een publish taak toe waarmee de map manifesten voor een toekomstige fase wordt opgeslagen, zoals wordt weergegeven in het volgende codefragment. Zorg ervoor dat de inspringing van deze taak overeenkomt met die van de vorige taak.

- task: Docker@2
  displayName: 'Build and push the leaderboard image to container registry'
  inputs:
    command: buildAndPush
    buildContext: $(Build.Repository.LocalPath)
    repository: $(leaderboardRepository)
    dockerfile: '$(Build.SourcesDirectory)/Tailspin.SpaceGame.LeaderboardContainer/Dockerfile'
    containerRegistry: 'Container Registry Connection'
    tags: |
      $(tag)

- publish: '$(Build.SourcesDirectory)/manifests'
  artifact: manifests

De implementatiefase vervangen

Mara: Ik ga onze bestaande Deploy-fase vervangen door een fase die een deploy-opdracht gebruikt. Een implementatietaak is een speciaal soort taak waarmee we onze implementatie kunnen koppelen aan de Azure DevOps-omgeving die eerder is gemaakt. Dit maakt het eenvoudiger om de implementatiegeschiedenis bij te houden, wat vooral nuttig is omdat onze oplossingen geavanceerder worden.

Verwijder de bestaande implementatiefase (alles na de buildfase) en vervang deze door het volgende fragment. Noteer de gemarkeerde regel die aangeeft dat de implementatieomgeving moet worden gebruikt.
```
- stage: 'Deploy'
  displayName: 'Deploy the containers'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    displayName: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: 'Dev'
    variables:
    - group: Release
    strategy:
      runOnce:
        deploy:
          steps:
```
Mara: De eerste stap die we in de implementatiefase opnemen, is het downloaden van de manifest-artefacten die eerder zijn gepubliceerd met behulp van de taak DownloadBuildArtifacts@0.

Andy: Mag ik raden, is er een download afkorting voor die taak?

Mara: Precies juist! We kunnen de specificatie current gebruiken om aan te geven dat we het artefact willen van de huidige uitvoering van de pijplijn.

Voeg de gemarkeerde regels toe als de eerste stap van de implementatiefase .

- stage: 'Deploy'
  displayName: 'Deploy the containers'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    displayName: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: 'spike.default'
    variables:
    - group: Release
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: manifests

Andy: Nu moeten we een image pull secret maken dat wordt gedeeld tussen onze ACR- en AKS-instanties. Weet u of er een taak is die we kunnen gebruiken?

Mara: Ik was het net aan het opzoeken, en we hebben geluk. De KubernetesManifest@0-taak ondersteunt een actie om het benodigde geheim te maken.

Kubernetes-manifesttaak

De Kubernetes-manifesttaak is ontworpen voor het beheren van alle basisimplementatiebewerkingen die vereist zijn voor Kubernetes. Het ondersteunt meerdere action opties, variërend van het creëren van geheimen tot het implementeren van afbeeldingen. In dit geval wordt de actie createSecret gebruikt, samen met de volgende parameters:

action geeft aan dat de functie moet worden uitgevoerd. In dit geval maakt createSecret het gedeelde geheim.
connectionType geeft het type serviceverbinding op dat moet worden gebruikt. Opties: azureResourceManager of kubernetesServiceConnection.
secretName geeft de naam op van het geheim dat moet worden gemaakt.
dockerRegistryEndpoint geeft de naam van de Azure Container Registry Services-verbinding op.
azureSubscriptionConnection geeft de naam van de ARM Services-verbinding op.
azureResourceGroup geeft de naam van uw resourcegroep op.
kubernetesCluster geeft de naam van uw AKS-cluster op.
namespace geeft de Kubernetes-naamruimte op waarop deze actie van toepassing is.

Voeg het volgende codefragment toe aan het einde van de pijplijn. Zorg ervoor dat zowel de naam van de resourcegroep als de clusternaam overeenkomen met de namen die u eerder hebt gemaakt. Zorg ervoor dat de inspringing van deze taak overeenkomt met die van de downloadtaak .
```
- task: KubernetesManifest@1
  displayName: Create imagePullSecret
  inputs:
    action: createSecret
    connectionType: azureResourceManager
    secretName: $(imagePullSecret)
    dockerRegistryEndpoint: 'Container Registry Connection'
    azureSubscriptionConnection: 'Kubernetes Cluster Connection'
    azureResourceGroup: 'tailspin-space-game-rg'
    kubernetesCluster: 'tailspinspacegame-24591'
    namespace: 'default'
```
Andy: De laatste stap is het starten van de deployment van onze afbeeldingen in het Kubernetes-cluster. Op basis van de documentatie lijkt het erop dat we dezelfde taak kunnen gebruiken, maar met een andere actie en parameters.
- action geeft aan dat de functie moet worden uitgevoerd. In dit geval deploy om te implementeren in een AKS-cluster.
- connectionType geeft het type serviceverbinding op dat moet worden gebruikt. Opties: azureResourceManager of kubernetesServiceConnection.
- azureSubscriptionConnection geeft de naam van de ARM Services-verbinding op.
- azureResourceGroup geeft de naam van uw resourcegroep op.
- kubernetesCluster geeft de naam van uw AKS-cluster op.
- namespace geeft de Kubernetes-naamruimte op waarop deze actie van toepassing is.
- imagePullSecrets geeft de lijst met geheimen op die nodig zijn om uit het containerregister te halen.
- containers specificeert de lijst van containerafbeeldingen die moeten worden uitgevoerd.

Voeg het volgende codefragment toe aan het einde van de pijplijn. Zorg ervoor dat zowel de naam van de resourcegroep als de clusternaam overeenkomen met de namen die u eerder hebt gemaakt. Zorg ervoor dat de inspringing van deze taak overeenkomt met die van de vorige taak.

- task: KubernetesManifest@1
  displayName: Deploy to Kubernetes cluster
  inputs:
    action: deploy
    connectionType: azureResourceManager
    azureSubscriptionConnection: 'Kubernetes Cluster Connection'
    azureResourceGroup: 'tailspin-space-game-rg'
    kubernetesCluster: 'tailspinspacegame-24591'
    namespace: 'default'
    manifests: |
      $(Pipeline.Workspace)/manifests/deployment.yml
      $(Pipeline.Workspace)/manifests/service.yml
    imagePullSecrets: |
      $(imagePullSecret)
    containers: |
      $(RegistryName)/$(webRepository):$(tag)
      $(RegistryName)/$(leaderboardRepository):$(tag)

Voer uw pijplijn uit

Selecteer opslaan in de rechterbovenhoek van de pagina. Selecteer Opslaan om uw doorvoerbericht te bevestigen.
Select Uitvoeren, bevestig de naam van uw branch en selecteer vervolgens Uitvoeren om een pijplijndraai te starten.
Selecteer Pijplijnen en selecteer vervolgens uw pijplijn om de logbestanden weer te geven terwijl uw pijplijn wordt uitgevoerd.
Nadat de pijplijnuitvoering is voltooid, selecteert u Omgevingen in het linkerdeelvenster en selecteert u vervolgens de Ontwikkelomgeving om uw implementatietaken weer te geven.
Nu gaan we onze geïmplementeerde web-app en API-eindpunt bekijken. Hiervoor moeten we de externe IP-adressen voor zowel de web - als leaderboard-services ophalen.
Navigeer naar Azure Portal, selecteer uw AKS-cluster en selecteer vervolgens Services en ingresses.
Selecteer het externe IP-adres voor uw webservice om uw site op AKS weer te geven.
Ga terug naar uw Azure Portal-venster waar u was gebleven en kopieer vervolgens het externe IP-adres voor uw leaderboardservice . Dit IP-adres is waar de leaderboard-API openbaar wordt gehost.
Vervang de tijdelijke aanduiding in de volgende koppeling door het externe IP-adres dat u hebt gekopieerd. U kunt ook een pageSize=10 queryparameter toevoegen om het JSON-antwoord gemakkelijker weer te geven in uw browser. Gebruik een URL zoals de volgende op een nieuw browsertabblad.
```
http://[IP]/api/Leaderboard?pageSize=10
```
U kunt het onbewerkte JSON-antwoord bekijken vanuit de leaderboard-API die wordt gehost in uw AKS-cluster. U hebt nu een REST API die u kunt aanroepen vanuit andere toepassingen.

Andy: Dit bleek geweldig! Ik denk dat het gebruik van Kubernetes een uitstekende manier zou zijn om een bredere microservicesstrategie aan te nemen.

Feedback

Is deze pagina nuttig?