Apigee では、Edge for Private Cloud をバージョン 4.50.00 またはバージョン 4.51.00 からバージョン 4.52.00 に直接アップグレードできます。このページでは、それぞれのアップグレードを行う方法について説明します。
更新を実行できるユーザー
更新を行うユーザーは、最初に Edge をインストールしたユーザー、または root として実行しているユーザーである必要があります。
Edge RPM をインストールした後は、誰でも構成できます。
更新が必要なコンポーネント
すべての Edge コンポーネントを更新する必要があります。Edge では、複数のバージョンのコンポーネントを含む設定はサポートされていません。
前提条件を更新する
Apigee Edge をアップグレードする前に、次の前提条件を満たしていることを確認してください。
- すべてのノードをバックアップする
安全上の理由から、更新する前にすべてのノードを完全にバックアップすることをおすすめします。現在のバージョンの Edge でバックアップを行います。これにより、新しいバージョンへの更新が正常に機能しなかった場合に備えて、バックアップ プランを作成できます。バックアップの詳細については、バックアップと復元をご覧ください。
- Edge が実行されていることを確認する
次のコマンドを使用して、更新プロセス中に Edge が稼働していることを確認します。/opt/apigee/apigee-service/bin/apigee-all status
- Cassandra のコンパクション戦略が
LeveledCompactionStrategy
であることを確認する
Cassandra のコンパクション戦略を変更するの説明に沿って、Cassandra のコンパクション戦略がLeveledCompactionStrategy
に設定されていることを確認します。
プロパティ設定の自動伝播
/opt/apigee/customer/application
の .properties
ファイルを編集してプロパティを設定した場合、それらの値は更新の際にも保持されます。
Zookeeper 3.8.0 へのアップグレードが必要
この Edge for Private Cloudes のリリースには、Zookeeper 3.8.0 へのアップグレードが含まれています。このアップグレードの一環として、すべての Zookeeper データは Zookeeper 3.8.0 に移行されます。
Zookeeper をアップグレードする前に、Zookeeper メンテナンス ガイドをご覧ください。ほとんどの Edge 本番環境システムは、複数のデータセンターに分散した Zookeeper ノードのクラスタを使用します。これらのノードの一部は、Zookeeper リーダーの選出に参加するボーターとして構成され、残りはオブザーバーとして構成されています。詳細については、 リーダー、フォロワー、ボーター、オブザーバーについてをご覧ください。ボーターノードがリーダーを選出し、その後、ボーターノード自体がフォロワーになります。
更新プロセス中に、リーダーノードがシャットダウンされると、一時的な遅延や Zookeeper への書き込みエラーが発生する可能性があります。これは、Zookeeper に書き込む管理オペレーション(プロキシのデプロイ オペレーションなど)や、Apigee インフラストラクチャの変更(Message Processor の追加や削除など)に影響する可能性があります。以下の手順に従って、Zookeeper のアップグレード中に Apigee のランタイム API が管理 API を呼び出す場合を除き、Apigee のランタイム API には影響しません。
大まかに言うと、アップグレード プロセスでは各ノードのバックアップを作成します。その後、すべてのオブザーバーとフォロワーがアップグレードされ、最終的にリーダーノードがアップグレードされます。
バックアップを取る
ロールバックが必要になった場合に備えて、Zookeeper のすべてのノードのバックアップを作成します。ロールバックを行うと、Zookeeper がバックアップ作成時の状態に復元されます。注: バックアップの作成以降に Apigee でデプロイまたはインフラストラクチャを変更すると、復元中に情報(Zookeeper に保存されている情報)が失われます。
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup
仮想マシンを使用していて、その機能がある場合は、VM のスナップショットまたはバックアップを作成して、復元またはロールバックすることもできます(必要な場合)。
リーダー、フォロワー、オブザーバーを特定する
注: 以下のサンプル コマンドでは、nc ユーティリティを使用して Zookeeper にデータを送信します。別のユーティリティを使用して Zookeeper にデータを送信することもできます。
- nc が ZooKeeper ノードにインストールされていない場合は、
sudo yum install nc
をインストールします。 - ノードで次の nc コマンドを実行します。ここで、2181 は ZooKeeper ポートです。
echo stat | nc localhost 2181
次のような出力が表示されます。
Zookeeper version: 3.8.0-5a02a05eddb59aee6ac762f7ea82e92a68eb9c0f, built on 2022-02-25 08:49 UTC Clients: /0:0:0:0:0:0:0:1:41246[0](queued=0,recved=1,sent=0) Latency min/avg/max: 0/0.2518/41 Received: 647228 Sent: 647339 Connections: 4 Outstanding: 0 Zxid: 0x400018b15 Mode: follower Node count: 100597
ノードの出力の
Mode
行に、ノード構成に応じてオブザーバー、リーダー、フォロワー(リーダーではないボーター)が表示されます。注: 単一の ZooKeeper ノードを持つ Edge のスタンドアロン インストールでは、Mode
がスタンドアロンに設定されます。 - ZooKeeper ノードごとに手順 1 と 2 を繰り返します。
オブザーバー ノードとフォロワー ノードで Zookeeper をアップグレードする
オブザーバー ノードとフォロワー ノードごとに、次のように Zookeeper をアップグレードします。
- 外部インターネット接続のあるノードで 4.52.00 に更新するの説明に従って、Edge for Private Cloud 4.52 のブートストラップをダウンロードして実行します。このプロセスは、ノードが外部インターネットに接続されているか、オフライン インストールを実行するかによって異なります。
- Zookeeper コンポーネントをアップグレードします。
/opt/apigee/apigee-setup/bin/update.sh -c zk -f <silent-config-file>
注: これらのノードに他のコンポーネント(Cassandra など)がインストールされている場合は、cs,zk プロファイルなどを使用して、ここでもアップグレードできます。または、後で他のコンポーネントをアップグレードすることもできます。最初に Zookeeper をアップグレードし、クラスタが正しく動作していることを確認してから他のコンポーネントをアップグレードすることをおすすめします。 - Zookeeper オブザーバー ノードとフォロワー ノードごとに、上記の手順を繰り返します。
リーダーをシャットダウンする
オブザーバー ノードとフォロワー ノードがすべてアップグレードされたら、リーダーをシャットダウンします。リーダーとして識別されたノードで、次のコマンドを実行します。
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
このイベント中、新しいリーダーが選出される前に、Zookeeper で一時的な遅延や書き込み失敗が発生する可能性があります。これは、Zookeeper への書き込みオペレーション(プロキシのデプロイ アクション、Apigee インフラストラクチャの変更(Message Processor の追加や削除など)など)に影響する可能性があります。
新しいリーダーが選出されたことを確認する
前述のリーダー、フォロワー、オブザーバーを特定するの手順を使用して、既存のリーダーが停止したら、フォロワーから新しいリーダーが選出されたことを確認します。リーダーは、現在のリーダーとは異なるデータセンターで選出されることもあります。
リーダーのアップグレード
上記の オブザーバー ノードとフォロワー ノードで Zookeeper をアップグレードすると同じ手順を行います。
古いリーダーノードもアップグレードしたら、クラスタの正常性を確認し、リーダーノードがあることを確認します。
ロールバック
ロールバックが必要な場合:
- まず、オブザーバーとフォロワーでロールバックの手順を実施します。
- ロールバックするバージョン(4.50 または 4.51)のブートストラップをダウンロードして実行します。このプロセスは、ノードに外部インターネット接続があるかどうかによって、またはオフライン インストールを行っているかどうかによって異なります。
- ノードで実行されている場合は Zookeeper を停止します。
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
- 既存の Zookeeper をアンインストールします。
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
/opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
バックアップを復元
バックアップからの復元をご覧ください。以前のバージョンの Edge for Private Cloud から取得した Zookeeper のバックアップ(4.50 や 4.51 など)は、Edge for Private Cloud 4.52 の Zookeeper のバージョンと互換性があるはずです。
Postgres 14 へのアップグレードが必要
この Edge リリースには、Postgres 14 へのアップグレードが含まれています。このアップグレードの一環として、すべての Postgres データが Postgres 14 に移行されます。
ほとんどの Edge 本番環境システムは、マスター / スタンバイ レプリケーション用に構成された 2 つの Postgres ノードを使用します。更新プロセスの間、Postgres ノードが更新のために停止している間、分析データは Qpid ノードに書き込まれます。Postgres ノードが更新されてオンラインに戻ると、分析データが Postgres ノードに push されます。
Postgres の更新方法は、Postgres ノードのデータ ストレージの構成方法によって異なります。
- Postgres ノードにローカル データ ストレージを使用している場合は、アップグレード中に新しい Postgres スタンバイ ノードをインストールする必要があります。アップグレードが完了したら、新しい Postgres スタンバイ ノードを廃止できます。
なんらかの理由で更新をロールバックする必要がある場合は、追加の Postgres スタンバイ ノードが必要です。更新をロールバックする必要がある場合は、ロールバック後に、新しい Postgres スタンバイ ノードがマスター Postgres ノードになります。したがって、新しい Postgres スタンバイ ノードをインストールする際、そのノードは、Edge のインストール要件で定義されている Postgres サーバーのハードウェア要件をすべて満たすノード上に配置する必要があります。
プロトタイピングとテストに使用されるトポロジである Edge の 1 ノードと 2 ノードの構成では、Postgres ノードは 1 つだけです。これらの Postgres ノードは、新しい Postgres ノードを作成せずに直接更新できます。
- Postgres ノードにネットワーク ストレージを使用する場合は、Apigee で推奨されているように、新しい Postgres ノードをインストールする必要はありません。以下の手順では、新しい Postgres スタンバイ ノードをインストールして後で廃止する手順をスキップできます。
更新プロセスを開始する前に、Postgres で使用されるデータストアのネットワーク スナップショットを作成します。その後、更新中にエラーが発生し、ロールバックを行う必要が生じた場合は、そのスナップショットから Postgres ノードを復元できます。
新しい Postgres スタンバイ ノードのインストール
この手順では、新しいノードに Postgres スタンバイ サーバーを作成します。バージョン 4.52.00 ではなく、既存のバージョンの Edge(4.50.00 または 4.51.00)に新しい Postgres スタンバイ サーバーをインストールしていることを確認します。
インストールには、現在のバージョンの Edge のインストールに使用したのと同じ構成ファイルを使用します。
新しい Postgres スタンバイ ノードを作成するには:
- 現在の Postgres マスターで、
/opt/apigee/customer/application/postgresql.properties
ファイルを編集して次のトークンを設定します。このファイルが存在しない場合は作成します。conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust
ここで、existing_standby_ip は現在の Postgres スタンバイ サーバーの IP アドレス、new_standby_ip は新しいスタンバイ ノードの IP アドレスです。
- Postgres マスターで
apigee-postgresql
を再起動します。/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
- マスターの
/opt/apigee/apigee-postgresql/conf/pg_hba.conf
ファイルを表示して、新しいスタンバイ ノードが追加されたことを確認します。ファイルに次の行があるはずです。host replication apigee existing_standby_ip/32 trust host replication apigee new_standby_ip/32 trust
- 新しい Postgres スタンバイ サーバーをインストールします。
- 現在のバージョンの Edge のインストールに使用した構成ファイルを編集して、
# IP address of the current master: PG_MASTER=192.168.56.103 # IP address of the new standby node PG_STANDBY=192.168.56.102
を指定します。 - Edge apigee-setup ユーティリティをインストールするの説明に従って、SELinux を無効にします。
現在 Edge 4.51.00 を使用している場合:
- Edge bootstrap_4.51.00.sh ファイルを
/tmp/bootstrap_4.51.00.sh
にダウンロードします。curl https://software.apigee.com/bootstrap_4.51.00.sh -o /tmp/bootstrap_4.51.00.sh
- Edge
apigee-service
ユーティリティと依存関係をインストールします。sudo bash /tmp/bootstrap_4.51.00.sh apigeeuser=uName apigeepassword=pWord
現在 Edge 4.50.00 を使用している場合:
- Edge bootstrap_4.50.00.sh ファイルを
/tmp/bootstrap_4.50.00.sh
にダウンロードします。curl https://software.apigee.com/bootstrap_4.50.00.sh -o /tmp/bootstrap_4.50.00.sh
- Edge
apigee-service
ユーティリティと依存関係をインストールします。sudo bash /tmp/bootstrap_4.50.00.sh apigeeuser=uName apigeepassword=pWord
- Edge bootstrap_4.51.00.sh ファイルを
apigee-service
を使用してapigee-setup
ユーティリティをインストールします。/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
- Postgres をインストールします。
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
- 新しいスタンバイ ノードで、次のコマンドを実行します。
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
スタンバイを確認します。
- 現在のバージョンの Edge のインストールに使用した構成ファイルを編集して、
Postgres のインプレース アップグレードの実行
予備的な手順
Postgres にインプレース アップグレードを行う前に、マスターホストとスタンバイの両方で次の手順を行い、apigee-postgresql
の max_locks_per_transaction
プロパティを更新します。
- 存在しない場合は、
/opt/apigee/customer/application/postgresql.properties
ファイルを作成します。 - このファイルのオーナーを
apigee
に変更します。sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
-
conf/postgresql.conf+max_locks_per_transaction=30000
プロパティをファイルに追加します。 apigee-postgresql
を設定します。apigee-service apigee-postgresql configure
apigee-postgresql
を再起動します。apigee-service apigee-postgresql restart
インプレース アップグレードを行う
Postgres 14 にインプレース アップグレードを行うには、次の操作を行います。
- マスターホスト上の postgres のアップグレード
/opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
- マスターホストで setup コマンドを実行します。
apigee-service apigee-postgresql setup -f /opt/silent.conf
- マスターホストで configure コマンドを実行します。
apigee-service apigee-postgresql configure
- マスターホストを再起動します。
apigee-service apigee-postgresql restart
- マスターとして構成します。
apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf
- マスターホストが起動していることを確認します。
apigee-service apigee-postgresql wait_for_ready
- スタンバイを停止します。
apigee-service apigee-postgresql stop
- スタンバイをアップグレードします。
注: このステップがエラーまたは失敗した場合は、無視してかまいません。
update.sh
はスタンバイ サーバーを不適切な構成で起動しようとします。Postgres インストールが 14 にアップグレードされていれば、このエラーは無視してかまいません。/opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
- スタンバイが停止していることを確認します。
apigee-service apigee-postgresql stop
- 古いスタンバイ構成を削除します。
rm -rf /opt/apigee/data/apigee-postgresql/
- スタンバイ サーバーでレプリケーションを設定します。
apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf
- マスターホストとスタンバイの両方のファイル
/opt/apigee/customer/application/postgresql.properties
からconf/postgresql.conf+max_locks_per_transaction=30000
の行を削除します。この行は予備手順で追加されました。
この手順を完了すると、スタンバイが正常に起動します。
Postgres ノードの廃止
更新が完了したら、新しいスタンバイ ノードを廃止します。
- Postgres が実行されていることを確認します。
/opt/apigee/apigee-service/bin/apigee-all status
Postgres が実行されていない場合は、起動します。
/opt/apigee/apigee-service/bin/apigee-all start
- 新しいスタンバイ ノードで
curl
コマンドを実行して、新しいスタンバイ ノードの UUID を取得します。curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
出力の最後に、ノードの UUID が
"type" : [ "postgres-server" ], "uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
の形式で表示されます。 - 新しいスタンバイ ノードで次のコマンドを実行して、新しいスタンバイ ノードを停止します。
/opt/apigee/apigee-service/bin/apigee-all stop
- Postgres マスターノードで、
/opt/apigee/customer/application/postgresql.properties
を編集して、conf_pg_hba_replication.connection
から新しいスタンバイ ノードを削除します。conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
- Postgres マスターで apigee-postgresql を再起動します。
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
- マスターの
/opt/apigee/apigee-postgresql/conf/pg_hba.conf
ファイルを表示して、新しいスタンバイ ノードが削除されたことを確認します。ファイルにhost replication apigee existing_standby_ip/32 trust
という行のみが表示されるはずです。 - Management Server ノードで Edge 管理 API 呼び出しを行い、ZooKeeper からスタンバイ ノードの UUID を削除します。
curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid
Postgres のアップグレード後の手順
Postgres のメジャー アップグレード後、Postgres の内部統計情報は消去されます。これらの統計情報は、Postgres のクエリ プランナーが最適なインデックスとパスを利用してクエリを実行するのに役立ちます。
Postgres は、クエリの実行時や自動バキューム デーモンの実行時に、徐々に統計情報を再構築できます。ただし、統計情報が再構築されるまで、クエリが遅くなる可能性があります。
この問題に対処するには、マスター Postgres ノード上のデータベース内のすべてのテーブルで ANALYZE
を実行します。または、一度に少数のテーブルに対して ANALYZE
を実行することもできます。
新しい Edge UI
このセクションでは、Edge UI に関する考慮事項について説明します。詳細については、Private Cloud 用の新しい 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 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
ユーティリティを実行しているユーザーにこのディレクトリへのアクセス権がない場合は、ログを update_username.log
という名前のファイルとして /tmp
ディレクトリに書き込みます。
ユーザーに /tmp
へのアクセス権がない場合、update.sh
ユーティリティは失敗します。
ダウンタイムなしで更新
ゼロ ダウンタイムの更新(ローリング アップデート)を使用すると、Edge をダウンさせることなく Edge インストールを更新できます。
ゼロ ダウンタイムの更新は、5 ノード以上の構成でのみ可能です。
ダウンタイムなしでアップグレードするには、ロードバランサから各 Router を 1 つずつ削除します。その後、Router と 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 ノードの場合:
サイレント構成ファイルを使用する
サイレント構成ファイルを update コマンドに渡す必要があります。サイレント構成ファイルは、Edge 4.50.00 または 4.51.00 のインストールに使用したものと同じである必要があります。
外部インターネット接続があるノードで 4.52.00 に更新する
ノード上の 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.00.sh
ファイルを/tmp/bootstrap_4.52.00.sh
にダウンロードします。curl https://software.apigee.com/bootstrap_4.51.00.sh -o /tmp/bootstrap_4.51.00.sh
- 次のコマンドを実行して、Edge 4.52.00 の
apigee-service
ユーティリティと依存関係をインストールします。sudo bash /tmp/bootstrap_4.52.00.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 Serverldap
: 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-ui restart
- インストールをテストするの説明に沿って、Management Server で
apigee-validate
ユーティリティを実行して更新をテストします。
後で更新をロールバックする場合は、4.52.00 のロールバックの説明に従ってください。
ローカル リポジトリから 4.52.00 に更新する
Edge ノードがファイアウォールの内側にあるか、インターネット経由での Apigee リポジトリへのアクセスがなんらかの方法で禁止されている場合は、Apigee リポジトリのローカル リポジトリまたはミラーから更新を実行できます。
ローカル Edge リポジトリを作成した後、ローカル リポジトリから Edge を更新する方法は 2 つあります。
- リポジトリの .tar ファイルを作成し、その .tar ファイルをノードにコピーしてから、.tar ファイルから Edge を更新します。
- ローカル リポジトリがあるノードにウェブサーバーをインストールし、他のノードがアクセスできるようにします。Apigee から提供されている Nginx ウェブサーバーを使用することも、独自のウェブサーバーを使用することもできます。
ローカルの 4.52.00 リポジトリから更新するには:
- Edge apigee-setup ユーティリティのインストールの「ローカルに Apigee リポジトリを作成する」の説明に従って、4.52.00 リポジトリをローカルに作成します。
- .tar ファイルから apigee-service をインストールするには:
- ローカル リポジトリがあるノードで、次のコマンドを使用して、ローカル リポジトリを
/opt/apigee/data/apigee-mirror/apigee-4.52.00.tar.gz
という名前の単一の .tar ファイルにパッケージ化します。/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
- Edge を更新するノードに .tar ファイルをコピーします。たとえば、新しいノードの
/tmp
ディレクトリにコピーします。 - 新しいノードで、tar ファイルを
/tmp
ディレクトリに展開します。tar -xzf apigee-4.52.00.tar.gz
このコマンドにより、.tar ファイルを含むディレクトリに
repos
という名前の新しいディレクトリが作成されます。例:/tmp/repos
/tmp/repos
から Edgeapigee-service
ユーティリティと依存関係をインストールします。sudo bash /tmp/repos/bootstrap_4.52.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
このコマンドには、Repos ディレクトリへのパスが含まれていることに注意してください。
- ローカル リポジトリがあるノードで、次のコマンドを使用して、ローカル リポジトリを
- Nginx ウェブサーバーを使用して apigee-service をインストールするには:
- Edge apigee-setup ユーティリティをインストールするの「Nginx ウェブサーバーを使用してリポジトリからインストールする」の説明に従って、Nginx ウェブサーバーを構成します。
- リモートノードで、Edge
bootstrap_4.52.00.sh
ファイルを/tmp/bootstrap_4.52.00.sh
にダウンロードします。/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.00.sh -o /tmp/bootstrap_4.52.00.sh
ここで、uName:pWord はリポジトリ用に以前に設定したユーザー名とパスワード、remoteRepo はリポジトリ ノードの IP アドレスまたは DNS 名です。
- リモートノードで、Edge
apigee-setup
ユーティリティと依存関係をインストールします。sudo bash /tmp/bootstrap_4.52.00.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 Serverldap
: 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.00 のロールバックの説明に従ってください。
マシンの更新順序
Edge インストールでマシンを更新する順序は重要です。
- 他のノードを更新する前に、すべての Cassandra ノードと ZooKeeper ノードを更新する必要があります。
- 複数の Edge コンポーネント(Management Server、Message Processor、Router、QPID Server ではなく Postgres Server を除く)を搭載したマシンの場合は、
-c edge
オプションを使用してすべてを同時に更新します。 - 複数のマシンで行うように指定されたステップは、指定されたマシン順に実行します。
- Monetization の更新に特別な手順はありません。
-c edge
オプションを指定すると更新されます。
1 ノード スタンドアロン アップグレード
1 ノードのスタンドアロン構成を 4.52.00 にアップグレードするには:
- すべてのコンポーネントを更新します。
/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 の Cassandra と ZooKeeper を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
- マシン 2 の Qpid と Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid,ps -f configFile
- マシン 1 の LDAP を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
- マシン 2 と 1 の Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -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 の Cassandra と ZooKeeper を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
- マシン 4 の Qpid と Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid, ps -f configFile
- マシン 5 の Qpid と Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid, ps -f configFile
- マシン 1 の LDAP を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
- マシン 4、5、1、2、3 の Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -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 の Cassandra と ZooKeeper を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
- マシン 6、7 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -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
- マシン 6、7、8、9、1、4、5 の順番で Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -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 の Cassandra と ZooKeeper を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
- マシン 12、13 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -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
- マシン 12、13、8、9、6、7、10、11 の順番で Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -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 のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。
- Cassandra と ZooKeeper を更新します。
- データセンター 1 のマシン 1、2、3 で、次のコマンドを実行します。
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
- データセンター 2 のマシン 7、8、9 で、次のコマンドを実行します。
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
- データセンター 1 のマシン 1、2、3 で、次のコマンドを実行します。
- qpidd を更新します。
- データセンター 1 のマシン 4、5 で、次の手順を実施します。
- マシン 4 の
qpidd
を更新します。/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- マシン 5 の
qpidd
を更新します。/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- マシン 4 の
- データセンター 2 のマシン 10、11 で、次の手順を実施します。
- マシン 10 の
qpidd
を更新します。/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- マシン 11 の
qpidd
を更新します。/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- マシン 10 の
- データセンター 1 のマシン 4、5 で、次の手順を実施します。
- Postgres を更新します。
- データセンター 1 のマシン 6
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- データセンター 2 のマシン 12
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- データセンター 1 のマシン 6
- LDAP を更新します。
- データセンター 1 のマシン 1
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
- データセンター 2 のマシン 7
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
- データセンター 1 のマシン 1
- Edge コンポーネントを更新します。
- データセンター 1 のマシン 4、5、6、1、2、3
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- データセンター 2 のマシン 10、11、12、7、8、9
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- データセンター 1 のマシン 4、5、6、1、2、3
- 新しい UI(
ue
)または従来の UI(ui
)を更新します。- データセンター 1 のマシン 1:
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
- データセンター 2 のマシン 7:
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
- データセンター 1 のマシン 1:
apigee-adminapi
がインストールされている場合は、apigee-adminapi
ユーティリティを更新します。- データセンター 1 のマシン 1:
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
- データセンター 2 のマシン 7:
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
- データセンター 1 のマシン 1:
- Apigee SSO がインストールされている場合は、Apigee SSO を更新します。
- データセンター 1 のマシン 1:
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
- データセンター 2 のマシン 7:
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。
- データセンター 1 のマシン 1:
- マシン 1 と 7 で新しい Edge UI(
edge-management-ui
)または従来の Edge UI(edge-ui
)コンポーネントを再起動します。/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
標準以外の構成の場合
標準以外の構成がある場合は、次の順序で Edge コンポーネントを更新します。
- ZooKeeper
- Cassandra
- qpidd、ps
- LDAP
- Edge。すべてのノードの「-c edge」プロファイルを、Qpid Server、Edge Postgres Server、Management Server、Message Processor、Router の順で使用します。
- Edge UI(クラシックまたは新規)
apigee-adminapi
- Apigee SSO
更新が完了したら、Edge UI コンポーネントを実行しているすべてのマシンで、必ず Edge UI コンポーネントを再起動します。
- Edge