Apigee Edge 4.51.00、4.52.00、または 4.52.01 を 4.52.02 に更新する

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 のコンパクション戦略に必要な変更を行います。次の手順に沿って操作してから、メインのアップグレード手順に戻ります。

アップグレードで考慮すべき特別な手順

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 のデータモデルに特定の変更を加える必要がありました。これらの変更は最小限ですが、アップグレード プロセスが開始されると、特定の Management API が中断されます。一般的に中断される Management API の詳細については、以下の関連セクションをご覧ください。

さらに、アップグレード プロセスにより、アップグレード中のデータセンターで、より多くのランタイム プロキシフローと Management 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 システムの管理が含まれます。これには、デプロイ、アプリの変更、プロダクト、ターゲット サーバー、キーストアなどが含まれますが、これらに限定されません。すべての Management API（および Apigee UI やデベロッパー ポータルなどのクライアント）がこのスコープに含まれます。

このアップグレード中、更新が実行されているリージョンまたはデータセンター（DC）で、ランタイム トラフィックと管理トラフィックが影響を受けます。更新されるデータセンターに関係なく、すべてのデータセンターの特定の Management API に影響があります。この影響は各ステップの後に記載されています。

以下の各ステップでは、アップグレード手順のさまざまな段階におけるランタイムと管理の状態について説明します。

アップグレード戦略

複数のデータセンター

トラフィックの継続性を確保し、ダウンタイムを回避するには、アップグレードをデータセンターごとに実行する必要があります。DC をアップグレードする前に、トラフィックを他の機能している DC に再ルーティングする必要があります。

単一のデータセンター

単一のデータセンター設定の場合、アップグレード手順はランタイム トラフィックと特定の Management API に大きな影響を与えます。単一のデータセンターの設定では、次のオプションを使用できます。

  • アップグレード中にトラフィックを処理するために、既存のデータセンターに加えてデータセンターを追加して、Edge for Private Cloud クラスタを一時的なデータセンターに拡張します。アップグレード プロセスが完了したら、いずれかのデータセンターを廃止します。
  • 追加のデータセンターに拡張できない場合は、ダウンタイムに備え、トラフィックが少ない期間にアップグレードをスケジュールして、Management API とランタイム トラフィックへの影響を最小限に抑えます。

ランタイム トラフィックと Management API への影響を回避するため、追加のデータセンターに拡張することをおすすめします。アップグレード中に、アップグレード対象のデータセンターに影響が及ぶ領域には、以下を含みます（ただしこれらに限定されません）。

  • OAuth トークンを更新する Runtime API
  • Access Entity ポリシーを使用する Runtime API
  • デベロッパー アプリを一覧表示する Management API
  • プロダクトを一覧表示する Management API

上記の変更に加えて、特定の Management API は、すべてのデータセンターがアップグレードされるまで、すべてのデータセンターで機能しないままになります。このような Management API については、以降のセクションの手順で説明します。

ロールバック - 概要

  • ロールバック中の影響

    Cassandra 3.11.x から 2.1.x にロールバックすると、ロールバックが実行されているデータセンター（DC）内のランタイム トラフィックと管理トラフィックの両方に影響します。また、現在ロールバックされている DC に関係なく、すべてのデータセンターで特定の Management API が中断される可能性があります。

  • DC ごとの DC ロールバック アプローチに従う

    サービスの継続性を維持し、ダウンタイムを防ぐために、ロールバックはデータセンターごとに 1 つずつ実行する必要があります。特定の DC でロールバックを開始する前に、アプリケーション トラフィックが完全に稼働している別のデータセンターに再ルーティングされていることを確認します。

  • 部分的にアップグレードされたクラスタのロールバック

    少なくとも 1 つのデータセンターが古いバージョンの Cassandra（2.1.22）で完全に動作している場合、完全に機能している Cassandra 2.1.X DC から再ビルドを実行することで、アップグレードされた他の DC をロールバックできます。

  • クラスタ全体のロールバック

    Cassandra クラスタ全体がアップグレードされ、ロールバックが必要な場合は、バックアップまたは VM スナップショットを使用してロールバックを実行する必要があります。このアプローチは複雑で、一時的なダウンタイムやデータ損失につながる可能性があります。

  • アップグレード前の考慮事項

    アップグレードを試みる前に、ロールバック手順をよく理解しておくことが重要です。適切なロールバック パスが利用できるように、アップグレード中にロールバックのニュアンスを考慮することが重要です。

単一のデータセンターでクラスタをロールバックする

Cassandra をバージョン 2.1.x から 3.11.x にアップグレードすると、ランタイム トラフィックと特定の Management API に大きな影響を与える可能性があります。これらの影響はロールバック中にも適用され、ダウンタイムやデータ損失が発生する可能性があります。

