Apigee ハイブリッドのアップグレード

バージョン 1.2.0 へのアップグレード

Apigee ハイブリッドをバージョン 1.2.0 にアップグレードするには次のようにします。

ステップ 1: Kubernetes をアップグレードし、リリースパッケージをダウンロードする

Kubernetes プラットフォームをアップグレードする方法は次のとおりです。ヘルプが必要な場合は、プラットフォームのドキュメントをご覧ください。

プラットフォーム	アップグレード後のバージョン
GKE	1.14.x
Anthos	1.2
AKS	1.14.x

ご使用のオペレーティングシステムに対応したリリースパッケージをダウンロードします。

Mac 64 ビット:

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

Linux 64 ビット

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

Mac 32 ビット:

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

Linux 32 ビット

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

ステップ 2: インストールディレクトリを再構成する

Apigee ハイブリッドの初回インストール時に作成されたインストールのベースディレクトリを特定します。ベースディレクトリは、$APIGEEGTL_HOME ディレクトリが存在するディレクトリです。次の例では、ベースディレクトリは /Users/myhome/hybrid です。
```
echo $APIGEECTL_HOME
/Users/myhome/hybrid/apigeectl
```
ダウンロードした gzip ファイルの内容を Apigee ハイブリッドのベースディレクトリに展開します。
```
tar xvzf filename.tar.gz -C path-to-base-directory
```
cd でベースディレクトリに移動します。
デフォルトでは、tar の内容が展開されるディレクトリの名前にバージョンとプラットフォームが含まれています。例: ./apigeectl_1.2.0-f7b96a8_linux_64。
現在の apigeectl ディレクトリの名前を変更します。たとえば、現在のバージョンが 1.1.1 の場合は apigeectl ディレクトリの名前を apigeectl_1.1.1 に変更します。
新しく展開したインストールディレクトリの名前を apigeectl に変更します。これで、環境 $APIGEECTL_HOME でこのディレクトリが参照されるようになりました。

ステップ 3: オーバーライドファイルを更新する

オーバーライドファイルのコピーを作成し、ロールバックが必要になった場合に備えて古いファイルを保存してください。次の手順では、オーバーライドファイルをクラスタに適用する前に、必要な変更を行います。
注: バージョン 1.2.0 にアップグレードするには、以前のバージョンと互換性のないオーバーライドファイルを変更する必要があります。次のステップで説明するオーバーライドファイルの変更が必要です。

オーバーライドファイルを更新して、次の変更を加えます。

オーバーライドファイルに行う必要がある構成変更の概要を次に示します。完全な例は、概要に続く表に示します。envs[] プロパティは以前のバージョンから大幅に変更されています。

プロパティ envs[].hostAlias は削除され、新しいプロパティ virtualhosts.hostAliases[] に置き換えられました。
注: 以前のバージョンで環境ホストのエイリアスに単一のワイルドカード「*」を使用していた場合、バージョン 1.2.0 では、仮想ホストのエイリアス構成で完全修飾 DNS 名またはサブドメインワイルドカードを使用する必要があります。たとえば、*.mydomain.com のようになります。単一のワイルドカード文字による構成 hostAliases['*'] はサポートされなくなりました。
新しい必須構成プロパティ virtualhosts を追加する必要があります。
envs[].sslCertPath プロパティと envs[].sslKeyPath プロパティは、envs から virtualhosts に移動する必要があります。
virtualhosts.routingRules 構成スタンザを追加する必要があります。virtualhosts.routingRules プロパティは、以前の envs[].paths プロパティに代わるものです。オーバーライドファイルに envs[].paths が含まれている場合は削除する必要があります。仮想ホストの構成の詳細については、仮想ホストの構成をご覧ください。

次の表は、1.1.1 のオーバーライドファイルとバージョン 1.2.0 のファイルの違いを示したものです。この例では、バージョン 1.2.0 で行う必要がある変更の種類について説明します。

v1.1.x の構成	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

v1.1.x の構成

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

注: envs[].paths を指定しない場合（上記の表を参照）、アップグレードで virtualhosts[].routingRules.paths[] プロパティを省略できます。デフォルトでは、パスは「/」です。たとえば、デフォルトのパス「/」を使用する場合は、次のように virtualhosts[].routingRules を構成できます。

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

ステップ 4: アップグレードをクラスタに適用する

バージョン 1.1.1 のインストールで Apigee Connect を有効にしていた場合は、そのデプロイを削除する必要があります。
1. まず、Apigee Deployment を一覧表示します。
```
kubectl -n namespace get ad
```
2. Apigee Connect のデプロイを削除します。
```
kubectl -n namespace delete ad apigee-connect-name
```
Pod を一覧表示します。
```
kubectl get pods -n namespace
```
クラスタから apigee-cps-setup Pod を削除します。前のコマンドで返された組織名を含む Pod のフルネームを使用します。次に例を示します。
```
kubectl -n namespace delete pod apigee-cps-setup-org
```
同じ名前空間の apigee-cps-create-user Pod を削除します。
```
kubectl -n namespace delete pod apigee-cps-create-user
```
ハイブリッドのランタイム名前空間の完了済みジョブをクリーンアップします。ここで、名前空間を指定した場合、namespace はオーバーライドファイルで指定した名前空間になります。指定しない場合、デフォルトの名前空間は apigee です。
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

apigee-system 名前空間の完了済みジョブをクリーンアップします。

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

istio-system 名前空間の完了済みジョブをクリーンアップします。

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

cd で ./hybrid-files ディレクトリに移動します。

新しいバージョンの apigeectl を初期化します。

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

初期化が完了したかどうかを確認します。

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

check-ready から「All containers are ready」と返ってきたら、「ドライラン」インストールを試すことができます。--dry-run=true フラグを指定して apply コマンドを実行します。ドライランを行うと、クラスタが変更される前にエラーがないかどうかを確認できます。
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true
```
エラーがなければ、Apigee 固有のランタイムコンポーネントをクラスタに適用できます。
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml
```
check-ready を再実行して、アップグレードが完了したことを確認します。

アップグレードのロールバック

以前のアップグレードをロールバックする手順は次のとおりです。

ハイブリッドのランタイム名前空間の完了済みジョブをクリーンアップします。ここで、名前空間を指定した場合、namespace はオーバーライドファイルで指定した名前空間になります。指定しない場合、デフォルトの名前空間は apigee です。
```
kubectl delete job -n namespace \
  $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```