Edge 4.52.02 への更新時にエラーが発生した場合は、エラーの原因となったコンポーネントをロールバックしてから更新を再試行できます。
Edge 4.52.02 は、次のいずれかのメジャー リリース バージョンにロールバックできます。
- バージョン 4.52.01
- バージョン 4.52.00
- バージョン 4.51.00
バージョンをロールバックするには、アップグレードした可能性のあるすべてのコンポーネントをロールバックする必要があります。また、開始したバージョンによっては、特定のソフトウェア コンポーネントをロールバックする前に特別な手順を検討する必要があります。次の表に、ロールバック中に特別な手順が必要になる可能性のあるさまざまなソフトウェア コンポーネントを示します。
バージョンにロールバック | ソフトウェアに関する特別な考慮事項 |
---|---|
4.52.01 | Cassandra |
4.52.00 | Zookeeper、Cassandra、Qpid |
4.51.00 | Zookeeper、Postgres、Cassandra、Qpid |
ロールバックを行うシナリオには、次の 2 つがあります。
- 以前のメジャー リリースまたはマイナー リリースにロールバックする。たとえば、4.52.02 から 4.52.00 へのロールバックです。
- 同じリリースの前の修正プログラム リリースにロールバックする。たとえば、4.52.00.02 から 4.52.00.01 へのロールバックです。
詳細については、Apigee Edge リリース プロセスをご覧ください。
ロールバックの順序
コンポーネントのロールバックは、アップグレードの逆順で行う必要があります。ただし、Management Server は Cassandra の後にロールバックする必要があります。Cassandra、ランタイム コンポーネント、Management Server はすべて、データセンターごと(DC-by-DC)のアプローチを使用してロールバックし、トラフィックを機能しているデータセンターに一時的にリダイレクトする必要があります。
Private Cloud 4.52.02 の一般的なロールバック順序は次のとおりです。
単一データセンター
単一データセンターの設定では、ロールバック プロシージャは実行時のトラフィックと特定の管理 API に大きな影響を与えます。
- Qpid とその他の分析関連コンポーネントをロールバックする
- Router と Message Processor をロールバックする
- Cassandra をロールバックする
- ロールバック Management Server
- Postgres と Zookeeper をロールバックする
複数のデータセンター
マルチデータセンター構成では、ロールバックはデータセンターごと(DC-by-DC)のアプローチに従い、トラフィックを機能しているデータセンターに一時的にリダイレクトする必要があります。これにより、トラフィックの継続性が確保され、ダウンタイムを回避できます。また、Cassandra、Management Server、Runtime ノードの制御されたロールバック プロセスが可能になります。
- すべての DC で Qpid とその他の分析関連コンポーネントをロールバックします。
- 最初のデータセンターでトラフィックをブロックし、トラフィックを他の DC に再ルーティングします。
- 最初のデータセンターの Router と Message Processor をロールバックします。
- 最初のデータセンターで Cassandra をロールバックします。
- 最初のデータセンターの Rollback Management サーバー。
- 最初のデータセンターでトラフィックのブロックを解除し、最後のデータセンターでランタイム ノード、Cassandra、管理サーバーがロールバックされるまで、ステップ 2 ~ 6 に沿って操作します。
- すべての DC で Postgres、Zookeeper、LDAP をロールバックします。
たとえば、Cassandra クラスタ全体、すべての Management Server、いくつかのランタイム メッセージ プロセッサ(RMP)をバージョン 4.52.01 から 4.52.02 にアップグレードし、ロールバックを実行する必要がある場合を考えてみましょう。この場合、ロールバックは次のように行います。
- 最初のデータセンター(データセンター)へのトラフィックをブロックし、他のアクティブな DC にトラフィックを再ルーティングして、サービスの継続性を確保します。
- 最初のデータセンターで Router と Message Processor をロールバックします。
- バックアップまたは VM スナップショットから復元して、最初のデータセンターで Cassandra をロールバックします。
- 最初のデータセンターでManagement Server をロールバックします。
- 最初のデータセンターへのトラフィックのブロックを解除します。
- すべてのランタイム ノード、Cassandra、Management Server がロールバックされるまで、残りの各データセンターで手順 1 ~ 5 を繰り返します。
ロールバックを実施できるユーザー
ロールバックを行うユーザーは、Edge を更新したユーザーか、root として実行するユーザーである必要があります。
デフォルトでは、Edge コンポーネントはユーザー「apigee」として動作します。ただし、場合によっては別のユーザーとして Edge コンポーネントを実行することもあります。たとえば、Router が特権付きポート(1000 未満のポート)にアクセスする必要がある場合、Router を root として実行するか、これらのポートに対するアクセス権限が割り当てられたユーザーとして実行しなければなりません。あるいは、あるコンポーネントをあるユーザーとして実行し、別のコンポーネントを別のユーザーとして実行することもできます。
共通のコードを使用するコンポーネント
次の Edge コンポーネントは共通のコードを共有します。したがって、ノード上でこれらのコンポーネントのいずれかをロールバックする場合は、そのノード上でこれらのコンポーネントをすべてロールバックする必要があります。
edge-management-server
(Management Server)edge-message-processor
(Message Processor)edge-router
(Router)edge-postgres-server
(Postgres Server)edge-qpid-server
(Qpid Server)
たとえば、あるノードに Management Server、Router、Message Processor がインストールされている場合、このうちのいずれかをロールバックするとしたら、これら 3 つのコンポーネントのすべてをロールバックする必要があります。
Cassandra のロールバック
特定の Cassandra ノードで Cassandra のメジャー アップグレードが実行されると、Cassandra はノードに保存されているデータのスキーマを変更するため、直接ロールバックできなくなります。ロールバックには 2 つの方法があります。ロールバック元のアップグレードの状態に基づいて、次のいずれかの方法を使用します。
ロールバックの方法
ロールバックのシナリオ
Edge for Private Cloud 4.52.02 では、Cassandra と、Message Processor と Management Server が Cassandra への接続に使用するドライバがアップグレードされています。そのため、これらの 3 つのコンポーネントのアップグレードとロールバックは密接に関連しています。次の表に、これらの 3 つのコンポーネントのロールバック シナリオの一般的な例を示します。他のコンポーネントのロールバックは、ロールバックの順序のセクションに従って行います。
このセクションでは、上記のアプローチに基づいて、さまざまなロールバック シナリオと推奨される方法論について概説します。
シナリオ | ロールバック戦略 |
---|---|
単一データセンター、一部の Cassandra ノードがアップグレードされている | バックアップの復元 |
単一データセンター、すべての Cassandra ノードがアップグレードされている | バックアップの復元 |
単一データセンター、すべてのノード(Cassandra、Management Server、ランタイム ノード)がアップグレードされている | |
複数のデータセンター、最初のデータセンター内の一部またはすべての Cassandra ノードがアップグレードされている | 既存のデータセンターから再構築する |
複数のデータセンター、最初のデータセンター内のすべての Cassandra ノード、Management Server、ランタイム ノードをアップグレード |
これは一度に 1 つのデータセンターで行う必要があります。 |
複数のデータセンター、最後のデータセンターの一部またはすべての Cassandra ノードがアップグレードされている | |
複数のデータセンター、すべての Cassandra ノード、すべての DC でアップグレードされた Management Server ノードとランタイム ノード |
これは、一度に 1 つのデータセンターで行う必要があります。 |
通常、Cassandra をロールバックする際には、次の点を考慮する必要があります。
- ランタイム コンポーネントまたは管理コンポーネントのロールバック
任意のデータセンター(DC)で Edge Management Server や Edge Message Processor などのコンポーネントを以前の Edge Private Cloud バージョンにロールバックする必要がある場合は、その特定のデータセンターで Cassandra も同時にロールバックしてください。これは、管理トラフィックとランタイム トラフィックの障害を防ぐために必要です。
- バックアップを使用したロールバック
Cassandra 3.11.x から取得したバックアップは、Cassandra 2.1.x のバックアップと互換性がありません。バックアップの復元を使用してロールバックを有効にするには、アップグレードを実行する前に Cassandra 2.1.x のバックアップを取得してください。
- ロールバック用にデータセンターを分離する
ダウンタイムを回避するには、トラフィックが完全に機能するデータセンターにリダイレクトされ、ロールバック中のデータセンターからブロックされていることを確認します。
再ビルドを使用して Cassandra をロールバックする
前提条件
- 複数のデータセンターにまたがって Edge for Private Cloud 4.51.00 / 4.52.00 / 4.52.01 クラスタを運用している
- Cassandra を 2.1.X から 3.11.X にアップグレードしているときに、アップグレード中に問題が発生した
- クラスタ内に、古いバージョンの Cassandra(Cassandra 2.1.X)がまだ稼働しているデータセンターが 1 つ以上ある
大まかな手順
- ロールバックするデータセンター(部分的にアップグレードまたは完全にアップグレードされたデータセンター)を 1 つ選択します。このデータセンターからすべてのアプリケーション トラフィックを、完全に機能する別のデータセンターにリダイレクトします。
- Router と Message Processor がアップグレードされている場合は、データセンター内のすべての Router ノードと Message Processor ノードを 1 つずつロールバックします。
- 1 つのノードで Cassandra を停止し、アンインストールして、関連するすべてのデータをクリーンアップします。
- 以前のバージョンのブートストラップをインストールし、クリーンアップしたノードに Cassandra バージョン 2.1.x を設定します。
- Cassandra 2.1.x をまだ実行している既存の機能データセンターからノードを再ビルドします。
- データセンター内の残りの Cassandra ノードに対して、1 ノードずつ手順 3 ~ 5 を実行します。
- データセンターで Management Server の設定を再実行します。
- テストを実施してロールバックを検証します。確認したら、アプリケーション トラフィックを復元されたデータセンターにリダイレクトします。
- ロールバックが必要な他の各データセンターで、上記の手順を 1 つずつ繰り返します。
クラスタ内の既存のノードをワイプしてノード再ビルドを行う詳細な手順は次のとおりです。
ロールバックするノードから開始します。
- 次のステップに進む前に、トラフィックが完全に機能するデータセンターにリダイレクトされていることを確認します。
- Router と Message Processor がアップグレードされている場合は、データセンター内のすべての Router ノードと Message Processor ノードを以前のバージョンにロールバックします。
- ノードで Cassandra を停止します。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
- ノードから Cassandra ソフトウェアをアンインストールします。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall
-
ノードからデータ ディレクトリを削除します。
rm -rf /opt/apigee/data/apigee-cassandra
ロールバック先の Edge for Private Cloud の古いバージョンのブートストラップをダウンロードして実行します。
例: 4.52.01 にロールバックする
- 4.52.01 のブートストラップをダウンロードします。
curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’
- 4.52.01 のブートストラップを実行します。
sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord
- ノードに Cassandra ソフトウェアをインストールします。
apigee-service apigee-cassandra install
/opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh
ファイルに次のプロパティを追加します。JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=<cass_ip-address>"
例:
JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=10.0.0.1"
- ノードで Cassandra を設定します。
/opt/apigee/apigee-setup/bin/setup.sh -p c -f configFile
- Cassandra が稼働したら、次のファイル(
/opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh
ファイル)から上記の CWC を削除します。 - Cassandra ノードを再起動する
apigee-service apigee-cassandra restart
- 機能するデータセンターの名前を指定して、ノードで再ビルドを実行します。
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -h <node-IP> <functional-dc>
例:
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -h 10.0.0.1 dc-2
- データセンターでロールバックするノードごとに、上記の手順を 1 つずつ繰り返します。
データセンター内のすべての Cassandra ノードがロールバックされて再構築されたら
- ロールバックするデータセンターで管理サーバー ノードの設定を実行します。ロールバックされたバージョンの Management Server であることを確認します。そうでない場合は、Management Server もロールバックします。
- Management Server を停止します。
/opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
- 収益化を使用している場合は、収益化もアンインストールします。
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
- edge-gateway と apigee-cassandra-client をアンインストールします。
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
- 古いバージョンのブートストラップをダウンロードして実行します。たとえば、次の手順でバージョン 4.52.01 のブートストラップをダウンロードして実行します。
curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’
sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord
- 1 つの Management Server ノードの設定を実行します。
/opt/apigee/apigee-setup/bin/setup.sh -p mt -f configFile
- 上記の手順を完了したら、トラフィックをロールバックされたデータセンターに戻します。
Management Server を古いバージョンにロールバックする
管理サーバーの設定
再ビルド後の最適化
上記の手順では、再ビルド中にノードのすべてのデータがリモート データセンターからストリーミングされます。すべてのレプリカがローカル データセンターにストリーミングされたら、修復を使用してこのプロセスを最適化できます。これにより、データセンター間のストリーミングを回避でき、リモート データセンターからすべてのノードを再ビルドするよりも高速になります。
例: ローカル データセンターに 6 つの Cassandra ノードがあるとします。デフォルトでは、Apigee のレプリケーション係数は 3 であるため、すべてのノードがデータの 50% を保持します。この場合は、上記の手順に沿ってノード #1 と #4 を再ビルドできます。ノード #2、#3、#5、#6 の場合は、次の手順に沿ってバックアップを復元し、修復を実行します。
- ドキュメントに記載されている手順に沿って、ローカル データセンターでレプリカを再ビルドします。
- 残りのノードについては、残りの各ノードで次の手順を 1 つずつ行います。
- このノードでキャプチャしたバックアップを復元します(注: このバックアップは Cassandra のアップグレードを開始する前に取得されたため、古いデータが含まれている可能性があります)。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file
ノードの VM スナップショットがある場合は、Cassandra バックアップを復元する代わりにスナップショットを復元できます。
- バックアップが復元されたら、ノードで Cassandra サービスを起動します。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
- 既存のデータセンターから最新のデータをストリーミングできるように、ノードで修復を実行します。
/opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -dc <local-dc-name>
例:
/opt/apigee/apigee-cassandra/bin/nodetool -h 10.0.0.1 repair -dc dc-1
- 修復するノードごとに、ステップ 2 で説明した上記の手順をすべて繰り返します。
バックアップ / VM スナップショットを使用して Cassandra をロールバックする
この手順は、Cassandra クラスタ全体をアップグレードしてロールバックする場合にのみ使用できます。また、Apigee のバックアップはノード固有です。1 つのノードで取得したバックアップを別のノードに復元することはできません。Cassandra バックアップには、ノードのメタデータ情報(IP アドレス、リング位置など)が含まれます。
前提条件
- 最後のデータセンターで Cassandra を 2.1.X から 3.11.X にアップグレードしているときに、アップグレード中に問題が発生しました。
- ロールバックするアップグレード前のノードのバックアップがあること。バックアップは、2.1.X から 3.11.X へのアップグレードが試行される前に取得されました。
大まかな手順
- ロールバックするデータセンター(部分的にアップグレードまたは完全にアップグレード)を選択します。このデータセンターからすべてのランタイム トラフィックを、完全に機能する別のデータセンターにリダイレクトします。
- Router と Message Processor がアップグレードされている場合は、データセンター内のすべての Router ノードと Message Processor ノードを 1 つずつロールバックします。
- 1 つのノードで Cassandra を停止し、アンインストールして、関連するすべてのデータをクリーンアップします。
- 以前のバージョンのブートストラップをインストールし、クリーンアップしたノードに Cassandra バージョン 2.1.x を設定します。
- Cassandra ノードを停止し、関連するすべてのデータをクリーンアップします。
- アップグレード前に取得したバックアップから Cassandra ノードを復元します。
- データセンター内の残りの Cassandra ノードに対して、手順 3 ~ 6 を 1 ノードずつ繰り返します。
- データセンターで Management Server の設定を再実行します。
- テストを実行して、ロールバックを検証します。確認したら、ランタイム トラフィックを復元されたデータセンターにリダイレクトします。
- ロールバックが必要な他の各データセンターで、上記の手順を 1 つずつ繰り返します。
- (省略可)データセンター間でデータの不整合がある場合は、すべてのデータセンターのすべての Cassandra ノードで repair コマンドを実行します。
バックアップ/VM スナップショットを使用して Cassandra をロールバックする詳細な手順
クラスタ内の Cassandra ノードは 1 つから始めます。
- 次のステップに進む前に、トラフィックが完全に機能するデータセンターにリダイレクトされていることを確認します。
- Router と Message Processor がアップグレードされている場合は、データセンター内のすべての Router ノードと Message Processor ノードを以前のバージョンにロールバックします。
- ノードで Cassandra を停止します。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
- ノードから Cassandra ソフトウェアをアンインストールします。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall
- ノードからデータ ディレクトリを削除します。
rm -rf /opt/apigee/data/apigee-cassandra
ロールバック先の Edge for Private Cloud の古いバージョンのブートストラップをダウンロードして実行します。
例: 4.52.01 にロールバックする
- 4.52.01 のブートストラップをダウンロードします。
curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’
- 4.52.01 のブートストラップを実行します。
sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord
- ノードで Cassandra を設定します。
/opt/apigee/apigee-setup/bin/setup.sh -p c -f configFile
- ノードで Cassandra を停止します。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
- ノードのデータ ディレクトリを削除します。
rm -rf /opt/apigee/data/apigee-cassandra/data
- バックアップを復元する:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file
- ノードで Cassandra サービスを起動します。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
- 各 Cassandra ノードで手順を 1 つずつ繰り返します。
- ロールバックするデータセンターで管理サーバー ノードの設定を実行します。ロールバックされたバージョンの Management Server であることを確認します。そうでない場合は、Management Server もロールバックします。
- 上記の手順を完了したら、トラフィックをロールバックされたデータセンターに戻します。
- (省略可)データセンター間でデータの不整合がある場合は、すべてのデータセンターのすべての Cassandra ノードで repair コマンドを実行します。
/opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -pr
Zookeeper 3.8.3 アップデートをロールバックする
バージョン 4.52.00 または 4.51.00 にロールバックする場合は、Zookeeper をロールバックする前に、特別な手順を参照する必要があります。これらの手順はロールバックに記載されています。
バージョン 4.52.01 にロールバックする場合は、下記の以前のメジャー リリースまたはマイナー リリースにロールバックするセクションに記載されているように、ソフトウェアをロールバックするように Zookeeper をロールバックします。
Qpid をロールバックする
バージョン 4.52.00 または 4.51.00 にロールバックする場合は、Qpid をロールバックする前に特別な手順を参照する必要があります。これらの手順はロールバックに記載されています。
バージョン 4.52.01 にロールバックする場合は、以前のメジャー リリースまたはマイナー リリースにロールバックするに記載されているように、ソフトウェアをロールバックするように Qpid をロールバックします。
Postgres 10.17 更新をロールバックする
バージョン 4.51.00 にロールバックする場合は、Postgres をロールバックする前に特別な手順を確認する必要があります。これらの手順はロールバックに記載されています。
バージョン 4.52.01 または 4.52.00 にロールバックする場合は、下記の以前のメジャー リリースまたはマイナー リリースにロールバックするセクションに記載されているように、ソフトウェアをロールバックするように Postgres をロールバックします。
以前のメジャー リリースまたはマイナー リリースにロールバックする
以前のメジャー リリースまたはマイナー リリースにロールバックするには、コンポーネントをホストしている各ノード上で次の操作を行います。
-
ロールバック先のバージョンの
bootstrap.sh
ファイルをダウンロードします。- 4.51.00 にロールバックする場合は、
bootstrap_4.51.00.sh
をダウンロードします。
- 4.51.00 にロールバックする場合は、
- ロールバックするコンポーネントを停止します。
- ノード上の共通のコードを使用するコンポーネントをロールバックする場合は、次の例に示すように、それらすべてのコンポーネントを停止する必要があります。
/opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
- ノード上のそれ以外のコンポーネントをロールバックする場合は、そのコンポーネントのみを停止します。
/opt/apigee/apigee-service/bin/apigee-service component stop
- ノード上の共通のコードを使用するコンポーネントをロールバックする場合は、次の例に示すように、それらすべてのコンポーネントを停止する必要があります。
- Monetization をロールバックする場合は、すべての Management Server ノードと Message Processor ノードから Monetization をアンインストールします。
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
- ロールバックするコンポーネントをノードからアンインストールします。
- ノード上の共通のコードを使用するコンポーネントをロールバックする場合は、次の例に示すように、
edge-gateway
コンポーネント グループとapigee-cassandra-client
コンポーネント グループをアンインストールして、それらすべてのコンポーネントをアンインストールする必要があります。/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
- ノード上のそれ以外のコンポーネントをロールバックする場合は、そのコンポーネントのみをアンインストールします。
/opt/apigee/apigee-service/bin/apigee-service component uninstall
ここで、component はコンポーネント名です。
- Edge Router をロールバックする場合、
edge-gateway
コンポーネント グループをアンインストールするだけでなく、/opt/nginx/conf.d
ファイルの内容を削除する必要もあります。cd /opt/nginx/conf.d
rm -rf *
- ノード上の共通のコードを使用するコンポーネントをロールバックする場合は、次の例に示すように、
- 4.52.02 バージョンの
apigee-setup
をアンインストールします。/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
- 4.51.00 バージョンの
apigee-service
ユーティリティとその依存関係をインストールします。次の例では、4.51.00 バージョンのapigee-service
をインストールします。sudo bash /tmp/bootstrap_4.51.00.sh apigeeuser=uName apigeepassword=pWord
ここで、uName と pWord は Apigee から取得したユーザー名とパスワードです。pWord を省略すると、パスワードの入力を求められます。
エラーが発生した場合は、手順 1 で
bootstrap.sh
ファイルをダウンロードしたことを確認してください。 apigee-setup
をインストールします。/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
- 古いバージョンのコンポーネントをインストールします。
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
ここで、component はインストールするコンポーネント、configFile は古いバージョンの構成ファイルです。
- Qpid をロールバックしている場合は、iptables を消去します。
sudo iptables -F
- ロールバックするコンポーネントをホストしているノードのそれぞれで、上記のプロセスを繰り返します。
以前のパッチ リリースにロールバックする
特定のパッチ リリースにコンポーネントをロールバックするには、コンポーネントをホストしている各ノードで次の操作を行います。
- 該当するバージョンのコンポーネントをダウンロードします。
/opt/apigee/apigee-service/bin/apigee-service component_version install
ここで、component_version はインストールするコンポーネントとパッチ リリースです。例:
/opt/apigee/apigee-service/bin/apigee-service edge-ui-4.51.05-0.0.3749 install
Apigee オンライン リポジトリを使用している場合、次のコマンドを使用して、コンポーネントの利用可能なバージョンを確認できます。
yum --showduplicates list component
次に例を示します。
yum --showduplicates list edge-ui
apigee-setup
を使用してコンポーネントをインストールします。/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
次に例を示します。
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
コンポーネントをインストールする際は、コンポーネント名のみを指定し、バージョンは指定しないことにご注意ください。
- ロールバックするコンポーネントをホストしているノードのそれぞれで、上記のプロセスを繰り返します。
mTLS をロールバックする
mTLS 更新をロールバックするには、すべてのホストで次の手順を行います。
- Apigee を停止します。
apigee-all stop
- mTLS を停止します。
apigee-service apigee-mtls uninstall
- mTLS を再インストールします。
apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf