Mettre à niveau Apigee hybrid

Mettre à niveau vers la version 1.2.0

Pour mettre à niveau Apigee hybrid vers la version 1.2.0, procédez comme suit :

Étape 1 : Mettez à niveau Kubernetes et téléchargez le package de version

Mettez à niveau votre plate-forme Kubernetes comme suit. Si vous avez besoin d'aide, consultez la documentation de votre plate-forme :

Plate-forme	Mise à niveau vers la version
GKE	1.14.x
Anthos	1.2
AKS	1.14.x

Téléchargez le package de version pour votre système d'exploitation :

Mac 64 bits :

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

Linux 64 bits :

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

Mac 32 bits :

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

Linux 32 bits

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

Étape 2 : Reconfigurez votre répertoire d'installation

Identifiez le répertoire d'installation de base créé lors de l 'installation initiale d'Apigee hybride. Le répertoire de base est celui dans lequel se trouve le répertoire $APIGEEGTL_HOME. Dans l'exemple suivant, le répertoire de base est /Users/myhome/hybrid:
```
echo $APIGEECTL_HOME
/Users/myhome/hybrid/apigeectl
```
Extrayez le contenu du fichier gzip téléchargé dans le répertoire de base Apigee hybrid :
```
tar xvzf filename.tar.gz -C path-to-base-directory
```
cd dans le répertoire de base.
Le contenu du fichier tar est, par défaut, développé dans un répertoire dont le nom contient la version et la plate-forme. Exemple : ./apigeectl_1.2.0-f7b96a8_linux_64.
Renommez le répertoire apigeectl actuel. Par exemple, si la version actuelle est 1.1.1, renommez le répertoire apigeectl en apigeectl_1.1.1.
Renommez le répertoire d'installation que vous venez d'extraire en apigeectl. Il s'agit maintenant de l'emplacement vers lequel l'environnement $APIGEECTL_HOME pointe.

Étape 3 : Mettez à jour le fichier de remplacement

Effectuez une copie de votre fichier de remplacement, et veillez à conserver l'ancien fichier au cas où vous auriez besoin d'effectuer un rollback. Dans les étapes suivantes, vous devrez apporter les modifications requises au fichier de remplacement avant de l'appliquer au cluster.
REMARQUE : Pour passer à la version 1.2.0, vous devez modifier votre fichier de remplacement, qui est incompatible avec les versions précédentes. Les modifications du fichier de remplacement décrites à l'étape suivante sont requises.

Mettez à jour votre fichier de remplacement avec les modifications décrites ci-dessous :

Vous trouverez ci-dessous un résumé des modifications de configuration que vous devez apporter à votre fichier de remplacement. Un exemple complet est donné dans la table à la suite du résumé. Comme vous pourrez le constater, la propriété envs[] a considérablement changé par rapport aux versions précédentes :

La propriété envs[].hostAlias a été supprimée et remplacée par la nouvelle propriété virtualhosts.hostAliases[].
REMARQUE : Si vous avez utilisé un seul caractère générique "*" pour l'alias d'hôte de l'environnement dans une version précédente, dans la version 1.2.0, vous DEVEZ utiliser un nom DNS complet ou caractère générique de sous-domaine dans la configuration de l'alias de l'hôte virtuel. Exemple : *.mydomain.com. La configuration à un seul caractère générique hostAliases['*'] n'est plus acceptée.
Vous devez ajouter la nouvelle propriété de configuration virtualhosts requise.
Vous devez déplacer les propriétés envs[].sslCertPath et envs[].sslKeyPath de envs vers virtualhosts.
Vous devez ajouter le stanza de configuration virtualhosts.routingRules. La propriété virtualhosts.routingRules remplace la propriété envs[].paths précédente. Si votre fichier de remplacement contient la propriété envs[].paths, vous devez la supprimer. Pour plus d'informations sur la configuration de l'hôte virtuel, consultez la page Configurer des hôtes virtuels.

Le tableau ci-dessous illustre les différences entre un fichier de remplacement 1.1.1 et un fichier de version 1.2.0. L'exemple vise à mettre en évidence les types de modifications à apporter pour la version 1.2.0 :

