このページは Cloud Translation API によって翻訳されました。

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 をインストールしたユーザーと同じである必要があります。ユーザーです。

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 から更新する場合は、構成ファイルで SMTPMailFROM を設定する必要があります。 SMTP サーバーを有効にするときに使用します

API BaaS バージョン 4.17.09 では、SMTPMailFROM プロパティのサポートも追加されています。 API BaaS を 4.17.01 または 4.17.05 から更新する場合、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 のマスターノードになります。そのため、Python や Curl など、すべてのハードウェアを満たすノード上に配置する必要があります。 Postgres サーバーの要件を満たす必要があります。インストール要件

1 ノードおよび 2 ノード構成の Edge（プロトタイピングとテストに使用するトポロジ）では、次の作業を行います。 Postgres ノードは 1 つだけですこれらの Postgres ノードは、新しい Postgres ノードを作成します
Postgres ノードにネットワークストレージを使用している場合: 新しい Postgres ノードをインストールする必要はありません。手順を実施する場合は、新しいコンテナをインストールして後で廃止することを指定する手順をスキップし、 Postgres スタンバイノード。

更新プロセスを開始する前に、使用しているデータストアのネットワークスナップショットを Postgres です更新中にエラーが発生してロールバックが必要になった場合はそのスナップショットから Postgres ノードを復元できます

新しい Postgres のインストールスタンバイノード

この手順では、新しいノードに Postgres スタンバイサーバーを作成します。新しいソフトウェアインスタンスを Edge の既存バージョン（4.17.0x）の Postgres スタンバイサーバー。バージョン 4.18.01 です。

現在のバージョンのインストールに使用したものと同じ構成ファイルを使用して、インストールを行います。説明します。

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

