Anwendungen mit Application Delivery verwalten


In dieser Anleitung wird schrittweise gezeigt, wie Sie ein Deployment von NGINX mit Application Delivery konfigurieren. Das Deployment wird in zwei Umgebungen ausgeführt: staging und prod. Die prod-Umgebung verwendet eine reguläre Konfiguration, während für staging eine geringfügig modifizierte Konfiguration genutzt wird.

Anforderungen

Für diese Anleitung ist Folgendes erforderlich:

  • Git 2.19.2 oder höher lokal installiert
  • Ein GitHub- oder GitLab-Konto mit Berechtigungen zum Erstellen eines privaten Repositorys ist vorhanden. Application Delivery unterstützt nur GitHub- und GitLab-Repositories.
  • Ein Cluster mit GKE-Version 1.15 oder höher.
  • Ein Nutzer mit clusterAdmin-Berechtigungen ist vorhanden.
  • Kustomize ist lokal installiert. Sie können der Installationsanleitung folgen.
  • Wenn Sie Ihre Kubernetes-Konfigurationsdateien im Deployment-Repository validieren möchten, müssen Sie Docker installieren.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API:
  • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud-Befehlszeile für diese Aufgabe verwenden möchten, müssen Sie die Google Cloud CLI installieren und dann initialisieren.
  • Fügen Sie Ihrem GitHub- oder GitLab-Konto SSH-Schlüssel hinzu.
  • Testen Sie Ihre Schlüssel mit ssh:

    GitHub

    sh ssh -T git@github.com

    GitLab

    sh ssh -T git@gitlab.com

    Eventuell werden Sie aufgefordert, die Verbindungsdetails oder Ihre Schlüssel-Passphrase zu bestätigen. Wenn die Verbindung hergestellt ist, wird eine Nachricht zum Terminal gesendet.

Application Delivery einrichten

So verwenden Sie Application Delivery:

  1. Erstellen Sie einen neuen Cluster mit aktivierter Application Delivery oder aktivieren Sie ihn in einem vorhandenen GKE-Cluster ab Version 1.15.
  2. Installieren Sie das Application Delivery-Befehlszeilentool appctl.

Neuen Cluster mit Application Delivery erstellen

Sie können einen neuen Cluster mit aktiviertem Application Delivery mit der gcloud CLI oder der Console erstellen.

gcloud

Erstellen Sie einen Cluster.

gcloud beta container clusters create CLUSTER_NAME \
      --cluster-version CLUSTER_VERSION\
      --addons ApplicationManager

Dabei gilt:

  • CLUSTER_NAME: Der Name des neuen Clusters.
  • CLUSTER_VERSION ist die Version Ihres neuen Clusters. Es muss mindestens GKE 1.15 sein.

Console

  1. Öffnen Sie in der Console die Seite Google Kubernetes Engine:

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie auf Erstellen.

  3. Klicken Sie unter Standard auf Konfigurieren.

  4. Geben Sie einen Namen für Ihren Cluster ein.

  5. Wählen Sie eine Steuerungsebenenversion von 1.15.x oder höher aus.

  6. Konfigurieren Sie den Cluster wie gewünscht.

  7. Klicken Sie im Navigationsbereich unter Cluster auf Features.

  8. Klicken Sie das Kästchen Anwendungsmanager aktivieren an.

  9. Klicken Sie auf Erstellen.

Application Delivery für einen vorhandenen Cluster aktivieren

Sie können Application Delivery für einen vorhandenen Cluster mit der gcloud CLI oder der Console aktivieren.

gcloud

Führen Sie den folgenden Befehl aus, um Application Delivery für einen vorhandenen Cluster zu aktivieren:

gcloud beta container clusters update CLUSTER_NAME \
      --update-addons ApplicationManager=ENABLED

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres vorhandenen Clusters.

