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 に書き込む管理オペレーションや、Message Processor の追加や削除など、Apigee インフラストラクチャの変更に影響する可能性があります。以下の手順に沿って Zookeeper をアップグレードする間、Apigee のランタイム API に影響はありません(これらのランタイム API が管理 API を呼び出す場合を除く)。
大まかに、アップグレード プロセスでは各ノードのバックアップを取得します。次に、すべてのオブザーバーとフォロワーをアップグレードし、最後にリーダーノードをアップグレードします。
バックアップを作成する
ロールバックが必要な場合に備えて、ZooKeeper のすべてのノードのバックアップを作成します。ロールバックすると、ZooKeeper はバックアップ取得時の状態に復元されます。注: バックアップ取得以降に Apigee で行われたデプロイメントやインフラストラクチャの変更 (その情報は Zookeeper に保存されます) は、復元時に失われます。
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup
仮想マシンを使用していて、その機能がある場合は、復元またはロールバック(必要な場合)のために VM のスナップショットまたはバックアップを取得することもできます。
リーダー、フォロワー、オブザーバーを特定する
注: 以下のサンプル コマンドでは、nc ユーティリティを使用して Zookeeper にデータを送信します。別のユーティリティを使用して Zookeeper にデータを送信することもできます。
- ZooKeeper ノードにインストールされていない場合は、nc をインストールします。
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 ノードを使用する 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 インフラストラクチャの変更(Message Processor の追加や削除など)など、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 へのインプレース、ゼロ ダウンタイム アップグレードを実行するには:
- 最初に Qpid ノードを 1 つ選択します。
- ノードで Qpid ブローカーを停止します。
apigee-service apigee-qpidd stop
- ファイアウォールを適用して、すべての Message Processor からのブローカー ポート 5672 の受信トラフィックをブロックします。このファイアウォールは、Qpid ノード インスタンスまたはその他の外部ファイアウォール / ネットワーク コンポーネントのレベルで適用できます。
すべての Message Processor IP アドレスに対して同じ手順を行うことをおすすめします。たとえば、IPTables を使用して、Message Processor の IP アドレスからポート 5672 の Qpid ノードに送信されるリクエストを DROP するには、次のようなコマンドを使用します。
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 ノード インスタンスのレベル、または他の外部ファイアウォール / ネットワーク コンポーネントのレベルで適用できます。
すべての Message Processor の IP アドレスに対して同じ手順を行うことをおすすめします。たとえば、IPTables を使用して、Message Processor の IP アドレスからポート 5672 の Qpid ノードに送信されるリクエストを DROP するには、次のようなコマンドを使用します。
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 つずつ繰り返します。
ロールバック
以前の機能リリースにロールバックするには、ロールバックするバージョンの bootstrap.sh ファイルをダウンロードしてください。v 4.52.00 にロールバックするには、bootstrap_4.52.00.sh をダウンロードします。
Qpid をロールバックするには、すべての Qpid ホストで次の手順を行います。
- 既存の Qpid ブローカーを停止します。
apigee-service apigee-qpidd stop
- ファイアウォールを適用して、すべての Message Processor からのブローカー ポート 5672 の受信トラフィックをブロックします。このファイアウォールは、Qpid ノード インスタンスまたはその他の外部ファイアウォール / ネットワーク コンポーネントのレベルで適用できます。
すべての Message Processor IP アドレスに対して同じ手順を行うことをおすすめします。たとえば、IPTables を使用して、Message Processor の IP アドレスからポート 5672 の Qpid ノードに送信されるリクエストを DROP するには、次のようなコマンドを使用します。
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 に関する考慮事項について説明します。詳細については、プライベート クラウド用の新しい Edge UI をご覧ください。
Edge UI のインストール
初期インストールが完了したら、Edge UI をインストールすることをおすすめします。これは、Apigee Edge for Private Cloud のデベロッパーと管理者向けの拡張ユーザー インターフェースです。
Edge UI では、基本認証を無効にして、SAML や LDAP などの IDP を使用する必要があります。
詳細については、新しい Edge UI をインストールするをご覧ください。
Edge UI の更新
Edge UI コンポーネントを更新するには、アップグレード元の Edge for プライベート クラウド のバージョンを考慮してください。
- 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 を更新するタイミングになったら、サーバー(Message Processor / Router)のネットワーク到達性の有効化と無効化の説明に従って、いずれか 1 つの Router を選択して到達不能にします。
- 選択した Router と、その Router と同じマシンにある他のすべての Edge コンポーネントを更新します。すべての Edge 構成で、Router と Message Processor が同じノードに表示されます。
- ルーターを再度到達可能にします。
- 残りのルーターについて、手順 2 ~ 4 を繰り返します。
- インストール環境内の残りのマシンに対して更新を続行します。
更新の前後に次の点に注意してください。
- Router と Message Processor の組み合わせノードの場合:
- 更新前 - 次の操作を行います。
- ルーターに到達できないようにします。
- Message Processor に到達できないようにします。
- 更新後 - 次の操作を行います。
- Message Processor を到達可能にします。
- Router にアクセスできるようにします。
- 更新前 - 次の操作を行います。
- 単一のルーターノードの場合:
- 更新する前に、Router にアクセスできないようにします。
- 更新後、Router にアクセスできるようにします。
- 単一の Message Processor ノードの場合:
- 更新する前に、Message Processor を到達不能にします。
- 更新後、Message Processor を到達可能にします。
サイレント構成ファイルの使用
update コマンドにサイレント構成ファイルを渡す必要があります。サイレント構成ファイルは、Edge 4.50.00 または 4.51.00 のインストールに使用したものと同じである必要があります。
外部インターネット接続があるノードで 4.52.01 に更新する
ノード上の Edge コンポーネントを更新する手順は次のとおりです。
- 存在する場合は、更新が完了するまで、Cassandra で修復オペレーションを実行するように構成された
cronジョブを無効にします。 - Edge RPM をインストールするには、root としてノードにログインします。
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 ファイルをノードにコピーして、.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ディレクトリにコピーします。 - 新しいノードで、ファイルを
/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 コンポーネントを再起動します。
- Classic UI: Classic 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
- Classic UI: Classic 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 コンポーネントを再起動します。
- Classic UI: Classic 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
- Classic UI: Classic 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 コンポーネントを再起動します。
- Classic UI: Classic 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
- Classic UI: Classic 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 サーバー、Edge Postgres Server、Management Server、Message Processor、Router の順にノードをインストールします。
- qpidd
- Edge UI(Classic または New)
apigee-adminapi- Apigee SSO
更新が完了したら、Edge UI コンポーネントを実行しているすべてのマシンで Edge UI コンポーネントを再起動してください。