本番環境のワークロードでは、アップグレードの前に新しいデータセンターをプロビジョニングすることを強くおすすめします。これにより、データの損失や API トラフィックの中断を伴わない、より安全なロールバック パスが可能になります。アップグレードが正常に完了したら、追加のデータセンターを廃止できます。

新しいデータセンターを追加することが不可能で、ロールバック機能が必要な場合は、アップグレード前に信頼性の高いバックアップが作成されていることを確認してください。バックアップから Cassandra 2.1.x を復元することは可能ですが、このアプローチではサービスのダウンタイムが発生し、データ損失の可能性があります。

複数のデータセンターがあるクラスタをロールバックする

複数のデータセンターをロールバックする場合は、データセンターごと（DC-by-DC）のアプローチに従います。このアプローチでは、ロールバックされるデータセンターからのトラフィックが他の機能データセンターにリダイレクトされ、Cassandra、Management Server、ランタイム ノードのロールバック プロセスが制御され、分離されるため、トラフィックの中断を回避できます。

詳細については、Cassandra 3.11.16 の更新をロールバックするをご覧ください。

ステップ 0: 開始状態

  • Zookeeper、Postgres、LDAP の各コンポーネントは、すでに 4.52.02 バージョンにアップグレードされています。Edge for プライベート クラウド クラスタが安定して動作している。ロールバックが必要な場合、クラスタはこの状態にロールバックされます。
  • Apigee の Cassandra はバージョン 2.1.22 で実行されています。
  • Edge コンポーネント:
    • Management Server が古い Thrift プロトコルを介して Cassandra と通信している。
    • 古い Thrift プロトコルを介して Cassandra と通信するランタイム サーバー（Message Processor と Router）。
このステージのランタイム状態 この段階での管理状態
ランタイムが完全に機能する 管理機能が完全に動作

ステップ 1: アップグレードを準備する

以下の手順は、コンポーネントのアップグレードを有効にするための Apigee の標準構成ファイルなど、通常作成する標準ファイルに加えて行うものです。

  1. Cassandra を LeveledCompactionStrategy を使用するように変更する。
  2. Apigee を使用して Cassandra をバックアップする。
  3. Cassandra ノードの VM スナップショットを取得します（可能な場合）。
  4. 各 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 を作成します。
  5. Apigee Drupal 7 デベロッパー ポータルの SmartDocs 機能を使用する場合は、デベロッパー ポータル UI から JSON 形式でダウンロードして、各モデルをエクスポートします。これらのモデルは、管理サーバーの更新後に Apigee にインポートし直す必要があります。
  6. ポート 9160 と 9042 がすべての Edge コンポーネントから Cassandra ノードにアクセスできることを確認します（まだ存在しない場合）。詳細については、ポートの要件をご覧ください。

ステップ 2: 最初のデータセンターからトラフィックをリダイレクトする

  1. 最初のデータセンターからの受信ランタイム トラフィックと管理トラフィックをブロックします。
  2. すべてのランタイム トラフィックと Management API を他の機能データセンターにリダイレクトします。
  3. ランタイム トラフィックと管理トラフィックが他の DC で正常に処理されていることを確認します。

ステップ 3: 最初のデータセンターのすべての Cassandra ノードをアップグレードする

  1. データセンター内のすべての Cassandra ノードを 1 つずつアップグレードします。各ノードで次のコマンドを 1 つずつ実行します。
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  2. ノードが更新されたら、ノードで次のコマンドを実行して、先に進む前にいくつかの検証を行います。
    /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
  3. アップグレードが完了したら、各 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、ランタイム コンポーネント、management-server でアップグレードされたら、最初のデータセンターへのランタイム トラフィックと管理トラフィックを再度有効にします。
  • ランタイム トラフィックと管理トラフィックが DC 間で正常に処理されていることを確認します。

ステップ 7: 他のデータセンターをアップグレードする

残りのデータセンターでステップ 1～ステップ 6 を繰り返します。このとき、トラフィックをデータセンターからリダイレクトし、Apigee ソフトウェアを更新して、データセンターのトラフィックを再度有効にします。

ステップ 8: すべての管理ノードでアップグレード手順を再実行する

データセンター全体のすべての管理ノードで、次のアップグレード コマンドを再実行します。

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

ステップ 9 - [省略可] 以前にエクスポートした SmartDocs をインポートする

すべての管理サーバーをアップグレードしたら、ステップ 1 でエクスポートしたスマートドキュメント モデルをインポートできます。この設定は後で行うこともできます。