Console

  1. Öffnen Sie in der Console die Seite Google Kubernetes Engine.

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

  3. Klicken Sie unter Features neben dem Feld Anwendungsmanager auf Anwendungsmanager bearbeiten.

  4. Klicken Sie auf das Kästchen Anwendungsmanager aktivieren.

  5. Klicken Sie auf Änderungen speichern.

Installation prüfen

Führen Sie folgende Schritte aus, um den Status Ihrer Application Delivery-Installation zu prüfen:

  1. Prüfen Sie den Bereitstellungsstatus:

    kubectl get deployment application-controller-manager -n application-system
    

    Die Ausgabe sieht etwa so aus:

    NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
    application-controller-manager   2/2     2            2           1h
    

    In dieser application-controller-manager-Bereitstellung sollten zwei Pods verfügbar sein.

  2. Prüfen Sie den StatefulSet-Status:

    kubectl get statefulset kalm-controller-manager -n kalm-system
    

    Die Ausgabe sieht etwa so aus:

    NAME                      READY   AGE
    kalm-controller-manager   1/1     1h
    

    In diesem kalm-controller-manager-StatefulSet sollte ein Pod bereit sein.

appctl installieren

Verwenden Sie zum Installieren des Application Delivery-Befehlszeilentools appctl die gcloud CLI, um pkg zu installieren.

gcloud components install pkg

Nachdem Sie Application Delivery für einen Cluster aktiviert und pkg installiert haben, können Sie Ihre erste Anwendung bereitstellen.

Anwendung bereitstellen

So stellen Sie eine Anwendung bereit:

  1. Erstellen Sie neue Git-Repositories oder initialisieren Sie vorhandene Repositories.
  2. Erstellen einer Basiskonfiguration
  3. Erstellen Sie eine oder mehrere Umgebungen für Ihr Deployment.
  4. (Optional) Wenden Sie Konfigurations-Overlays auf Ihre Umgebungen in Ihrem Anwendungs-Repository an.
  5. Erstellen Sie einen Releasekandidaten in Form einer Pull- oder Zusammenführungsanfrage.
  6. Stellen Sie Ihre Releases bereit.

Neue Repositories erstellen

Erstellen Sie mit appctl Repositories für Application Delivery auf GitHub oder GitLab.

  1. Wechseln Sie in das Verzeichnis, in dem Sie das Anwendungsverzeichnis erstellen möchten.
  2. Erstellen Sie Ihre Application Delivery-Repositories mit appctl.

    GitHub

    Führen Sie dazu diesen Befehl aus:

    appctl init APP_NAME \
        --app-config-repo=github.com/USERNAME/APP_NAME
    

    Dabei gilt:

    • APP_NAME ist der Name Ihrer Anwendung.
    • USERNAME ist Ihr GitHub-Nutzername

    Wenn Ihr GitHub-Nutzername beispielsweise octocat lautet und Sie eine Anwendung namens myapp erstellen möchten, führen Sie Folgendes aus:

    appctl init myapp \
        --app-config-repo=github.com/octocat/myapp
    

    GitLab

    Führen Sie dazu diesen Befehl aus:

    appctl init APP_NAME \
        --app-config-repo=gitlab.com/USERNAME/APP_NAME
    

    Dabei gilt:

    • APP_NAME ist der Name Ihrer Anwendung.
    • USERNAME ist Ihr GitLab-Nutzername

    Wenn Ihr GitLab-Nutzername beispielsweise alice lautet und Sie eine Anwendung namens myapp erstellen möchten, führen Sie Folgendes aus:

    appctl init myapp \
        --app-config-repo=gitlab.com/alice/myapp
    
  3. appctl fordert Sie auf, Ihre neuen privaten Repositories zu bestätigen.

appctl erstellt zwei private Remote-Git-Repositories:

  • Das Anwendungs-Repository github.com/USERNAME/APP_NAME. Dieses Repository wird in das aktuelle Verzeichnis geklont.
  • Das Deployment-Repository github.com/USERNAME/APP_NAME-deployment. Das lokale Deployment-Repository wird in ./APP_NAME/.deployment gespeichert.

Weitere Informationen zum Inhalt und zur Struktur dieser Repositories finden Sie im Konzeptleitfaden zu Application Delivery.

Vorhandene Repositories initialisieren

Wenn Sie bereits Repositories haben, können Sie sie für Application Delivery auf GitHub oder GitLab mit appctl initialisieren.

  1. Wechseln Sie in das Verzeichnis, in dem Sie das Anwendungsverzeichnis erstellen möchten.

  2. Führen Sie den Befehl appctl init aus, um ein Verzeichnis mit dem Namen APP_NAME zu erstellen und Ihr Repository dort zu klonen.

    Der Befehl appctl init initialisiert eine Kustomize-Basisebene in den Konfigurationsdateien, die im Verzeichnis ./config des Repositorys gespeichert sind. Mit dem Flag --config-path können Sie einen anderen Konfigurationspfad angeben.

    appctl init verwendet standardmäßig github.com/USERNAME/APP_NAME-deployment als URL des Deployment-Repositorys. Mit dem Flag --deployment-repo können Sie eine andere URL angeben. Wenn das Deployment-Repository nicht vorhanden ist, erstellt der appctl-Befehl eines.

    GitHub

    appctl init APP_NAME \
          --app-config-repo=github.com/USERNAME/APP_NAME \
          [--config-path=CONFIG_PATH]
    

    Dabei gilt:

    • APP_NAME ist der Name Ihrer Anwendung.
    • USERNAME ist Ihr GitHub-Nutzername
    • CONFIG_PATH ist der optionale Pfad zum Konfigurationsverzeichnis Ihres Repositorys. Wenn keine Angabe gemacht wird, lautet der Standardwert ./config.

    Wenn das vorhandene Anwendungskonfigurations-Repository beispielsweise https://github.com/octocat/myapp ist und Sie davon ausgehen, dass das Deployment-Repository https://github.com/octocat/myapp-deploy ist, führen Sie folgenden Befehl aus:

    appctl init myapp \
        --app-config-repo=github.com/octocat/myapp
    

    GitLab

    appctl init APP_NAME \
        --app-config-repo=gitlab.com/USERNAME/APP_NAME \
        [--config-path=CONFIG_PATH]
    

    Dabei gilt:

    • APP_NAME ist der Name Ihrer Anwendung.
    • USERNAME ist Ihr GitLab-Nutzername.
    • CONFIG_PATH ist der optionale Pfad zum Konfigurationsverzeichnis Ihres Repositorys. Wenn keine Angabe gemacht wird, lautet der Standardwert ./config.

    Wenn das vorhandene Anwendungskonfigurations-Repository beispielsweise gitlab.com/alice/myapp ist, führen Sie folgenden Befehl aus:

    appctl init myapp --app-config-repo=gitlab.com/alice/myapp
    

Basiskonfiguration erstellen

  1. Wechseln Sie als Arbeitsverzeichnis in Ihr Anwendungs-Repository.

  2. Erstellen Sie die Konfiguration für Ihre Kubernetes-Arbeitslast. Dies kann ein beliebiges gültiges Kubernetes-Deployment sein.

    Mit der nachfolgend aufgeführten Konfiguration wird eine Anwendung namens nginx definiert, die drei Replikate des nginx-Containers bereitstellt. Kopieren Sie die Konfiguration in die Datei config/base/myapp.yaml. Wenn Sie einen Load-Balancer aktivieren möchten, entfernen Sie das Kommentarzeichen in der Zeile type: LoadBalancer.

    #myapp/config/base/myapp.yaml
    
    apiVersion: v1
    kind: Service
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      # if your cluster supports it, uncomment the following to automatically create
      # an external load-balanced IP for the frontend service.
      # type: LoadBalancer
      ports:
        - port: 80
      selector:
        app: nginx
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.7.9
            ports:
            - containerPort: 80
    
  3. Konfigurieren Sie Application Delivery so, dass diese Konfiguration auf die Basis angewendet wird. Fügen Sie zu config/base/kustomization.yaml Folgendes hinzu:

    #config/base/kustomization.yaml
    
    resources:
      - myapp.yaml
    

