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 のデータモデルに特定の変更を加える必要があります。これらの変更は最小限ですが、アップグレードが開始されると、アップグレード プロセスによって特定の管理 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 クラスタを一時的なデータセンターに拡張します。アップグレード プロセスの完了後に、いずれかのデータセンターを廃止します。
  • 追加のデータセンターに拡張できない場合は、管理 API とランタイム トラフィックへの影響を最小限に抑えるために、ダウンタイムに備えてトラフィックの少ない時間帯にアップグレードをスケジュールします。

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

  • ランタイム API による OAuth トークンの更新
  • Access Entity ポリシーを使用するランタイム API
  • デベロッパー アプリを一覧表示する管理 API
  • プロダクトをリストする管理 API

上記の影響は、すべてのデータセンターがアップグレードされるまで、すべてのデータセンターで機能しなくなる特定の管理 API に加えて発生します。このような管理 API は、以降のセクションの手順で説明します。

ロールバック - 概要

  • ロールバック中の影響

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

  • DC による 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-by-DC）のアプローチで行われます。このアプローチでは、ロールバックされるデータセンターからのトラフィックが他の機能するデータセンターにリダイレクトされます。これにより、Cassandra、Management Server、Runtime ノードのロールバック プロセスが制御され、分離されるため、トラフィックの中断を回避できます。

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

ステップ 0: 開始状態

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

ステップ 1: アップグレードの準備

次の手順は、コンポーネントのアップグレードを有効にする Apigee の標準構成ファイルなど、通常作成する標準ファイルに加えて行う必要があります。

  1. LeveledCompactionStrategy を使用するように Cassandra を変更します。
  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. すべてのランタイム トラフィックと管理 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 を 1 つずつ繰り返します。データセンターからトラフィックをリダイレクトし、Apigee ソフトウェアを更新して、データセンターでトラフィックを再度有効にします。

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

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

/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 - 残りの 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 をすでに使用しているはずです。追加の 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 のバージョンを考慮してください。

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 を更新するときは、任意の Router を 1 つ選択し、サーバー（Message Processor または Router）の到達可能性の有効化 / 無効化の説明に従ってその Router を到達不能な状態にします。
  3. 選択した Router と、その同じマシンにある他のすべての Edge コンポーネントを更新します。すべての Edge 構成で、Router と Message Processor は同じノードにあります。
  4. Router を到達可能な状態に戻します。
  5. 残りの Router に対し、2 ～ 4 の手順を繰り返します。
  6. インストール中の残りのすべてのマシンで更新を続行します。

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

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

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

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

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

  1. Cassandra の修復オペレーションを行う cron ジョブが設定されている場合は、更新が完了するまでそれらのジョブを無効にします。
  2. ノードに root としてログインし、Edge RPM をインストールします。
  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 ファイルから 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. 新しいノードで、.tar ファイルを /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 コンポーネントを再起動します。
    • 従来の 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

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 コンポーネントを再起動します。
    • 従来の 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

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 コンポーネントを再起動します。
    • 従来の 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

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