Bereitstellen in Kubernetes

Azure DevOps Services

Azure Pipelines kann für die Bereitstellung in Kubernetes-Clustern verwendet werden, die von mehreren Cloudanbietern angeboten werden. Dieses Dokument enthält die Konzepte zum Einrichten von Bereitstellungen für jeden Kubernetes-Cluster.

Es ist zwar möglich, ein Skript zum Laden von Kubeconfig-Dateien von einem Remotespeicherort oder sicheren Dateien auf den Agent zu verwenden und dann kubectl zum Ausführen der Bereitstellungen zu verwenden. Die KubernetesManifest-Aufgabe und die Kubernetes-Dienstverbindung werden jedoch empfohlen.

KubernetesManifest-Aufgabe

Die KubernetesManifest-Aufgabe hat die zusätzlichen Vorteile der Möglichkeit, die Objektstabilität zu überprüfen, bevor eine Aufgabe als Erfolgreich/Fehler markiert wird. Der Task kann auch Artefaktersetzungen durchführen, Anmerkungen zur Pipeline-Nachverfolgbarkeit zu bereitgestellten Objekten hinzufügen, die Erstellung und verweise auf imagePullSecrets vereinfachen, Manifeste mit Helm oder kustomization.yaml oder Docker Compose-Dateien baken und bei Rollouts der Bereitstellungsstrategie unterstützen.

Kubernetes-Ressource in Umgebungen

Die Kubernetes-Ressourcein Umgebungen bietet eine sichere Möglichkeit, die Anmeldeinformationen anzugeben, die zum Herstellen einer Verbindung mit einem Kubernetes-Cluster zum Ausführen von Bereitstellungen erforderlich sind.

Ressourcenerstellung

Bei der Azure Kubernetes Service-Anbieteroption werden nach dem Angeben des Abonnements, des Clusters und der Namespaceeingaben zusätzlich zum Abrufen und sicheren Speichern der erforderlichen Anmeldeinformationen für einen RBAC-fähigen Cluster ServiceAccount- und RoleBinding-Objekte erstellt, damit ServiceAccount nur Aktionen für den ausgewählten Namespace ausführen kann.

Mit der Option Generischer Anbieter (vorhandenes ServiceAccount wiederverwendbar) kann eine Verbindung mit dem Cluster eines beliebigen Cloudanbieters (AKS/EKS/GKE/OpenShift usw.) konfiguriert werden.

Beispiel

jobs:
- deployment:
  displayName: Deploy to AKS
  pool:
    vmImage: ubuntu-latest
  environment: contoso.aksnamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Create secret
          inputs: 
            action: createSecret
            namespace: aksnamespace
            secretType: dockerRegistry
            secretName: foo-acr-secret
            dockerRegistryEndpoint: fooACR
            
        - task: KubernetesManifest@0
          displayName: Create secret
          inputs: 
            action: createSecret
            namespace: aksnamespace
            secretType: dockerRegistry
            secretName: bar-acr-secret
            dockerRegistryEndpoint: barACR
            
        - task: KubernetesManifest@0
          displayName: Deploy
          inputs:
            action: deploy
            namespace: aksnamespace
            manifests: manifests/deployment.yml|manifests/service.yml
            containers: |
              foo.azurecr.io/demo:$(tagVariable1)
              bar.azurecr.io/demo:$(tagVariable2)
            imagePullSecrets: |
              foo-acr-secret
              bar-acr-secret

Um Imagepull aus privaten Registrierungen zu ermöglichen, deploycreateSecret wird vor der Aktion die Aktion zusammen mit Instanzen der Docker-Registrierungsdienstverbindung verwendet, um imagePullSecrets zu erstellen, auf die später in deploy dem Schritt verwiesen wird, der der Aktion entspricht.

Tipp

• Wenn Sie eine End-to-End-CI-CD-Pipeline von Grund auf für ein Repository einrichten, das eine Dockerfile enthält, sehen Sie sich die Vorlage Deploy to Azure Kubernetes (In Azure Kubernetes bereitstellen) an, die eine End-to-End-YAML-Pipeline zusammen mit der Erstellung einer Umgebung und einer Kubernetes-Ressource erstellt, um diese Bereitstellungen zu visualisieren.
• Die YAML-basierte Pipeline unterstützt derzeit Trigger für ein einzelnes Git-Repository, aber wenn Trigger für Manifestdateien erforderlich sind, die in einem anderen Git-Repository gespeichert sind, oder wenn Trigger für Azure Container Registry oder Docker Hub erforderlich sind, wird die Verwendung von Releasepipelines anstelle einer YAML-basierten Pipeline für die Kubernetes-Bereitstellungen empfohlen.

Alternativen

Anstatt die KubernetesManifest-Aufgabe für die Bereitstellung zu verwenden, können Sie auch die folgenden Alternativen verwenden:

• Kubectl-Aufgabe
• kubectl-Aufruf für Skript. Beispiel: script: kubectl apply -f manifest.yml