Konfiguration testen und per Push übertragen

  1. Testen Sie die Konfiguration aus Ihrem Anwendungs-Repository-Verzeichnis mit kustomize build:

    kustomize build config/base/
    

    Wenn Ihre Konfiguration gültig ist, gibt kustomize die YAML-Datei aus, die nach ihrer Anwendung im Cluster bereitgestellt wird.

  2. Nachdem Sie Ihre YAML-Datei geprüft haben, erstellen Sie einen Commit und übertragen ihn per Push in Ihr Anwendungs-Repository:

    git add .
    git commit -m "Creating APP_NAME"
    git push origin master
    

Releaseumgebung hinzufügen

Application Delivery stellt Ihre Anwendung in Umgebungen bereit. Umgebungen fügen Sie für Ihre Releases mit appctl hinzu.

  1. Wechseln Sie in das Stammverzeichnis des Anwendungs-Repositorys.

  2. Erstellen Sie Ihre Umgebung mit appctl:

    appctl env add ENVIRONMENT_NAME \
        --cluster=CLUSTER_NAME
    

    Dabei gilt:

    • ENVIRONMENT_NAME ist der Name der neuen Umgebung.
    • CLUSTER_NAME: Der Name Ihres Clusters.

    appctl erstellt einen Git-Commit, der eine Kustomize-Konfiguration mit Scaffold enthält.

    Sie können den Namen des Namespace für eine Releaseumgebung dieser Anwendung mit --namespace angeben. Wenn nicht, ist der Standard-Namespace APP_NAME-ENVIRONMENT_NAME:

    Führen Sie beispielsweise den folgenden Befehl aus, um die Umgebungen staging und prod dem Cluster application-cluster mit dem Standard-Namespace-Namen hinzuzufügen:

    appctl env add staging --cluster=application-cluster
    appctl env add prod --cluster=application-cluster
    

    Führen Sie den folgenden Befehl aus, um die test-Umgebung im test-Namespace dem Cluster application-cluster hinzuzufügen:

    appctl env add test --cluster=application-cluster --namespace=test
    

    Wenn Sie eine Umgebung hinzufügen, müssen Sie berücksichtigen, ob im Bereitstellungs-Repository für diese Umgebung Pull-Anfragen und Codeüberprüfungen erforderlich sind. Standardmäßig werden Pull-Anfragen erstellt. Wenn die Umgebung nicht produktionskritisch ist und keine Codeüberprüfung erforderlich ist, können Sie das Erstellen von Pull-Anfragen mit --review-required=false überspringen.

    Führen Sie beispielsweise den folgenden Befehl aus, um die test-Umgebung hinzuzufügen, für die keine Pull-Anfragen erforderlich sind:

    appctl env add test \
        --cluster=application-cluster \
        --review-required=false
    
  3. Optional können Sie die Änderungen, die Application Delivery in Ihrem Git-Repository vorgenommen hat, mit git log aufrufen:

    git log -p *
    
  4. Übertragen Sie die Konfiguration per Push in Ihr Anwendungs-Repository:

    git push origin master
    

Optional: Deployment-Repository prüfen

Rufen Sie die Seite von GitHub oder GitLab für Ihr Deployment-Repository auf. Wenn beispielsweise Ihr GitHub-Nutzername octocat lautet und Sie eine Anwendung namens myapp erstellt haben, lautet die URL https://github.com/octocat/myapp-deployment. Auf dieser Seite werden die Zweige angezeigt, die für jede Umgebung erstellt wurden.

Umgebung bereitstellen

