Apigee Hybrid aktualisieren

Upgrade auf Version 1.2.0

Führen Sie die folgenden Schritte aus, um die Apigee-Hybrid auf Version 1.2.0 zu aktualisieren:

Schritt 1: Kubernetes aktualisieren und das Releasepaket herunterladen

So führen Sie ein Upgrade Ihrer Kubernetes-Plattform durch: Weitere Informationen finden Sie in der Dokumentation der Plattform:

Plattform	Auf Version aktualisieren
GKE	1.14.x
Anthos	1.2
AKS	1.14.x

Laden Sie das Release-Paket für Ihr Betriebssystem herunter:

Mac 64-Bit:

curl -LO \
    https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_mac_64.tar.gz

Linux 64-Bit

curl -LO \
    https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_linux_64.tar.gz

Mac 32-Bit:

curl -LO \
    https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_mac_32.tar.gz

Linux 32-Bit

curl -LO \
    https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_linux_32.tar.gz

Schritt 2: Installationsverzeichnis neu konfigurieren

Ermitteln Sie das Basisinstallationsverzeichnis, das bei der ursprünglichen Installation von Apigee Hybrid erstellt wurde. Das Basisverzeichnis ist das Verzeichnis, in dem sich das Verzeichnis $APIGEEGTL_HOME befindet. Im folgenden Beispiel ist das Basisverzeichnis /Users/myhome/hybrid:
```
echo $APIGEECTL_HOME
/Users/myhome/hybrid/apigeectl
```
Extrahieren Sie die heruntergeladenen gzip-Dateiinhalte in das Apigee Hybrid-Basisverzeichnis:
```
tar xvzf filename.tar.gz -C path-to-base-directory
```
cd zum Basisverzeichnis.
Die TAR-Inhalte werden standardmäßig in ein Verzeichnis mit der Version und der Plattform in ihrem Namen erweitert. Beispiel: ./apigeectl_1.2.0-f7b96a8_linux_64.
Benennen Sie das aktuelle apigeectl-Verzeichnis um. Wenn die aktuelle Version beispielsweise 1.1.1 ist, benennen Sie das Verzeichnis apigeectl in apigeectl_1.1.1 um.
Benennen Sie das neu extrahierte Installationsverzeichnis in apigeectl um. Hier verweist die Umgebung $APIGEECTL_HOME auf diese Umgebung.

Schritt 3: Überschreibungsdatei aktualisieren

Erstellen Sie eine Kopie Ihrer Überschreibungsdatei und speichern Sie die alte Datei unbedingt, falls Sie später ein Rollback durchführen müssen. In den folgenden Schritten nehmen Sie die erforderlichen Änderungen an der Überschreibungsdatei vor, bevor Sie sie auf den Cluster anwenden.
HINWEIS: Wenn Sie ein Upgrade auf Version 1.2.0 durchführen möchten, müssen Sie Änderungen in der Überschreibungsdatei vornehmen, die mit früheren Versionen nicht kompatibel sind. Die im nächsten Schritt beschriebenen Änderungen an der Überschreibungsdatei sind erforderlich.

Aktualisieren Sie die Überschreibungsdatei mit den unten beschriebenen Änderungen:

Im Folgenden finden Sie eine Zusammenfassung der Konfigurationsänderungen, die Sie an Ihrer Überschreibungen-Datei vornehmen müssen. Ein vollständiges Beispiel finden Sie in der Tabelle nach der Zusammenfassung. Wie Sie sehen, hat sich das Attribut envs[] im Vergleich zu früheren Versionen deutlich geändert:

Das Attribut envs[].hostAlias wurde entfernt und durch das neue Attribut virtualhosts.hostAliases[] ersetzt.
HINWEIS: Wenn Sie in einer früheren Version einen einzigen Platzhalter '*' für den Umgebungs-Host-Alias verwendet haben, MÜSSEN Sie in Version 1.2.0 in der Konfiguration des Alias des virtuellen Hosts entweder einen voll qualifizierten DNS-Namen oder einen Subdomain-Platzhalter verwenden. Beispiel: *.mydomain.com. Die Konfiguration mit einem einzelnen Platzhalterzeichen hostAliases['*'] wird nicht mehr unterstützt.
Sie müssen das neue erforderliche Konfigurationsattribut virtualhosts hinzufügen.
Sie müssen die Attribute envs[].sslCertPath und envs[].sslKeyPath von envs in virtualhosts verschieben.
Sie müssen die virtualhosts.routingRules-Konfigurations-Stanza hinzufügen. Das Attribut virtualhosts.routingRules ersetzt das vorherige Attribut envs[].paths. Wenn Ihre Überschreibungsdatei envs[].paths enthalten, müssen Sie sie entfernen. Weitere Informationen zur Konfiguration des virtuellen Hosts finden Sie unter Virtuelle Hosts konfigurieren.

Die folgende Tabelle zeigt die Unterschiede zwischen einer 1.1.1-Überschreibungsdatei und einer Version 1.2.0-Datei. In diesem Beispiel werden die Änderungen hervorgehoben, die Sie für Version 1.2.0 vornehmen müssen:

v1.1.x-Konfiguration	v1.2.0-Konfiguration
envs: - name: test1 hostAlias: "api.example.com" sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.pem serviceAccountPaths: synchronizer: ./sa/sync.json udca: ./sa/udca.json paths: uri: prefixes: - /orders - /items - name: test2 hostAlias: "api.example.com" sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.pem serviceAccountPaths: synchronizer: ./sa/sync.json udca: ./sa/udca.json paths: uri: prefixes: - /v0/hello - /httpbin	virtualhosts: - name: default hostAliases: ["api.example.com"] sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.pem routingRules: - paths: - /orders - /items env: test1 - paths: - /v0/hello - /httpbin env: test2 envs: - name: test1 serviceAccountPaths: synchronizer: ./sa/synchronizer.json udca: ./sa/udca.json - name: test2 serviceAccountPaths: synchronizer: ./sa/synchronizer.json udca: ./sa/udca.json