現在の Postgres マスターで、 /opt/apigee/customer/application/postgresql.properties ファイルで次のように設定します。 token:
```
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
```
apigee-postgresql を再起動します。 Postgres マスターに対して次のコマンドを実行します。
```
/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 スタンバイサーバーをインストールします。 <ph type="x-smartling-placeholder">
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 ユーティリティ
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 のステータス

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

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

前提条件の更新

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

すべてのノードをバックアップする
安全のために、更新前にすべてのノードを完全にバックアップすることをおすすめしますできます。現在のバージョンの Edge の手順に沿ってバックアップを実行します。

これにより、新しいバージョンにアップデートされなかった場合に備えて、バックアッププランを作成できます。確認します。バックアップの詳細については、バックアップおよび復元をご覧ください。
Edge が動作していることを確認する
次のコマンドを使用して、更新プロセス中に Edge が稼働していることを確認します。

> /opt/apigee/apigee-service/bin/apigee-all のステータス

更新の失敗への対応

更新に失敗した場合は、問題を修正してから update.sh を実行する ] をクリックします。更新は複数回実行でき、最後に終了したところから続行されます。オフにします。

失敗して更新を前のバージョンにロールバックする必要がある場合は、4.18.01 ロールバックプロセスをご覧ください。

更新情報のロギング

デフォルトでは、update.sh ユーティリティは、次の場所にログ情報を書き込みます。

/opt/apigee/var/log/apigee-setup/update.log

update.sh ユーティリティを実行するユーザーにそのディレクトリにログが update_username.log という名前のファイルとして /tmp ディレクトリに書き込まれます。

ユーザーに /tmp へのアクセス権がない場合、update.sh ユーティリティは失敗します。

ダウンタイムなしで更新

ゼロダウンタイムアップデート（ローリングアップデート）では、Edge インストール環境をダウンタイムなしで更新できます。 Edge がダウンします

ゼロダウンタイムでの更新は、5 ノード以上の構成でのみ可能です。

ゼロダウンタイムでアップグレードするための鍵は、各 Router を 1 つずつ負荷から削除することです。内部 IP アドレスを使用します次に、ルーターとその同じマシン上にある他のコンポーネントを更新します。 Router をロードバランサに追加し直します

以下の「注文表示されます。
Router を更新するときは、任意の Router を 1 つ選択し、詳しくは、サーバーの有効化と無効化に関する（Message Processor/Router）のネットワーク到達性をご覧ください。
選択した Router と、その Router と同じマシンにある他のすべての Edge コンポーネントを更新します。すべての Edge 構成では、同じノード上に Router と Message Processor があります。
Router を再び到達可能にします。
残りのルーターに手順 2 ～ 4 を繰り返します。
インストール済みの残りのマシンについて、更新を続行してください。

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

Router ノードと Message Processor ノードが統合されている場合: <ph type="x-smartling-placeholder">
- 更新前 – 次のことを行います。 <ph type="x-smartling-placeholder">
  1. Router を到達不能にします。
  2. Message Processor を到達不能な状態にします。
- 更新後 - 次の操作を行います。 <ph type="x-smartling-placeholder">
  1. Message Processor を到達可能にします。
  2. Router を到達可能にします。
単一の Router ノード: <ph type="x-smartling-placeholder">
- 更新する前に、Router を到達不能な状態にしてください。
- 更新後、Router を到達可能にします。
単一の Message Processor ノードの場合: <ph type="x-smartling-placeholder">
- 更新前に、Message Processor を到達不能な状態にします。
- 更新後、Message Processor を到達可能にします。

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

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

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

ノード上の Edge コンポーネントを更新するには、次の操作を行います。

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

ネットワークストレージを使用している場合は、新しいノードをインストールする必要はありません。代わりに、 Postgres で使用されるデータストアのネットワークスナップショット。詳細については、Postgres 9.6 へのアップグレードが必要をご覧ください。
Cassandra の修復オペレーションを実行するように構成された CRON ジョブがある場合は、無効にします更新が完了するまで表示されません。
root としてノードにログインして Edge RPM をインストールします。
注: RPM のインストールには root 権限が必要ですが、Edge も実行可能です。ルート権限なしで構成できます。
yum-utils と yum-plugin-priorities:
>sudo yum install yum-utils
>sudo yum install yum-plugin-priorities
インストール Edge apigee-setup ユーティリティをご覧ください。
Oracle 7.x にインストールする場合は、次のコマンドを実行します。
>sudo yum-config-manager --enable ol7_optional_latest
AWS にインストールする場合は、次の yum-configure-manager コマンドを実行します。
>おいしい最新情報 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=uNameuName apigeepassword=pWord

ここで、uName:pWord は、 ApigeepWord を省略すると、パスワードの入力を求められます。

デフォルトでは、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 の更新
apigee-validate を更新する Management Server 上のユーティリティです。
> /opt/apigee/apigee-service/bin/apigee-service apigee-validate の更新
apigee-provision を更新するユーティリティ:
> /opt/apigee/apigee-service/bin/apigee-service apigee-provision の更新
後述の「マシン更新」下:
> /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 コンポーネント Edge UI を除く: Management Server、Message Processor、Router、QPID Server、Postgres Server
ui = Edge UI
all = デバイス上のすべてのコンポーネントを更新（Edge aio インストールプロファイルまたは API BaaS としてのインストールでのみ使用可能）プロフィール）
e = ElasticSearch
b = API BaaS スタック
p = API BaaS ポータル
ebp = ElasticSearch、API BaaS スタックと API BaaS ポータルを同じノード上に配置
管理ページで apigee-validate ユーティリティを実行して、更新をテストします。サーバー。インストールをテストするをご覧ください。
新しい Postgres スタンバイノードをインストールした場合は、上記の手順に沿ってそのノードを廃止します。具体的には Postgres ノード。

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

後で更新をロールバックするには、4.18.01 ロールバックプロセスで説明されている手順を行います。

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

Edge ノードがファイアウォールの内側にあるか、なんらかの理由でアクセスが禁止されている場合は、ローカルリポジトリから更新を実行できます。またはミラーを作成します。

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

リポジトリの .tar ファイルを作成し、その .tar ファイルをノードにコピーして、 .tar ファイルです。
ローカルリポジトリのあるノードにウェブサーバーをインストールし、他のノードがアクセスできるようにします。 Apigee が提供する Nginx ウェブサーバーを使用することも、独自のウェブサーバーを使用することもできます。使用します。

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

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

ネットワークストレージを使用している場合は、新しいノードをインストールする必要はありません。代わりに、 Postgres で使用されるデータストアのネットワークスナップショット。詳細については、Postgres 9.6 へのアップグレードが必要をご覧ください。
「ローカルの Apigee リポジトリを作成する」の説明に沿って、ローカルに 4.18.01 リポジトリを作成するEdge apigee-setup ユーティリティのインストールをご覧ください。
注: 既存の 4.17.0x リポジトリがすでにある場合は、「ローカルの Apigee リポジトリを更新する」の説明に沿って 4.18.01 リポジトリをこのフォルダにコピーします。Edge apigee-setup ユーティリティのインストールをご覧ください。
.tar ファイルから apigee-service をインストールするには: <ph type="x-smartling-placeholder">
1. ローカルリポジトリがあるノードで、次のコマンドを使用してローカルリポジトリをパッケージ化します。 /opt/apigee/data/apigee-mirror/apigee-4.18.01.tar.gz という名前の単一の.tar ファイル:
  > /opt/apigee/apigee-service/bin/apigee-service apigee-mirror パッケージ
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
  
  このコマンドには、Repo ディレクトリのパスが含まれています。
Nginx ウェブサーバーを使用して apigee-service をインストールするには: <ph type="x-smartling-placeholder">
1. 「Nginx を使用してリポジトリからインストールする」の説明に沿って、Nginx ウェブサーバーを構成します。 webserver"Edge のインストール apigee-setup ユーティリティを実行します。
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 の更新
apigee-validate を更新する Management Server 上のユーティリティです。
> /opt/apigee/apigee-service/bin/apigee-service apigee-validate の更新
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 コンポーネント Edge UI を除く: Management Server、Message Processor、Router、QPID Server、Postgres Server
ui = Edge UI
all = デバイス上のすべてのコンポーネントを更新（Edge aio インストールプロファイルまたは API BaaS としてのインストールでのみ使用可能）プロフィール）
e = ElasticSearch
b = API BaaS スタック
p = API BaaS ポータル
ebp = ElasticSearch、API BaaS スタックと API BaaS ポータルを同じノード上に配置
管理ページで apigee-validate ユーティリティを実行して、更新をテストします。サーバー。インストールをテストするをご覧ください。
新しい Postgres スタンバイノードをインストールした場合は、前述の手順に沿ってノードを廃止します。上記のデコミッション Postgres ノードです。

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

後で更新をロールバックするには、4.18.01 ロールバックプロセスで説明されている手順を行います。

マシンの更新の順序

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

いずれかの Cassandra ノードと ZooKeeper ノードを更新する前に、すべての Cassandra ノードを更新する必要があります。他のノードで使用できます。
複数の Edge コンポーネント（Management Server、Message Processor、 Postgres Server ではなく、Router、QPID Server など）、「-c edge」を使用します。すべて更新するオプションができます。
ステップが複数のマシンで実行されるように指定されている場合、そのステップはマシン順序を指定します。
Monetization を更新するための個別の手順はありません。これは、"-c" エッジ"選択します。