この操作が必要になるのは、Drupal 7 ベースのデベロッパー ポータルを使用し、SmartDocs 機能を使用している場合のみです。

このステージのランタイム状態 この段階での管理状態
ランタイムが完全に機能する 管理機能が完全に動作

ステップ 10 - 未使用のテーブルを削除する

次のコマンドを実行して、Cassandra クラスタから未使用の古いテーブルを削除します。このコマンドを実行するまで、Cassandra の特定の機能（新しい認証の設定など。古い認証メカニズムは引き続き機能します）は使用できません。このコマンドは、クラスタ内の 1 つのノードでのみ実行できます。

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile

ステップ 11 - 残りのすべての Edge コンポーネントとその他のコンポーネントを Private Cloud 4.52.02 にアップグレードする

すべてのリージョンで、残りの 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 を使用しているはずであり、追加の Qpid アップグレード手順は必要ありません。

新しい Edge UI

このセクションでは、Edge UI に関する考慮事項について説明します。詳細については、プライベート クラウド用の新しい Edge UI をご覧ください。

Edge UI のインストール

初期インストールが完了したら、Edge UI をインストールすることをおすすめします。これは、Apigee Edge for Private Cloud のデベロッパーと管理者向けの拡張ユーザー インターフェースです。

Edge UI では、基本認証を無効にして、SAML や LDAP などの IDP を使用する必要があります。

詳細については、新しい Edge UI をインストールするをご覧ください。

Edge UI の更新

Edge UI コンポーネントを更新するには、アップグレード元の Edge for プライベート クラウド のバージョンを考慮してください。

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 をロードバランサに再び追加します。

  1. マシンの更新順序の説明に沿って、インストールに適した順序でマシンを更新します。
  2. Router を更新するタイミングになったら、サーバー（Message Processor / Router）のネットワーク到達性の有効化と無効化の説明に従って、いずれか 1 つの Router を選択して到達不能にします。
  3. 選択した Router と、その Router と同じマシンにある他のすべての Edge コンポーネントを更新します。すべての Edge 構成で、Router と Message Processor が同じノードに表示されます。
  4. ルーターを再度到達可能にします。
  5. 残りのルーターについて、手順 2 ～ 4 を繰り返します。
  6. インストール環境内の残りのマシンに対して更新を続行します。

更新の前後に次の点に注意してください。

サイレント構成ファイルの使用

update コマンドにサイレント構成ファイルを渡す必要があります。サイレント構成ファイルは、Edge 4.50.00 または 4.51.00 のインストールに使用したものと同じである必要があります。

外部インターネット接続があるノードで 4.52.02 に更新する

ノード上の Edge コンポーネントを更新する手順は次のとおりです。

  1. 存在する場合は、更新が完了するまで、Cassandra で修復オペレーションを実行するように構成された cron ジョブを無効にします。
  2. Edge RPM をインストールするには、root としてノードにログインします。
  3. yum-utils と yum-plugin-priorities をインストールします。 
    sudo yum install yum-utils
sudo yum install yum-plugin-priorities
  4. Edge apigee-setup ユーティリティのインストールの説明に従って、SELinux を無効にします。
  5. Oracle 7.x にインストールする場合は、次のコマンドを実行します。
    sudo yum-config-manager --enable ol7_optional_latest
  6. 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

  7. 現在 Edge 4.51.00 を使用している場合:

    1. 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
    2. 次のコマンドを実行して、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 を自分でインストールする必要があります。
    3. 次の例のように、apigee-service を使用して apigee-setup ユーティリティを更新します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
    4. 次の例のように、Management Server の apigee-validate ユーティリティを更新します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
    5. 次の例のように、Management Server の apigee-provision ユーティリティを更新します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
    6. 次のコマンドを実行して、ノードで update ユーティリティを実行します。
      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

      これは、マシンの更新順序に記載されている順序で行います。

      ここで

      • component は、更新する Edge コンポーネントです。有効な値は次のとおりです。
        • cs: Cassandra
        • edge: Edge UI を除くすべての Edge コンポーネント（Management Server、Message Processor、Router、Qpid Server、Postgres Server）
        • ldap: OpenLDAP
        • ps: postgresql
        • qpid: qpidd
        • sso: Apigee SSO（SSO をインストールした場合）
        • ue: 新しい Edge UI
        • ui: 従来の Edge UI
        • zk: 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
    7. Edge UI コンポーネントを実行するすべてのノードで Edge UI コンポーネントを再起動します（まだ再起動していない場合）。
      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
    8. インストールのテストの説明に従って、Management Server で apigee-validate ユーティリティを実行して、更新をテストします。

