Actualiza Apigee Hybrid

Estás viendo la versión 1.2 de la documentación de Apigee Hybrid. This version is end of life. You should upgrade to a newer version. Para obtener más información, consulta las Versiones compatibles.

Version 1.2 (unsupported)

   Versiones compatibles:

• v1.13 (la más reciente)                        
• v1.12                         
• v1.11                         
• Lista de versiones compatibles

   Versiones no compatibles

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

No puedes actualizar de la versión 1.0.0 a ninguna versión posterior porque no son retrocompatibles con la versión 1.0.0. Si usas la versión 1.0.0 y deseas actualizarla, debes realizar una instalación nueva.

Actualiza a la versión 1.2.0

Sigue estos pasos para actualizar Apigee Hybrid a la versión 1.2.0:

Paso 1: Actualiza Kubernetes y descarga el paquete de actualización

1. Actualiza tu plataforma de Kubernetes de la siguiente manera. Si necesitas ayuda, sigue la documentación de la plataforma:

   Plataforma	Actualizar a la versión
   GKE	1.14.x
   Anthos	1.2
   AKS	1.14.x

2. Descarga el paquete de actualización para tu sistema operativo:

   Mac (64 bits)

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

   Linux de 64 bits

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

   Mac de 32 bits:

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

   Linux de 32 bits

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

Paso 2: Vuelve a configurar el directorio de instalación

1. Identifica el directorio de instalación base que se creó cuando Apigee Hybrid se instaló originalmente. El directorio base es el directorio en el que se encuentra el directorio $APIGEEGTL_HOME. En el siguiente ejemplo, el directorio base es /Users/myhome/hybrid:

   echo $APIGEECTL_HOME
   /Users/myhome/hybrid/apigeectl

2. Extrae el contenido del archivo gzip descargado en el directorio base de Apigee Hybrid:

   tar xvzf filename.tar.gz -C path-to-base-directory

3. cd al directorio base.

4. De forma predeterminada, los contenidos del archivo tar se expanden a un directorio con la versión y la plataforma en su nombre. Por ejemplo: ./apigeectl_1.2.0-f7b96a8_linux_64.

5. Cambia el nombre del directorio apigeectl actual. Por ejemplo, si la versión actual es 1.1.1, cambia el nombre del directorio apigeectl por apigeectl_1.1.1.
6. Cambia el nombre del directorio de instalación recién extraído por apigeectl. Aquí es donde apunta el entorno $APIGEECTL_HOME.

Paso 3: Actualiza el archivo de anulaciones

1. Haz una copia de tu archivo de anulaciones y asegúrate de guardar el archivo anterior en caso de que necesites revertirlo. En los siguientes pasos, realizarás los cambios necesarios en el archivo de anulación antes de aplicarlo al clúster.
   NOTA: Para actualizar a la versión 1.2.0, debes realizar cambios en tu archivo de anulaciones que sean incompatibles con las versiones anteriores. Los cambios del archivo de anulación que se describen en el siguiente paso son obligatorios.

2. Actualiza tu archivo de anulaciones con los cambios que se describen a continuación:

   A continuación, se incluye un resumen de los cambios de configuración que debes realizar en tu archivo de anulaciones. Se proporciona un ejemplo completo en la tabla que sigue al resumen. Como verás, hubo cambios significativos en la propiedad envs[] con respecto a las versiones anteriores:

   • Se quitó la propiedad envs[].hostAlias y se reemplazó por la nueva propiedad virtualhosts.hostAliases[].
     NOTA: Si usaste un comodín único “*” para el alias del host de entorno en una versión anterior, en la versión 1.2.0, DEBE usar un nombre de DNS completamente calificado o un comodín de subdominio en la configuración del alias del host virtual. Por ejemplo: *.mydomain.com. La configuración de caracteres comodín hostAliases['*'] único ya no es compatible.
   • Debes agregar la nueva propiedad de configuración obligatoria virtualhosts.
   • Debes mover las propiedades envs[].sslCertPath y envs[].sslKeyPath de envs a virtualhosts.
   • Debes agregar la estrofa de configuración virtualhosts.routingRules. La propiedad virtualhosts.routingRules reemplaza la propiedad envs[].paths anterior. Si tienes envs[].paths en tu archivo de anulaciones, debes quitarlo. Para obtener más información sobre la configuración del host virtual, consulta Configura hosts virtuales.

   En la siguiente tabla, se ilustran las diferencias entre un archivo de anulaciones 1.1.1 y un archivo de la versión 1.2.0. El objetivo del ejemplo es destacar los tipos de cambios que debes realizar en la versión 1.2.0:

   NOTA: El código que se muestra es solo un ejemplo.

   Configuración de v1.1.x

   Configuración de 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

   NOTA: Si no especificas envs[].paths (como se muestra en la tabla anterior), puedes omitir la propiedad virtualhosts[].routingRules.paths[] en la actualización. De forma predeterminada, la ruta es “/”. Por ejemplo, si deseas usar la ruta de acceso predeterminada de “/”, puedes configurar el virtualhosts[].routingRules de la siguiente manera:

   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

