バージョン 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: オーバーライド ファイルを更新する
- オーバーライド ファイルのコピーを作成し、ロールバックが必要になった場合に備えて古いファイルを保存してください。次の手順では、オーバーライド ファイルをクラスタに適用する前に、必要な変更を行います。
オーバーライド ファイルを更新して、次の変更を加えます。
オーバーライド ファイルに行う必要がある構成変更の概要を次に示します。完全な例は、概要に続く表に示します。
envs[]
プロパティは以前のバージョンから大幅に変更されています。- プロパティ
envs[].hostAlias
は削除され、新しいプロパティvirtualhosts.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
- プロパティ
ステップ 4: アップグレードをクラスタに適用する
- バージョン 1.1.1 のインストールで Apigee Connect を有効にしていた場合は、そのデプロイを削除する必要があります。
- まず、Apigee Deployment を一覧表示します。
kubectl -n namespace get ad
- Apigee Connect のデプロイを削除します。
kubectl -n namespace delete ad apigee-connect-name
- まず、Apigee Deployment を一覧表示します。
- 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}')
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}')
- Apigee 演算子のデプロイを削除します。このオペレーションは、ランタイム トラフィックには影響しません。
kubectl -n apigee-system delete deployment apigee-controller-manager
- 元のバージョンの
apigeectl
を含むディレクトリを指すように$APIGEECTL_HOME
変数を変更します。次に例を示します。export APIGEECTL_HOME=path-to-original-apigeectl-directory
- ロールバックするインストールのルート ディレクトリで
apigeectl init
を実行し、続いてapigeectl apply
を実行します。ロールバックするバージョンの元のオーバーライド ファイルを必ず使用してください。$APIGEECTL_HOME
/apigeectl init -f overrides/original-overrides.yaml$APIGEECTL_HOME
/apigeectl apply -f overrides/original-overrides.yaml