Apigee Edge 4.53.00 のロールバック

Edge 4.53.00 への更新時にエラーが発生した場合、エラーの原因となったコンポーネントをロールバックしてから更新を再試行できます。

Edge 4.53.00 は次のマイナー リリース バージョンにロールバックできます。

  • バージョン 4.52.02

バージョンのロールバックでは、アップグレードした可能性のあるすべてのコンポーネントをロールバックします。また、Cassandra をバージョン 4.52.02 にロールバックする場合は、特別な考慮事項を考慮する必要があります。

ロールバックを行うシナリオには、次の 2 つがあります。

  1. 以前のメジャー リリースまたはマイナー リリースにロールバックする。たとえば、4.53.00 から 4.52.02 へのロールバックです。
  2. 同じリリースの前のパッチリリースへのロールバック。たとえば、4.53.00.01 から 4.53.00.00 へのロールバックです。

詳細については、Apigee Edge リリース プロセスをご覧ください。

ロールバックの順序

コンポーネントのロールバックは、アップグレードされた順序の逆順で行う必要があります。ただし、管理サーバーは Cassandra の後にロールバックする必要があります。

Private Cloud 4.53.00 の一般的なロールバックの順序は次のようになります。

  1. Postgres、Qpid、その他の分析関連コンポーネントをロールバックする
  2. Router と Message Processor をロールバックする
  3. Cassandra、Zookeeper のロールバック
  4. Management Server をロールバックする

たとえば、Cassandra クラスタ全体、すべての管理サーバー、いくつかの RMP をバージョン 4.52.02 からバージョン 4.53.00 にアップグレードし、ロールバックするとします。この場合は、次のようになります。

  1. すべての RMP を 1 つずつロールバックする
  2. バックアップを使用して Cassandra クラスタ全体をロールバックする
  3. Edge Management Server ノードを 1 つずつロールバックする

ロールバックを実施できるユーザー

ロールバックを行うユーザーは、Edge を更新したユーザーか、root として実行するユーザーである必要があります。

デフォルトでは、Edge コンポーネントはユーザー「apigee」として動作します。ただし、場合によっては別のユーザーとして Edge コンポーネントを実行することもあります。たとえば、Router が特権付きポート（1000 未満のポート）にアクセスする必要がある場合、Router を root として実行するか、これらのポートに対するアクセス権限が割り当てられたユーザーとして実行しなければなりません。あるいは、あるコンポーネントをあるユーザーとして実行し、別のコンポーネントを別のユーザーとして実行することもできます。

共通のコードを使用するコンポーネント

次の Edge コンポーネントは共通のコードを共有します。したがって、ノード上でこれらのコンポーネントのいずれかをロールバックする場合は、そのノード上でこれらのコンポーネントをすべてロールバックする必要があります。

  • edge-management-server（Management Server）
  • edge-message-processor（Message Processor）
  • edge-router（ルーター）
  • edge-postgres-server（Postgres Server）
  • edge-qpid-server（Qpid Server）

たとえば、あるノードに Management Server、Router、Message Processor がインストールされている場合、このうちのいずれかをロールバックするとしたら、これら 3 つのコンポーネントのすべてをロールバックする必要があります。

Cassandra のロールバック

Cassandra のロールバック

特定のノードで Cassandra のメジャー アップグレードが実行されると、Cassandra はそのノードに保存されているデータのスキーマを変更します。そのため、直接のインプレース ロールバックは実現できません。

ロールバックのシナリオ

Edge for Private Cloud 4.53.00 で使用可能な Cassandra 4.0.X は、Private Cloud 4.52.02 の他のコンポーネントと互換性があります。

使用できるさまざまなロールバック戦略の概要については、以下の表をご覧ください。

シナリオ ロールバック戦略
単一の DC、一部の Cassandra ノードがアップグレードされている バックアップを使用する
単一の DC、すべての Cassandra ノードがアップグレードされている Cassandra をロールバックしないでください。他のコンポーネントはロールバックできます。
単一の DC、すべてのノード（Cassandra など）がアップグレードされている Cassandra をロールバックしないでください。他のコンポーネントはロールバックできます。
複数の DC、1 つの DC の一部のノードがアップグレードされた 既存の DC から再構築する
複数の DC、一部の DC のすべての Cassandra ノードがアップグレードされた 既存の DC から再構築する
複数の DC、最後の DC の Cassandra ノードがアップグレードされている アップグレードを完了してみてください。実行できない場合は、バックアップを使用して 1 つの DC をロールバックします。ロールバックされた DC から残りの DC を再構築します。
複数の DC、すべての Cassandra ノードがアップグレードされている Cassandra をロールバックしないでください。他のコンポーネントはロールバックできます。
複数の DC、すべてのノード（Cassandra など）がアップグレードされた Cassandra をロールバックしないでください。他のコンポーネントはロールバックできます。

一般的な考慮事項

ロールバックを検討する際は、次の点に注意してください。

  • ランタイム コンポーネントまたは管理コンポーネントのロールバック: edge-management-server、edge-message-processor などのコンポーネントや、Cassandra 以外のコンポーネントを Private Cloud バージョン 4.52.02 にロールバックする場合は、Cassandra をロールバックしないことをおすすめします。Private Cloud 4.53.00 に付属の Cassandra は、Edge for Private Cloud 4.52.02 の Cassandra 以外のすべてのコンポーネントと互換性があります。Cassandra がバージョン 4.0.13 のままである間は、ここに記載されている方法を使用して Cassandra 以外のコンポーネントをロールバックできます。
  • Cassandra クラスタ全体が 4.0.X にアップグレードされた後のロールバック: Private Cloud バージョン 4.53.00 へのアップグレードの一環として Cassandra クラスタ全体がバージョン 4.0.X にアップグレードされた場合は、このクラスタ設定を続行し、Cassandra をロールバックしないことをおすすめします。Private Cloud バージョン 4.52.02 の edge-management-server、edge-message-processor、edge-router などのコンポーネントは、Cassandra バージョン 4.0.X と互換性があります。
  • Cassandra のアップグレード中の Cassandra のロールバック: Cassandra のアップグレード中に問題が発生した場合は、ロールバックを検討してください。この記事に記載されているロールバック戦略は、アップグレード プロセス中の状態に基づいて実施できます。
  • バックアップを使用したロールバック: Cassandra 4.0.X から取得したバックアップは、Cassandra 3.11.X のバックアップと互換性がありません。バックアップの復元を使用して Cassandra をロールバックするには、アップグレードを試みる前に Cassandra 3.11.X のバックアップを作成する必要があります。

再構築を使用して Cassandra をロールバックする

前提条件

  • 複数のデータセンターにわたって Edge for Private Cloud 4.52.02 クラスタを運用している。
  • Cassandra を 3.11.X から 4.0.X にアップグレードするプロセスで、アップグレード中に問題が発生しました。
  • クラスタに、古いバージョンの Cassandra（Cassandra 3.11.X）をまだ実行している完全に機能するデータセンターが少なくとも 1 つある。

この手順は、既存のデータセンターからのデータ ストリーミングに依存しています。Cassandra に保存されているデータの量によっては、かなりの時間がかかることがあります。ロールバックの進行中に、ランタイム トラフィックをこのデータセンターから転送できるように準備する必要があります。

手順の概要

  1. ロールバックするデータセンター（部分的にアップグレードされたもの、完全にアップグレードされたもののいずれか）を 1 つ選択します。ランタイム トラフィックを別の機能しているデータセンターに転送します。
  2. データセンター内のシードノードを特定し、いずれかのシードノードから開始します。
  3. Cassandra ノードを停止、アンインストール、クリーンアップします。
  4. ノードに古いバージョンの Cassandra をインストールし、必要に応じて構成します。
  5. 先ほど追加した余分な構成を削除します。
  6. データセンター内のすべてのシードノードに対して、上記の手順を 1 つずつ繰り返します。
  7. データセンター内の残りのすべての Cassandra ノードに対して、上記の手順を 1 つずつ繰り返します。
  8. 既存の機能するデータセンターからノードを 1 つずつ再構築します。
  9. Cassandra に接続されているデータセンター内のすべての edge-* コンポーネントを再起動します。
  10. トラフィックをテストして、このデータセンターにリダイレクトします。
  11. データセンターごとに、上記の手順を 1 つずつ繰り返します。

詳細な手順

  1. すべての Cassandra ノードまたは一部の Cassandra ノードがアップグレードされるデータセンターを 1 つ選択します。このデータセンターの Cassandra ノードがロールバックされている間、このデータセンターからのすべてのランタイム プロキシ トラフィックと管理トラフィックを転送します。ノードで nodetool ring コマンドを実行したときに、すべての Cassandra ノードが UN（Up/Normal）状態であることを確認します。特定のノードがダウンしている場合は、問題をトラブルシューティングし、それらのノードを復元してから続行します。

    下記の例をご覧ください。

    /opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

    ノードで nodetool describecluster を実行すると、クラスタ全体の現在の状態を把握できます。たとえば、次の例は、すべての DC-1 ノードが Cassandra バージョン 4 で、すべての DC-2 ノードが Cassandra バージョン 3 である 2 つのデータセンター クラスタのインスタンスを示しています。

    # On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    3.11.16: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
  2. データセンター内のシードノードを特定します。付録のシードノードを特定する方法のセクションを参照してください。シードノードのいずれかで次の手順を実行します。
  3. Cassandra のノードからデータを停止、アンインストール、クリーンアップします。このデータセンターの Cassandra バージョン 4 の最初のシードノードを選択します。Stop it. 
    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra
  4. ノードに古い Cassandra ソフトウェアをインストールし、いくつかの構成を設定します。Edge for Private Cloud 4.52.02 のブートストラップ ファイルを実行します。
    5. # Download bootstrap of 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord

# Execute bootstrap of 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
  5. /opt/apigee/customer/application/cassandra.properties ファイルを作成または編集します。
  6. ファイルに次の内容を追加します。ipOfNode は、Cassandra が他の Cassandra ノードとの通信に使用するノードの IP アドレスです。
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. ファイルの所有者が Apigee ユーザーであり、そのユーザーがファイルを読み取れることを確認します。
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Cassandra をインストールして設定します。
    # Install cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  9. ノードが起動したことを確認します。このノードとクラスタ内の他のノードで次のコマンドを確認します。ノードが「UN」（Up/Normal）状態であることを報告する必要があります。
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. 以前に追加した余分な構成をファイル /opt/apigee/customer/application/cassandra.properties から削除します。
  11. データセンター内のすべての Cassandra シードノードで、ステップ 3 ～ 10 を 1 つずつ繰り返します。
  12. データセンター内の残りのすべての Cassandra ノードで、ステップ 3 ～ 10 を 1 つずつ繰り返します。
  13. 古い Cassandra バージョンを実行しているデータセンターから、データセンター内のすべてのノードを再構築します。この手順は、一度に 1 つのノードで実行します。
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    この手順には時間がかかることがあります。必要に応じて streamingthroughput を調整できます。nodetool netstats でオペレーションの完了ステータスを確認します。

  14. （省略可）データが再構築されない場合は、Cassandra ノードで修復コマンドを実行します。
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. データセンター内のすべての edge-* コンポーネントを 1 つずつ再起動します。
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  16. トラフィックを検証して、このデータセンターにリダイレクトします。このデータセンターでランタイム トラフィックと管理 API の検証を実行し、プロキシと管理 API のトラフィックをこのデータセンターにリダイレクトします。
  17. ロールバックするデータセンターごとに上記の手順を繰り返します。

バックアップを使用して Cassandra をロールバックする

前提条件

  1. Cassandra を 3.11.X から 4.0.X にアップグレードするプロセスで、アップグレード中に問題が発生しました。
  2. ロールバックするノードのバックアップがある。バックアップは、3.11.X から 4.0.X へのアップグレードを試みる前に作成されました。

手順

  1. ロールバックするノードを 1 つ選択します。バックアップを使用してデータセンター内のすべてのノードをロールバックする場合は、まずシードノードから開始します。付録の「シードノードを特定する方法」のセクションを参照してください。

  2. Cassandra ノードを停止、アンインストール、クリーンアップします。

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

  3. ノードに古い Cassandra ソフトウェアをインストールして構成します。

    • Edge for Private Cloud 4.52.02 のブートストラップ ファイルを実行します。
      • # Download bootstrap for 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’

# Execute bootstrap for 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
    • /opt/apigee/customer/application/cassandra.properties ファイルを作成または編集します。
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • ファイルの所有者が Apigee ユーザーであり、読み取り可能であることを確認します。
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Cassandra をインストールして設定します。
      • # Install Cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

    ノードが起動したことを確認します。このノードとクラスタ内の他のノードで次のコマンドを確認します。ノードは、このノードが「UN」状態であることを報告する必要があります。

    /opt/apigee/apigee-cassandra/bin/nodetool status

  4. Cassandra サービスを停止してバックアップを復元します。詳しくは、バックアップと復元のドキュメントをご覧ください。

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

  5. バックアップが復元されたら、追加の構成を削除します。

    以前に追加した構成を /opt/apigee/customer/application/cassandra.properties ファイルから削除します。

  6. ノードで Cassandra サービスを起動します。

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

  7. バックアップを使用してロールバックする Cassandra ノードごとに、手順を 1 つずつ繰り返します。

  8. すべての Cassandra ノードが復元されたら、edge-* コンポーネントを 1 つずつ再起動します。

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

バックアップの最適化（詳細オプション）

最新のデータを含むレプリカが使用可能な場合は、バックアップの復元中にデータ損失を最小限に抑える（または排除する）ことができます。レプリカが使用可能な場合は、バックアップを復元した後、復元されたノードで修復を実行します。

付録

シードノードを特定する方法

データセンター内の任意の Cassandra ノードで、次のコマンドを実行します。

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

このコマンドは複数の行を出力します。出力の最後の行を確認します。最後の行にリストされている IP アドレスはシードノードです。次の例では、DC-1-IP1、DC-1-IP2、DC-2-IP1、DC-2-IP2 がシードノードの IP です。

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

以前のメジャー リリースまたはマイナー リリースにロールバックする

以前のメジャー リリースまたはマイナー リリースにロールバックするには、該当するコンポーネントをホストしている各ノード上で、次の手順を行います。

  1. ロールバック先のバージョンの bootstrap.sh ファイルをダウンロードします。

    • 4.52.02 にロールバックする場合は、bootstrap_4.52.02.sh をダウンロードします。
      curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
  2. ロールバックするコンポーネントを停止します。
    1. ノード上の共通のコードを使用するコンポーネントをロールバックする場合、次の例に示すように、それらすべてのコンポーネントを停止する必要があります。
      /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
    2. ノード上のそれ以外のコンポーネントをロールバックする場合は、そのコンポーネントのみを停止します。
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Monetization をロールバックする場合は、すべての Management Server ノードと Message Processor ノードから Monetization をアンインストールします。
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. ロールバックするコンポーネントをノードからアンインストールします。
    1. ノード上の共通のコードを使用するコンポーネントをロールバックする場合、次の例に示すように、edge-gateway コンポーネント グループをアンインストールして、それらすべてのコンポーネントをアンインストールする必要があります。
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
    2. 次のように Nginx をロールバックします。
      ###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.x
    3. ノード上のそれ以外のコンポーネントをロールバックする場合は、次の例に示すように、そのコンポーネントのみをアンインストールします。
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      ここで、component はコンポーネント名です。

    4. Edge Router をロールバックする場合、edge-gateway コンポーネント グループをアンインストールするだけでなく、/opt/nginx/conf.d ファイルの内容を削除する必要もあります。
      cd /opt/nginx/conf.d
rm -rf *
  5. 4.53.00 バージョンの apigee-setup をアンインストールします。
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. 4.52.02 バージョンの apigee-service ユーティリティとその依存関係をインストールします。次の例では、4.52.02 バージョンの apigee-service をインストールします。
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

    ここで、uName と pWord は Apigee から受け取ったユーザー名とパスワードです。pWord を省略すると、パスワードの入力を求められます。

    エラーが発生した場合は、手順 1 で bootstrap.sh ファイルをダウンロードしたことを確認してください。

  7. apigee-setup をインストールします。
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. 古いバージョンのコンポーネントをインストールします。
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    ここで、component はインストールするコンポーネント、configFile は古いバージョンの構成ファイルです。

  9. Qpid をロールバックしている場合は、iptables を消去します。
    sudo iptables -F
  10. ロールバックするコンポーネントをホストしているノードのそれぞれで、上記のプロセスを繰り返します。

以前のパッチ リリースにロールバックする

特定のパッチ リリースにコンポーネントをロールバックするには、該当するコンポーネントをホストしている各ノード上で、次の手順を行います。

  1. 該当するバージョンのコンポーネントをダウンロードします。
    /opt/apigee/apigee-service/bin/apigee-service component_version install

    ここで、component_version はインストールするコンポーネントとパッチ リリースです。例:

    /opt/apigee/apigee-service/bin/apigee-service edge-ui-4.53.00-0.0.20254 install

    Apigee オンライン リポジトリを使用している場合、次のコマンドを使用して、コンポーネントの利用可能なバージョンを確認できます。

    yum --showduplicates list comp

    次に例を示します。

    yum --showduplicates list edge-ui
  2. apigee-setup を使用してコンポーネントをインストールします。
    /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile

    次に例を示します。

    /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile

    コンポーネントをインストールする際は、コンポーネント名のみを指定し、バージョンは指定しないことにご注意ください。

  3. ロールバックするコンポーネントをホストしているノードのそれぞれで、上記のプロセスを繰り返します。

mTLS をロールバックする

mTLS 更新をロールバックするには、すべてのホストで次の手順を行います。

  1. Apigee を停止します。 
    apigee-all stop
  2. mTLS を停止します。 
    apigee-service apigee-mtls uninstall
  3. mTLS を再インストールします。 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf