Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Apigee Edge 4.17.0x を 4.18.01 に更新する

Edge for Private Cloud v4.18.01

4.18.01 に更新できる Edge のバージョン

この手順を使用して、Apigee Edge バージョン 4.17.0x を更新できます。

バージョン 4.16.01 より前のバージョンの Edge を使用している場合は、まずバージョン 4.16.01.x に移行してから、バージョン 4.18.01 に更新する必要があります。

更新を行えるユーザー

更新を実行するユーザーは、最初に Edge をインストールしたユーザー、または root として実行するユーザーと同じである必要があります。

Edge RPM をインストールした後は、すべてのユーザーがそれを構成できます。

更新する必要のあるコンポーネント

すべての Edge コンポーネントを更新する必要があります。Edge では、複数のバージョンのコンポーネントを含む設定はサポートされていません。

互換性を維持する

Apigee Edge for Private Cloud を 4.18.01 にアップグレードする場合は、構成ファイルでサポートされているプロパティのみが参照されるようにする必要があります。

プロパティ	ロケーション	説明
`conf_load_balancing_load.balancing. driver.nginx.server.retry`	`router.properties`	このプロパティを `router.properties` ファイルから削除します。4.18.01 で再試行オプションを設定するには、仮想ホストの構成プロパティを使用します。

プロパティ設定の自動伝播

/opt/apigee/customer/application の .properties ファイルを編集してプロパティを設定している場合、これらの値は更新によって保持されます。

SMTPMAILFROM 構成パラメータの追加が必要

Edge 4.17.05 では、SMTP サーバーを有効にするときに使用する構成ファイルに、新しい必須パラメータが追加されました。4.17.01 から更新する場合は、SMTP サーバーを有効にするときに、構成ファイルで SMTPMAILFROM を設定する必要があります。

API BaaS バージョン 4.17.09 では、SMTPMAILFROM プロパティのサポートも追加されました。4.17.01 または 4.17.05 から API BaaS を更新する場合は、構成ファイルで SMTPMAILFROM を設定する必要があります。

このパラメータの形式は次のとおりです。

SMTPMAILFROM="My Company <myco@company.com>"

Postgres 9.6 への必須アップグレード

このリリースの Edge には、Postgres 9.6 へのアップグレードが含まれています。このアップグレードの一環として、すべての Postgres データが Postgres 9.6 に移行されます。

ほとんどの Edge 本番環境システムでは、マスター / スタンバイレプリケーション用に構成された 2 つの Postgres ノードを使用します。更新プロセス中に、更新のために Postgres ノードが停止している間も、分析データは Qpid ノードに書き込まれます。Postgres ノードが更新され、オンラインに戻ると、アナリティクスデータが Postgres ノードに push されます。

Postgres の更新方法は、Postgres ノードのデータストレージの構成方法によって異なります。

Postgres ノードにローカルデータストレージを使用している場合は、アップグレード中に新しい Postgres スタンバイノードをインストールする必要があります。アップグレードが完了したら、新しい Postgres スタンバイノードをデコミッションできます。

なんらかの理由で更新をロールバックする必要がある場合は、追加の Postgres スタンバイノードが必要です。アップデートをロールバックする必要がある場合、ロールバック後に新しい Postgres スタンバイノードがマスター Postgres ノードになります。したがって、新しい Postgres スタンバイノードをインストールする場合は、Edge のインストール要件で定義されている Postgres サーバーのすべてのハードウェア要件を満たすノードにインストールする必要があります。

Edge の 1 ノードおよび 2 ノードのインストール（プロトタイピングとテストに使用されるトポロジ）では、Postgres ノードは 1 つだけです。これらの Postgres ノードは、新しい Postgres ノードを作成することなく直接更新できます。
Apigee の推奨に従って Postgres ノードにネットワークストレージを使用している場合は、新しい Postgres ノードをインストールする必要はありません。以下の手順では、新しい Postgres スタンバイノードをインストールして後で廃止する手順をスキップできます。

更新プロセスを開始する前に、Postgres で使用されるデータストアのネットワークスナップショットを取得します。更新中にエラーが発生し、ロールバックを強制的に実行する必要がある場合は、そのスナップショットから Postgres ノードを復元できます。

新しい Postgres スタンバイノードをインストールする

この手順では、新しいノードに Postgres スタンバイサーバーを作成します。バージョン 4.18.01 ではなく、既存のバージョンの Edge（4.17.0x）に新しい Postgres スタンバイサーバーをインストールしてください。

インストールを実行するには、現在のバージョンの Edge のインストールに使用した構成ファイルを使用します。

新しい Postgres スタンバイノードを作成するには:

現在の Postgres マスターで、/opt/apigee/customer/application/postgresql.properties ファイルを編集して次のトークンを設定します。
```
conf_pg_hba_replication.connection=host replication apigee existing_slave_ip/32
trust\ \nhost replication apigee new_slave_ip/32 trust
```
ここで、existing_slave_ip は現在の Postgres スタンバイサーバーの IP アドレス、new_slave_ip は新しいスタンバイノードの IP アドレスです。

postgresql.properties ファイルが存在しない場合は、次の例に示すように、ファイルを作成し、chown を使用して apigee ユーザーにアクセス権を付与します。
```
chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
```

Postgres マスターで apigee-postgresql を再起動します。

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

マスターの /opt/apigee/apigee-postgresql/conf/pg_hba.conf ファイルを表示して、新しいスタンバイノードが追加されたことを確認します。このファイルには、次の行が含まれています。
```
host replication apigee existing_slave_ip/32 trust
host replication apigee new_slave_ip/32 trust
```
新しい Postgres スタンバイサーバーをインストールします。
1. 現在のバージョンの Edge のインストールに使用した構成ファイルを編集して、次の項目を指定します。
```
# IP address of the current master:
PG_MASTER=192.168.56.103
# IP address of the new standby node
PG_STANDBY=192.168.56.102 
```
2. Edge apigee-setup ユーティリティのインストールの説明に従って、SELinux を無効にします。
3. Edge bootstrap_4.17.0x.sh ファイル（4.17.0x は 4.17.01、4.17.05、4.17.09 のいずれか）を /tmp/bootstrap_4.17.0x.sh にダウンロードします。
```
curl https://software.apigee.com/bootstrap_4.17.0x.sh -o /tmp/bootstrap_4.17.0x.sh
```
4. Edge apigee-service ユーティリティと依存関係をインストールします。
```
sudo bash /tmp/bootstrap_4.17.0x.sh apigeeuser=uName
  apigeepassword=pWord
```
5. apigee-service を使用して apigee-setup ユーティリティをインストールします。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
```
6. Postgres をインストールします。
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
7. 新しいスタンバイサーバーで、次のコマンドを実行します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
  スタンバイであることを確認します。

Postgres ノードを廃止する

更新が完了したら、新しいスタンバイノードをデコミッションします。

Postgres が実行されていることを確認します。
> /opt/apigee/apigee-service/bin/apigee-all status

Postgres が実行されていない場合は、起動します。
> /opt/apigee/apigee-service/bin/apigee-all start
新しいスタンバイノードで次の cURL コマンドを実行して、新しいスタンバイノードの UUID を取得します。
> curl -u sysAdminEmail:password http://<node_IP>:8084/v1/servers/self

出力の最後に、次の形式でノードの UUID が表示されます。
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
新しいスタンバイノードで次のコマンドを実行して、新しいスタンバイノードを停止します。
> /opt/apigee/apigee-service/bin/apigee-all stop
Postgres マスターノードで、/opt/apigee/customer/application/postgresql.properties を編集して、conf_pg_hba_replication.connection から新しいスタンバイノードを削除します。
conf_pg_hba_replication.connection=host replication apigee existing_slave_ip/32 trust
Postgres マスターで apigee-postgresql を再起動します。
> /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
マスターの /opt/apigee/apigee-postgresql/conf/pg_hba.conf ファイルを表示して、新しいスタンバイノードが削除されたことを確認します。このファイルには、次の行のみが表示されます。
host replication apigee existing_slave_ip/32 trust
Management Server ノードで次の Edge Management API 呼び出しを行い、ZooKeeper からスタンバイノードの UUID を削除します。
> curl -u sysAdminEmail:password -X DELETE http://<ms_IP>:8080/v1/servers/<new_slave_uuid>

更新の前提条件

Apigee Edge をアップグレードする前に、次の前提条件を満たしていることを確認してください。

すべてのノードをバックアップする
更新する前に、安全上の理由から、すべてのノードの完全バックアップを実行することをおすすめします。現在の Edge バージョンのバックアップ手順に沿ってください。

これにより、新しいバージョンへの更新が正常に機能しない場合に備えて、バックアッププランを用意できます。バックアップの詳細については、バックアップと復元をご覧ください。
Edge が実行されていることを確認する
更新プロセス中に Edge が稼働していることを確認するには、次のコマンドを使用します。

> /opt/apigee/apigee-service/bin/apigee-all status

更新が失敗した場合の処理

更新に失敗した場合は、問題を修正してから、update.sh を再度実行してみてください。更新は複数回実行できます。更新は、最後に中断したところから再開されます。

障害により、以前のバージョンにアップデートをロールバックする必要がある場合は、4.18.01 のロールバックプロセスをご覧ください。

更新情報のロギング

デフォルトでは、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）のネットワーク到達性の有効化と無効化の説明に従って、いずれかの Router を選択して到達不能にします。
選択した Router と、その Router と同じマシンにある他のすべての Edge コンポーネントを更新します。すべての Edge 構成で、Router と Message Processor が同じノードに表示されます。
ルーターを再び到達可能にします。
残りのルーターについて、手順 2 ～ 4 を繰り返します。
インストール環境内の残りのマシンで更新を続行します。

更新の前後に次の点に注意してください。

Router と Message Processor の組み合わせノードの場合:
- 更新前 - 次の操作を行います。
  1. ルーターを到達不能にします。
  2. Message Processor に到達できないようにします。
- 更新後 - 次の操作を行います。
  1. Message Processor を到達可能にします。
  2. ルーターにアクセスできるようにします。
単一のルーターノードの場合:
- 更新前に、ルーターにアクセスできないようにします。
- 更新後、Router にアクセスできるようにします。
単一の Message Processor ノードの場合:
- 更新する前に、Message Processor にアクセスできないようにします。
- 更新後、Message Processor にアクセスできるようにします。

サイレント構成ファイルの使用

update コマンドにサイレント構成ファイルを渡す必要があります。サイレント構成ファイルは、Edge 4.17.0x のインストールに使用したものと同じである必要があります。

外部インターネット接続があるノードで 4.18.01 に更新する手順

ノード上の Edge コンポーネントを更新する手順は次のとおりです。

現在、ローカルストレージで Postgres マスター / スタンバイレプリケーションを使用している場合は、上記の新しい Postgres スタンバイノードをインストールするの説明に従って、新しい Postgres スタンバイノードをインストールします。

ネットワークストレージを使用している場合は、新しいノードをインストールする必要はありません。代わりに、Postgres で使用されるデータストアのネットワークスナップショットを取得します。詳細については、Postgres 9.6 への必須アップグレードをご覧ください。
Cassandra で修復オペレーションを実行するように構成された CRON ジョブがある場合は、更新が完了するまで無効にします。
root としてノードにログインし、Edge RPM をインストールします。
注: RPM のインストールには root アクセス権が必要ですが、Edge の構成は 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.18.01 の bootstrap_4.18.01.sh ファイルを /tmp/bootstrap_4.18.01.sh にダウンロードします。
> curl https://software.apigee.com/bootstrap_4.18.01.sh -o /tmp/bootstrap_4.18.01.sh
Edge 4.18.01 の apigee-service ユーティリティと依存関係をインストールします。
> sudo bash /tmp/bootstrap_4.18.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
apigee-provision ユーティリティを更新します。
> /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
以下の「マシンの更新順序」で説明されている順序で、ノードで更新ユーティリティを実行します。
> /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

構成ファイルに関する唯一の要件は、構成ファイルが「apigee」ユーザーによってアクセス可能または読み取り可能であることです。

更新するコンポーネントを指定するには、-c オプションを使用します。指定可能なコンポーネントのリストは次のとおりです。
ldap = OpenLDAP
cs = Cassandra
zk = Zookeeper
qpid = qpidd
ps = postgresql
edge =Edge UI を除くすべての Edge コンポーネント: Management Server、Message Processor、Router、QPID Server、Postgres Server
ui = Edge UI
all = マシン上のすべてのコンポーネントを更新（Edge aio インストールプロファイルまたは API BaaS asa インストールプロファイルでのみ使用）
e = ElasticSearch
b = API BaaS Stack
p = API BaaS Portal
ebp = 同じノード上の ElasticSearch、API BaaS Stack、API BaaS Portal
インストールのテストの説明に従って、Management Server で apigee-validate ユーティリティを実行して、更新をテストします。
新しい Postgres スタンバイノードをインストールした場合は、Postgres ノードのデコミッションの説明に沿ってノードをデコミッションします。

ネットワークストレージを使用している場合は、新しいノードをインストールする必要はありません。詳細については、Postgres 9.6 への必須アップグレードをご覧ください。

後で更新をロールバックするには、4.18.01 のロールバックプロセスの手順に沿ってください。

ローカルリポジトリから 4.18.01 に更新する手順

Edge ノードがファイアウォールの背後にあるか、インターネット経由での Apigee リポジトリアクセスが禁止されている場合は、Apigee リポジトリのローカルリポジトリ（つまりミラー）から更新を行うことができます。

ローカル Edge リポジトリを作成したら、ローカルリポジトリから Edge を更新する方法が 2 つあります。

リポジトリの .tar ファイルを作成し、その .tar ファイルをノードにコピーして、.tar ファイルから Edge を更新します。
ローカルリポジトリを持つノードにウェブサーバーをインストールし、他のノードからアクセスできるようにします。Apigee から提供されているウェブサーバーは Nginx ですが、他のウェブサーバーを使用してもかまいません。

ローカルの 4.18.01 リポジトリから更新するには:

現在 Postgres のマスター / スタンバイレプリケーションを使用している場合は、上記の新しい Postgres スタンバイノードをインストールするの説明に従って、新しい Postgres スタンバイノードをインストールします。

ネットワークストレージを使用している場合は、新しいノードをインストールする必要はありません。代わりに、Postgres で使用されるデータストアのネットワークスナップショットを取得します。詳細については、Postgres 9.6 への必須アップグレードをご覧ください。
Edge apigee-setup ユーティリティのインストールの「ローカルに Apigee リポジトリを作成する」の手順で 4.18.01 リポジトリをローカルに作成します。
注: すでに 4.17.0x リポジトリが存在する場合は、Edge apigee-setup ユーティリティのインストールの「ローカルの Apigee リポジトリを更新する」の手順に沿って、4.18.01 リポジトリを追加できます。
.tar ファイルから apigee-service をインストールするには:
1. ローカルリポジトリがあるノードで、次のコマンドを使用して、ローカルリポジトリを /opt/apigee/data/apigee-mirror/apigee-4.18.01.tar.gz という名前の単一の.tar ファイルにパッケージ化します。
  > /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
2. Edge を更新する対象のノードに .tar ファイルをコピーします。たとえば、新しいノードの /tmp ディレクトリにコピーします。
3. 新しいノードで、ファイルを /tmp ディレクトリに解凍します。
  > tar -xzf apigee-4.18.01.tar.gz
  
  このコマンドは、.tar ファイルを含むディレクトリに repos という名前の新しいディレクトリを作成します。（例: /tmp/repos）。
4. /tmp/repos から Edge apigee-service ユーティリティと依存関係をインストールします。
  > sudo bash /tmp/repos/bootstrap_4.18.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
  
  コマンドに repos ディレクトリへのパスが含まれている点に注意してください。
Nginx ウェブサーバーを使用して apigee-service をインストールするには:
1. Edge apigee-setup ユーティリティのインストールの「Nginx ウェブサーバーを使用してリポジトリからインストールする」の手順に沿って、Nginx ウェブサーバーを構成します。
2. リモートノードで、Edge bootstrap_4.18.01.sh ファイルを /tmp/bootstrap_4.18.01.sh にダウンロードします。
  > /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.18.01.sh -o /tmp/bootstrap_4.18.01.sh
  
  ここで、uName:pWord は、上記でリポジトリに設定したユーザー名とパスワードです。remoteRepo は、リポジトリノードの IP アドレスまたは DNS 名です。
3. リモートノードで、Edge apigee-service ユーティリティと依存関係をインストールします。
  > sudo bash /tmp/bootstrap_4.18.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
apigee-provision ユーティリティを更新します。
> /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
以下の「マシンの更新順序」で説明されている順序で、ノードで更新ユーティリティを実行します。
> /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

構成ファイルに関する唯一の要件は、構成ファイルが「apigee」ユーザーによってアクセス可能または読み取り可能である必要があることです。

更新するコンポーネントを指定するには、-c オプションを使用します。指定可能なコンポーネントのリストは次のとおりです。
ldap = OpenLDAP
cs = Cassandra
zk = Zookeeper
qpid = qpidd
ps = postgresql
edge =Edge UI を除くすべての Edge コンポーネント: Management Server、Message Processor、Router、QPID Server、Postgres Server
ui = Edge UI
all = マシン上のすべてのコンポーネントを更新（Edge aio インストールプロファイルまたは API BaaS asa インストールプロファイルでのみ使用）
e = ElasticSearch
b = API BaaS Stack
p = API BaaS Portal
ebp = 同じノード上の ElasticSearch、API BaaS Stack、API BaaS Portal
インストールのテストの説明に従って、Management Server で apigee-validate ユーティリティを実行して、更新をテストします。
新しい Postgres スタンバイノードをインストールした場合は、上記の Postgres ノードのデコミッションの説明に沿ってノードをデコミッションします。

ネットワークストレージを使用している場合は、新しいノードをインストールする必要はありません。詳細については、Postgres 9.6 への必須アップグレードをご覧ください。

後で更新をロールバックするには、4.18.01 のロールバックプロセスの手順に沿ってください。

マシンの更新順序

Edge インストールでマシンを更新する順序は重要です。更新に関する最も重要な考慮事項は次のとおりです。

他のノードを更新する前に、すべての Cassandra ノードと ZooKeeper ノードを更新する必要があります。
複数の Edge コンポーネント（Management Server、Message Processor、Router、QPID Server。Postgres Server は除く）がインストールされているマシンでは、-c edge オプションを使用して、すべてのコンポーネントを同時に更新します。
複数のマシンで実行する必要があるステップの場合は、指定されたマシンの順序で実行します。
Monetization を更新するための個別のステップはありません。「-c edge」オプションを指定すると更新されます。