Apigee では、Edge for Private Cloud をバージョン 4.51.00 またはバージョン 4.52.00 からバージョン 4.52.01 に直接アップグレードできます。このページでは、どちらのアップグレードを行う方法についても説明します。
更新を行えるユーザー
更新を行うユーザーは、最初に 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.3 へのアップグレードが必須
Edge for Private Cloud のこのリリースには、Zookeeper 3.8.3 へのアップグレードが含まれています。このアップグレードの一環として、すべての Zookeeper データが Zookeeper 3.8.3 に移行されます。
Zookeeper をアップグレードする前に、Zookeeper メンテナンス ガイドをお読みください。ほとんどの Edge 本番環境システムでは、複数のデータセンターに分散された Zookeeper ノードのクラスタを使用します。これらのノードの一部は、Zookeeper リーダーの選出に参加するボーターとして構成され、残りはオブザーバとして構成されます。詳細については、 リーダー、フォロワー、ボーター、オブザーバについてをご覧ください。ボーターノードはリーダーを選出します。その後、ボーターノード自体がフォロワーになります。
更新プロセス中に、リーダーノードがシャットダウンされたときに、Zookeeper への書き込みが一時的に遅れたり、失敗したりすることがあります。これにより、プロキシのデプロイ オペレーションなど、Zookeeper に書き込む管理オペレーションや、メッセージ プロセッサの追加や削除など、Apigee インフラストラクチャの変更に影響する可能性があります。以下の手順に沿って Zookeeper をアップグレードする際、Apigee のランタイム API に影響はありません(これらのランタイム API が管理 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.3-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 ノードが 1 つしかない Edge のスタンドアロン インストールでは、Mode
は standalone に設定されます。 - ZooKeeper ノードごとにステップ 1 と 2 を繰り返します。
オーザーバー ノードとフォロワー ノードで Zookeeper をアップグレードする
各オブザーバー ノードとフォロワー ノードで Zookeeper をアップグレードします。
- 外部インターネット接続があるノードで 4.52.01 に更新するの説明に沿って、Edge for Private Cloud 4.52 のブートストラップをダウンロードして実行します。プロセスは、ノードに外部インターネット接続があるかどうか、オフライン インストールを実行しているかどうかによって異なる場合があります。
- Zookeeper コンポーネントをアップグレードします。
注: これらのノードに他のコンポーネント(Cassandra など)がインストールされている場合は、今すぐアップグレードすることも(cs、zk プロファイルなど)、後でアップグレードすることもできます。Apigee では、まず Zookeeper のみをアップグレードし、クラスタが正常に動作していることを確認してから、他のコンポーネントをアップグレードすることをおすすめします。/opt/apigee/apigee-setup/bin/update.sh -c zk -f <silent-config-file>
- Zookeeper オブザーバー ノードとフォロワー ノードのそれぞれで、上記の手順を繰り返します。
リーダーをシャットダウンする
すべてのオブザーバー ノードとフォロワー ノードをアップグレードしたら、リーダーをシャットダウンします。リーダーとして識別されたノードで、次のコマンドを実行します。
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
このイベント中、新しいリーダーが選出される前に、Zookeeper で一時的な遅延や書き込みエラーが発生する可能性があります。これにより、プロキシのデプロイ アクションや Apigee インフラストラクチャの変更(メッセージ プロセッサの追加や削除など)など、Zookeeper に書き込むオペレーションに影響する可能性があります。
新しいリーダーが選出されたことを確認する
上記のリーダー、フォロワー、オブザーバーを特定するの手順に沿って、既存のリーダーが停止された後、フォロワーから新しいリーダーが選出されていることを確認します。リーダーは、現在のリーダーとは異なるデータセンターで選出されている可能性があります。
アップグレード リーダー
上記の オブザーバー ノードとフォロワー ノードで 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
- 通常どおり Zookeeper をインストールします。
/opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
- すべてのフォロワーとオブザーバーがロールバックされたら、リーダーノードでステップ 2 ~ 5 に沿ってリーダーノードをロールバックします。
- すべてのノードがロールバックされたら、クラスタの状態を確認し、クラスタにリーダーノードがあることを確認します。
バックアップを復元
バックアップから復元するを参照してください。4.50 や 4.51 などの以前のバージョンの Edge for Private Cloud から取得した Zookeeper のバックアップは、Edge for Private Cloud 4.52 の Zookeeper のバージョンと互換性がある必要があります。
Postgres 14 への必須アップグレード
Edge for Private Cloud のこのリリースには、Postgres 14 へのアップグレードが含まれています。このアップグレードの一環として、すべての Postgres データが Postgres 14 に移行されます。
- Edge for Private Cloud 4.51.00 から 4.52.01 にアップグレードする場合は、Postgres のアップグレード手順を追加で行う必要があります。バージョン 4.51.00 から 4.52.01 にアップグレードする場合は、Postgres 14 へのアップグレードが必須のセクションをご覧ください。
- Edge for Private Cloud 4.52.00 から 4.52.01 にアップグレードする場合、Postgres の追加のアップグレード手順は必要ありません。
Qpid をアップグレードする
この Edge for Private Cloud リリースには、Qpid J-Broker へのアップグレードが含まれています。
Qpid のアップグレードを行うには、次のいずれかの方法を選択することをおすすめします。
ダウンタイムなしのインプレース アップグレード
この方法では、Edge ランタイム環境のダウンタイムが確実に発生せず、アナリティクス用に取得されたランタイム データの損失(ある場合)を最小限に抑えることができます。
Qpid へのインプレース アップグレードをダウンタイムなしで行うには:
- 最初に 1 つの Qpid ノードを選択します。
- ノードで Qpid ブローカーを停止します。
apigee-service apigee-qpidd stop
- ファイアウォールを適用して、すべての Message Processor からのブローカー ポート 5672 の受信トラフィックをブロックします。このファイアウォールは、Qpid ノード インスタンスまたは他の外部ファイアウォール/ネットワーク コンポーネントのレベルで適用できます。
すべてのメッセージ プロセッサの IP アドレスに対して同じ手順を実行することをおすすめします。たとえば、IPTables を使用して、Message Processor の IP アドレスからポート 5672 の Qpid ノードに送信されるリクエストをドロップするには、次のようなコマンドを使用します。
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
- Qpid ブローカーを再起動して、既存のメッセージをドレインします(存在する場合)。
apigee-service apigee-qpidd start
- 既存のキューが無いことを確認します。
qpid-stat -q
メッセージがデッドレター キュー(DLQ)(ax-q-axgroup-001-consumer-group-001-dl)にスタックしている場合は、デッドレター キューにスタックしたアナリティクス データを解決する手順に沿ってキューをドレインします。
- 古いノードでキューがドレインされたことを確認したら、
apigee-qpidd
を停止します。apigee-service apigee-qpidd stop
- ノードの Qpid をアップグレードします。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
edge-qpid-server
を再起動します。apigee-service edge-qpid-server restart
手順 3 で適用したファイアウォール ルールを削除します。
ファイアウォールが適用されたすべての Message Processor の IP アドレスに対して、同じ削除手順を実行します。ファイアウォールが削除されると、Message Processor の IP アドレスからポート 5672 の Qpid ノードへのリクエストが受け入れられるようになります。
iptables
を使用してファイアウォールを追加した場合は、ファイアウォールを削除して既存の設定を一覧表示するには、次のようなコマンドを使用します。iptables -F iptables -L
- ウェブ モニタリングを使用して、Qpid キューがメッセージを受信していることを確認します。
http://QPID_NODE_IP:8090
- Qpid ノードごとに手順 1 ~ 9 を繰り返します。
新しい Qpid ノードの導入
この方法では、新しいノードに apigee-qpidd
と edge-qpid-server
をセットアップしてインストールします。
- 新しい Qpid ノードを追加します。この手順では、J-broker を使用して Qpid ノードを設定します。詳しい手順については、Qpid サーバーを追加するをご覧ください。
- 既存の Qpid ノード(アップグレード元のバージョンのノード)を選択します。
- ノードで Qpid ブローカーを停止します。
apigee-service apigee-qpidd stop
- ファイアウォールを適用して、すべての Message Processor からのブローカー ポート 5672 の受信トラフィックをブロックします。このファイアウォールは、Qpid ノード インスタンスまたはその他の外部ファイアウォール/ネットワーク コンポーネントのレベルで適用できます。
すべてのメッセージ プロセッサの IP アドレスに対して同じ手順を実行することをおすすめします。たとえば、IPTables を使用して、Message Processor の IP アドレスからポート 5672 の Qpid ノードに送信されるリクエストをドロップするには、次のようなコマンドを使用します。
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
- Qpid ブローカーを再起動して、既存のメッセージをドレインします(存在する場合)。
apigee-service apigee-qpidd start
- 既存のキューが無いことを確認します。
qpid-stat -q
メッセージがデッドレター キュー(DLQ)(ax-q-axgroup-001-consumer-group-001-dl)にスタックしている場合は、トラブルシューティング トピックの Analytics データが Qpidd のデッドレター キューでスタックするの手順に沿ってキューをドレインします。
- 古いノードでキューがドレインされたことを確認したら、
apigee-qpidd
を停止します。apigee-service apigee-qpidd stop
- Qpid サーバーを削除するの手順に沿って、古い Qpid ノードの登録を解除します。
- すべての Qpid ノードがアップグレードされるまで、新しいノードを 1 つずつ追加し、古いノードを 1 つずつ削除します。
ロールバック
以前の機能リリースにロールバックするには、ロールバックするバージョンの bootstrap.sh
ファイルをダウンロードしてください。v 4.52.00 にロールバックするには、bootstrap_4.52.00.sh
をダウンロードします。
Qpid をロールバックするには、すべての Qpid ホストで次の手順を実施します。
- 既存の Qpid ブローカーを停止します。
apigee-service apigee-qpidd stop
- ファイアウォールを適用して、すべての Message Processor からのブローカー ポート 5672 の受信トラフィックをブロックします。このファイアウォールは、Qpid ノード インスタンスまたは他の外部ファイアウォール/ネットワーク コンポーネントのレベルで適用できます。
すべてのメッセージ プロセッサの IP アドレスに対して同じ手順を実行することをおすすめします。たとえば、IPTables を使用して、Message Processor の IP アドレスからポート 5672 の Qpid ノードに送信されるリクエストをドロップするには、次のようなコマンドを使用します。
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
- qpid ブローカーを再起動して、既存のメッセージをドレインします(存在する場合)。
apigee-service apigee-qpidd start
- 既存のキューが無いことを確認します。確認するには、Qpid 管理ポータルにログインします。
注: QPID ノード上のこのポート 8090 にアクセスできない場合は、SSH ポート転送などの代替メカニズムを使用してこの URL にアクセスできます。http://QPID_NODE_IP:8090
- キューがドレインされたことを確認したら、Qpid を停止してアンインストールします。
apigee-service apigee-apidd uninstall
- Qpid データ ディレクトリを削除します。
rm -r APIGEE_ROOT/data/apigee-qpidd
- Qpid ブローカーを再インストールします。
/opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile
- Qpid ブローカーを再インストールしたら、ファイアウォールの設定を削除し、次のコマンドを使用して既存の設定を一覧表示します。
iptables -F
iptables -L
新しい 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 のバージョンを考慮してください。
- 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
ユーティリティを実行しているユーザーにこのディレクトリへのアクセス権がない場合は、/tmp
ディレクトリの update_username.log
というファイルにログが書き込まれます。
ユーザーに /tmp
へのアクセス権がない場合、update.sh
ユーティリティは失敗します。
ゼロダウンタイムでの更新
ゼロダウンタイムでの更新(ローリング アップデート)により、Edge をダウンさせることなく、インストール済みの Edge を更新できます。
ゼロダウンタイム更新は、ノードが 5 つ以上の構成でのみ利用可能です。
ゼロダウンタイムでアップグレードする場合に重要となる点は、各 Router をロードバランサから一度に 1 台ずつ削除することです。削除した 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 単独のノード:
サイレント構成ファイルの使用
サイレント構成ファイルを更新コマンドに渡す必要があります。サイレント構成ファイルは、Edge 4.50.00 または 4.51.00 のインストールに使用したものと同じである必要があります。
外部インターネット接続があるノードで 4.52.01 に更新する
ノードで 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.01.sh
ファイルを/tmp/bootstrap_4.52.01.sh
にダウンロードします。curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh
- 次のコマンドを実行して、Edge 4.52.01 の
apigee-service
ユーティリティと依存関係をインストールします。sudo bash /tmp/bootstrap_4.52.01.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 Server が含まれます。ldap
: 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-management-ui|edge-ui] restart
- インストールのテストの説明に従って Management Server で
apigee-validate
ユーティリティを実行し、更新をテストします。
- Edge
後で更新をロールバックすることにした場合は、4.52.01 のロールバックの手順に沿ってください。
ローカル リポジトリから 4.52.01 に更新する
Edge ノードがファイアウォールの背後にあるか、インターネット経由での Apigee リポジトリ アクセスが禁止されている場合は、Apigee リポジトリのローカル リポジトリ(つまりミラー)から更新を行うことができます。
ローカル Edge リポジトリを作成した後、Edge をローカル リポジトリから更新する方法は 2 通りあります。
- リポジトリの .tar ファイルを作成してそれをノードにコピーし、.tar ファイルから Edge を更新します。
- ローカル リポジトリを持つノードにウェブサーバーをインストールし、他のノードからアクセスできるようにします。Apigee から提供されているウェブサーバーは Nginx ですが、他のウェブサーバーを使用してもかまいません。
ローカルの 4.52.01 リポジトリから更新するには:
- Edge apigee-setup ユーティリティのインストールの「ローカルに Apigee リポジトリを作成する」の手順で 4.52.01 リポジトリをローカルに作成します。
- .tar ファイルから apigee-service をインストールするには:
- ローカル リポジトリが存在するノードで次のコマンドを使用し、ローカル リポジトリを
/opt/apigee/data/apigee-mirror/apigee-4.52.01.tar.gz
という名前の単一の .tar ファイルにパッケージ化します。/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
- Edge を更新する対象のノードに .tar ファイルをコピーします。たとえば、新しいノードの
/tmp
ディレクトリにコピーします。 - 新しいノードで、.tar ファイルを
/tmp
ディレクトリに解凍します。tar -xzf apigee-4.52.01.tar.gz
このコマンドにより、.tar ファイルが存在するディレクトリの中に
repos
という新しいディレクトリが作成されます。例:/tmp/repos
/tmp/repos
から Edgeapigee-service
ユーティリティと依存関係をインストールします。sudo bash /tmp/repos/bootstrap_4.52.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
コマンドに repos ディレクトリへのパスが含まれている点に注意してください。
- ローカル リポジトリが存在するノードで次のコマンドを使用し、ローカル リポジトリを
- Nginx ウェブサーバーを使用して apigee-service をインストールするには:
- Edge apigee-setup ユーティリティのインストールの「Nginx ウェブサーバーを使用してリポジトリからインストールする」の手順に沿って、Nginx ウェブサーバーを構成します。
- リモートノードで、Edge
bootstrap_4.52.01.sh
ファイルを/tmp/bootstrap_4.52.01.sh
にダウンロードします。/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh
ここで、uName:pWord は上記の手順でリポジトリに設定したユーザー名とパスワード、remoteRepo はリポジトリ ノードの IP アドレスまたは DNS 名です。
- リモートノードで、Edge
apigee-setup
ユーティリティと依存関係をインストールします。sudo bash /tmp/bootstrap_4.52.01.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 Server が含まれます。ldap
: 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.01 のロールバックの手順に沿ってください。
マシンの更新順序
Edge 構成内のマシンの更新順序は重要です。
- 他のノードを更新する前に、すべての Cassandra ノードと ZooKeeper ノードを更新する必要があります。
- 複数の Edge コンポーネント(Management Server、Message Processor、Router、QPID Server。ただし Postgres Server は該当しない)を搭載しているマシンでは、
-c edge
オプションを使用してすべてのコンポーネントを同時に更新します。 - 複数のマシンで行うよう指示されているステップは、指定されたマシン順に行ってください。
- Monetization の更新に関して特別な手順はありません。これは
-c edge
オプションを指定した場合に更新されます。
1 ノード スタンドアロン構成のアップグレード
1 ノード スタンドアロン構成を 4.52.01 にアップグレードするには:
- すべてのコンポーネントを更新します。
/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 の 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
- マシン 2、1 の Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- マシン 2 で Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -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 の Postgres を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
- マシン 5 の 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
- マシン 4、5、1、2、3 の Edge コンポーネントを更新します。
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- マシン 4 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- マシン 5 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -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
- マシン 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
- マシン 6、7 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -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
- マシン 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
- マシン 12、13 の Qpid を更新します。
/opt/apigee/apigee-setup/bin/update.sh -c qpid -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 で、次のコマンドを実行します。
- 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 で、次のコマンドを実行します。
- 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 で、次の手順を実施します。
- 新しい 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
- ps
- LDAP
- Edge(すべてのノードの「-c edge」プロファイルを意味します。順序は Qpid Server ノード、Edge Postgres Server ノード、Management Server ノード、Message Processor ノード、Router ノードの順です)。
- qpidd
- Edge UI(従来または新規の UI)
apigee-adminapi
- Apigee SSO
更新が完了したら、Edge UI コンポーネントを実行しているすべてのマシンで Edge UI コンポーネントを再起動してください。