Apigee は、Edge for Private Cloud をバージョン 4.51.00、4.52.00、4.52.01 からバージョン 4.52.02 に直接アップグレードすることをサポートしています。このページでは、このようなアップグレードを行う方法について説明します。
更新を行えるユーザー
更新を行うユーザーは、最初に Edge をインストールしたユーザーまたは root ユーザーである必要があります。
Edge RPM をインストールした後は、すべてのユーザーがそれを構成できます。
更新する必要のあるコンポーネント
すべての Edge コンポーネントを更新する必要があります。Edge では、コンポーネントのバージョンが混在する設定はサポートされません。
更新の前提条件
Apigee Edge をアップグレードする前に、次の前提条件を確認してください。
- すべてのノードをバックアップする
安全上の理由から、更新する前にすべてのノードの完全なバックアップを行うことをおすすめします。現在の Edge バージョンのバックアップ手順に沿ってください。これにより、新しいバージョンへの更新が適切に機能しない場合に備えてバックアップ計画を立てることができます。バックアップの詳細については、バックアップと復元をご覧ください。
- Edge が動作していることを確認する
次のコマンドを使用して、更新中に Edge が動作していることを確認します。/opt/apigee/apigee-service/bin/apigee-all status
- Cassandra の圧縮戦略が
LeveledCompactionStrategyであることを確認する
現在のバージョンに応じて、Cassandra の圧縮戦略に必要な変更を行います。次の手順に沿って操作し、メインのアップグレード手順に戻ります。- バージョン 4.51.00 からアップグレードする場合は、v4.51.00 の Cassandra 圧縮戦略に関するドキュメントをご覧ください。
- バージョン 4.52.00 からアップグレードする場合は、v4.52.00 の Cassandra 圧縮戦略に関するドキュメントをご覧ください。
- バージョン 4.52.01 からアップグレードする場合は、v4.52.01 の Cassandra 圧縮戦略に関するドキュメントを参照してください。
アップグレードで考慮すべき特別な手順
Edge for Private Cloud 4.52.02 にアップグレードするには、特定のソフトウェアをアップグレードするための特定の手順の実行を検討してください。必要な手順は現在のバージョンによって異なります。補足の手順が必要なソフトウェアについては、以下の表を参照し、それぞれの詳細な手順に沿って操作してください。必要なタスクを完了したら、メインのアップグレード手順に戻ってアップグレード プロセスを続行します。
| 現在のバージョン | 4.52.02 へのアップグレードに特別な手順が必要なソフトウェア |
|---|---|
| 4.52.01 | Cassandra |
| 4.52.00 | Zookeeper、Cassandra、Qpid |
| 4.51.00 | Zookeeper、Postgres、Cassandra、Qpid |
バージョンに基づいて必要な手順を実行したら、メインのアップグレード手順に戻って続行します。
プロパティ設定の自動伝播
/opt/apigee/customer/application にある .properties ファイルを編集してプロパティを設定した場合、それらの値は更新後も保持されます。
Zookeeper 3.8.3 にアップグレードする
Edge for Private Cloud 4.52.02 には、Zookeeper のアップグレードは含まれていません。ただし、4.52.01 より前のバージョンからアップグレードする場合は、以下に示す Zookeeper のアップグレード手順に沿って操作する必要があります。
- Edge for Private Cloud バージョン 4.51.00 または 4.52.00 からアップグレードする場合は、Zookeeper 3.8.3 へのアップグレードが必要の手順を参照して、Zookeeper をアップグレードします。
- Edge for Private Cloud バージョン 4.52.01 からアップグレードする場合は、すでに Zookeeper バージョン 3.8.3 を使用しているため、Zookeeper のアップグレードに関する特別な手順を行う必要はありません。
Postgres 14 にアップグレードする
- Edge for Private Cloud 4.51.00 から 4.52.02 にアップグレードする場合は、Edge for Private Cloud 4.52.02 に Postgres のアップグレードが含まれていなくても、Postgres をアップグレードする手順に沿って操作する必要があります。Edge for Private Cloud 4.51.00 から 4.52.02 にアップグレードするには、Postgres の追加のアップグレード手順が必要です。Postgres 14 へのアップグレードが必須セクションをご覧ください。
- Edge for Private Cloud 4.52.00 または 4.52.01 から 4.52.02 にアップグレードする場合は、Postgres の追加のアップグレード手順は必要ありません。
Cassandra 3.11.16 にアップグレードする
Apigee Edge for Private Cloud 4.52.02 には、Cassandra のバージョン 3.11.16 へのアップグレードが含まれています。Cassandra は Apigee の重要なコンポーネントです。このアップグレードには、Cassandra のクエリと書き込みに使用されるさまざまなランタイム コンポーネントと管理コンポーネントのドライバ ソフトウェアの更新も含まれています。
これはメジャー アップグレードであるため、新しいバージョンで最適なパフォーマンスを確保するために、Cassandra の Apigee のデータモデルに特定の変更が必要でした。これらの変更は最小限ですが、アップグレード プロセスでは、アップグレードが開始されると特定の管理 API が中断されます。一般的に中断される管理 API については、以下の関連セクションをご覧ください。
また、アップグレード プロセスでは、アップグレードされるデータセンター内のランタイム プロキシ フローと管理 API の大部分が中断されます。このような中断を最小限に抑えるため、アップグレードするデータセンターからランタイム トラフィックと管理トラフィックを分離することが重要です。詳細については、以下の単一データセンターと複数データセンターのセクションをご覧ください。
デベロッパー ポータル - API のドキュメント作成
Apigee Drupal デベロッパー ポータルには、API のドキュメント作成に役立つさまざまな機能が用意されています。Drupal 7 ベースのデベロッパー ポータルの使用から移行することをおすすめしますが、まだ使用していて SmartDocs 機能を利用している場合は、 SmartDocs API の使用に関するドキュメントが適用されます。新しいバージョンのデベロッパー ポータルを使用している場合、このアップグレード中に API ドキュメントに影響はありません。
Apigee をバージョン 4.52.02 にアップグレードすると、Drupal 7 デベロッパー ポータルの SmartDocs 機能を使用して作成された API モデルは、新しいバージョンに自動的に移行されません。デベロッパー ポータルを使用して各モデルを手動でエクスポートし、アップグレードの完了後に再度インポートする必要があります。
以下の用語を使用します
ランタイム: ランタイムには、ランタイム プロキシ トラフィックの処理が含まれます。これには、既存のプロキシのランタイム API リクエストを効果的に処理するために Router と Message Processor によって実行されるすべてのオペレーションが含まれます。ただし、新しいプロキシやプロキシの新しいリビジョンのデプロイは含まれません。
管理: 管理には、Apigee Edge システムの管理が含まれます。これには、デプロイ、アプリ、プロダクト、ターゲット サーバー、キーストアなどの変更が含まれますが、これらに限定されません。すべての管理 API（および Apigee UI やデベロッパー ポータルなどのクライアント）がこの範囲に含まれます。
このアップグレード中、更新が実行されているリージョンまたはデータセンター（DC）でランタイム トラフィックと管理トラフィックが影響を受けます。更新されるデータセンターに関係なく、すべてのデータセンターで特定の管理 API に影響があります。各ステップの後に、この影響が記載されています。
以下の各ステップでは、アップグレード手順のさまざまな段階でランタイムと管理の状態がどのように変化するかを説明します。
アップグレード戦略
複数のデータセンター
トラフィックの継続性を確保し、ダウンタイムを回避するため、アップグレードは一度に 1 つのデータセンターで実行する必要があります。DC をアップグレードする前に、トラフィックを他の機能している DC に転送する必要があります。
単一データセンター
単一のデータセンター設定の場合、アップグレード手順は、ランタイム トラフィックと特定の管理 API に大きな影響を与えます。単一データセンターの設定では、次のオプションを使用できます。
- 既存のデータセンターに加えて データセンターを追加して、Edge for Private Cloud クラスタを一時的なデータセンターに拡張し、アップグレード中のトラフィックを処理します。アップグレード プロセスが完了したら、データセンターの 1 つを廃止します。
- 追加のデータセンターに拡張できない場合は、ダウンタイムに備え、トラフィックの少ない時間帯にアップグレードをスケジュールして、管理 API とランタイム トラフィックへの影響を最小限に抑えます。
ランタイム トラフィックと管理 API への影響を回避するため、追加のデータセンターに拡張することをおすすめします。アップグレード中、アップグレードされるデータセンターに影響する分野は次のとおりです（ただし、これらに限定されません）。
- OAuth トークンを更新するランタイム API
- Access Entity ポリシーを使用する Runtime API
- デベロッパー アプリを一覧表示する管理 API
- プロダクトを一覧表示する管理 API
上記の影響は、すべてのデータセンターがアップグレードされるまで、すべてのデータセンターで機能しなくなる特定の管理 API に加えて発生します。このような管理 API は、以降のセクションの手順に記載されています。
ロールバック - 概要
- ロールバック中の影響
Cassandra 3.11.x から 2.1.x へのロールバックは、ロールバックが実行されているデータセンター（DC）内のランタイム トラフィックと管理トラフィックの両方に影響します。また、現在ロールバックされている DC に関係なく、特定の管理 API でデータセンター全体にわたって中断が発生する可能性があります。
- DC by DC ロールバック アプローチに従う
サービス継続性を維持し、ダウンタイムを防ぐため、ロールバックは一度に 1 つのデータセンターで実行する必要があります。特定の DC でロールバックを開始する前に、アプリケーション トラフィックが完全に運用可能な別のデータセンターに再ルーティングされていることを確認します。
- 部分的にアップグレードされたクラスタのロールバック
少なくとも 1 つのデータセンターが古いバージョンの Cassandra（2.1.22）で完全に動作している場合は、完全に機能している Cassandra 2.1.X DC から再構築を実行することで、アップグレードされた他の DC をロールバックできます。
- クラスタ全体のロールバック
Cassandra クラスタ全体がアップグレードされ、ロールバックが必要な場合は、バックアップまたは VM スナップショットを使用して実行する必要があります。このアプローチは複雑で、一時的なダウンタイムやデータ損失が発生する可能性があります。
- アップグレード前の考慮事項
アップグレードを試みる前に、ロールバック手順をよく理解しておくことが重要です。適切なロールバック パスを確保するには、アップグレード時にロールバックのニュアンスを考慮することが重要です。
単一のデータセンターでクラスタをロールバックする
Cassandra をバージョン 2.1.x から 3.11.x にアップグレードすると、ランタイム トラフィックと特定の管理 API に大きな影響を与える可能性があります。これらの影響はロールバック時にも発生し、ダウンタイムやデータ損失につながる可能性があります。
本番環境のワークロードでは、アップグレードの前に新しいデータセンターをプロビジョニングすることを強くおすすめします。これにより、データ損失や API トラフィックの中断を伴わない、より安全なロールバック パスが可能になります。アップグレードが正常に完了したら、追加のデータセンターを廃止できます。
新しいデータセンターの追加が実現不可能で、ロールバック機能が引き続き必要な場合は、アップグレードの前に信頼性の高いバックアップが作成されていることを確認してください。バックアップから Cassandra 2.1.x を復元することは可能ですが、この方法ではサービスのダウンタイムが発生し、データが失われる可能性があります。
複数のデータセンターがあるクラスタをロールバックする
複数のデータセンターのロールバックは、データセンター単位（DC 単位）のアプローチで行われます。このアプローチでは、ロールバックされるデータセンターからのトラフィックが他の機能的なデータセンターにリダイレクトされ、Cassandra、管理サーバー、ランタイム ノードの制御された分離されたロールバック プロセスが保証され、トラフィックの中断が回避されます。
詳細については、Cassandra 3.11.16 の更新をロールバックするセクションをご覧ください。
ステップ 0: 開始状態
- Zookeeper、Postgres、LDAP コンポーネントはすでに 4.52.02 バージョンにアップグレードされています。プライベート クラウド クラスタ用の Edge が安定して動作している。ロールバックが必要な場合、クラスタはこの状態にロールバックされます。
- Apigee で Cassandra がバージョン 2.1.22 で実行されています。
- Edge コンポーネント:
- 古い thrift プロトコルを介して Cassandra と通信する管理サーバー。
- 古い thrift プロトコルを介して Cassandra と通信するランタイム サーバー（Message Processor と Router）。
| このステージのランタイム状態 | このステージの管理状態 |
|---|---|
| ランタイムが完全に機能している | 管理機能が完全に機能している |
ステップ 1: アップグレードの準備をする
以下の手順は、コンポーネントのアップグレードを有効にするための Apigee の標準構成ファイルなど、通常作成する標準ファイルに加えて行うものです。
- LeveledCompactionStrategy を使用するように Cassandra を変更します。
- Apigee を使用して Cassandra をバックアップします。
- Cassandra ノードの VM スナップショットを作成します（可能な場合）。
-
各 Cassandra ノードの
/opt/apigee/apigee-cassandra/cass_upgrade.confに、次の内容で Cassandra アップグレード構成ファイルを作成します。# IP Address of node HOSTIP=10.0.0.1 # Username for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication. CASS_USERNAME=<cassuser> # Password for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication. CASS_PASSWORD=<casspass> # Port for connecting to Cassandra via thrift. Optional. Defaults to 9160 if skipped. CASS_PORT=9160 # Port for connecting to Cassandra via CQL. Optional. Defaults to 9042 if skipped. CASS_CQL_PORT=9042 # Directory to be used by Cassandra upgrade scripts. Optional. Defaults to /tmp/cass_upgrade_scripts if skipped. # Note that if upgrade is successful, this directory is deleted via root user - so provide a directory accordingly. CASS_TMP_DIR=/tmp/cass_upgrade_scripts/opt/apigee/apigee-cassandra/cass_upgrade.confでファイルを作成できない場合は、各 Cassandra ノードに同じ内容の/opt/silent.confファイルを作成します。 - Apigee Drupal 7 デベロッパー ポータルの SmartDocs 機能を使用している場合は、デベロッパー ポータル UI から JSON 形式でダウンロードして、各モデルのエクスポートを作成します。これらのモデルは、管理サーバーの更新後に Apigee にインポートし直す必要があります。
- ポート 9160 と 9042 がすべての Edge コンポーネントから Cassandra ノードにアクセスできることを確認します（まだ存在しない場合）。詳細については、ポートの要件をご覧ください。
ステップ 2: 最初のデータセンターからトラフィックをリダイレクトする
- 最初のデータセンターからのランタイム トラフィックと管理トラフィックをブロックします。
- すべてのランタイム トラフィックと管理 API を他の機能的なデータセンターにリダイレクトします。
- ランタイム トラフィックと管理トラフィックが他の DC で正常に処理されていることを確認します。
ステップ 3: 最初のデータセンター内のすべての Cassandra ノードをアップグレードする
-
データセンター内のすべての Cassandra ノードを 1 つずつアップグレードします。各ノードで次のコマンドを 1 つずつ実行します。
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
-
ノードが更新されたら、ノードで次のコマンドを実行して、先に進む前にいくつかの検証を実行します。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
Cassandra version is verified - [cqlsh 5.0.1 | Cassandra 3.11.16 | CQL spec 3.4.4 | Native protocol v3] Metadata is verified
- アップグレードが完了したら、各 Cassandra ノードで次の
post_upgradeコマンドを 1 つずつ実行します。/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
| このステージのランタイム状態 | このステージの管理状態 |
|---|---|
|
|
ステップ 4: 最初のデータセンターのすべての管理ノードをアップグレードする
データセンター内のすべての管理ノードをアップグレードします。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
| このステージのランタイム状態 | このステージの管理状態 |
|---|---|
|
|
ステップ 5: 最初のデータセンターのすべてのランタイム ノードをアップグレードする
データセンター内のすべての Router ノードと Message Processor ノードを 1 つずつアップグレードします。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
| このステージのランタイム状態 | このステージの管理状態 |
|---|---|
|
|
ステップ 6: トラフィックを最初のデータセンターにリダイレクトする
- 最初のデータセンターが Cassandra、ランタイム コンポーネント、管理サーバーでアップグレードされたら、最初のデータセンターへのランタイム トラフィックと管理トラフィックを再度有効にします。
- DC 間でランタイム トラフィックと管理トラフィックが正常に流れるようにします。
ステップ 7: 他のデータセンターをアップグレードする
ステップ 1～ステップ 6 を残りのデータセンターで 1 つずつ繰り返します。データセンターからトラフィックをリダイレクトし、Apigee ソフトウェアを更新して、データセンターでトラフィックを再度有効にします。
ステップ 8: すべての管理ノードでアップグレード手順を再実行する
データセンターのすべての管理ノードで、次のアップグレード コマンドを再実行します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
ステップ 9 - [省略可] 以前にエクスポートしたスマートドキュメントをインポートする
すべての管理サーバーがアップグレードされたら、ステップ 1 でエクスポートしたスマートドキュメント モデルをインポートできます。この手順は後で行うこともできます。
この操作が必要なのは、Drupal 7 ベースのデベロッパー ポータルを使用し、SmartDocs 機能を使用している場合のみです。
| このステージのランタイム状態 | このステージの管理状態 |
|---|---|
| ランタイムが完全に機能している | 管理機能が完全に機能している |
ステップ 10 - 未使用のテーブルを削除する
次のコマンドを実行して、古い未使用のテーブルを Cassandra クラスタから削除します。このコマンドを実行するまで、Cassandra の一部の機能（新しい認証の設定など）は使用できません（古い認証メカニズムは引き続き機能します）。このコマンドは、クラスタ内の 1 つのノードでのみ実行できます。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile
ステップ 11 - Private Cloud 4.52.02 の残りの Edge コンポーネントとその他のコンポーネントをすべてアップグレードする
すべてのリージョンに残っている edge-qpid-server ノードと edge-postgres-server ノードを 1 つずつアップグレードします。
この段階で、Edge for Private Cloud 4.52.01 より前のバージョンからアップグレードする場合は、以下のように Qpid、Postgres のアップグレードに追加の手順を行い、これらの手順に従って残りのコンポーネントをアップグレードします。
Qpid J-Broker にアップグレードする
Edge for Private Cloud 4.52.02 には Qpid のアップグレードは含まれていませんが、4.52.01 より前のバージョンからアップグレードする場合は、手順に沿って QPID をアップグレードする必要があります。
- Edge for Private Cloud 4.51.00 または 4.52.00 から 4.52.02 にアップグレードする場合は、Qpid のアップグレード手順を追加で実行する必要があります。バージョン 4.51.00 または 4.52.00 から 4.52.02 にアップグレードする場合は、Qpid をアップグレードするセクションを参照してください。
- Edge for Private Cloud 4.52.01 から 4.52.02 にアップグレードする場合は、すでに最新バージョンの Qpid Broker を使用しているため、追加の Qpidupgrade 手順は必要ありません。
新しい Edge UI
このセクションでは、Edge UI に関する注意事項を示します。詳細については、Private Cloud 用の新しい Edge UI をご覧ください。
Edge UI をインストールする
初期インストールが完了した後、Edge UI をインストールすることをおすすめします。Edge UI は、Apigee Edge for Private Cloud のデベロッパーと管理者向けの強化されたユーザー インターフェースです。
Edge UI では、Basic 認証を無効にし、SAML や LDAP などの IDP を使用する必要があります。
詳細については、新しい Edge UI をインストールするをご覧ください。
Edge UI を更新する
Edge UI コンポーネントを更新するには、アップグレード元の Edge for Private Cloud のバージョンを考慮してください。
- 4.51.00 から 4.52.00（新しい Edge UI がすでにインストールされている場合）:
edge-management-uiコンポーネントにはこのセクションのアップグレード手順を使用してください。
Apigee mTLS での更新
Apigee mTLS を更新する手順は次のとおりです。
更新のロールバック
更新に失敗した場合は、問題の解決を試みた後で update.sh を再び実行できます。更新は複数回実行でき、最後に終了したところから続行されます。
失敗した結果、前のバージョンへのロールバックが必要になった場合の詳しい手順については、4.52.00 のロールバックをご覧ください。
更新情報のロギング
デフォルトでは、update.sh ユーティリティからのログ情報は次のファイルに書き込まれます。
/opt/apigee/var/log/apigee-setup/update.log
update.sh ユーティリティを実行しているユーザーにこのディレクトリへのアクセス権がない場合は、/tmp ディレクトリの update_username.log というファイルにログが書き込まれます。
/tmp へのアクセス権がない場合、update.sh ユーティリティは失敗します。
ゼロダウンタイムでの更新
ゼロダウンタイム更新（つまりローリング アップデート）により、Edge をダウンさせることなく、インストール済みの Edge を更新できます。
ゼロダウンタイム更新は、ノードが 5 つ以上の構成でのみ利用可能です。
ゼロダウンタイムでアップグレードする場合に重要となる点は、各 Router をロードバランサから一度に 1 台ずつ削除することです。削除した Router と、その同じマシンにあるすべてのコンポーネントを更新してから、Router をロードバランサに再び追加します。
- マシンの更新順序に記載された正しい順序でマシンを更新してください。
- Router を更新するときは、任意の Router を 1 つ選択し、サーバー（Message Processor または Router）のネットワーク到達性の有効化 / 無効化の説明に従ってその Router を到達不能な状態にします。
- 選択した Router と、その同じマシンにある他のすべての Edge コンポーネントを更新します。すべての Edge 構成で、Router と Message Processor は同じノードにあります。
- Router を到達可能な状態に戻します。
- 残りの Router に対し、2 ～ 4 の手順を繰り返します。
- インストール中の残りのすべてのマシンで更新を続行します。
更新の前後で次の点に注意してください。
- Router と Message Processor の共存ノード:
- 更新前 - 次のことを行います。
- Router を到達不能な状態にします。
- Message Processor を到達不能な状態にします。
- 更新後 - 次の作業を行います。
- Message Processor を到達可能な状態にします。
- Router を到達可能な状態にします。
- 更新前 - 次のことを行います。
- Router 単独のノード:
- 更新前に、Router を到達不能な状態にします。
- 更新後に、Router を到達可能な状態にします。
- Message Processor 単独のノード:
サイレント構成ファイルを使用する
サイレント構成ファイルを更新コマンドに渡す必要があります。サイレント構成ファイルは、Edge 4.50.00 または 4.51.00 のインストールに使用したものと同じである必要があります。
外部インターネット接続があるノードで 4.52.02 に更新する
ノードで Edge コンポーネントを更新する手順は次のとおりです。
- Cassandra の修復オペレーションを行う
cronジョブが設定されている場合は、更新が完了するまでそれらのジョブを無効にします。 - ノードに root としてログインし、Edge RPM をインストールします。
yum-utilsとyum-plugin-prioritiesをインストールします。sudo yum install yum-utils
sudo yum install yum-plugin-priorities- Edge apigee-setup ユーティリティのインストールの説明に従って、SELinux を無効にします。
- Oracle 7.x にインストールする場合は、次のコマンドを実行します。
sudo yum-config-manager --enable ol7_optional_latest
- AWS にインストールする場合は、次の
yum-configure-managerコマンドを実行します。yum update rh-amazon-rhui-client.noarch
sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional 現在 Edge 4.51.00 を使用している場合:
- Edge
bootstrap_4.52.02.shファイルを/tmp/bootstrap_4.52.02.shにダウンロードします。curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
- 次のコマンドを実行して、Edge 4.52.02 の
apigee-serviceユーティリティと依存関係をインストールします。sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
ここで、uName:pWord は Apigee から取得したユーザー名とパスワードです。pWord を省略すると、パスワードの入力を求められます。
デフォルトでは、Java 1.8 がインストールされているかどうかが検査されます。インストールされていない場合は自動的にインストールされます。
JAVA_FIXオプションを使用して、Java インストールの処理方法を指定できます。JAVA_FIXの有効な値は次のとおりです。I: OpenJDK 1.8 をインストールします（デフォルト）。C: Java をインストールせずに続行します。Q: 終了します。この場合、Java を自分でインストールする必要があります。
- 次の例のように、
apigee-serviceを使用してapigee-setupユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
- 次の例のように、Management Server で
apigee-validateユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
- 次の例のように、Management Server で
apigee-provisionユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
- 次のコマンドを使用して、各ノードで
updateユーティリティを実行します。/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
マシンの更新順序に記載された順序でこれを行ってください。
ここで
- component は更新する Edge コンポーネントです。有効な値は次のとおりです。
cs: Cassandraedge: Edge UI 以外のすべての Edge コンポーネント。これには、Management Server、Message Processor、Router、Qpid Server、Postgres Server が含まれます。ldap: OpenLDAPps: postgresqlqpid: qpiddsso: Apigee SSO（SSO がインストールされている場合）ue: 新しい Edge UIui: 従来の Edge UIzk: Zookeeper
- configFile は、4.50.00 または 4.51.00 のインストール時に Edge コンポーネントの定義に使用した構成ファイルです。
component を「all」に設定すると、すべてのコンポーネントに対して
update.shを実行できますが、これが可能なのは Edge オールインワン（AIO）インストール プロファイルがある場合のみです。次に例を示します。/opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
- component は更新する Edge コンポーネントです。有効な値は次のとおりです。
- Edge UI コンポーネントを実行するすべてのノードで Edge UI コンポーネントを再起動します（まだ再起動していない場合）。
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
- インストールのテストの説明に従って Management Server で
apigee-validateユーティリティを実行し、更新をテストします。
- Edge
後で更新をロールバックすることにした場合は、4.52.02 のロールバックの手順に沿ってください。
ローカル リポジトリから 4.52.02 に更新する
Edge ノードがファイアウォールの背後にあるか、インターネット経由での Apigee リポジトリへのアクセスが禁止されている場合は、Apigee リポジトリのローカル リポジトリ（ミラー）から更新を行うことができます。#heading
ローカル Edge リポジトリを作成した後、Edge をローカル リポジトリから更新する方法は 2 通りあります。
- リポジトリの .tar ファイルを作成してそれをノードにコピーし、.tar ファイルから Edge を更新します。
- ローカル リポジトリを持つノードにウェブサーバーをインストールし、他のノードからアクセスできるようにします。Apigee から提供されているウェブサーバーは Nginx ですが、他のウェブサーバーを使用してもかまいません。
ローカルの 4.52.02 リポジトリから更新するには:
- Edge apigee-setup ユーティリティのインストールの「ローカルに Apigee リポジトリを作成する」の手順で 4.52.02 リポジトリをローカルに作成します。
- .tar ファイルから apigee-service をインストールするには:
- ローカル リポジトリが存在するノードで次のコマンドを使用し、ローカル リポジトリを
/opt/apigee/data/apigee-mirror/apigee-4.52.02.tar.gzという名前の単一の .tar ファイルにパッケージ化します。/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
- Edge を更新する対象のノードに .tar ファイルをコピーします。たとえば、新しいノードの
/tmpディレクトリにコピーします。 - 新しいノードで、.tar ファイルを
/tmpディレクトリに解凍します。tar -xzf apigee-4.52.02.tar.gz
このコマンドにより、.tar ファイルが存在するディレクトリの中に
reposという新しいディレクトリが作成されます。例:/tmp/repos /tmp/reposから Edgeapigee-serviceユーティリティと依存関係をインストールします。sudo bash /tmp/repos/bootstrap_4.52.02.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
このコマンドには repos ディレクトリへのパスが含まれています。
- ローカル リポジトリが存在するノードで次のコマンドを使用し、ローカル リポジトリを
- Nginx ウェブサーバーを使用して apigee-service をインストールするには:
- Edge apigee-setup ユーティリティのインストールの「Nginx ウェブサーバーを使用してリポジトリからインストールする」の手順に沿って、Nginx ウェブサーバーを構成します。
- リモートノードで、Edge
bootstrap_4.52.02.shファイルを/tmp/bootstrap_4.52.02.shにダウンロードします。/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
ここで、uName:pWord は上記の手順でリポジトリに設定したユーザー名とパスワード、remoteRepo はリポジトリ ノードの IP アドレスまたは DNS 名です。
- リモートノードで、Edge
apigee-setupユーティリティと依存関係をインストールします。sudo bash /tmp/bootstrap_4.52.02.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
ここで、uName:pWord はリポジトリのユーザー名とパスワードです。
- 次の例のように、
apigee-serviceを使用してapigee-setupユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
- 次の例のように、Management Server で
apigee-validateユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
- 次の例のように、Management Server で
apigee-provisionユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
- マシンの更新順序に記載された順に、各ノードで
updateユーティリティを実行します。/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
ここで
- component は更新する Edge コンポーネントです。通常は次のコンポーネントを更新します。
cs: Cassandraedge: Edge UI 以外のすべての Edge コンポーネント。これには、Management Server、Message Processor、Router、Qpid Server、Postgres Server が含まれます。ldap: OpenLDAPps: postgresqlqpid: qpiddsso: Apigee SSO（SSO がインストールされている場合）ue新しい Edge UIui: 従来の Edge UIzk: Zookeeper
- configFile は、4.50.00 または 4.51.00 のインストール時に Edge コンポーネントの定義に使用した構成ファイルです。
component を「all」に設定すると、すべてのコンポーネントに対して
update.shを実行できますが、これが可能なのは Edge オールインワン（AIO）インストール プロファイルがある場合のみです。次に例を示します。/opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
- component は更新する Edge コンポーネントです。通常は次のコンポーネントを更新します。
- UI コンポーネントが実行されているすべてのノードで UI コンポーネントを再起動します（まだ再起動していない場合）。
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
- インストールのテストの説明に従って Management Server で
apigee-validateユーティリティを実行し、更新をテストします。
後で更新をロールバックすることにした場合は、4.52.02 のロールバックの手順に沿ってください。
マシンの更新順序 - 4.51.00、4.52.00、4.52.01 からのアップグレード
Edge 構成内のマシンの更新順序は重要です。
- 他のすべてのコンポーネントをアップグレードする前に、データセンター全体のすべての ZooKeeper ノードを更新する必要があります。Edge Private Cloud 4.51.00 または 4.52.00 からアップグレードする場合は、ZooKeeper をアップグレードするための追加の手順も行う必要があります。
- すべてのデータセンターで Postgresql を更新する必要があります。Edge Private Cloud 4.51.00 からアップグレードする場合は、Postgres をアップグレードするための追加の手順も行う必要があります。
- すべてのデータセンターで LDAP ノードを更新する必要があります。
- すべてのデータセンターがアップグレードされるまで、すべての Cassandra、Management Server、Message Processor、Router ノードを一度に 1 つのデータセンターずつ更新する必要があります。
- すべてのデータセンターで
edge-qpid-serverコンポーネントとedge-postgres-serverコンポーネントを更新する必要があります。 - すべてのデータセンターで Qpid ノードをアップグレードする必要があります。Edge Private Cloud 4.51.00 または 4.52.00 からアップグレードする場合は、Qpid をアップグレードするための追加の手順も行う必要があります。
- すべてのデータセンターで Edge UI、新しい Edge UI、SSO ノードを更新します。
- Monetization の更新に関して特別な手順はありません。これは -c edge オプションを指定した場合に更新されます。
1 ノード スタンドアロン構成のアップグレード
1 ノード スタンドアロン構成を 4.52.02 にアップグレードするには:- すべてのコンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
- （
apigee-adminapiがインストールされている場合）apigee-adminapiユーティリティを更新しました。/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
2 ノード 単体アップグレード
2 ノード スタンドアロン構成では、次のコンポーネントを更新します。
Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。
- マシン 1 の Zookeeper を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
- マシン 2 の Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- マシン 1 の LDAP を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
- マシン 1 の Cassandra を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
- マシン 1、2 の Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- マシン 2 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- マシン 1 の UI を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
apigee-adminapiがインストールされている場合は、マシン 1 のapigee-adminapiユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
- Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。
- マシン 1 の Edge UI コンポーネントを再起動します。
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
5 ノード構成のアップグレード
5 ノード構成では、次のコンポーネントを更新します。
Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。
- マシン 1、2、3 の ZooKeeper を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
- マシン 4 の Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- マシン 5 の Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- マシン 1 の LDAP を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
- マシン 1、2、3 の Cassandra を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
- マシン 1、2、3、4、5 の Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- マシン 4 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- マシン 5 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- Edge UI を更新します。
- 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の
uiコンポーネントを更新します。/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
- 新しい Edge UI: 新しい Edge UI をインストールした場合は、該当するマシン（マシン 1 ではない場合があります）の
ueコンポーネントを更新します。/opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
- 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の
apigee-adminapiがインストールされている場合は、マシン 1 のapigee-adminapiユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
- Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。
- UI コンポーネントを再起動します。
- 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の
edge-uiコンポーネントを再起動します。/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
- 新しい Edge UI: 新しい Edge UI をインストールした場合は、該当するマシン（マシン 1 ではない場合があります）の
edge-management-uiコンポーネントを再起動します。/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
- 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の
9 ノードクラスタ構成のアップグレード
9 ノードクラスタ構成では、次のコンポーネントを更新します。
Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。
- マシン 1、2、3 の ZooKeeper を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
- マシン 8 の Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- マシン 9 の Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- マシン 1 の LDAP を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
- マシン 1、2、3 の Cassandra を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
- マシン 1、4、5、6、7、8、9 の順に Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- マシン 6、7 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- マシン 1 の新しい UI（
ue）または従来の UI（ui）を更新します。/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
apigee-adminapiがインストールされている場合は、マシン 1 のapigee-adminapiユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
- Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。
- UI コンポーネントを再起動します。
- 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の
edge-uiコンポーネントを再起動します。/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
- 新しい Edge UI: 新しい Edge UI をインストールした場合は、該当するマシン（マシン 1 ではない場合があります）の
edge-management-uiコンポーネントを再起動します。/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
- 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の
13 ノードクラスタ構成のアップグレード
13 ノードクラスタ構成では、次のコンポーネントを更新します。
Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。
- マシン 1、2、3 の ZooKeeper を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
- マシン 8 の Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- マシン 9 の Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- マシン 4、5 の LDAP を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
- マシン 1、2、3 の Cassandra を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
- マシン 6、7、10、11、12、13、8、9 の順に Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- マシン 12、13 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- マシン 6 と 7 の新しい UI（
ue）または従来の UI（ui）を更新します。/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
apigee-adminapiがインストールされている場合は、マシン 6、7 のapigee-adminapiユーティリティを更新します。/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
- Apigee SSO がインストールされている場合は、マシン 6、7 の Apigee SSO を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。
- UI コンポーネントを再起動します。
- 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 6 と 7 で
edge-uiコンポーネントを再起動します。/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
- 新しい Edge UI: 新しい Edge UI をインストールした場合は、マシン 6 と 7 で
edge-management-uiコンポーネントを再起動します。/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
- 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 6 と 7 で
12 ノードクラスタ構成のアップグレード
12 ノードクラスタ構成では、次のコンポーネントを更新します。
Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。
両方の DC のマシン 1、2、3、7、8、9 で ZooKeeper を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
- 両方の DC のマシン 6 と 12 で Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- 両方の DC でマシン 1、7 の LDAP を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
DC-1 のトラフィックをブロックし、すべてのトラフィックが他の DC-2 に転送されることを確認します。
- DC-1 のマシン 1、2、3 で Cassandra を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
- DC-1 のマシン 1 で Management Server を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- DC-1 のマシン 2、3 で Router と Message Processor を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- DC-1 でトラフィックのブロックを解除して DC-1 を検証し、DC-2 でトラフィックをブロックして DC-1 にトラフィックを再ルーティングすることで、DC-2 を続行します。
- DC-2 のマシン 7、8、9 で Cassandra を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
- DC-2 のマシン 7 で Management Server を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- DC-2 のマシン 8、9 で Router と Message Processor を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- DC-2 でトラフィックのブロックを解除します。これで、両方の DC がトラフィックを処理します。
- マシン 1 と 7 の DC 全体のすべての management-server で、更新コマンドを再実行します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- 両方の DC のマシン 4、5、6、10、11、12 で edge-qpid-server と edge-postgres-server を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- 両方の DC でマシン 4、5、10、11 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- 両方の DC で新しい UI（ue）または従来の UI（ui）を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
- （apigee-adminapi をインストールした場合）両方の DC で apigee-adminapi を更新します。
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
- （Apigee SSO をインストールしている場合）両方の DC で Apigee SSO ノードを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
- 両方の DC で新しい Edge UI（edge-management-ui）または従来の Edge UI（edge-ui）コンポーネントを再起動します。
/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart