Esta página se ha traducido con Cloud Translation API.

Actualizar la versión de Apigee Hybrid

Actualización 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 lanzamiento

Actualiza tu plataforma de Kubernetes de la siguiente manera. Consulta la documentación de tu plataforma si necesitas ayuda:

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

Descarga el paquete de lanzamiento para tu sistema operativo:

Mac de 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

Identifica el directorio de instalación base que se creó cuando se instaló originalmente Apigee hybrid. 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
```
Extrae el contenido del archivo gzip descargado en el directorio base de Apigee Hybrid:
```
tar xvzf filename.tar.gz -C path-to-base-directory
```
cd al directorio base.
De forma predeterminada, el contenido de tar se descomprime en un directorio cuyo nombre incluye la versión y la plataforma. Por ejemplo: ./apigeectl_1.2.0-f7b96a8_linux_64.
Cambia el nombre del directorio apigeectl actual. Por ejemplo, si la versión actual es 1.1.1, cambia el nombre del directorio apigeectl a apigeectl_1.1.1.
Cambia el nombre del directorio de instalación recién extraído a apigeectl. Ahora, el entorno $APIGEECTL_HOME apunta a este lugar.

Paso 3: Actualiza el archivo de anulaciones

Haz una copia del archivo de anulaciones y guarda el archivo antiguo por si necesitas deshacer los cambios. En los pasos siguientes, harás los cambios necesarios en el archivo de anulaciones antes de aplicarlo al clúster.
NOTA: Para actualizar a la versión 1.2.0, debes hacer cambios en el archivo de anulaciones que no son compatibles con las versiones anteriores. Es obligatorio realizar los cambios en el archivo override que se describen en el paso siguiente.

Actualiza el archivo de anulaciones con los cambios que se describen a continuación:

A continuación, se muestra un resumen de los cambios de configuración que debes hacer en el archivo de anulaciones. En la tabla que aparece después del resumen se muestra un ejemplo completo. Como verás, la propiedad envs[] ha cambiado significativamente respecto a las versiones anteriores:

La propiedad envs[].hostAlias se ha quitado y se ha sustituido por la nueva propiedad virtualhosts.hostAliases[].
NOTA: Si has usado un solo comodín (*) para el alias de host del entorno en una versión anterior, en la versión 1.2.0 DEBES usar un nombre de DNS completo o un comodín de subdominio en la configuración del alias de host virtual. Por ejemplo: *.mydomain.com. La configuración de un solo carácter comodín hostAliases['*'] ya no se admite.
Debe añadir la nueva propiedad de configuración obligatoria virtualhosts.
Debe mover las propiedades envs[].sslCertPath y envs[].sslKeyPath de envs a virtualhosts.
Debes añadir la estrofa de configuración virtualhosts.routingRules. La propiedad virtualhosts.routingRules sustituye a 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 de hosts virtuales, consulta el artículo Configurar hosts virtuales.

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

Configuración de v1.1.x	Configuración de la versión 1.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

Configuración de v1.1.x

Configuración de la versión 1.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 de arriba), puedes omitir la propiedad virtualhosts[].routingRules.paths[] en la actualización. De forma predeterminada, la ruta es "/". Por ejemplo, si quiere usar la ruta predeterminada "/", puede configurar virtualhosts[].routingRules de esta forma:

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

Si has habilitado Apigee Connect en la instalación de la versión 1.1.1, debes eliminar la implementación:
1. Primero, enumera los despliegues de Apigee:
```
kubectl -n namespace get ad
```
2. Elimina la implementación de Apigee Connect:
```
kubectl -n namespace delete ad apigee-connect-name
```
Muestra los pods:
```
kubectl get pods -n namespace
```
Elimina el pod apigee-cps-setup del clúster. Usa el nombre completo del pod, que incluye el nombre de tu organización, tal como se ha devuelto en el comando anterior. Por ejemplo:
```
kubectl -n namespace delete pod apigee-cps-setup-org
```
Elimina el pod apigee-cps-create-user en el mismo espacio de nombres:
```
kubectl -n namespace delete pod apigee-cps-create-user
```
Limpia las tareas completadas del espacio de nombres del tiempo de ejecución híbrido, donde namespace es el espacio de nombres especificado en el archivo de anulaciones, si has especificado alguno. Si no es así, el espacio de nombres predeterminado es apigee:
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Limpia las tareas completadas 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}')

Limpia las tareas completadas 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}')

cd al directorio ./hybrid-files:

Inicializa apigeectl para la nueva versión:

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

Comprueba cuándo se ha completado la inicialización:

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

Cuando check-ready responda "Todos los contenedores están listos", puedes probar a hacer una instalación de prueba. Ejecuta el comando apply con la marca --dry-run=true. Al hacer una prueba, puedes comprobar si hay errores antes de que se apliquen cambios al clúster:
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true
```
Si no hay errores, puede aplicar los componentes de tiempo de ejecución específicos de Apigee al clúster:
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml
```
Vuelve a ejecutar check-ready para determinar cuándo se ha completado la actualización.

Restaurar una versión anterior de una actualización

Sigue estos pasos para revertir una actualización anterior:

Limpia las tareas completadas del espacio de nombres del tiempo de ejecución híbrido, donde namespace es el espacio de nombres especificado en el archivo de anulaciones, si has especificado alguno. Si no es así, el espacio de nombres predeterminado es apigee:
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```