4 Oracle REST Data Servicesのその他の構成オプション
この項では、リクエストをルーティングして複数のデータベースに接続するようにOracle REST Data Servicesを構成する方法を説明し、その他の構成情報については、その他のドキュメント・ソースを参照します。
ノート:
構成の変更後、Oracle REST Data Servicesを再起動する必要があります。高可用性を確保するために、複数のORDSインスタンスの前にロード・バランサを使用して、ローリング再起動を実行できるようにすることをお薦めします。トピック:
Oracle RAC Fast Connection Failoverのサポート
Oracle REST Data Servicesは、Oracle Real Application Clusters (Oracle RAC)のFast Connection Failover (FCF)機能をサポートします。
Oracle REST Data Servicesは、WebLogic、Tomcatなど、サポートするすべてのApplication Server環境でUniversal Connection Pool (UCP)とともに実行されます。また、UCPはFast Connection Failoverをサポートします。FCFを有効化するには、Oracle Notification Service (ONS)が有効化されている必要があります。ONSを有効化するには、次のコード・スニペットに示すように、Oracle REST Data Services settings.xml
構成ファイルにあるプロパティのリストにエントリを追加します。
<entry key="jdbc.enableONS">true</entry>
<entry key= "jdbc.ONSConfig">nodes=racnode1:4200,racnode2:4200\nwalletfile=/oracle11/onswalletfile</entry>
<entry key="db.connectionType">customurl</entry>
<entry key="db.customURL">jdbc:oracle:thin:@(DESCRIPTION=(FAILOVER=ON)(ADDRESS_LIST=
(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=prod_scan.example.com)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=ISPRD)))|</entry>
defaults.xml
構成ファイルを更新した後、Oracle REST Data Servicesを再起動するまで変更は有効になりません。
-
計画外の停止: RACはインスタンス障害を検出するとFAN Downイベントを生成し、それをFCFが捕捉します。 FCFは失敗したインスタンスへのすべての接続を終了し、それ以降のすべてのリクエストを、残っているRACインスタンスに送ります。
-
計画的な停止: たとえば、データベース管理者(DBA)が、一部のメンテナンス・アクティビティを実行するためにRACインスタンスを正常にシャットダウンすることがあります。インスタンス・シャットダウンはFAN Planned Downイベントを生成し、それをFCFが捕捉します。 続いてFCFはすべての新しいリクエストを他のRACインスタンスに送り、現在アクティブなトランザクションを排出するか完了させます。
ノート:
長い間実行されているトランザクションは、強制終了が必要な場合があります。Kerberos設定を使用したORDSの構成
この項では、ORDSをKerberosファイルベースのチケット・キャッシュを参照し、ORDS実行権限を持つOracle Database Kerberos認証済ユーザーに接続するように構成する方法について説明します。
- 外部認証を使用した新規ユーザーの作成
- 環境変数の設定
- 有効なチケットの指定
- ORDSプール設定の追加
Oracle Data Guardで保護されているユーザーにアクセスするためのOracle REST Data Servicesの認可
Oracle Data Vault Realmで保護されているデータベース・スキーマ・オブジェクトにアクセスするには、Oracle REST Data Services Publicユーザーにプロキシ・ユーザー認可を付与する必要があります。
ORDS_PUBLIC_USER
がデータベースのHR
ユーザーのプロキシとして動作することを認可します。begin
DBMS_MACADM.AUTHORIZE_PROXY_USER('ORDS_PUBLIC_USER','HR');
end;
/
REST対応SQLサービス設定の構成
この項では、REST対応SQLサービスを構成する方法について説明します。
ノート:
REST対応SQLサービスを有効にすると、Oracle RESTデータ・サービス対応のデータベース・スキーマに対する認証が有効になります。これにより、データベース・パスワードを使用して、データベース・スキーマがHTTPS経由でアクセス可能になります。Oracleでは、強力かつ安全なデータベース・パスワードを指定することをお薦めします- 次のコマンドを実行します。
ords --config <configuration_folder> config [--db-pool <pool_name>] set restEnabledSql.active true
- Oracle REST Data Servicesを再起動します。
問合せから戻される行の最大数の構成
- 次のコマンドを実行します。
ords --config <configuration_folder> config set [--db-pool <pool_name>] misc.pagination.maxRows <number>
ノート:
misc.pagination.maxRows
のデフォルト値は10000です。 - Oracle REST Data Servicesを再起動します。
ウィルス・スキャン用のICAPサーバー統合の構成
この項では、ウイルス・スキャン用にICAPサーバーと統合するようにORDSを構成する方法について説明します。
ORDS PL/SQLゲートウェイでは、ファイル・アップロード時に、Internet Content Adaptation Protocol (ICAP)準拠のウイルス・スキャン・サーバーにウイルス・スキャンの職責を任せることができます。ウィルス・スキャン・サーバーのホスト名とポートは、icap.server
、icap.port
およびicap.secure.port
グローバル構成プロパティで指定します。
APEXではORDS PL/SQLゲートウェイが使用されます。このICAP統合は、構成すると、APEXでのファイル・アップロードにも適用されます。
- 次のコマンドを実行します。
ords --config <configuration_folder> config [--db-pool <pool_name>] set icap.port <number> ords --config <configuration_folder> config [--db-pool <pool_name>] set icap.server <name_or_ip>
- Oracle REST Data Servicesを再起動します。
- ICAPバージョン1.0
- AVSCANという名前のウイルス対策サービス
- action=SCANに対応しているウイルス対策サービス
- 4バイト以上のプレビュー
- X-Infectionという名前のヘッダーを返す
RESPMOD icap://<icap_server>:<icap_port>/AVSCAN?action=SCAN ICAP/1.0
Host: <icap_server>:<icap_port>
Preview: 4
Allow: 204
Encapsulated: req-hdr=0 res-hdr=153 res-body=200
カスタム・エラー・ページの構成
この項では、Oracle REST Data Servicesにより生成されたエラー・ページではなく、カスタム・エラー・ページを構成する方法について説明します。
-
次のコマンドを実行します。
ords --config /path/to/conf config set error.externalPath /path/to/error/pages/folder/
説明:
/path/to/error/pages/folder
は、エラー・ページを定義するファイルが格納されているフォルダのパスです。ファイルは、{status}.html
形式で格納されます。ここで、{status}
は、カスタム・エラー・ページを作成するHTTPステータス・コードです。 -
Oracle REST Data Servicesを再起動します
例4-1 HTTP 404ステータス・コードのカスタム・エラー・ページの構成
「HTTP 404 – Not Found」ステータスのカスタム・エラー・ページを構成するには、次のステップを実行します。
-
404.html
という名前のファイルを作成します。 -
/usr/local/share/ords/error-pages/
フォルダに保存します。 -
/usr/local/share/ords/errro-pages/
フォルダを指すように、error.externalPath
パラメータを構成します。 -
Oracle REST Data Servicesを再起動します。
ORDS管理者権限の管理
ORDS_ADMIN
PL/SQLパッケージへのアクセス権は、ORDS_ADMINISTRATOR_ROLE
を介してプロビジョニングします。ORDS_ADMIN
パッケージを介してこのロールをプロビジョニングして、追加のORDS管理者を作成できます。
ユーザーへのORDS_ADMINISTRATOR_ROLEのプロビジョニング
この項では、ORDS_ADMINISTRATOR_ROLE
ロールをユーザーにプロビジョニングする方法について説明します。
データベースのGRANT
コマンドまたはORDS_ADMIN.PROVISION_ADMIN_ROLE
PL/SQLメソッド(ORDS管理者)を使用して、ORDS_ADMINISTRATOR_ROLE
ロールをユーザーにプロビジョニングできます。
例4-2 Grantコマンドの使用
GRANT ORDS_ADMINISTRATOR_ROLE TO HR_ADMIN;
例4-3 ORDS_ADMINパッケージ・メソッドの使用
BEGIN
ORDS_ADMIN.PROVISION_ADMIN_ROLE(
p_user => 'HR_ADMIN');
END;
/
ユーザーからのORDS_ADMINISTRATOR_ROLEのプロビジョニング解除
この項では、ORDS_ADMINISTRATOR_ROLE
をユーザーからプロビジョニング解除する方法について説明します。
ORDS管理者は、データベースのREVOKE
コマンドまたはORDS_ADMIN.UNPROVISION_ROLES
PL/SQLメソッドを使用して、ORDS_ADMINISTRATOR_ROLE
をユーザーからプロビジョニング解除できます。
例4-4 REVOKEコマンドの使用
REVOKE ORDS_ADMINSTRATOR_ROLE FROM HR_ADMIN;
例4-5 ORDS_ADMINパッケージ・メソッドの使用
BEGIN
ORDS_ADMIN.UNPROVISION_ROLES(
p_user => 'HR_ADMIN',
p_administrator_role => TRUE);
END;
/
ORDS実行権限の管理
ORDS_RUNTIME_ROLE
データベース・ロールを使用すると、ユーザーはランタイム・ユーザーとして機能できます。ランタイム・ユーザーはORDSサービス・インスタンスで必要なランタイム接続リソースを管理および構成できます。ORDS_PUBLIC_USER
は、そのようなデータベース・ユーザーの1つです。追加のランタイム・ユーザーがプロビジョニングされると、異なる宛先アドレスと接続プールを持つが同じOracleデータベース・コンテナでホストされる、個別のORDSサービス・インスタンスを構成できます。
ランタイム・ユーザーには他のユーザーへのプロキシに必要な権限が累積されるため、他の目的で再利用しないことをお薦めします。ランタイム・ユーザーには、ORDS_RUNTIME_ROLE
ロールに加えてCREATE SESSION
権限のみが必要です。
ユーザーへのORDS_RUNTIME_ROLEのプロビジョニング
この項では、ORDS_RUNTIME_ROLE
ロールをユーザーにプロビジョニングする方法について説明します。
ORDS管理者は、データベースのGRANT
コマンドまたはORDS_ADMIN.PROVISION_ADMIN_ROLE
PL/SQLメソッドを使用して、ORDS_RUNTIME_ROLE
ロールをユーザーにプロビジョニングできます。
例4-6 Grantコマンドの使用
GRANT ORDS_RUNTIME_ROLE TO ORDS_PUBLIC_USER_2;
例4-7 ORDS_ADMINパッケージ・メソッドの使用
BEGIN
ORDS_ADMIN.PROVISION_RUNTIME_ROLE(
p_user => 'ORDS_PUBLIC_USER_2');
END;
/
ユーザーからのORDS_RUNTIME_ROLEのプロビジョニング解除
この項では、ORDS_RUNTIME_ROLE
ロールをユーザーからプロビジョニングを解除する方法について説明します
管理者は、データベースのREVOKE
コマンドまたはORDS_ADMIN.UNPROVISION_ROLES
PL/SQLメソッドを使用して、ORDS_RUNTIME_ROLE
をユーザーからプロビジョニング解除できます。
例4-8 REVOKEコマンドの使用
REVOKE ORDS_RUNTIME_ROLE FROM ORDS_RUNTIME_USER_2;
例4-9 ORDS_ADMINパッケージ・メソッドの使用
BEGIN
ORDS_ADMIN.UNPROVISION_ROLES(
p_user => 'ORDS_RUNTIME_USER_2',
p_runtime_role => TRUE);
END;
/
非HTTPS環境でOAuth2の使用
RESTfulサービスは、非公開データへのアクセスを制御するOAuth2プロトコルで保護できます。データのスヌーピングを防ぐため、OAuth2では、OAuth2認証プロセスに関与するすべてのリクエストをHTTPSを使用して転送する必要があります。Oracle REST Data Servicesのデフォルトの動作では、OAuth2関連のすべてのリクエストはHTTPSを使用して受信されたことを検証されます。HTTPを介して受信するリクエストへのサービスは拒否され、403 ForbiddenのHTTPステータス・コードが返されます。
このデフォルトの動作は、HTTPSを使用できない環境では次のようにして無効にできます。
-
Oracle REST Data Servicesの構成が格納されているフォルダを探します。例:
/path/to/conf
- 次のコマンドを実行します。
ords --config /path/to/conf config set security.verifySSL false
-
実行中なら、Oracle REST Data Servicesを再起動します。
この設定の使用は、開発またはテスト環境でのみ適切であることに注意してください。ユーザーの資格証明がクリア・テキストで渡されることになるので、本番環境でこの設定を使用するのは適切ではありません。
ノート:
Oracle REST Data Servicesは、構成の変更を行った後に再起動する必要があります。アプリケーションを再起動する方法はアプリケーション・サーバーのマニュアルを参照してください。
ORDSメタデータ・キャッシュの構成
この項では、ORDSメタデータ・キャッシュの構成方法について説明します。
RESTサービスの数が増加するにつれて、対応するメタデータのデータベースを問い合せるオーバーヘッドが、サービス・パフォーマンスおよびスループット全体に悪影響を与える可能性があります。時間の経過とともに、ORDS_METADATA
ビューの問合せの完了に時間がかかるようになります。これらの問合せは、リクエストごとに実行されます。ORDSメタデータ・キャッシュは、ORDS_METADATA
ビューの問合せが各リクエストにとって高負荷になる程度までサービス数が増加したときに、RESTサービスの全体的なレスポンス時間を改善するのに役立ちます。ORDSメタデータ・キャッシュでは、権限およびモジュール・メタデータのコピーをメモリーに一時的に保持して、RESTサービス・リクエストの受信時に実行されるデータベース問合せの数を減らすことができます。メタデータに対する変更が後続のリクエストにすぐに適用されるように、キャッシュはデフォルトで無効になっています。
表4-1 ORDSメタデータ・キャッシュの構成プロパティ
プロパティ | データ型 | デフォルト値 | 説明 |
---|---|---|---|
cache.metadata.enabled |
ブール値 | false |
メタデータ・キャッシュを有効または無効にする設定を指定します。 |
cache.metadata.timeout |
期間 | 30s |
メタデータ・レコードがキャッシュに残る期間を決定するための設定を指定します。期間が長いほど、適用された変更の表示に時間がかかります。 |