Paso 4: Aplica la actualización al clúster

1. Si habilitaste Apigee Connect en tu instalación de la versión 1.1.1, debes quitar la implementación:
   1. Primero, enumera las implementaciones de Apigee:

      kubectl -n namespace get ad

   2. Borra la implementación de Apigee Connect:

      kubectl -n namespace delete ad apigee-connect-name

2. Haz una lista de pods:

   kubectl get pods -n namespace

3. Borra el pod apigee-cps-setup del clúster. Usa el nombre completo del pod, que incluye el nombre de tu organización, como se muestra en el comando anterior. Por ejemplo:

   kubectl -n namespace delete pod apigee-cps-setup-org

4. Borra el pod apigee-cps-create-user en el mismo espacio de nombres:

   kubectl -n namespace delete pod apigee-cps-create-user

5. Limpia los trabajos completados del espacio de nombres del entorno de ejecución híbrido, en el que namespace es el espacio de nombres especificado en el archivo de anulaciones, si especificaste un espacio de nombres. De lo contrario, el espacio de nombres predeterminado será apigee:

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

6. Limpia los trabajos completados del espacio de nombres apigee-system:

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

7. Limpia los trabajos completados del espacio de nombres istio-system:

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

8. cd para el directorio ./hybrid-files:
9. Inicializa apigeectl para la versión nueva:

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

10. Comprueba cuando se completó la inicialización:

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

11. Cuando check-ready responde con “Todos los contenedores están listos”, puedes probar una instalación de “ejecución de prueba”. Ejecuta el comando apply con la marca --dry-run=true. Realizar una ejecución de prueba te permite comprobar si hay errores antes de que se realicen cambios en el clúster:

    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true

12. Si no hay errores, puedes aplicar los componentes de entorno de ejecución específicos de Apigee al clúster:

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

13. Vuelve a ejecutar check-ready para determinar cuándo se completará la actualización.

Revierte una actualización

Sigue estos pasos para revertir una actualización anterior:

1. Limpia los trabajos completados del espacio de nombres del entorno de ejecución híbrido, en el que namespace es el espacio de nombres especificado en el archivo de anulaciones, si especificaste un espacio de nombres. De lo contrario, el espacio de nombres predeterminado será apigee:

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

2. Limpia los trabajos completados del espacio de nombres apigee-system:

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

3. Limpia los trabajos completados del espacio de nombres istio-system:

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

4. Borra la implementación de los operadores de Apigee. Esta operación no tendrá ningún efecto en el tráfico de tu entorno de ejecución:

   kubectl -n apigee-system delete deployment apigee-controller-manager

5. Cambia la variable $APIGEECTL_HOME para que apunte al directorio que contiene la versión original de apigeectl. Por ejemplo:

   export APIGEECTL_HOME=path-to-original-apigeectl-directory

6. En el directorio raíz de la instalación a la que deseas revertir, ejecuta apigeectl init y luego ejecuta apigeectl apply. Asegúrate de usar el archivo de anulaciones original para la versión a la que deseas revertir:

     $APIGEECTL_HOME/apigeectl init -f overrides/original-overrides.yaml
     $APIGEECTL_HOME/apigeectl apply -f overrides/original-overrides.yaml