Configuration v1.1.x	Configuration v1.2.0
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

Configuration v1.1.x

Configuration v1.2.0


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

REMARQUE : Si vous ne spécifiez pas envs[].paths (comme illustré dans le tableau ci-dessus), vous pouvez omettre la propriété virtualhosts[].routingRules.paths[] dans la mise à niveau. Par défaut, le chemin est "/". Par exemple, si vous souhaitez utiliser le chemin par défaut "/", vous pouvez configurer virtualhosts[].routingRules comme suit :

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

Étape 4 : Appliquez la mise à niveau au cluster

Si vous avez activé Apigee Connect dans votre version d'installation 1.1.1, vous devez supprimer le déploiement :
1. Commencez par répertorier les déploiements Apigee :
```
kubectl -n namespace get ad
```
2. Supprimez le déploiement Apigee Connect :
```
kubectl -n namespace delete ad apigee-connect-name
```
Répertoriez les pods :
```
kubectl get pods -n namespace
```
Supprimez le pod apigee-cps-setup du cluster. Utilisez le nom complet du pod, qui comprend le nom de votre organisation, tel qu'il apparaît dans la commande précédente. Exemple :
```
kubectl -n namespace delete pod apigee-cps-setup-org
```
Supprimez le pod apigee-cps-create-user dans le même espace de noms :
```
kubectl -n namespace delete pod apigee-cps-create-user
```
Nettoyez les tâches terminées pour l'espace de noms d'exécution hybride, où namespace correspond à l'espace de noms spécifié dans votre fichier de remplacement, si vous avez spécifié un espace de noms. Si ce n'est pas le cas, l'espace de noms par défaut est apigee :
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Nettoyez les tâches terminées pour l'espace de noms apigee-system :

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

Nettoyez les tâches terminées pour l'espace de noms istio-system :

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

cd dans le répertoire ./hybrid-files :

Initialisez apigeectl pour la nouvelle version :

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

Vérifiez si l'initialisation est terminée :

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

Lorsque check-ready renvoie "Tous les conteneurs sont prêts", vous pouvez effectuer une installation en mode "simulation". Exécutez la commande apply avec l'option --dry-run=true. L'exécution d'une simulation vous permet de rechercher les erreurs éventuelles avant que des modifications ne soient apportées au cluster :
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true
```
Si aucune erreur ne s'affiche, vous pouvez appliquer les composants d'exécution spécifiques à Apigee au cluster :
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml
```
Exécutez à nouveau check-ready pour déterminer quand la mise à niveau est terminée.

Effectuer un rollback de la mise à niveau

Suivez ces étapes ci-dessous pour effectuer le rollback vers une mise à niveau précédente :

Nettoyez les tâches terminées pour l'espace de noms d'exécution hybride, où namespace correspond à l'espace de noms spécifié dans votre fichier de remplacement, si vous avez spécifié un espace de noms. Si ce n'est pas le cas, l'espace de noms par défaut est apigee :
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Nettoyez les tâches terminées pour l'espace de noms apigee-system :

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

Nettoyez les tâches terminées pour l'espace de noms istio-system :

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

Supprimez le déploiement Apigee Operators. Cette opération n'aura aucun effet sur votre trafic d'exécution :
```
kubectl -n apigee-system delete deployment apigee-controller-manager
```
Modifiez la variable $APIGEECTL_HOME pour qu'elle pointe en direction du répertoire contenant la version d'origine de apigeectl. Exemple :
```
export APIGEECTL_HOME=path-to-original-apigeectl-directory
```
Dans le répertoire racine de l'installation vers laquelle vous souhaitez effectuer un rollback, exécutez apigeectl init, puis apigeectl apply. Veillez à utiliser le fichier de remplacement d'origine pour la version vers laquelle vous souhaitez effectuer un rollback :
```
  $APIGEECTL_HOME/apigeectl init -f overrides/original-overrides.yaml
  $APIGEECTL_HOME/apigeectl apply -f overrides/original-overrides.yaml
```