So stellen Sie eine Umgebung mit Application Delivery bereit:

  1. Erstellen Sie eine Version mit git tag und übertragen Sie das Tag per Push.

    git tag VERSION
    git push origin VERSION
    

    Ersetzen Sie VERSION durch die Versionsnummer Ihrer Anwendung.

    Um beispielsweise die Version v0.1.0 per Push zu übertragen, führen Sie die folgenden Befehle aus:

    git tag v0.1.0
    git push origin v0.1.0
    ```
    
  2. Verwenden Sie appctl prepare, um die aktuell mit Tags versehene Version zu benennen und eine Pull-Anfrage im Deployment-Repository zur Prüfung zu generieren.

    appctl prepare ENVIRONMENT_NAME
    

    Führen Sie beispielsweise den folgenden Befehl aus, um die staging-Umgebung zu verwenden:

    appctl prepare staging \
        --validate=true
    

    Dieser Befehl löst die kpt-Validierungsfunktion gcr.io/kustomize-functions/example-validator aus, um zu prüfen, welche Änderung per Push an das Deployment-Repository übertragen wird.

    kpt wird von gcloud components install pkg installiert. Diese Validierungsfunktion führt kubeval im Hintergrund aus, wodurch Kubernetes-Konfigurationsdateien mithilfe von Schemas aus der OpenAPI-Spezifikation von Kubernetes validiert werden.

    Zum Ausführen von kpt prepare staging --validate müssen Sie Docker auf Ihrem Computer installieren.

    Das Flag --validate ist standardmäßig deaktiviert.

    Wenn appctl den Commit im Deployment-Repository durchgeführt hat, gibt es eine URL wie die folgende aus, um eine Pull-Anfrage zu erstellen:

    Created a "Pull Request": "https://github.com/octocat/myapp-deployment/pull/[Pull_Request_ID]"
    
  3. Verwenden Sie GitHub oder GitLab, um die Pull-Anfrage zu prüfen und zu genehmigen.

  4. Nachdem die Pull-Anfrage genehmigt wurde, schließen Sie das Deployment mit appctl apply ab:

    appctl apply ENVIRONMENT_NAME
    

    Ersetzen Sie ENVIRONMENT_NAME durch den Namen Ihrer Umgebung.

    Führen Sie beispielsweise folgenden Befehl aus, um Änderungen in der staging-Umgebung bereitzustellen:

    appctl apply staging
    
  5. Prüfen Sie, ob Ihre Anwendung mit kubectl oder über die Console ausgeführt wird.

    kubectl

    Verwenden Sie kubectl describe, um den Status Ihrer Anwendung aufzurufen:

    kubectl get releasetracks.app.gke.io APP_NAME \
        --n NAMESPACE \
        -w
    

    Ersetzen Sie Folgendes:

    • APP_NAME: der Name Ihres Anwendungs-Repositorys
    • NAMESPACE: den Namespace-Namen, den Sie beim Erstellen der Umgebung angegeben haben. Wenn Sie keinen Namespace-Namen angegeben haben, ist die Standardeinstellung APP_NAME-ENVIRONMENT_NAME.

    Beispielsweise können Sie mit dem folgenden Befehl den Status der staging-Umgebung der Anwendung myapp prüfen:

    kubectl get releasetracks.app.gke.io myapp -n myapp-staging
    

    Führen Sie den folgenden Befehl aus, um den Status der test-Umgebung zu prüfen, die zuvor mit env add --namespace test hinzugefügt wurde:

    kubectl get releasetracks.app.gke.io myapp -n test
    

    Console

    Informationen zu Status und Version Ihrer Anwendungen, die mit Application Delivery bereitgestellt wurden, finden Sie auf der GKE-Seite Anwendungen in der Console.

Release hochstufen

  1. Mit dem folgenden Befehl können Sie einen Releasekandidaten von einer Umgebung in eine andere hochstufen:

    appctl prepare TARGET_ENVIRONMENT \
        --from-env=SOURCE_ENVIRONMENT
    

    Dabei gilt:

    • TARGET_ENVIRONMENT ist der Name der Umgebung, in der Sie den Releasekandidaten bereitstellen möchten
    • SOURCE_ENVIRONMENT: der Name der aktuellen Umgebung

    Zum Hochstufen von staging nach prod führen Sie beispielsweise Folgendes aus:

    appctl prepare prod --from-env=staging
    
  2. Verwenden Sie GitHub oder GitLab, um die Pull-Anfrage zu prüfen und zu genehmigen.

  3. Zum Bereitstellen des Releasekandidaten in der Zielumgebung führen Sie den folgenden Befehl aus:

    appctl apply TARGET_ENVIRONMENT
    

    Für ein Deployment in der prod-Umgebung führen Sie beispielsweise den folgenden Befehl aus:

    appctl apply prod
    

Umgebungen in der Console ansehen

Sobald die Anwendung einer Umgebung bereitgestellt wurde, wird sie auf der GKE-Seite Anwendungen aufgeführt. Diese Seite enthält eine Liste von Anwendungen, einschließlich ihrer Umgebungen, die in Klammern angegeben sind. Hier ist ein Screenshot einer Anwendung myapp mit den zwei Umgebungen staging und prod. Auf dieser Seite werden auch der Namespace, der Cluster und die Version jeder Umgebung angezeigt.

Screenshot: Seite "Anwendungen"

Klicken Sie auf den Namen der Anwendung, wenn Sie Anwendungsdetails wie das Git-Tag, die Komponenten und die Umgebungsliste sehen möchten. Der folgende Screenshot zeigt die Details für myapp.

Screenshot: Detailseite einer Anwendung

Konfiguration einer Umgebung ändern

In diesem Abschnitt wird davon ausgegangen, dass eine staging-Umgebung wie in den vorherigen Schritten konfiguriert wurde. Möglicherweise müssen Sie diese Anleitung entsprechend anpassen.

In diesem Abschnitt ändern Sie die Parameter für die staging-Umgebung mithilfe eines Kustomize-Overlays. Nachdem Sie die Änderungen vorgenommen haben, werden sie per Push nach Git übertragen und mit Tags gekennzeichnet. Application Delivery aktualisiert dann Ihren Cluster.

  1. Erstellen Sie eine Datei mit dem Namen config/envs/staging/patch-replicas.yaml und kopieren Sie den folgenden Text in diese Datei. Damit wird die Konfiguration in der staging-Umgebung aktualisiert, sodass nur ein Replikat statt drei Replikaten ausgeführt wird.

    #config/envs/staging/patch-replicas.yaml
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
    spec:
      replicas: 1
    
  2. Bearbeiten Sie die Datei config/envs/staging/kustomization.yaml und fügen Sie patch-replicas.yaml einer neuen Sammlung namens patchesStrategicMerge hinzu.

    #config/envs/staging/kustomization.yaml
    namespace: myapp-staging
    bases:
       - ../../base
    patchesStrategicMerge:
       - patch-replicas.yaml
    

    Sie können diesem Overlay auch umgebungsspezifische Anmerkungen hinzufügen. Im folgenden Beispiel wird eine Anmerkung mit dem Namen oncall-team eingefügt, um alle Ressourcen in dieser Umgebung hinzuzufügen. Weitere Informationen finden Sie unter Kustomization File Fields.

    #config/envs/staging/kustomization.yaml
    
    #Don't change the namespace field
    namespace: myapp-staging
    bases:
       - ../../base
    patchesStrategicMerge:
       - patch-replicas.yaml
    commonAnnotations:
      oncall-team: staging-oncall@foo.bar
    
  3. Testen Sie Ihre Konfiguration mit kustomize build:

    kustomize build config/envs/staging/
    
  4. Fügen Sie Ihre Änderungen mit einem Commit hinzu:

    git add .
    git commit -m "<var>COMMIT_MESSAGE</var>"
    git push origin master
    

    Ersetzen Sie COMMIT_MESSAGE durch eine Nachricht, die Ihre Änderungen beschreibt.

  5. Erstellen Sie eine Version mit git tag und übertragen Sie diese per Push:

    git tag VERSION
    git push origin VERSION
    

    Ersetzen Sie VERSION durch die gewünschte Versionsnummer.

  6. Generieren Sie mit appctl prepare eine Pull-Anfrage im Deployment-Repository zur Prüfung:

    appctl prepare ENVIRONMENT_NAME
    
  7. Folgen Sie dem Link, um eine GitHub- oder GitLab-Pull-Anfrage zu erstellen.

  8. Sehen Sie sich den Inhalt Ihrer Pull-Anfrage an. Application Delivery führt eine Änderung in einer Zeile aus, mit der für replicas der Wert 1 festgelegt wird.

  9. Genehmigen Sie die Pull-Anfrage mit GitHub oder GitLab.

  10. Übernehmen Sie die Änderungen mit appctl apply:

    appctl apply staging
    

Konfigurationsänderungen rückgängig machen

Führen Sie folgenden Befehl aus, um ein Rollback zu einem früheren Release durchzuführen:

appctl apply TARGET_ENVIRONMENT \
    --from-tag GIT_TAG

Dabei gilt:

  • TARGET_ENVIRONMENT: der Name der Umgebung, in der Sie den Release bereitstellen möchten
  • GIT_TAG: der Name des Tags für den Release

appctl in Skripts verwenden

Das Tool appctl ist interaktiv und erfordert standardmäßig eine Nutzereingabe. Wenn Sie appctl in einem Skript, in einem Container oder in Pipelines ausführen möchten, legen Sie die Umgebungsvariable APPCTL_INTERACTIVE auf false fest.

Beispielsweise können Sie in Bash Shell den folgenden Befehl ausführen:

export APPCTL_INTERACTIVE=false

Informationen zu den jeweiligen appctl-Befehlen erhalten Sie mit appctl help command. Hilfe zu appctl prepare können Sie beispielsweise mit appctl help prepare aufrufen.

Anwendungsmanager deinstallieren

Zum Entfernen der Anwendung, die in Ihrem Cluster ausgeführt wird, löschen Sie alle Namespaces, die mit neuen Umgebungen erstellt wurden.

Wiederholen Sie dazu für alle Umgebungen und Cluster die im Folgenden aufgeführten Befehle.

  1. Wechseln Sie für die jeweilige Umgebung zum zugehörigen Cluster:

    kubectl config use-context ENVIRONMENT_CLUSTER_NAME
    

    Ersetzen Sie ENVIRONMENT_CLUSTER_NAME durch den Namen des Clusters in der ausgewählten Umgebung.

  2. Löschen Sie den Namespace, in dem Ihre Anwendung für diese Umgebung ausgeführt wird:

    kubectl delete ns NAMESPACE
    

    Ersetzen Sie NAMESPACE durch den Namespace-Namen, den Sie löschen möchten. Der Standardwert ist APP_NAME-ENVIRONMENT_NAME.

  3. Löschen Sie in GitHub oder GitLab die beiden Git-Repositories, die mit appctl erstellt wurden.

  4. Löschen Sie Ihr lokales Anwendungsverzeichnis mit folgendem Befehl:

    rm -rf myapp/
    
  5. Sie können Application Delivery in Ihrem Cluster mit gcloud oder mit der Console deaktivieren:

    gcloud

    gcloud beta container clusters update CLUSTER_NAME \
        --update-addons ApplicationManager=DISABLED
    

    Console

    1. Öffnen Sie in der Console die Seite Google Kubernetes Engine.

      Zur Seite „Google Kubernetes Engine“

    2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

    3. Klicken Sie unter Features neben dem Feld Anwendungsmanager auf Anwendungsmanager bearbeiten.

    4. Entfernen Sie das Häkchen von Anwendungsmanager aktivieren.

    5. Klicken Sie auf Änderungen speichern.

Nächste Schritte

Mehr über Kustomize erfahren