v1.1.x-Konfiguration

v1.2.0-Konfiguration


envs:
  - name: test1
    hostAlias: "api.example.com"
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    serviceAccountPaths:
      synchronizer: ./sa/sync.json
      udca: ./sa/udca.json
    paths:
      uri:
        prefixes:
          - /orders
          - /items
  - name: test2
    hostAlias: "api.example.com"
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    serviceAccountPaths:
      synchronizer: ./sa/sync.json
      udca: ./sa/udca.json
    paths:
      uri:
        prefixes:
          - /v0/hello
          - /httpbin


virtualhosts:
  - name: default
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - paths:
        - /orders
        - /items
        env: test1
      - paths:
        - /v0/hello
        - /httpbin
        env: test2

envs:
  - name: test1
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json
  - name: test2
    serviceAccountPaths:
      synchronizer: ./sa/synchronizer.json
      udca: ./sa/udca.json

HINWEIS: Wenn Sie envs[].paths nicht wie in der Tabelle oben angegeben angeben, können Sie das Attribut virtualhosts[].routingRules.paths[] im Upgrade weglassen. Der Pfad ist standardmäßig "/". Wenn Sie beispielsweise den Standardpfad "/" verwenden möchten, können Sie die virtualhosts[].routingRules so konfigurieren:

virtualhosts:
  - name: default
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - env: test1
  - name: prod
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - env: test2

Schritt 4: Upgrade auf den Cluster anwenden

Wenn Sie Apigee Connect in der Version 1.1.1-Installation aktiviert haben, müssen Sie das Deployment entfernen:
1. Listen Sie zuerst die Apigee-Deployments auf:
```
kubectl -n namespace get ad
```
2. Löschen Sie das Apigee Connect-Deployment:
```
kubectl -n namespace delete ad apigee-connect-name
```
Listen Sie die Pods auf:
```
kubectl get pods -n namespace
```
Löschen Sie den Pod apigee-cps-setup aus dem Cluster. Verwenden Sie den vollständigen Namen des Pods, der den Namen Ihrer Organisation enthält, wie im vorherigen Befehl zurückgegeben. Beispiel:
```
kubectl -n namespace delete pod apigee-cps-setup-org
```
Löschen Sie den Pod apigee-cps-create-user im selben Namespace:
```
kubectl -n namespace delete pod apigee-cps-create-user
```
Bereinigen Sie abgeschlossene Jobs für den Namespace der Hybridlaufzeit. Dabei ist namespace der Namespace, der in der Überschreibungsdatei angegeben ist, wenn Sie einen Namespace angegeben haben. Wenn nicht, ist der Standard-Namespace apigee:
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Bereinigen Sie abgeschlossene Jobs für den Namespace apigee-system:

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

Bereinigen Sie abgeschlossene Jobs für den Namespace istio-system:

kubectl delete job -n istio-system \
  $(kubectl get job -n istio-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

cd zum Verzeichnis ./hybrid-files:

Initialisieren Sie apigeectl für die neue Version:

$APIGEECTL_HOME/apigeectl init -f overrides/overrides-file.yaml

Prüfen Sie, ob die Initialisierung abgeschlossen ist:

$APIGEECTL_HOME/apigeectl check-ready -f overrides/overrides-file.yaml

Wenn check-ready mit "Alle Container sind bereit" antwortet, können Sie eine "Probelauf"-Installation durchführen. Führen Sie den Befehl apply mit dem Flag --dry-run=true aus. Mit einem Probelauf können Sie auf Fehler prüfen, bevor Änderungen am Cluster vorgenommen werden:
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true
```
Wenn keine Fehler auftreten, können Sie die Apigee-spezifischen Laufzeitkomponenten auf den Cluster anwenden:
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml
```
Führen Sie check-ready noch einmal aus, um zu ermitteln, wann das Upgrade abgeschlossen ist.

Rollback für Upgrade durchführen

So führen Sie ein Rollback für ein Upgrade durch:

Bereinigen Sie abgeschlossene Jobs für den Namespace der Hybridlaufzeit. Dabei ist namespace der Namespace, der in der Überschreibungsdatei angegeben ist, wenn Sie einen Namespace angegeben haben. Wenn nicht, ist der Standard-Namespace apigee:
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Bereinigen Sie abgeschlossene Jobs für den Namespace apigee-system:

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

Bereinigen Sie abgeschlossene Jobs für den Namespace istio-system:

kubectl delete job -n istio-system \
  $(kubectl get job -n istio-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

Löschen Sie die Deployments der Apigee-Operatoren. Dieser Vorgang hat keine Auswirkungen auf Ihren Laufzeittraffic:
```
kubectl -n apigee-system delete deployment apigee-controller-manager
```
Ändern Sie die Variable $APIGEECTL_HOME so, dass sie auf das Verzeichnis verweist, das die ursprüngliche Version von apigeectl enthält. Beispiel:
```
export APIGEECTL_HOME=path-to-original-apigeectl-directory
```
Führen Sie im Stammverzeichnis der Installation, zu der Sie ein Rollback durchführen möchten, apigeectl init und dann apigeectl apply aus. Achten Sie darauf, die Original-Überschreibungsdatei für die Version zu verwenden, für die Sie ein Rollback durchführen möchten:
```
  $APIGEECTL_HOME/apigeectl init -f overrides/original-overrides.yaml
  $APIGEECTL_HOME/apigeectl apply -f overrides/original-overrides.yaml
```