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

Apigee Edge 4.16.09 を 4.18.01 に更新する

Edge for Private Cloud v4.18.01

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

この手順で Apigee Edge バージョン 4.16.09.0x を 4.18.01 に更新できます。

バージョン 4.16.01 より前の Edge をお持ちの場合は、最初にバージョン 4.16.01.x を作成し、バージョン 4.18.01 に更新します。

更新を実行できるユーザー

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

Edge RPM をインストールした後は、どのユーザーでも構成できます。

更新が必要なコンポーネント

すべての Edge コンポーネントを更新する必要があります。Edge は、コンポーネントを含む設定をサポートしていません使用できます。

Qpid 1.35 へのアップグレードが必要

このリリースには、Qpid 1.35 に必要なアップデートが含まれています。Qpid ノードの更新の一環として、必要があります。

次の方法で、Router と Message Processor からの Qpid ノードへの書き込みを一時的に禁止します。ポート 5672 をブロックします。このポートをブロックするには、次のコマンドを使用します。 Qpid ノード:
>sudo iptables -A 入力 -p tcp --destination-port 5672 !-s `hostname` -i eth0 -j DROP
Qpid キューでメッセージが空の状態になるまで待ってから、Qpid ノードですべての処理が完了したことを確認します。メッセージが表示されます。次のコマンドを使用して、Qpid メッセージキューが空:
>qpid-stat -q
Qpid ノードを更新します。
Qpid ノードのポート 5672 のブロックを解除して、Router と Message Processor からのアクセスを許可します。このポートのブロックを解除するには、次のコマンドを使用します。
>sudo iptables -F

他のルールに iptables を使用している場合、-D オプションを使用すると、具体的な変更:
>sudo iptables -D INPUT -p tcp --destination-port 5672 !-s `hostname` -i eth0 -j DROP

このプロセスについては、以下で Edge トポロジごとに詳しく説明します。

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

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

更新プロセス中は、Postgres ノードが更新のためにダウンしている間、分析データは Qpid ノードに書き込まれます。Postgres ノードが更新されてオンラインに戻ると、 Postgres ノードに push されます

任意の Postgres スタンバイノードで更新をロールバックする必要がある場合は、追加の Postgres スタンバイノードが必要です。できます。更新をロールバックする必要がある場合は、新しい Postgres スタンバイノードがマスターになるロールバック後の Postgres ノード。そのため、新しい Postgres スタンバイノードをインストールすると、 Postgres サーバーのハードウェア要件をすべて満たすノード上に配置されている必要があります。 Edge のインストール要件

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

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

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

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

現在の Postgres マスターで、/opt/apigee/customer/application/postgresql.properties を編集します。次のトークンを設定します。このファイルが存在しない場合は作成します。

conf_pg_hba_replication.connection=host レプリケーション Apigee existing_slave_ip/32 信頼\n ホストレプリケーション Apigee new_slave_ip/32 信頼

ここで、existing_slave_ip は現在の Postgres の IP アドレスです。 new_slave_ip は新しいスタンバイの IP アドレスです。あります。
apigee-postgresql を再起動します。 Postgres マスターに対して次のコマンドを実行します。
> /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql の再起動
/opt/apigee/apigee-postgresql/conf/pg_hba.conf を表示して、新しいスタンバイノードが追加されたことを確認します。コピーします。このファイルに次の行が記述されているはずです。
ホストレプリケーション Apigee existing_slave_ip/32 信頼
ホストレプリケーション apigee new_slave_ip/32 信頼
新しい Postgres スタンバイサーバーをインストールします。 <ph type="x-smartling-placeholder">
1. 現在のバージョンの Edge のインストールに使用した構成ファイルを編集して、次の要素:
  
  # 現在の IP アドレスマスター:
  PG_MASTER=192.168.56.103
  # 新しいスタンバイノードの IP アドレス
  PG_STANDBY=192.168.56.102
2. Edge apigee-setup ユーティリティをインストールするの説明に沿って、SELinux を無効にします。
3. Edge bootstrap_4.16.09.sh ファイルを /tmp/bootstrap_4.16.09.sh にダウンロードします。
  >curl https://software.apigee.com/bootstrap_4.16.09.sh -o /tmp/bootstrap_4.16.09.sh
4. Edge apigee-service ユーティリティをインストールします。依存関係:
  >sudo bash /tmp/bootstrap_4.16.09.sh apigeeuser=uNameuName 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>

EPEL リポジトリを有効にするために必要です

[Extra Packages for]（追加パッケージ）を Enterprise Linux（EPEL）を使用して Edge をインストールまたは更新します。使用するコマンドは、 RedHat/CentOS のバージョン上の

RedHat/CentOS/Oracle 7.x の場合:
>wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm;RPM -IVH epel-release-latest-7.noarch.rpm
RedHat/CentOS/Oracle 6.x の場合:
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm;RPM -IVH epel-release-latest-6.noarch.rpm

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

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

API BaaS バージョン 4.17.09 では、SMTPMailFROM プロパティのサポートも追加されています。 API BaaS を更新するときは、SMTPMailFROM を構成ファイルが更新されます。

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

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

使用するときに更新する場合は必須外部認証

外部ディレクトリサービスを既存の Apigee Edge Private Cloud に統合できます。インストールできます。この機能は、LDAP、LDAP、サポートしています。外部 LDAP ソリューションを使用すると、管理者は、一元化されたディレクトリ管理サービスからユーザー認証情報を管理できます。 Apigee Edge などのシステムでは外部にデプロイされます

外部認証をご覧ください。構成をご覧ください。

外部認証が有効になっている場合、ほとんどのお客様は Active Directory SAM アカウントを使用する name フィールドを認証のユーザー名として使用します。これは、サービスアカウントによって使用される Edge OpenLDAP サーバーです。

外部ディレクトリサービスと統合している場合は、次の行を Edge を 4.17.09 に更新するときに、構成ファイルを次のように変更します。

IS_EXTERNAL_AUTH="true"

この行により、メールアドレスではなくアカウント名をサポートするように Edge が構成されます。表示されます。

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

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

前提条件の更新

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.16.09 のインストールに使用したものと同じである必要があります。

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

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

現在 Postgres のマスター / スタンバイレプリケーションを使用している場合は、新しい Postgres をインストールする上記の新しい Postgres のインストールや Postgres のスタンバイノード。
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 ユーティリティをご覧ください。
上記の手順に沿って EPEL リポジトリを有効にします。
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 ポータルを同じノード上に配置
Management Server で apigee-validate ユーティリティをインストールをテストするをご覧ください。
新しい Postgres スタンバイノードをインストールした場合は、上記の手順に沿ってそのノードを廃止します。 Postgres の廃止 Node.js のものです。

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

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

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

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

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

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

現在 Postgres のマスター / スタンバイレプリケーションを使用している場合は、新しい Postgres スタンバイノードを作成します。詳細については、新しい Postgres スタンバイノードを作成します。
「ローカルの Apigee リポジトリを作成する」の説明に沿って、ローカルに 4.18.01 リポジトリを作成するEdge apigee-setup ユーティリティのインストールをご覧ください。
注: 既存の 4.16.09 リポジトリがある場合は、4.18.01 リポジトリを追加できます。「ローカルの Apigee リポジトリを更新する」の説明に沿ってそのリポジトリに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 ポータルを同じノード上に配置
Management Server で apigee-validate ユーティリティをインストールをテストするをご覧ください。
新しい Postgres スタンバイノードをインストールした場合は、前述の手順に沿ってノードを廃止します。上記のデコミッション Postgres ノードです。

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

マシンの更新の順序

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

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