後で更新をロールバックすることにした場合は、4.52.02 のロールバックの手順に沿ってください。

ローカル リポジトリから 4.52.02 に更新する

Edge ノードがファイアウォールの背後にあるか、インターネット経由での Apigee リポジトリ アクセスが禁止されている場合は、Apigee リポジトリのローカル リポジトリ（つまりミラー）から更新を行うことができます。#heading

ローカル Edge リポジトリを作成したら、ローカル リポジトリから Edge を更新する方法が 2 つあります。

  • リポジトリの .tar ファイルを作成し、その .tar ファイルをノードにコピーして、.tar ファイルから Edge を更新します。
  • ローカル リポジトリを持つノードにウェブサーバーをインストールし、他のノードからアクセスできるようにします。Apigee から提供されているウェブサーバーは Nginx ですが、他のウェブサーバーを使用してもかまいません。

ローカルの 4.52.02 リポジトリから更新するには:

  1. Edge apigee-setup ユーティリティのインストールの「ローカルに Apigee リポジトリを作成する」の手順で 4.52.02 リポジトリをローカルに作成します。
  2. .tar ファイルから apigee-service をインストールするには:
    1. ローカル リポジトリがあるノードで、次のコマンドを使用して、ローカル リポジトリを /opt/apigee/data/apigee-mirror/apigee-4.52.02.tar.gz という名前の単一の .tar ファイルにパッケージ化します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
    2. Edge を更新する対象のノードに .tar ファイルをコピーします。たとえば、新しいノードの /tmp ディレクトリにコピーします。
    3. 新しいノードで、ファイルを /tmp ディレクトリに解凍します。
      tar -xzf apigee-4.52.02.tar.gz

      このコマンドにより、.tar ファイルを含むディレクトリに repos という名前の新しいディレクトリが作成されます。例: /tmp/repos

    4. /tmp/repos から Edge apigee-service ユーティリティと依存関係をインストールします。
      sudo bash /tmp/repos/bootstrap_4.52.02.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

      コマンドに repos ディレクトリへのパスが含まれている点に注意してください。

  3. Nginx ウェブサーバーを使用して apigee-service をインストールするには:
    1. Edge apigee-setup ユーティリティのインストールの「Nginx ウェブサーバーを使用してリポジトリからインストールする」の手順に沿って、Nginx ウェブサーバーを構成します。
    2. リモートノードで、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 名です。

    3. リモートノードで、Edge apigee-setup ユーティリティと依存関係をインストールします。
      sudo bash /tmp/bootstrap_4.52.02.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      ここで、uName:pWord はリポジトリのユーザー名とパスワードです。

  4. 次の例のように、apigee-service を使用して apigee-setup ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
  5. 次の例のように、Management Server の apigee-validate ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
  6. 次の例のように、Management Server の apigee-provision ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
  7. マシンの更新順序で説明されている順序で、ノードで update ユーティリティを実行します。
    /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

    ここで

    • component は、更新する Edge コンポーネントです。通常、次のコンポーネントを更新します。
      • cs: Cassandra
      • edge: Edge UI を除くすべての Edge コンポーネント（Management Server、Message Processor、Router、Qpid Server、Postgres Server）
      • ldap: OpenLDAP
      • ps: postgresql
      • qpid: qpidd
      • sso: Apigee SSO（SSO をインストールした場合）
      • ue 新しい Edge UI
      • ui: 従来の Edge UI
      • zk: 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
  8. UI コンポーネントを実行するすべてのノードで UI コンポーネントを再起動します（まだ再起動していない場合）。
    /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
  9. インストールのテストの説明に従って、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 にアップグレードするには:
  1. すべてのコンポーネントを更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
  2. （apigee-adminapi をインストールした場合）apigee-adminapi ユーティリティを更新しました。
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

2 ノード 単体アップグレード

2 ノードのスタンドアロン インストール用に次のコンポーネントを更新します。

Edge トポロジとノード番号の一覧については、インストール トポロジをご覧ください。

  1. マシン 1 の Zookeeper を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. マシン 2 の Postgres を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. マシン 1 の LDAP を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  4. マシン 1 で Cassandra を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  5. マシン 1 と 2 の Edge コンポーネントを更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. マシン 2 で Qpid を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. マシン 1 の UI を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
  8. （apigee-adminapi がインストールされている場合）マシン 1 の apigee-adminapi ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    ここで、sso_config_file は、SSO をインストールしたときに作成した構成ファイルです。

  10. マシン 1 の Edge UI コンポーネントを再起動します。
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

5 ノード構成のアップグレード

5 ノード インストール用に次のコンポーネントを更新します。

Edge トポロジとノード番号の一覧については、インストール トポロジをご覧ください。

  1. マシン 1、2、3 で ZooKeeper を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. マシン 4 で Postgres を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. マシン 5 の Postgres を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  4. マシン 1 の LDAP を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  5. マシン 1、2、3 で Cassandra を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  6. マシン 1、2、3、4、5 の Edge コンポーネントを更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. マシン 4 で Qpid を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. マシン 5 の Qpid を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  9. 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
  10. （apigee-adminapi がインストールされている場合）マシン 1 の apigee-adminapi ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  11. Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    ここで、sso_config_file は、SSO をインストールしたときに作成した構成ファイルです。

  12. UI コンポーネントを再起動します。
    • Classic UI: Classic 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

9 ノードクラスタのアップグレード

9 ノードのクラスタ インストール用に次のコンポーネントを更新します。

Edge トポロジとノード番号の一覧については、インストール トポロジをご覧ください。

  1. マシン 1、2、3 で ZooKeeper を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. マシン 8 で Postgres を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. マシン 9 で Postgres を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  4. マシン 1 の LDAP を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  5. マシン 1、2、3 で Cassandra を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  6. マシン 1、4、5、6、7、8、9 の Edge コンポーネントをこの順序で更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. マシン 6 と 7 で Qpid を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. マシン 1 で新しい UI（ue）または従来の UI（ui）を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. （apigee-adminapi がインストールされている場合）マシン 1 の apigee-adminapi ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    ここで、sso_config_file は、SSO をインストールしたときに作成した構成ファイルです。

  11. UI コンポーネントを再起動します。
    • Classic UI: Classic 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

13 ノードクラスタのアップグレード

13 ノードのクラスタ インストールでは、次のコンポーネントを更新します。

Edge トポロジとノード番号の一覧については、インストール トポロジをご覧ください。

  1. マシン 1、2、3 で ZooKeeper を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. マシン 8 で Postgres を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. マシン 9 で Postgres を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  4. マシン 4 と 5 で LDAP を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  5. マシン 1、2、3 で Cassandra を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  6. マシン 6、7、10、11、12、13、8、9 の順に Edge コンポーネントを更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. マシン 12 と 13 で Qpid を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. マシン 6 と 7 で、新しい UI（ue）または従来の UI（ui）を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. （apigee-adminapi がインストールされている場合）マシン 6、7 の apigee-adminapi ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. Apigee SSO がインストールされている場合は、マシン 6、7 の Apigee SSO を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    ここで、sso_config_file は、SSO をインストールしたときに作成した構成ファイルです。

  11. UI コンポーネントを再起動します。
    • Classic UI: Classic 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

12 ノードクラスタのアップグレード

12 ノードのクラスタ インストール用に次のコンポーネントを更新します。

Edge トポロジとノード番号の一覧については、インストール トポロジをご覧ください。

  1. 両方の DC のマシン 1、2、3、7、8、9 で ZooKeeper を更新します。

    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. 両方の DC のマシン 6、12 で Postgres を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. 両方の DC のマシン 1、7 で LDAP を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

  4. DC-1 のトラフィックをブロックし、すべてのトラフィックが他の DC-2 に再ルーティングされるようにする

  5. DC-1 のマシン 1、2、3 で Cassandra を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  6. DC-1 のマシン 1 で Management Server を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. DC-1 のマシン 2、3 の Router、Message Processor を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  8. DC-1 のトラフィックをブロック解除して DC-1 を検証し、DC-2 のトラフィックをブロックして DC-1 に再ルーティングすることで DC-2 を続行します。
  9. DC-2 のマシン 7、8、9 で Cassandra を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  10. DC-2 のマシン 7 で Management Server を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  11. DC-2 のマシン 8、9 の Router、Message Processor を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  12. DC-2 のトラフィックのブロックを解除すると、両方の DC がトラフィックを処理するようになります。
  13. マシン 1 と 7 の DC 全体のすべての management-server で、update コマンドを再実行します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  14. 両方の DC のマシン 4、5、6、10、11、12 で edge-qpid-server と edge-postgres-server を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  15. 両方の DC のマシン 4、5、10、11 で Qpid を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  16. 両方の DC で新しい UI（ue）または従来の UI（ui）を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c  [ui|ue] -f configFile
  17. （apigee-adminapi がインストールされている場合）両方の DC で apigee-adminapi を更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  18. （Apigee SSO がインストールされている場合）両方の DC の Apigee SSO ノードを更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
  19. 両方の DC で、新しい Edge UI（edge-management-ui）コンポーネントまたは従来の Edge UI（edge-ui）コンポーネントを再起動します。
    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart