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

  1. 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
  2. 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

  1. 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
  2. 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
  3. cd dans le répertoire de base.
  4. 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.

  5. 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.
  6. 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

  1. 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.
  2. 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[].
    • 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

Étape 4 : Appliquez la mise à niveau au cluster

  1. 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
  2. Répertoriez les pods :
    kubectl get pods -n namespace
  3. 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
  4. Supprimez le pod apigee-cps-create-user dans le même espace de noms :
    kubectl -n namespace delete pod apigee-cps-create-user
  5. 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}')
  6. 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}')
  7. 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}')
  8. cd dans le répertoire ./hybrid-files :
  9. Initialisez apigeectl pour la nouvelle version :
    $APIGEECTL_HOME/apigeectl init -f overrides/overrides-file.yaml
  10. Vérifiez si l'initialisation est terminée :
    $APIGEECTL_HOME/apigeectl check-ready -f overrides/overrides-file.yaml
  11. 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
  12. 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
  13. 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 :

  1. 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}')
  2. 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}')
  3. 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}')
  4. 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
  5. 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
  6. 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