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 リリース プロセスをご覧ください。

ロールバックの順序

コンポーネントのロールバックは、アップグレードされた順序の逆順で行う必要があります。ただし、Management Server は 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（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 ノードのすべてまたは一部がアップグレードされるデータセンターを 1 つ選択します。このデータセンターの Cassandra ノードがロールバックされている間、このデータセンターからのすべてのランタイム プロキシ トラフィックと管理トラフィックを転送します。ノードで nodetool ring コマンドが実行されたときに、すべての Cassandra ノードが UN（起動/正常）状態であることを確認します。特定のノードが停止している場合は、問題のトラブルシューティングを行い、それらのノードを復元してから続行します。

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

    /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 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

Cassandra 構成を設定する

  1. /opt/apigee/customer/application/cassandra.properties ファイルを作成または編集します。
  2. ファイルに次の内容を追加します。ipOfNode は、Cassandra が他の Cassandra ノードとの通信に使用するノードの IP アドレスです。 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  3. ファイルの所有者が Apigee ユーザーであり、Apigee ユーザーがファイルを読み取れるようにします。 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Cassandra をインストールして設定します。
    • Cassandra バージョン 3.11.X をインストールします。 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
    • 標準構成ファイルを渡して Cassandra を設定します。 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
    • Cassandra 3.11.X がインストールされ、サービスが実行されていることを確認します。 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  5. ノードが起動したことを確認します。このノードとクラスタ内の他のノードで次のコマンドをチェックします。ノードは「UN」（起動/正常）状態であると報告します。 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  6. ファイル /opt/apigee/customer/application/cassandra.properties から、先ほど追加した余分な構成を削除します。
  7. データセンター内のすべての Cassandra シードノードで、手順 3 ～ 6 を 1 ノードずつ繰り返します。
  8. データセンター内の残りのすべての Cassandra ノードで、手順 3 ～ 6 を 1 ノードずつ繰り返します。
  9. 古いバージョンの Cassandra を実行しているデータセンターから、データセンター内のすべてのノードを再ビルドします。この手順は、1 つのノードずつ実行します。 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
    この手順には時間がかかることがあります。必要に応じて streamingthroughput を調整できます。次のコマンドを使用してステータスを確認します。 
    /opt/apigee/apigee-cassandra/bin/nodetool netstats
  10. データセンター内のすべての 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
  11. トラフィックを検証して、このデータセンターに戻します。このデータセンターでランタイム トラフィックと管理 API の検証を実行し、プロキシと管理 API トラフィックをこのデータセンターに再ルーティングします。
  12. ロールバックするデータセンターごとに上記の手順を繰り返します。

バックアップを使用して 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. ノード上のそれ以外のコンポーネントをロールバックする場合は、そのコンポーネントのみをアンインストールします。次の例をご覧ください。 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

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

    3. 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