3 OAAおよびOARMのインストール手順
3.1 管理コンテナについて
管理コンテナは、新規または既存のKubernetesクラスタにOAAおよびOARMをインストールするために必要なすべてのスクリプトとツールが含まれるコンテナです。
このコンテナは、Kubernetesクラスタでポッドとして実行されます。それ自体はOAAおよびOARMデプロイメントの一部ではありませんが、KubernetesクラスタへのOAAやOARMのデプロイをスムーズにします。
oraclelinux
に基づいて、次のバイナリがインストールされています:
- kubectl
- helm
- sqlplus: instantclient_19_10
- openssl
管理コンテナの詳細は、次の各トピックを参照してください:
3.1.1 管理コンテナのコンポーネント
この項では、管理コンテナ・ポッド内の重要なファイルおよびフォルダの概要を説明します。
表3-1 管理コンテナのファイルおよびフォルダ・リファレンス
ファイルおよびフォルダ | 説明 |
---|---|
OAA.sh |
このスクリプト・ファイルは、OAAおよびOARMのインストールに使用されます。OAA、OAA-OARMおよびOARMをインストールするためのスクリプトの引数として、installOAA.properties ファイルを指定する必要があります。
詳細は、「OAAおよびOARMインストール用のプロパティ・ファイルの準備」を参照してください |
installsettings |
このフォルダにはoaaoverride.yaml が含まれており、これをカスタマイズして、OAAおよびOARMの一部のサービスのreplicaCount を設定できます。
これを有効にするには、 |
helmcharts |
このフォルダには、すべてのOAAおよびOARMサービスのhelmチャートとvalue.yamlがあります。 |
libs |
このフォルダには、次のファイルが含まれています:
|
logs |
このフォルダはNFSボリューム<NFS_LOG_PATH> にマップされ、OAAおよびOARMインストールのログとステータスが格納されます。
|
oaa_cli |
このフォルダには、OARMのジオロケーション・データのインストールでカスタマイズや使用が可能なファイルがあります。詳細は、「ジオロケーション・データのロード」を参照してください |
scripts/creds |
このフォルダはNFSボリューム<NFS_CREDS_PATH> にマップされ、インストール中に使用される次のファイルが含まれます:
|
scripts/settings |
このフォルダはNFSボリューム<NFS_CONFIG_PATH> にマップされ、インストールに必要なinstallOAA.properties およびoaaoverride.yaml 構成ファイルが格納されます。
|
service/store/oaa/ |
このフォルダは、管理コンテナとOAAおよびOARMデプロイメント間で共有されるNFSボリューム<NFS_VAULT_PATH> にマップされます。これにはファイル・ベースのボールトが格納されます(OCIベースのボールトを使用していない場合)。
|
3.1.2 管理コンテナの事前設定された環境変数
管理コンテナ・ポッドは、事前定義された環境変数のセットで構成されます。
表3-2 事前設定された環境変数
環境変数 | 説明 |
---|---|
HELM_CONFIG |
これは/u01/oracle/scripts/creds/helmconfig に設定されます。
|
KUBECONFIG |
これは/u01/oracle/scripts/creds/k8sconfig に設定されます。
|
SCRIPT_PATH |
これは/u01/oracle/scripts に設定されます。これにはインストール・スクリプトが含まれます。
|
CONFIG_DIR |
これは、構成を外部に格納するために使用されるNFSボリューム<NFS_CONFIG_PATH> です。
コンテナ内のパス |
CREDS_DIR |
これは、helm構成、kube構成、ログイン秘密キーなどの資格証明を格納するために使用されるNFSボリューム<NFS_CREDS_PATH> です。
コンテナ内のパス |
LOGS_DIR |
これは、インストール・ログおよびステータスを格納するために使用されるNFSボリューム<NFS_LOGS_PATH> です。
コンテナ内のパス |
HELM_CHARTS_PATH |
これは、インストールに関連するすべてのhelmチャートが存在するパスです。 |
LD_LIBRARY_PATH |
instantclientフォルダを設定します。この変数は、コンテナ内に存在するinstantclientからsqlplus およびDB関連のコマンドを実行するために必要です。
|
LIBS_DIR |
これは、パス/u01/oracle/libs にあります。
電子メール・プロバイダおよびSMSプロバイダのカスタマイズに必要なjarファイルと、OAM認証プラグインが含まれます。 また、ファイル・ベースのボールトのデプロイメントに必要なjarも含まれます。 |
JARPATH |
これには、ファイル・ベースのボールトを適切に実行するために必要なjarが含まれます。 |
3.1.3 管理コンテナにマウントされたボリューム
この項では、管理コンテナ・ポッドにマウントされたボリュームについて詳しく説明します。
表3-3 管理コンテナにマウントされたボリューム
マウント・フォルダ | 説明 | 設定される権限 |
---|---|---|
/u01/oracle/logs |
パスは構成できません。 これは、インストール・ログおよびステータスを格納するために使用されます これは、前提条件として作成されたNFSボリューム |
読取り/書込み/実行 NFSボリューム |
/u01/oracle/scripts/settings |
パスは構成できません。 これは、OAAおよびOARMをインストールするためのカスタマイズされた構成ファイルの格納に使用されます。 これは、前提条件として作成されたNFSボリューム |
読取り/書込み/実行 NFSボリューム |
/u01/oracle/scripts/creds |
パスは構成できません。 これは、k8sconfig、helmconfig、trust.p12、cert.p2などの資格証明ファイルを格納するために使用されます これは、前提条件として作成されたNFSボリューム |
読取り/書込み/実行 NFSボリューム |
/u01/oracle/service/store/oaa |
パスは構成可能です。 これは、ファイルベースのボールトのボールト・アーティファクトを格納するために使用されます。 これは、前提条件として作成されたNFSボリューム |
読取り/書込み/実行 NFSボリューム |
3.2 OAAおよびOARMのインストールに事前に必要な構成
インストール手順に進む前に、次の操作を実行したことを確認してください:
3.2.1 Kubernetesクラスタの構成
OAAとOARMは、クラウド・ネイティブ環境にデプロイするよう設計されています。OAAとOARMは、Helmチャートで管理されるKubernetesクラスタ上でマイクロサービスとして実行される複数のコンポーネントで構成されています。具体的には、各コンポーネント(マイクロサービス)は、クラスタ内のKubernetesノードにデプロイされるKubernetesポッドとして構成されます。
次の要件を満たすKubernetesクラスタをインストールする必要があります:
- Kubernetesクラスタには3つ以上のノードが必要です。
- これらのノードは、次の最小システム仕様要件を満たしている必要があります:
システム 最小要件 メモリー 64GB RAM ディスク 150GB CPU 8 CPU (仮想化サポート付き。たとえば、Intel VTなど) - HelmをKubernetesクラスタにインストールする必要があります。Helmは、必要なリソースを作成およびデプロイするために使用されます。
- サポートされているコンテナ・エンジンをKubernetesクラスタにインストールして実行する必要があります。
- Kubernetesクラスタおよびコンテナ・エンジンは、My Oracle SupportのドキュメントID 2723908.1で概説されている最小バージョン要件を満たす必要があります。
- Kubernetesクラスタのノードは、ネットワーク・ファイル・システム(NFS)マウントなどの共有ボリュームにアクセスできる必要があります。このNFSマウントは、インストール中に管理コンテナによって使用され、(OCIベースのボールトを使用していない場合は)ファイル・ベースのボールトに対して、またジオロケーション・データのロードなどの他のインストール後のタスクに対して使用されます。
3.2.2 NFSボリュームの構成
Kubernetesクラスタ内のすべてのノードがNFSサーバー上の共有ボリュームにアクセスできる必要があります。OAA/OARMのインストール中、管理コンテナ・ポッドは構成情報、資格証明およびログをNFSボリュームに格納します。インストールが完了すると、ポッドは、ランタイム資格証明の格納およびアクセスのために、ファイル・ベースのボールト(OCIベースのボールトを使用しない場合)を含むボリュームにアクセスできる必要があります。
インストール前に、次のNFSボリュームを作成する必要があります。いずれの場合も、NFSエクスポート・パスにはすべてに対する読取り/書込み/実行権限が必要です。クラスタ内のすべてのノードでNFSボリュームにアクセスできることを確認します。
ボリューム | 説明 | パス |
---|---|---|
構成 | installOAA.properties などのOAA構成を格納するNFSボリューム。
|
<NFS_CONFIG_PATH> |
資格証明 | Kubernetes構成、Helm構成、SSHキー、PKCS12ファイルなどのOAA資格証明を格納するNFSボリューム。 | <NFS_CREDS_PATH> |
ログ | OAAインストール・ログおよびステータスを格納するNFSボリューム。 | <NFS_LOGS_PATH> |
ファイル・ベースのボールト | OAAランタイム資格証明を格納するNFSボリューム。 | <NFS_VAULT_PATH> |
3.2.3 Oracle Databaseのインストール
OAAおよびOARMでは、データベース・スキーマを使用して情報が格納されます。OCIまたはオンプレミスにOracle Databaseをインストールして構成する必要があります。データベースがパーティショニング機能/能力をサポートしている必要があります。
OAAおよびOARMでは、Oracle Database 12c (12.2.0.1+)、18cおよび19cがサポートされています。サポートされているデータベース・バージョンの詳細は、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlを参照してください。
OAA/OARMをインストールするKubernetesクラスタには、データベースへのネットワーク接続が必要です。
ノート:
ASM以外のデータベースを使用する場合は、データベースにパラメータDB_CREATE_FILE_DEST
が設定されていることを確認する必要があります。たとえば:SQL> connect SYS/<password> as SYSDBA;
Connected.
SQL> show parameter DB_CREATE_FILE_DEST;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string /u01/app/oracle/oradata
SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u01/app/oracle/oradata' scope=both;
ここで、/u01/app/oracle/oradata
は、データファイルが存在するパスです。
3.2.4 OAM OAuthのインストールおよび構成
OAAおよびOARMでは、OAuthを有効にしてOracle Access Management (OAM)インストールにアクセスする必要があります。OAA/OARMをインストールするKubernetesクラスタには、OAMインストールへのネットワーク接続が必要です。
ノート:
インストール中にUIコンポーネントが不要な場合や無効にする必要がある場合は、この項のOAuth構成をスキップできます。OAuth構成をスキップする場合は、installOAA.properties
内にoauth.enabled=false
を関連プロパティとともに設定する必要があります。詳細は、「OAM OAuth構成」を参照してください。
- Oracle Access Managementのインストール詳細は、「Oracle Access Managementのインストール」を参照してください。
- WebGatesをOAMに登録します。詳細は、OAMエージェントの登録および管理に関する項を参照してください
- Oracle Access ManagementコンソールでOAuthを有効にします:
- OAMコンソール(
https://<OAMAdminHost>:<OAMAdminPort>/oamconsole/
)にログインします - 「ようこそ」ページで、「構成」、「使用可能なサービス」の順にクリックします
- OAuthおよびOpenIDConnectサービスの横にある「サービスの有効化」をクリックします(または緑色のステータス・チェック・マークが表示されることを確認します)。
- OAMコンソール(
<OHS_HOME>/user_projects/domains/base_domain/config/fmwconfig/components/OHS/<ohs_instance_name>
にあるmod_wl_ohs.confファイルを開き、次を追加します:<Location /oauth2> SetHandler weblogic-handler WebLogicHost <OAM_Managed_Server_Host> WebLogicPort <OAM_Managed_Server_Port> </Location> <Location /oam> SetHandler weblogic-handler WebLogicHost <OAM_Managed_Server_Host> WebLogicPort <OAM_Managed_Server_Port> </Location> <Location /.well-known/openid-configuration> SetHandler weblogic-handler WebLogicHost <OAM_Managed_Server_Host> WebLogicPort <OAM_Managed_Server_Port> PathTrim /.well-known PathPrepend /oauth2/rest </Location> <Location /.well-known/oidc-configuration> SetHandler weblogic-handler WebLogicHost <OAM_Managed_Server_Host> WebLogicPort <OAM_Managed_Server_Port> PathTrim /.well-known PathPrepend /oauth2/rest </Location> <Location /CustomConsent> SetHandler weblogic-handler WebLogicHost <OAM_Managed_Server_Host> WebLogicPort <OAM_Managed_Server_Port> </Location>
ノート:
<OAM_Managed_Server_Host>
および<OAM_Managed_Server_Port>
は、OAM管理対象サーバーのホスト名とポートです。<OHS_HOME>/user_projects/domains/base_domain/config/fmwconfig/components/OHS/<ohs_instance_name>/
にあるhttpd.confファイルを開き、次を追加します:ノート:
<DomainName>
でOAuthアイデンティティ・ドメインの値を指定します。<DomainName>
は、後でinstallOAA.properties
のパラメータoauth.domainname
で使用されます。<IfModule mod_rewrite.c> RewriteEngine on RewriteRule ^/oauth2/rest/authorize? /oauth2/rest/authorize?domain=<DomainName> [PT,QSA,L] RewriteRule ^/oauth2/rest/token? /oauth2/rest/token?domain=<DomainName> [PT,QSA,L] RewriteRule ^/oauth2/rest/token/info? /oauth2/rest/token/info?domain=<DomainName> [PT,QSA,L] RewriteRule ^/oauth2/rest/authz? /oauth2/rest/authz?domain=<DomainName> [PT,QSA,L] RewriteRule ^/oauth2/rest/userinfo? /oauth2/rest/userinfo?domain=<DomainName> [PT,QSA,L] RewriteRule ^/oauth2/rest/security? /oauth2/rest/security?domain=<DomainName> [PT,QSA,L] RewriteRule ^/oauth2/rest/userlogout? /oauth2/rest/userlogout?domain=<DomainName> [PT,QSA,L] </IfModule> <IfModule mod_headers.c> #Add Identity domain header always for OpenID requests RequestHeader set X-OAUTH-IDENTITY-DOMAIN-NAME "<DomainName>" </IfModule>
- 前述のステップで定義されたOHS WebGateについて、OAMコンソールで次を実行します:
- 次の各リソースを作成し、「保護レベル」を
「除外」
に設定します。- /oauth2/rest/**
- /oam/**
- /.well-known/openid-configuration
- /iam/access/binding/api/v10/oap/**
- /oam/services/rest/**
- /iam/admin/config/api/v1/config/**
- /oaa-admin/**
- /admin-ui/**
- /oaa/**
- /policy/**
- /oaa-policy/**
- /oaa-email-factor/**
- /oaa-sms-factor/**
- /oaa-totp-factor/**
- /oaa-yotp-factor/**
- /fido/**
- /oaa-kba/**
- /oaa-push-factor/**
- /risk-analyzer/**
- /risk-cc/**
- /consolehelp/**
- /otpfp/**
- 次の各リソースを作成し、「保護レベル」を
「保護」
に設定し、「認証ポリシー」および「認可ポリシー」を保護されたリソース・ポリシー
に設定します- /oauth2/rest/approval (これは
POST
操作用です) - /oam/pages/consent.jsp (これは
GET
操作用です)
- /oauth2/rest/approval (これは
詳細は、ポリシー・リソース定義の追加および管理に関する項を参照してください
- 次の各リソースを作成し、「保護レベル」を
- OAMでOHSをリバース・プロキシとして構成します。次の手順を実行します:
- OAMコンソール(
https://<OAMAdminHost>:<OAMAdminPort>/oamconsole/
)にログインします - 「ようこそ」ページで、「構成」をクリックし、「設定」タイルで「表示」→「Access Manager」をクリックします。
- 「ロード・バランシング」で、「OHSホスト」と「OHSポート」を指定します。
- OAMコンソール(
3.2.5 OAMアイデンティティ・ストアでのユーザーおよびグループの設定
- OAA-Admin-Role。これは、OAA管理コンソールUIにアクセスする権限を持つユーザーを認証するために使用されます。
- OAA-App-User。これには、OAAユーザー・プリファレンスUIにアクセスする権限を持つユーザーが含まれます。
OAA-App-User
グループのメンバーであることが必要で、メンバーでない場合は、OAM OAuthを介してOAAユーザー・プリファレンスのUIにログインできません。同様に、管理者がOAA管理コンソールにアクセスするには、OAA-Admin-Role
グループのメンバーであることが必要です。
ノート:
ユーザーをOAA-Admin-RoleおよびOAA-App-Userグループの両方のメンバーにすることはできません。そのため、専用の管理者ユーザー名の使用をお薦めします。ユーザーとグループの作成
- LDIFファイル
oaa_admin.ldif
を作成します。このファイルの内容は次のとおりです:ノート:
次の例は、OAMが有効になったディレクトリが対象です。dn: cn=oaaadmin,cn=Users,dc=example,dc=com changetype: add objectClass: orclUserV2 objectClass: oblixorgperson objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: oblixPersonPwdPolicy objectClass: orclAppIDUser objectClass: orclUser objectClass: orclIDXPerson objectClass: top objectClass: OIMPersonPwdPolicy givenName: oaaadmin uid: oaaadmin orclIsEnabled: ENABLED sn: oaaadmin userPassword: <Password> mail: oamadmin@example.com orclSAMAccountName: oaaadmin cn: oaaadmin obpasswordchangeflag: false ds-pwp-password-policy-dn: cn=FAPolicy,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com dn:cn=OAA-Admin-Role,cn=Groups,dc=example,dc=com changetype: add objectClass: top objectClass: groupofuniquenames uniqueMember: cn=oaaadmin,cn=Users,dc=example,dc=com dn:cn=OAA-App-User,cn=Groups,dc=example,dc=com changetype: add objectClass: top objectClass: groupofuniquenames
- LDIFファイルをディレクトリにロードします。次の例では、Oracle Unified Directoryを使用していると想定しています:
$ cd INSTANCE_DIR/OUD/bin ldapmodify -h <OUD_HOSTNAME> -p 1389 -D "cn=Directory Manager" -w <password> -f oaa_admin.ldif
OAAユーザー・グループへの既存のユーザーの追加
OAA-App-User
グループにユーザーを追加する必要があります:
- LDAPインスタンスで次のコマンドを実行しますこれらのコマンドにより、既存のすべてのユーザーを
OAA-App-User
グループに追加するLDIFファイルが作成されます:echo "dn:cn=OAA-App-User,cn=Groups,dc=example,dc=com" > update_group.ldif
echo "changetype: modify" >> update_group.ldif
echo "add: uniqueMember" >> update_group.ldif
ldapsearch -h <OUD_HOSTNAME> -p 1389 "cn=Directory Manager" -w <password> -b cn=Users,dc=example,dc=com "cn=*" dn | grep -v oaaadmin | grep -v "dn: cn=Users,dc=example,dc=com" | grep cn| awk ' { print "uniqueMember: "$2 } ' >> update_group.ldif
update_group.ldif
を編集し、グループに追加しないユーザーを削除します。- LDIFファイルをディレクトリにロードします:
ldapmodify -h <OUD_HOSTNAME> -p 1389 -D "cn=Directory Manager" -w <password> -f update_group.ldif
3.2.6 コンテナ・イメージ・レジストリ(CIR)のインストール
管理コンテナのインストール中に、OAAおよびOARMコンテナ・イメージがコンテナ・イメージ・レジストリ(CIR)にプッシュされます。OAAとOARMがデプロイされるとき、デプロイメントでは同じコンテナ・イメージ・レジストリからイメージがプルされます。そのため、前提条件としてコンテナ・イメージ・レジストリをインストールする必要があります。コンテナ・イメージ・レジストリは、OAA/OARMをデプロイするKubernetesクラスタ内のすべてのノードからアクセスできる必要があります。
- oaa-admin
- oaa-factor-email
- oaa-factor-fido
- oaa-factor-kba
- oaa-factor-push
- oaa-factor-sms
- oaa-factor-totp
- oaa-factor-yotp
- oaa-factor-custom
- oaa-mgmt
- oaa-policy
- oaa-spui
- oaa-svc
- risk-cc
- risk-engine
CIRがない場合は、https://hub.docker.com/_/registry/からDockerレジストリをダウンロードできます。
3.2.7 外部ホスト名解決のためのCoreDNSの構成
Kubernetesクラスタがインストールに必要なホスト名を解決できるように、クラスタでCoreDNSを構成する必要があります。
- プロキシ・サーバー、Kubernetesノード、OAM OAuthサーバー、Oracle Databaseおよびコンテナ・イメージ・レジストリのhostname.domainとIPアドレスを追加します。または、
- プロキシ・サーバー、Kubernetesノード、OAM OAuthサーバー、Oracle Databaseおよびコンテナ・イメージ・レジストリのhostname.domainとIPアドレスを解決できるドメイン・ネーム・サーバー(DNS)を追加します。
CoreDNSへの個々のホスト名およびIPアドレスまたはDNSの追加
- 次のコマンドを実行して、coredns configmapを編集します:
これにより、kubectl edit configmap/coredns -n kube-system
vi
のような編集セッションに移動します。 - 個々のホスト名とIPアドレスを追加する場合は、定義するホストごとに1つずつエントリを含めたhostsセクションをファイルに追加します。たとえば:
または、ドメイン・ネーム・サーバー(DNS)を追加する場合は、DNSのセクションを追加します:apiVersion: v1 data: Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { max_concurrent 1000 } cache 30 loop reload loadbalance hosts custom.hosts example.com { 1.1.1.1 oam.example.com 1.1.1.2 db.example.com 1.1.1.3 container-registry.example.com 1.1.1.4 masternode.example.com 1.1.1.5 worker1.example.com 1.1.1.6 worker2.example.com fallthrough } } kind: ConfigMap metadata: creationTimestamp: "2021-11-09T14:08:31Z" name: coredns namespace: kube-system resourceVersion: "25242052" uid: 21e623cf-e393-425a-81dc-68b1b06542b4
apiVersion: v1 data: Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { max_concurrent 1000 } cache 30 loop reload loadbalance } example.com:53 { errors cache 30 forward . <DNS_IPADDRESS> } kind: ConfigMap metadata: creationTimestamp: "2021-11-09T14:08:31Z" name: coredns namespace: kube-system resourceVersion: "25242052" uid: 21e623cf-e393-425a-81dc-68b1b06542b4
- ファイルを保存します(
!wq
)。 - CoreDNSを再起動します:
- 次のコマンドを実行して、corednsを再起動します:
kubectl delete pod --namespace kube-system --selector k8s-app=kube-dns
- 次のコマンドを実行して、corednsポッドが問題なく再起動されることを確認します:
エラーが表示された場合は、次のコマンドを使用してログを表示してから、coredns configmapを再度編集して修正します:kubectl get pods -n kube-system
kubectl logs -n kube-system coredns--<ID>
- 次のコマンドを実行して、corednsを再起動します:
DNS解決の検証
- 次のコマンドを実行して、alpineコンテナを実行します:
これにより、コンテナ内のBashシェル内に移動します。kubectl run -i --tty --rm debug --image=docker.io/library/alpine:latest --restart=Never -- sh
- コンテナ内で、データベース、OAM OAuthサーバー、コンテナ・イメージ・レジストリなどに対して
nslookup
を実行できるようになります。次に例を示します:nslookup oam.example.com
3.2.8 インストール・ホストの要件
管理コンテナのインストールは、Kubernetesクラスタにデプロイするためのアクセス権を持つ任意のノードから実行できます。この項では、管理コンテナのインストールが実行されるノードに対する特定の要件をリストします。
インストール・ホストは、次の要件を満たしている必要があります:
- Linux x86_64。
- 2つ以上のCPUと16GBのRAM。
- ルート・パーティション"
/
"内に40GB以上の空き領域。 - ノードは、管理コンテナおよびOAA/OARMがインストールされるKubernetesクラスタにデプロイするためのアクセス権を持っている必要があります。kubectlバージョンの要件は、「Kubernetesクラスタの構成」のとおりです。
- Podman 3.3.0以降。(podmanを選択しない場合は、Docker 19.03以上を使用できます)。
- Helm 3.5以降。
- Openssl。
- インターネットへのアクセスにプロキシを必要とする環境の場合は、Oracle Container Registryに接続するために関連するプロキシを設定する必要があります。たとえば:
export http_proxy=http://proxy.example.com:80 export https_proxy=http://proxy.example.com:80 export HTTPS_PROXY=http://proxy.example.com:80 export HTTP_PROXY=http://proxy.example.com:80
また、no_proxy
が設定され、そこにkubectl config view
のserver
の下の出力で参照されるノードが含まれていることを確認する必要があります。たとえば、kubectl config view
で次のように表示されるとします:
この場合は、次のように設定します:kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://masternode.example.com:6443 name: kubernetes contexts: etc...
export NO_PROXY=masternode.example.com:$NO_PROXY export no_proxy=masternode.example.com:$no_proxy
- 「コンテナ・イメージ・レジストリ(CIR)のインストール」に示されているように、ノードがコンテナ・イメージ・レジストリにアクセスできる必要があります。
- インストールでサポート・イメージがプルされるためには、インストールを実行する管理者がOracle Container Registryのログイン資格証明を持っている必要があります。管理コンテナのインストール中に、これらの資格証明の入力を求められます。
- インストール・ホストからOracle Container Registryにログインできることを確認します:
podman login container-registry.oracle.com
ノート:
podmanを使用しておらず、Dockerを使用している場合は、docker login container-registry.oracle.com
を実行します。
3.2.9 サーバー証明書および信頼証明書の生成
OAAおよびOARMは通信にSSLを使用します。インストール前に、サーバー証明書および信頼証明書キーストア(PKCS12)を生成する必要があります。
証明書を生成するためのサード・パーティCAの使用
- 管理コンテナのインストールを実行するノードで、ディレクトリを作成し、そのフォルダに移動します。次に例を示します:
mkdir <workdir>/oaa_ssl export WORKDIR=<workdir> cd $WORKDIR/oaa_ssl
- サーバー証明書の4096ビット秘密キー(
oaa.key
) を生成します:openssl genrsa -out oaa.key 4096
- 証明書署名リクエスト(
oaa.csr
)を作成します:
求められた場合は、証明書署名リクエスト(CSR)作成の詳細を入力します。たとえば:openssl req -new -key oaa.key -out oaa.csr
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:California Locality Name (eg, city) [Default City]:Redwood City Organization Name (eg, company) [Default Company Ltd]:Example Company Organizational Unit Name (eg, section) []:Security Common Name (eg, your name or your server's hostname) []:oaa.example.com Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
- CSR (
oaa.csr
)をサード・パーティCAに送信します。 - CAから証明書を受信したら、ファイルの名前を
oaa.pem
に変更し、それを$WORKDIR/oaa_ssl
ディレクトリにコピーします。ノート:
証明書oaa.PEM
はPEM形式である必要があります。PEM形式でない場合は、opensslを使用してPEMに変換します。たとえば、DER形式からPEMに変換するには:openssl x509 -inform der -in oaa.der -out oaa.pem
- 信頼ルートCA証明書(
rootca.pem
)と、oaa.pem
に署名したチェーン内の他のCA証明書(rootca1.pem
、rootca2.pem
など)を、$WORKDIR/oaa_ssl
ディレクトリにコピーします。前述のとおり、CA証明書はPEM形式である必要があるため、必要に応じて変換します。 - CAのチェーンに複数の証明書がある場合は、すべてのCA証明書を含む
bundle.pem
を作成します:cat rootca.pem rootca1.pem rootca2.pem >>bundle.pem
- 次のように、信頼証明書PKCS12ファイル(
trust.p12
)をファイルから作成します:
求められた場合は、エクスポート・パスワードを入力して確認します。openssl pkcs12 -export -out trust.p12 -nokeys -in bundle.pem
ノート:
CAに証明書チェーンがない場合は、bundle.pem
をrootca.pem
に置き換えます。 - 次のように、サーバー証明書PKCS12ファイル(
cert.p12
)を作成します:
求められた場合は、エクスポート・パスワードを入力して確認します。openssl pkcs12 -export -out cert.p12 -inkey oaa.key -in oaa.pem -chain -CAfile bundle.pem
ノート:
CAに証明書チェーンがない場合は、bundle.pem
をrootca.pem
に置き換えます。
ノート:
cert.p12
およびtrust.p12
へのパスは、後でinstallOAA.properties
のパラメータcommon.local.sslcert
およびcommon.local.trustcert
で使用されます。
テスト目的で独自のCAおよび証明書を生成します
- 次のように、信頼証明書PKCS12ファイル(
trust.p12
)を作成します:- 管理コンテナのインストールを実行するノードで、ディレクトリを作成し、そのフォルダに移動します。次に例を示します:
mkdir <workdir>/oaa_ssl export WORKDIR=<workdir> cd $WORKDIR/oaa_ssl
- ルート認証局(CA)の4096ビットの秘密キーを生成します:
openssl genrsa -out ca.key 4096
- 自己署名ルートCA証明書(
ca.crt
)を作成します:
求められた場合は、CA作成の詳細を入力します。たとえば:openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:California Locality Name (eg, city) [Default City]:Redwood City Organization Name (eg, company) [Default Company Ltd]:Example Company Organizational Unit Name (eg, section) []:Security Common Name (eg, your name or your server's hostname) []:OAA Certificate Authority Email Address []:
- CA証明書のPKCS12ファイルを生成します:
求められた場合は、エクスポート・パスワードを入力して確認します。openssl pkcs12 -export -out trust.p12 -nokeys -in ca.crt
- 管理コンテナのインストールを実行するノードで、ディレクトリを作成し、そのフォルダに移動します。次に例を示します:
- 次のように、サーバー証明書PKCS12ファイル(
cert.p12
)を作成します:- サーバー証明書の4096ビット秘密キー(
oaa.key
) を生成します:openssl genrsa -out oaa.key 4096
- 証明書署名リクエスト(
cert.csr
)を作成します:
求められた場合は、証明書署名リクエスト(CSR)作成の詳細を入力します。たとえば:openssl req -new -key oaa.key -out cert.csr
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:California Locality Name (eg, city) [Default City]:Redwood City Organization Name (eg, company) [Default Company Ltd]:Example Company Organizational Unit Name (eg, section) []:Security Common Name (eg, your name or your server's hostname) []:oaa.example.com Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
- 作成しておいたCAを使用して、CSRから証明書を生成します:
openssl x509 -req -days 1826 -in cert.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out oaa.crt
- 秘密キーとサーバー証明書からPKCS12ファイル(
cert.p12
)を生成します:
求められた場合は、エクスポート・パスワードを入力して確認します。openssl pkcs12 -export -out cert.p12 -inkey oaa.key -in oaa.crt -chain -CAfile ca.crt
- サーバー証明書の4096ビット秘密キー(
ノート:
cert.p12
およびtrust.p12
へのパスは、後でinstallOAA.properties
のパラメータcommon.local.sslcert
およびcommon.local.trustcert
で使用されます。
3.2.10 Kubernetesネームスペースおよびシークレットの作成
OAAおよびOARMデプロイメントのKubernetesネームスペースおよびシークレットを作成します。
- OAAおよびOARMデプロイメント用のKubernetesネームスペースを作成します:
たとえば:kubectl create namespace <namespace>
kubectl create namespace oaans
ノート:
指定したネームスペースは、後でinstallOAA.properties
のパラメータcommon.kube.namespace=oaans
で使用されます。 - OAAネームスペースで、コンテナ・イメージ・レジストリ(CIR)のKubernetesシークレットを作成します。これは、管理コンテナ・ポッドがイメージをCIRにプッシュできるようにするため、またOAA/OARMデプロイメントがイメージをCIRからプルできるようにするために必要です。
たとえば:kubectl create secret docker-registry dockersecret --docker-server=<CONTAINER_REGISTRY> \ --docker-username='<USER_NAME>' \ --docker-password='<PASSWORD>' \ --docker-email='<EMAIL_ADDRESS>' \ --namespace=<namespace>
kubectl create secret docker-registry dockersecret --docker-server=container-registry.example.com \ --docker-username="user@example.com" \ --docker-password=<PASSWORD> --docker-email=user@example.com \ --namespace=oaans
ノート:
シークレット名dockersecret
は、後でinstallOAA.properties
のパラメータinstall.global.imagePullSecrets\[0\].name
で使用されます。
次のステップ: OAAおよびOARMインストール用のプロパティ・ファイルの準備
3.3 インストール・ファイルのダウンロードと管理コンテナの準備
この項では、インストール・ファイルをダウンロードし、OAAおよびOARMの管理コンテナを準備するステップを説明します。
管理コンテナのインストールは、Kubernetesクラスタにデプロイするためのアクセス権を持つ任意のノードから実行できます。インストール中、管理コンテナ・ポッドはKubernetesクラスタ内のいずれかのノードにデプロイします。
- ドキュメントID 2723908.1を参照して、My Oracle Supportから最新のOAAインストール・イメージ
<OAA_Image>.zip
をダウンロードします。 - 管理コンテナのインストールを実行するノードで、
$WORKDIR/oaaimages
ディレクトリを作成し、<OAA_Image>.zip
をそれにコピーします:mkdir -p $WORKDIR/oaaimages cd $WORKDIR/oaaimages cp <download_location>/<OAA_Image>.zip . unzip <OAA_Image>.zip
これにより、
<tar_file_name>.tar
ファイルが作成されます。 $WORKDIR/oaaimages/oaa-install
ディレクトリに移動し、インストール・テンプレート・ファイルをinstallOAA.properties
にコピーします:cd $WORKDIR/oaaimages/oaa-install cp installOAA.properties.template installOAA.properties
- 「OAAおよびOARMインストール用のプロパティ・ファイルの準備」に従って、この
installOAA.properties
を準備します
3.4 OAAおよびOARMインストール用のプロパティ・ファイルの準備
OAA、OAA-OARMおよびOARMのインストールは、installOAA.properties
ファイルでプロパティを設定してカスタマイズできます。installOAA.properties
は、管理コンテナのインストール・スクリプトで使用され、管理コンテナ・ポッドのインストール中に<NFS_CONFIG_PATH>
にコピーされます。installOAA.properties
ファイルは、後で、OAAまたはOARM(あるいはその両方)をデプロイするときにOAA.sh
スクリプトに引数として渡されます。「OAAおよびOARMのデプロイ」を参照してください。
次の各項では、installOAA.properties
で許可されるカスタマイズについて説明します。
3.4.1 共通のデプロイメント構成
この項では、installOAA.properties
で設定できる共通のデプロイメント構成プロパティについて詳しく説明します。
表3-4 共通のデプロイメント構成
プロパティ | 必須/オプション | インストール・タイプ | 説明 |
---|---|---|---|
common.dryrun |
オプション | OAA、OAA-OARMおよびOARM | 有効にしてtrueに設定すると、helmインストールでは生成された値のみが表示され、KubernetesクラスタでのOAA/OARMインストールは実際には実行されません。
これは、helmコマンドの |
common.deployment.name |
必須 | OAA、OAA-OARMおよびOARM | OAAインストールの名前。これは、helm installコマンドの実行時にはkubernetesクラスタおよびネームスペースごとに一意です。
指定する値は小文字にする必要があります。 |
common.deployment.overridefile |
オプション | OAA、OAA-OARMおよびOARM | チャート・パラメータのオーバーライドに関するオーバーライド・ファイル。helmチャートは、管理コンテナ内のhelmcharts ディレクトリにあります。values.yaml に定義されているすべてのパラメータは、有効になっていれば、このファイルでオーバーライドできます。このファイルの形式は、必ずYAMLにする必要があります。管理コンテナ内の~/installsettings ディレクトリに、サンプルのoaaoverride.yaml ファイルが存在します。
|
common.kube.context |
オプション | OAA、OAA-OARMおよびOARM | 使用するKubernetesコンテキストの名前。
コンテキストを指定しない場合、デフォルトのKubernetesコンテキストが使用されます。 |
common.kube.namespace |
オプション | OAA、OAA-OARMおよびOARM | OAAデプロイメントを作成するネームスペース。これは、「Kubernetesネームスペースおよびシークレットの作成」で作成したネームスペースである必要があります。パラメータが設定されていない場合は、デフォルト・ネームスペースにデプロイされます。 |
common.deployment.sslcert |
必須 | OAA、OAA-OARMおよびOARM | OAAインストールで使用されるサーバー証明書のPKCS12ファイルファイル名(cert.p12 など)は、「サーバー証明書および信頼証明書の生成」で生成したものと同じファイル名です。これはコンテナ内でマップされる内部パスであるため、PATHは変更しないでください。
ファイルはボールトにシードされ、すべてのOAAマイクロサービスによってダウンロードされます |
common.deployment.trustcert |
必須 | OAA、OAA-OARMおよびOARM | OAAインストールで使用される信頼証明書のPKCS12ファイル。ファイル名(trust.p12 など)は、「サーバー証明書および信頼証明書の生成」で生成したものと同じファイル名です。これはコンテナ内でマップされる内部パスであるため、PATHは変更しないでください。
ファイルはボールトにシードされ、すべてのOAAマイクロサービスによってダウンロードされます |
common.deployment.importtruststore |
必須 | OAA、OAA-OARMおよびOARM | 有効になっている場合、信頼証明書がJREトラストストアにインポートされます。 |
common.deployment.keystorepassphrase |
必須 | OAA、OAA-OARMおよびOARM | 証明書PKCS12ファイルのパスフレーズ。これは、「サーバー証明書および信頼証明書の生成」でキーストアを作成するときに使用したパスフレーズです。
ここに値を指定しない場合、インストール時に値の入力を求めるプロンプトが表示されます |
common.deployment.truststorepassphrase |
必須 | OAA、OAA-OARMおよびOARM | 信頼証明書のPKCS12ファイルのパスフレーズ。これは、「サーバー証明書および信頼証明書の生成」で信頼キーストアを作成するときに使用したパスフレーズです ここに値を指定しない場合、インストール時に値の入力を求めるプロンプトが表示されます。 |
common.deployment.generate.secret |
必須 | OAA、OAA-OARMおよびOARM | trueに設定すると、インストールによって3つの対称キーが生成され、パラメータcommon.deployment.sslcert が参照するcert.p12 に追加されます。
次の暗号化キーが生成されます:
これらのキーを手動で作成する場合は、値を
false に設定する必要があります。キーを作成するには、次のコマンドを実行します: たとえば:
|
common.deployment.mode |
必須 | OAA、OAA-OARMおよびOARM | 次の値をinstallOAA.properties に設定できます
|
common.migration.configkey |
オプション | OAA、OAA-OARMおよびOARM | Base64でエンコードされた移行システムの構成キー。有効にすると、値がボールトに配置され、レガシー・データの移行に使用されます。これは、Oracle Adaptive Access Manager 11gR2PS3から移行する場合にのみ使用します。 |
common.migration.dbkey |
オプション | OAA、OAA-OARMおよびOARM | Base64でエンコードされた移行システムのデータベース・キー。有効にすると、値がボールトに配置され、データベース・データの移行に使用されます。これは、Oracle Adaptive Access Manager 11gR2PS3から移行する場合にのみ使用します。 |
common.oim.integration |
オプション | OAAおよびOAA-OARM | OIMと統合するには、プロパティをtrueに設定します。これにより、パスワードを忘れた場合の機能も有効になります。これは、Oracle Adaptive Access Manager 11gR2PS3から移行する場合にのみ使用します。 |
common.deployment.push.apnsjksfile |
オプション | OAAおよびOAA-OARM | Appleプッシュ通知サービスのプッシュ・ファクタを有効化する際に使用されるファイル。これを設定する必要があるのは、インストール前にJKSファイルの構成が済んでいる場合のみです。それ以外の場合は、インストール後に構成できます。JKSファイルを<NFS_VAULT_PATH>/ChallengeOMAPUSH/apns/ ディレクトリにコピーする必要があります。値は/u01/oracle/service/store/oaa/ChallengeOMAPUSH/apns/APNSCertificate.jks に設定する必要があります。詳細は、「iOSでのOracle Mobile Authenticatorのプッシュ通知の構成」を参照してください。
|
3.4.2 データベース構成
この項では、installOAA.properties
で設定できるデータベース構成プロパティについて詳しく説明します。
表3-5 データベース構成
プロパティ | 必須/オプション | 説明 |
---|---|---|
database.createschema |
必須 |
インストール時にスキーマの作成を可能にします。 これが |
database.host |
必須 | データベースのホスト名またはIPアドレスを指定します。 |
database.port |
必須 | データベース・ポートを指定します |
database.sysuser |
必須 | データベースのsysdba ユーザーを指定します
|
database.syspassword |
必須 | sysパスワードを指定します。
ここに値を指定しない場合、インストール時に値の入力を求めるプロンプトが表示されます。 |
database.schema |
必須 | インストールに使用するデータベース・スキーマの名前を指定します。 |
database.tablespace |
必須 | インストールに使用する表領域名を指定します。 |
database.schemapassword |
必須 | スキーマ・パスワードを指定します。
ここに値を指定しない場合、インストール時に値の入力を求めるプロンプトが表示されます。 |
database.svc |
必須 | データベース・サービス名を指定します |
database.name |
必須 | データベース名を指定します。データベース・サービス名と同じでもかまいません
RACデータベースを使用している場合、このパラメータは必要ありません。 |
ノート:
SSLを介してOracle Databaseへのセキュアな接続を使用する場合は、追加の構成ステップが必要です。これらのステップは、管理コンテナの起動後、OAAおよびOARMのデプロイの前に実行する必要があります:- データベースのOracleウォレットを取得します:
- 標準のOracleデータベースの場合、Oracle Databaseウォレットの検索方法の詳細は、データベース固有のドキュメントを参照してください。
- Oracle Autonomous Database on Shared Exadata Infrastructure (ATP-S)データベースの場合、クライアント資格証明のダウンロードに関する項に従います。
- OAAデプロイメントで使用される
<NFS_CONFIG_PATH>
にdb_wallet
ディレクトリを作成します。ウォレット・ファイルを<NFS_CONFIG_PATH>/db_wallet
ディレクトリにコピーします。 - OAA管理ポッドのbashシェルに入ります:
たとえば:kubectl exec -n <namespace> -ti <oaamgmt-pod> -- /bin/bash
kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv9 -- /bin/bash
- コンテナ内で
TNS_ADMIN
環境変数を設定します:export TNS_ADMIN=<NFS_CONFIG_PATH>/db_wallet
db_wallet
ディレクトリには、コンテナ内からアクセスできるように、正しい読取りおよび書込みアクセス権限が必要です。 - 「OAAおよびOARMのデプロイ」に従ってOAAをデプロイします。
3.4.3 OAM OAuth構成
この項では、installOAA.properties
で設定できるOAM OAuth構成プロパティについて詳しく説明します。
OAuth用にOAMを構成するための前提条件ステップを実行したことを確認してください。詳細は、「OAM OAuthのインストールおよび構成」を参照してください。
表3-6 OAM OAuth構成
プロパティ | 必須/オプション | 説明 |
---|---|---|
oauth.enabled |
必須 |
OAA管理ユーザー・インタフェース(UI)およびOAAユーザー・プリファレンスのUIを使用する場合は、OAuthが必要です。 UIへのアクセスが必要な場合は、これを UIにアクセスしない場合は、これを
false に設定します。oauth.enabled=false を設定した場合、次のプロパティもfalse に設定し、インストールが失敗しないようにする必要があります:
oauth.enabled=false の場合、Optional Configurationで次のパラメータをfalse に設定する必要もあります:
|
oauth.createdomain |
オプション | OAuthドメインを作成します。
OAuthドメインは、OAuthリソースおよびクライアントの作成に必要です。 |
oauth.createresource |
オプション | OAuthリソースを作成します。
OAuthリソースは、OAuthクライアントの作成に必要です。 |
oauth.createclient |
オプション | OAuthクライアントを作成します。
|
oauth.domainname |
|
OAuthドメイン名を指定します。これは、「OAM OAuthのインストールおよび構成」に記載されている<DomainName> と同一にする必要があります。
|
oauth.identityprovider |
oauth.createdomain がtrue に設定されている場合は必須 |
OAM OAuthドメインのアイデンティティ・プロバイダを指定します。これは、OAMで使用されるユーザー・アイデンティティ・ストアの名前です。 |
oauth.clientname |
|
インストール時に作成されるOAuthクライアント名を指定します。 |
oauth.clientgrants |
oauth.createclient がtrue に設定されている場合は必須 |
OAuthクライアントのクライアント権限付与を指定します。OAuthクライアントにはCLIENT_CREDENTIALS が必要です。これは、OAuthステータスを確認するために検証ステージで使用されます。使用できるのは次の値です:
"PASSWORD"、"CLIENT_CREDENTIALS"、"JWT_BEARER"、"REFRESH_TOKEN"、"AUTHORIZATION_CODE"、"IMPLICIT"。 |
oauth.clienttype |
oauth.createclient がtrue に設定されている場合は必須 |
OAuthクライアント・タイプを指定します。OAM OAuthでは、次のクライアント・タイプがサポートされます:
PUBLIC_CLIENT、CONFIDENTIAL_CLIENT、MOBILE_CLIENT。 OAA管理コンソールおよびユーザー・プリファレンス・コンソールではOAuthが使用されるため、PUBLIC_CLIENTを使用する必要があります。 |
oauth.clientpassword |
oauth.enabled=true の場合は必須 |
OAuthクライアントに使用するパスワードを指定します。クライアント・パスワードは正規表現^[a-zA-Z0-9.\-\/+=@_ ]*$ に準拠する必要があり、最大長は500です。
|
oauth.resourcename |
oauth.enabled=true の場合は必須 |
インストール時に作成されるOAuthリソース名を指定します。OAuth設定の検証にも使用されます。 |
oauth.resourcescope |
oauth.enabled=true の場合は必須 |
インストール時に作成されるOAuthリソース・スコープを指定します。OAuth設定の検証にも使用されます。 |
oauth.redirecturl |
oauth.createclient がtrue に設定されている場合は必須 |
クライアント・リダイレクトURLを指定します。認証後のリダイレクトURLが必要です。これは、アクセス・トークンを生成してOAMのOAuthサービスの構成を検証するために使用されます。 |
oauth.applicationid |
oauth.createclient がtrue に設定されている場合は必須 |
OAuthによって保護されるOAAのアプリケーションID。値には、有効な任意の文字列を指定できます。OAAインストール後のOAMとOAA間のランタイム統合を設定する必要があります。「OAAとOAMとの統合」を参照してください。 |
oauth.adminurl |
oauth.enabled=true の場合は必須 |
OAuth管理URLを指定します。これはOAM管理サーバーのURLです(例: http://oam.example.com:7001 )。
|
oauth.basicauthzheader |
oauth.enabled=true の場合は必須 |
OAM管理サーバーのBase64でエンコードされた認可ヘッダー。値は、echo -n weblogic:<password> | base64 を実行して確認できます。
|
oauth.identityuri |
oauth.enabled=true の場合は必須 |
アイデンティティ・サーバーのURLで、/.well-known/openid-configuration エンドポイントを使用したOIDCメタデータの取得に使用されます。これは、OAuthサービスのランタイム・サポートを提供するOAM管理対象サーバーのフロントエンドURLです。例: http://ohs.example.com:7777 。
|
3.4.4 ボールト構成
この項では、installOAA.properties
で設定できるボールト構成プロパティについて詳しく説明します。
OCIボールトを使用している場合は、ファイルベースのボールトに設定するプロパティは無視できます。
表3-7 ボールト構成
プロパティ | 説明 |
---|---|
vault.deploy.name |
このデプロイメントのボールトに使用する名前。名前がボールトにすでに存在する場合は、再利用されます。 |
vault.create.deploy |
値がtrue に設定された場合、ボールトの作成が実行されます。ただし、vault.deploy.name に指定された名前のボールトがすでに存在する場合、ボールトの作成はスキップされます。
|
vault.provider |
ボールトがOCIかファイルベースかを指定します
次のいずれかの値を指定します。
|
vault.provider=oci を設定した場合、OCIベースのボールト構成には、次のプロパティが必須です。OCIボールトの作成の詳細は、 ボールトの管理に関する項を参照してください次のパラメータを設定するには、OCIボールトが存在している必要があります。
|
|
vault.oci.uasoperator |
OCIボールトに対する読取りおよび書込み権限を持つユーザーのBase64でエンコードされた秘密キーを指定します。 |
vault.oci.tenancyId |
テナンシIDのBase64でエンコードされたOCI IDを指定します。 |
vault.oci.userId |
OCIボールトに対する読取りおよび書込み権限を持つユーザーのBase64でエンコードされたOCIDを指定します。 |
vault.oci.fpId |
OCIボールトに対する読取りおよび書込み権限を持つユーザーのBase64でエンコードされたフィンガープリントを指定します。 |
vault.oci.compartmentId |
OCIにボールトが存在するコンパートメントのBase64でエンコードされたOCIDを指定します。 |
vault.oci.vaultId |
OCI上のボールトのBase64でエンコードされたOCIDを指定します。 |
vault.oci.keyId |
ボールトのシークレットの暗号化に使用されるOCIボールト内のマスター秘密キーのBase64でエンコードされたOCIDを指定します。 |
vault.provider=fks を設定した場合、ファイルベースのボールト構成には、次のプロパティが必須です
|
|
vault.fks.server |
<NFS_VAULT_PATH> にNFSサーバーのホスト名またはIPアドレスを指定します。
詳細は、「NFSボリュームの構成」を参照してください。 |
vault.fks.path |
ファイル・ベースのボールトを格納する<NFS_VAULT_PATH> を指定します。
詳細は、「NFSボリュームの構成」を参照してください。 |
vault.fks.key |
ファイル・ベースのボールトのBase64でエンコードされたパスワードを指定します。パスワードのBase64でエンコードされたバージョンを検索するには、echo -n weblogic:<password> | base64 を使用します。
|
vault.fks.mountpath |
管理コンテナのマウント・パスと、ボールトが存在するインストール済サービスのマウント・パス。このプロパティの値は、helmチャートから渡された値と同一にする必要があります。この値は変更しないでください: /u01/oracle/service/store/oaa 。
|
3.4.5 Helmチャート構成
この項では、installOAA.properties
で設定できるhelmチャート構成プロパティについて詳しく説明します。
これらのプロパティは、インストール時にhelmチャートへの入力として渡されます。
表3-8 Helmチャート構成
プロパティ | 必須/オプション | 説明 |
---|---|---|
install.global.repo |
必須 |
OAAコンテナ・イメージが存在するコンテナ・イメージ・レジストリを指定します。 詳細は、「コンテナ・イメージ・レジストリ(CIR)のインストール」を参照してください |
install.global.testrepo |
オプション | コンテナ・イメージをプルできる代替コンテナ・イメージ・レジストリを指定します。たとえば、OAAは、外部サイト(https://ghcr.io/oracle )からoraclelinux:8-slim およびoraclelinux7-instantclient イメージをインストールします。Kubernetesクラスタがインターネットにアクセスできない場合は、イメージをプルしてコンテナ・レジストリに格納する必要があります。次に、install.global.testrepo をコンテナ・レジストリの場所に設定する必要があります。
|
install.riskdb.service.type |
必須 | データベースがOAAインストールの外部にあるため、このプロパティの値は常にExternalName に設定する必要があります
|
install.global.imagePullSecrets\[0\].name |
必須 | 保護されたコンテナ・イメージ・レジストリからコンテナ・イメージをプルするときに使用する必要があるKubernetesシークレット参照を指定します。
ノート: これは、先に設定したKubernetesシークレット(dockersecret など)に設定する必要があります。詳細は、「Kubernetesネームスペースおよびシークレットの作成」を参照してください。
|
install.global.image.tag |
必須 | グローバル・イメージ・タグをコンテナ・イメージ・レジストリのイメージ・タグに更新します。
ノート: installOAA.properties.template をinstallOAA.properties にコピーした場合、このタグはすでに設定されています。
|
install.global.oauth.logouturl |
オプション | OAuthで保護されたリソースのログアウトURLを指定します。これは、OAM管理対象サーバーのフロントエンドURLです。例: http://ohs.example.com:7777/oam/server/logout 。oauth.enabled がtrue に設定されている場合にのみ必要です。
|
install.global.uasapikey |
必須 | OAAマイクロサービスのRESTエンドポイントの保護に使用されるREST APIキーを指定します。 |
install.global.policyapikey |
必須 | OAAポリシー・マイクロサービスのRESTエンドポイントの保護に使用されるREST APIキーを指定します。 |
install.global.factorsapikey |
必須 | OAAファクタ・マイクロサービスのRESTエンドポイントの保護に使用されるREST APIキーを指定します。 |
install.global.riskapikey |
オプション | OAAリスク・マイクロサービスのRESTエンドポイントの保護に使用されるREST APIキーを指定します。
OAA-OARMインストールまたはOARMのみのインストールを実行する場合、このパラメータは必須です。 |
OCIボールトの場合、helmのインストール時に読取り専用ユーザーに対して指定すると、次の構成をオーバーライドできます。次のプロパティに値を指定しない場合、値はボールト構成から選択されます。 | ||
install.global.vault.mapId |
オプション | 既存のボールトの場合は、Base64 mapIdを指定できます。プロパティが設定されている場合は、ボールト内のデプロイ情報に対して検証されます。 |
install.global.vault.oci.uasoperator |
オプション | ボールトに対する読取り専用権限を持つユーザーのBase64でエンコードされた秘密キーを指定します。 |
install.global.vault.oci.tenancyId |
オプション | OCIからのBase64でエンコードされたテナンシIDを指定します |
install.global.vault.oci.userId |
オプション | OCIからのBase64でエンコードされたユーザーIDを指定します。 |
install.global.vault.oci.fpId |
オプション | OCIからのユーザーのBase64でエンコードされたフィンガープリントIDを指定します。 |
3.4.6 オプションの構成
この項では、installOAA.properties
で設定できるオプションの構成プロパティについて詳しく説明します。
プロパティ | 必須/オプション | 説明 |
---|---|---|
install.global.ingress.enabled |
オプション | このプロパティは、デプロイメントでイングレスを有効化するかどうかを指定するために使用します。値がtrueに設定されている場合、デプロイメントのKubernetesクラスタ内のイングレス・リソースが生成されます。純粋なNodePortベースのデプロイメントが必要な場合は、値をfalseに設定する必要があります。 |
install.global.ingress.runtime.host |
オプション | ランタイム・ホストのイングレス定義に使用するホスト名を指定できます。プロパティの値がない場合、イングレス定義は'*'ホストを使用して作成されます。
ランタイム・ホストは、すべてのfactors、oaa、spuiおよびriskを含むランタイム・サービスへのアクセスに使用されます。 |
install.global.ingress.admin.host |
オプション | 管理ホストのイングレス定義に使用するホスト名を指定できます。プロパティの値がない場合、イングレス定義は'*'ホストを使用して作成されます。
管理ホストは、admin、policyおよびrisk-ccサービスへのアクセスに使用されます。 |
install.global.dbhost
|
オプション | これらのプロパティはデータベースに関連しています。ここでプロパティを指定しない場合は、データベース構成で指定された値が使用されます。 |
install.global.oauth.oidcidentityuri
|
オプション | 次のプロパティはOAuthに関連しています。ここで指定されない場合は、OAuth構成で指定された値が使用されます。 |
install.global.serviceurl |
オプション | ロード・バランサ/イングレスURLが存在する場合は、URLをここで構成します。すべてのUIサービスは、このロード・バランサ/イングレスの背後に位置します。イングレス・インストールがtrueに設定されている場合、イングレスのインストール後に適切なサービスURLがフェッチされて、サービスURLとして使用されます。install.global.serviceurl を指定すると、このプロパティのサービスURLの優先度が高くなり、元の値がオーバーライドされます。
|
install.oaa-admin-ui.serviceurl |
オプション | oaa管理のサービスURL (install.global.serviceurl と異なる場合)。
|
install.spui.enabled=false
|
オプション | oauth.enabled=false の場合、OAA管理コンソール(OAA-admin-ui )、ユーザー・プリファレンス・コンソール(spui )およびFIDO (FIDO )およびKBA (OAA-KBA )ファクタは使用できません。oauth.enabled=false の場合、これらのプロパティをコメント解除する必要があります。
|
install.totp.enabled=false
|
認証ファクタ・サービスはデフォルトで有効になっています。無効にするには、行をコメント解除します。
|
|
install.service.type=NodePort
|
オプション | サービスのデフォルト・サービス・タイプはNodePortです。
デプロイメント・モードがRiskの場合、次のサービスはデプロイされません: fido、push、yotp、email、sms、totpおよびkba。
|
イングレスを使用したインストールの詳細は、「NGINXイングレスを使用したOAAおよびOARMのインストール」を参照してください
3.4.7 イングレス構成
この項では、installOAA.properties
で設定できるイングレス構成プロパティについて詳しく説明します。
表3-9 イングレス構成
プロパティ | 必須/オプション | 説明 |
---|---|---|
ingress.install |
必須 |
OAAまたはOARMインストールでイングレス・コントローラをインストールする場合は、値を イングレス・コントローラをインストールしない場合は、 これが |
ingress.namespace |
inress.install=trueの場合は必須です | イングレスのインストールに使用されるKubernetesネームスペース。このネームスペースは、インストール時にKubernetesに作成されます。たとえば、ingress-nginx です。
|
ingress.admissions.name=ingress-nginx-controller-admission |
inress.install=trueの場合はオプションです |
アドミッション・コントローラの名前。 アドミッション・コントローラは個別にインストールできます。イングレスのアドミッション名が存在しない場合は、NGINXイングレス・チャートで |
ingress.class.name=ingress-nginx-class |
inress.install=trueの場合は必須です | インストールに使用する必要があるイングレス・クラス名。既存のクラス名にはできません。 |
ingress.service.type |
inress.install=trueの場合は必須です |
ベア・メタルKubernetesクラスタを使用している場合は、値を Kubernetesクラスタの管理対象サービス(Oracle Cloud Infrastructure (OCI)上のOracle Kubernetes Engine (OKE)など)を使用している場合は、値を |
ingress.install.releaseNameOverride=base |
inress.install=trueの場合はオプションです | ingress.install で始まるあらゆるものは、イングレス・チャートの値を設定するために追加で指定できます。
|
イングレスを使用したインストールの詳細は、「NGINXイングレスを使用したOAAおよびOARMのインストール」を参照してください
3.4.8 管理コンテナ構成
この項では、installOAA.properties
で設定できる管理コンテナ構成プロパティについて詳しく説明します。
表3-10 管理構成
プロパティ | 必須/オプション | 説明 |
---|---|---|
install.mount.config.path |
必須 |
|
install.mount.config.server |
必須 | <NFS_CONFIG_PATH> のNFSサーバーのIPアドレス。
|
install.mount.creds.path |
必須 |
|
install.mount.creds.server |
必須 | <NFS_CREDS_PATH> のNFSサーバーのIPアドレス。
|
install.mount.logs.path |
必須 |
|
install.mount.logs.server |
必須 | <NFS_LOGS_PATH> のNFSサーバーのIPアドレス。
|
install.mgmt.release.name |
オプション | helm installコマンドの実行時に使用されるOAA管理コンテナ・インストールの名前。設定しない場合、インストール時に名前の入力を求めるプロンプトが表示されます。
指定する値は小文字にする必要があります。 |
install.kube.creds |
オプション | この値は、kubeconfig が存在するローカルPATHに設定します。設定しない場合、管理コンテナはKubernetes資格証明に$KUBECONFIG または~/.kube/config を使用します。
|
common.local.sslcert |
必須 | この値は、サーバー証明書PKCS12ファイル(cert.p12 )が存在するローカルPATHに設定します。
|
common.local.trustcert |
必須 | この値は、信頼証明書PKCS12ファイル(trust.p12 )が存在するローカルPATHに設定します。
|
NFSマウントの詳細は、「NFSボリュームの構成」を参照してください
PKCS12ファイルの詳細は、「サーバー証明書および信頼証明書の生成」を参照してください
3.5 管理コンテナの実行
installManagementContainer.sh
スクリプトを実行して、管理コンテナを作成します。
- インストール・ファイルをダウンロードしたノードで、
$WORKDIR/oaaimages/oaa-install
ディレクトリに移動します:cd $WORKDIR/oaaimages/oaa-install
- 引数を指定して
installManagementContainer.sh
スクリプトを実行します。たとえば:./installManagementContainer.sh -t ./<oaa-image>.tar
次の表に、installManagementContainer.sh
の引数の完全なリストを示します:コマンドライン引数 必須 説明 -t
いいえ OAAイメージtarファイルへのパス。 使用方法:- 指定しない場合、コンテナ・イメージ・レジストリに対するpull、tagおよびpushは実行されません。
- プル、タグおよびプッシュが必要な場合は、
-t ./oaa-latest.tar
のように、イメージ<oaa-image.tar>
へのパスを指定する必要があります。 - インストール・スクリプトは、このタスクを実行するためにまずpodmanの使用を試み、見つからない場合はDockerを使用します(使用可能な場合)。podmanもDockerも使用できない場合、スクリプトは終了します。
-c
いいえ OAA管理helmチャートへのパス。 指定しない場合、スクリプトはパスとして
./charts/oaa-mgmt
を使用します。-d
いいえ インストールのhelmテスト実行を実行します。 -f
いいえ installOAA.properties
へのパス。指定しない場合、
./installOAA.properties
が使用されます。-v
いいえ スクリプトを冗長モードで実行します。 -p
いいえ OAA管理コンテナの環境でhttp/httpsプロキシを設定します。 デフォルトでは、プロキシは設定されません。指定した場合、スクリプトはその環境を使用して、使用するプロキシ構成を見つけます。
-e
いいえ OAA管理コンテナの /etc/hosts
にエントリを追加します。デフォルトでは、エントリは追加されません。指定した場合、スクリプトは情報の入力を要求します。
-n
いいえ プロンプトを表示しません デフォルトでは、このスクリプトはOAA管理チャートをインストールするために必要な情報の入力を要求し、インストールの1つのステージから次のステージに進みます。
このオプションを設定した場合、スクリプトでは欠落している情報の入力を要求したり、ステージとステージの間にプロンプトを表示したりしません。必要な情報が欠落している場合は、エラーで終了します。
-u
いいえ インストールではなく更新を実行します。 デフォルトでは、このスクリプトは、以前にインストールされたhelmチャートを検索して、インストールを実行するかアップグレードを実行するかを決定します。
インストールの進行中、様々な質問に回答して特定のタスクを実行するように求められます。次の表に、回答を求められる質問または実行を求められるタスクの一部について概説します:
出力 アクション Use 'podman login' to login into your private registry if you have not done so previously.Login successful? [Y/N]:
ノート:
Dockerを使用している場合は、前述の出力にdocker login
と表示されます。イメージを格納するプライベート・コンテナ・イメージ・レジストリ(CIR)でログインが必要な場合は、 podman login
またはdocker login
を使用してCIRにログインし、プロンプトが表示されたら資格証明を入力します:
または:podman login <container-registry.example.com>
docker login <container-registry.example.com>
Would you like to specify a kube context (otherwise 'kubernetes-admin@kubernetes' will be used)? [Y/N]:
クラスタに複数のkubeコンテキストがある場合は、使用するコンテキストを選択できます。「 Y
」を選択した場合は、使用するコンテキストを入力する必要があります。選択されているデフォルト・コンテキストを使用する場合、またはkube構成にコンテキストが1つしかない場合は、「N
」を選択します。ノート:
インストール中に表示されるプロンプトのほとんどは字義どおりなので、前述の表にすべてのプロンプトの完全なリストは含まれていません。管理コンテナのインストールが完了すると、次のような出力が表示されます:NAME: oaamgmt LAST DEPLOYED: <DATE> STATUS: deployed REVISION: 1 TEST SUITE: None Waiting 15 secs for OAA mgmt deployment to start... Executing 'kubectl get pods oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv -n oaans'... NAME READY STATUS RESTARTS AGE oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv 0/1 ContainerCreating 0 15s Waiting 15 secs for OAA mgmt deployment to run... Executing 'kubectl get pods oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv -n oaans'... NAME READY STATUS RESTARTS AGE oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv 0/1 ContainerCreating 0 30s Waiting 15 secs for OAA mgmt deployment to run... Executing 'kubectl get pods oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv -n oaans'... NAME READY STATUS RESTARTS AGE oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv 0/1 ContainerCreating 0 46s Waiting 15 secs for OAA mgmt deployment to run... Copying OAA properties file to oaans/oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv:/u01/oracle/scripts/settings Generating kube config for OAA mgmt pod 'oaans/oaamgmt-oaa-mgmt'. Using service account 'oaans/oaamgmt-oaa-mgmt'. Using token name 'oaamgmt-oaa-mgmt-token-5m88n'. Using cluster URL 'https://<URL>'. Cluster "oaa-cluster" set. User "oaa-service-account" set. Context "kubernetes-admin@kubernetes" created. Switched to context "kubernetes-admin@kubernetes". Copying OAA kube config files to oaans/oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv:/u01/oracle/scripts/creds... Using helm config '/home/opc/.config/helm/repositories.yaml'. Copying helm config to oaans/oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv:/u01/oracle/scripts/creds/helmconfig Copying certificates to oaans/oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv:/u01/oracle/scripts/creds Use command 'kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv -- /bin/bash' to get a shell to the OAA mgmt pod. From pod shell, use command 'kubectl get pods' to verify communication with the cluster. Continue OAA installation from the OAA mgmt pod. OAA management installation complete.
- 出力に従ってOAA管理ポッドに接続します。次に例を示します:
これにより、OAA管理ポッド内のBashシェル内に移動します:kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv9 -- /bin/bash
[oracle@oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv /]$
次のステップ: OAAおよびOARMのデプロイ
3.6 OAAおよびOARMのデプロイ
OAA、OAA-OARMまたはOARMのデプロイ
- OAA管理ポッドのBashシェルに入ります(まだ入っていない場合):
たとえば:kubectl exec -n <namespace> -ti <oaamgmt-pod> -- /bin/bash
kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv9 -- /bin/bash
- OAA管理ポッドのBashシェル内で、
OAA.sh
スクリプトを実行して、OAA、OAA-OARMまたはOARMをデプロイします:cd ~ ./OAA.sh -f installOAA.properties
ノート:
これにより、<NFS_CONFIG_PATH>
のinstallOAA.properties
が使用されます。
次のステップ: インストールが成功すると、「デプロイメントの詳細の出力」のような出力が表示されます。
3.7 デプロイメントの詳細の出力
ノート:
OAA/OARMに付属のイングレス・コントローラをインストールする場合、ホストおよびポートはコントローラがインストールされるワーカー・ノードに設定されます。独自のイングレス・コントローラを使用している場合、基本設定であると想定すると、ホストおよびポートはinstallOAA.properties
のプロパティinstall.global.serviceurl
の値に設定されます。
イングレスが無効になっている場合は、ワーカー・ノードのホストおよびNodePortが出力されます。
############################OAA Deployment Details: START################################### OAAService=https://oaainstall-host/oaa/runtime AdminUrl=https://oaainstall-host/oaa-admin PolicyUrl=https://oaainstall-host/oaa-policy SpuiUrl=https://oaainstall-host/oaa/rui Email=https://oaainstall-host/oaa-email-factor Push=https://oaainstall-host/oaa-push-factor Fido=https://oaainstall-host/fido SMS=https://oaainstall-host/oaa-sms-factor TOTP=https://oaainstall-host/oaa-totp-factor YOTP=https://oaainstall-host/oaa-yotp-factor KBA=https://oaainstall-host/oaa-kba RELEASENAME=oaainstall # Key below is Base64 encoded API key oaaapikey=YXBpa2V5dG9iZXNldGR1cmluZ2luc3RhbGxhdGlvbgo= # Key below is Base64 encoded Policy API key oaapolicyapikey=cG9sYXBpa2V5dG9iZXNldGR1cmluZ2luc3RhbGxhdGlvbgo= # Key below is Base64 encoded Factor API key oaafactorapikey=ZmFjdG9yYXBpa2V5dG9iZXNldGR1cmluZ2luc3RhbGxhdGlvbgo= ############################Deployment Details: END###################################
############################Risk Deployment Details: START###################################
AdminUrl=https://oaainstall-host/oaa-admin
PolicyUrl=https://oaainstall-host/oaa-policy
RISK=https://oaainstall-host/risk-analyzer
RISKCC=https://oaainstall-host/risk-cc
RELEASENAME=riskinstall
# Key below is Base64 encoded Policy API key
oaapolicyapikey=cG9sYXBpa2V5dG9iZXNldGR1cmluZ2luc3RhbGxhdGlvbgo=
# Key below is Base64 encoded Factor API key
riskfactorapikey=cmlza2ZhY3RvcmFwaWtleXRvYmVzZXRkdXJpbmdpbnN0YWxsYXRpb24K
############################Deployment Details: END###################################
- OAA管理ポッドのBashシェルに入ります(まだ入っていない場合):
たとえば:kubectl exec -n <namespace> -ti <oaamgmt-pod> -- /bin/bash
kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7d7597c694-vn4ds -- /bin/bash
printOAADetails.sh
を実行して、デプロイメントの詳細を出力します:cd ~/scripts ./printOAADetails.sh -f settings/installOAA.properties
ノート:
これにより、<NFS_CONFIG_PATH>
のinstallOAA.properties
が使用されます。
出力されたデプロイメントの情報に基づいて、コンソールには次のようにアクセスできます:
コンソール | 詳細出力参照* | URL | ユーザー名 | パスワード |
---|---|---|---|---|
OAA/OARM管理 | AdminUrl |
https://<hostname.domain>:<port>/oaa-admin |
oaadmin |
OAM OAuthアイデンティティ・ストアに設定されている<password> 。
|
OAAユーザー・プリファレンス | SpuiUrl |
https://<hostname.domain>:<port>/oaa/rui |
OAM OAuthアイデンティティ・ストアからのユーザー名。 | OAM OAuthアイデンティティ・ストアに設定されている<password> 。
|
*このドキュメント全体を通して、「詳細出力参照」列の値は使用するURLを示すために使用されます。たとえば、「ブラウザを起動して<AdminURL>
にアクセスする」は、示された対応するURL https://<hostname.domain>:<port>/oaa-admin
にアクセスすることを示します。
出力されたデプロイメントの情報に基づいて、REST APIエンドポイント情報は次のようになります:
REST API | 詳細出力参照** | URL | ユーザー名** | パスワード** |
---|---|---|---|---|
OAA/OARM管理 | PolicyUrl |
https://<hostname.domain>:<port>/oaa-policy |
<RELEASENAME>-oaa-policy |
<Base64Decoded(oaapolicyapikey)> |
OAAランタイム | OAAService |
https://<hostname.domain>:<port>/oaa/runtime |
<RELEASENAME>-oaa |
<Base64Decoded(oaaapikey)> |
リスク | RISK |
https://<hostname.domain>:<port>/risk-analyzer |
<RELEASENAME>-risk |
<Base64Decoded(riskfactorapikey)> |
リスク・カスタマ・ケア | RISKCC |
https://<hostname.domain>:<port>/risk-cc |
<RELEASENAME>-risk-cc |
<Base64Decoded(riskfactorapikey)> |
KBA | KBA |
https://<hostname.domain>:<port>/oaa-kba |
<RELEASENAME>_OAA_KBA |
<Base64Decoded{ oaafactorsapikey}> |
**このドキュメント全体を通して、REST APIの例が示されている場合、「詳細出力参照」列の値は使用するURLを示すために使用され、「ユーザー名」列と「パスワード」列の値は使用するユーザー名とパスワードを表します。
curl --location -g --request POST '<OAAService>/preferences/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <Base64Encoded(<username>:<password>)>'
etc...
<OAAService>
は、対応するURL https://<hostname.domain>:<port>/oaa/runtime
にアクセスすることを示し、<username>は<RELEASENAME>-oaa
を示し、<password>は<Base64Decoded(oaaapikey)>
を示します。
3.8 インストール後のステップ
3.8.1 すべてのインストールのインストール後のステップ
すべてのインストール・タイプ(OAAのみ、OAA-OARMおよびOARMのみ)について、インストール後のステップに従います。
次のステップを実行して、ポリシー・スナップショットをインポートします:
- ドキュメントID 2723908.1を参照して、My Oracle Supportから最新のスナップショット・ポリシー・ファイルを取得します。
ノート:
最新のスナップショット・ファイルを入手できない場合は、管理コンテナ内の/u01/oracle/scripts/oarm-12.2.1.4.1-base-snapshot.zip
ファイルを使用します。 - 最新のスナップショット・ファイルを
<NFS_CONFIG_PATH>
にコピーします。 <NFS_CONFIG_PATH>/installOAA.properties
を編集し、次のパラメータをCommon Deployment構成の一番下に追加します:common.deployment.import.snapshot=true common.deployment.import.snapshot.file=/u01/oracle/scripts/settings/<latest_snapshot>.zip
ノート:
最新のスナップショット・ファイル・セットを使用していない場合:common.deployment.import.snapshot.file=/u01/oracle/scripts/settings/oarm-12.2.1.4.1-base-snapshot.zip
- OAA管理ポッドのBashシェルに入ります(まだ入っていない場合):
たとえば:kubectl exec -n <namespace> -ti <oaamgmt-pod> -- /bin/bash
kubectl exec -n oaans -ti oaamgmt-oaa-mgmt-7dfccb7cb7-lj6sv9 -- /bin/bash
- Bashシェル内で次のコマンドを実行して、ポリシー・スナップショットをインポートします:
cd ~/scripts ./importPolicySnapshot.sh -f settings/installOAA.properties
ノート:
これにより、<NFS_CONFIG_PATH>
のinstallOAA.properties
が使用されます。スナップショットがインポートされ、成功すると、メッセージ
Successfully applied snapshot: 10001
(または類似のメッセージ)が表示されます。Bashシェルを終了します。
<NFS_CONFIG_PATH>/installOAA.properties
を編集し、Common Deployment構成の一番下にある次のパラメータを変更します:common.deployment.import.snapshot=false
ノート:
これは、将来のアップグレード中にポリシーが上書きおよび消去されないようにするための重要なステップです。
3.8.2 OAA-OARMおよびOARMインストールのインストール後のステップ
これらのインストール後のステップは、OAA-OARMおよびOARMのみのインストールで実行してください。
oaa.browser.cookie.domainおよびoaa.risk.integration.postauth.cpの設定
ノート:
以降のステップは、OAA-OARMのインストールにのみ適用されます。デバイスCookieを収集するには、プロパティoaa.browser.cookie.domain
をOAAホスト・ドメインに設定する必要があります。たとえば、https://oaa.example.com
でOAAにアクセスできる場合は、値をoaa.example.com
に設定します。
リスクのあるIP、地理的速度、地理的位置などのユースケースに対するリスク・ルールを呼び出すには、プロパティoaa.risk.integration.postauth.cp
をpostauth
に設定する必要があります。
- 次のようにプロパティを設定します:
<PolicyUrl>/policy/config/property/v1
REST APIを使用してプロパティを設定します。たとえば:curl --location -g --request PUT '<PolicyUrl>/policy/config/property/v1' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic <Base64Encoded(<username>:<password>)>' \ --data '[ { "name": "oaa.browser.cookie.domain", "value": "<host.domain>" }, { "name": "oaa.risk.integration.postauth.cp", "value": "postauth" } ]'
ノート:
この場合は、<PolicyUrl>
から/oaa-policy
を削除します。たとえば、https://<host>:<port>/oaa-policy/policy/config/property/v1
ではなくhttps://<host>:<port>/policy/config/property/v1
を使用しますPolicyUrl
の検索および認証の詳細は、「OAA管理API」を参照してください。構成プロパティRESTエンドポイントの詳細は、「構成プロパティRESTエンドポイント」を参照してください。
3.8.3 NodePort用のインストール後のステップ
どのインストール・タイプでも、イングレスではなくnodeportを使用している場合は、関連するリダイレクトURLでOAuthクライアントを更新する必要があります。次のステップを実行します。
- 「デプロイメントの詳細の出力」の説明に従って、
spui
、oaa-admin-ui
およびfido
ポッドのURLを検索します。次に例を示します:AdminUrl=https://worker1.example.com:32701/oaa-admin SpuiUrl=https://worker1.example.com:32721/oaa/rui Fido=https://worker1.example.com:30414/fido
ノート:
OARMのみのインストールの場合、検索する必要があるのはoaa-admin-ui
ポッドのURLのみです。 - コマンドを使用して、OAM管理者ユーザーとそのパスワードをエンコードします:
たとえば:echo -n <username>:<password> | base64
この値は、次の例のecho -n weblogic:<password> | base64
<ENCODED_OAMADMIN>
に使用する必要があります。 - OAAおよびOAA-OARMインストールの場合は、次のようにREST APIを使用してOAuthクライアントを更新します:
curl --location --request PUT 'http://<OAuth_Host>:<OAuth_Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client?name=OAAClient' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic <ENCODED_OAMADMIN>' \ --data '{ "id": "OAAClient", "clientType": "PUBLIC_CLIENT", "idDomain": "OAADomain", "name": "OAAClient", "redirectURIs": [ { "url": "https://worker1.example.com:32701/oaa/rui", "isHttps": true }, { "url": "https://worker1.example.com:32701/oaa/rui/oidc/redirect", "isHttps": true }, { "url": "https://worker1.example.com:32721/oaa-admin", "isHttps": true }, { "url": "https://worker1.example.com:32721/oaa-admin/oidc/redirect", "isHttps": true }, { "url": "https://worker1.example.com:30414/fido", "isHttps": true }, { "url": "https://worker1.example.com:30414/fido/oidc/redirect", "isHttps": true } ] }'
ノート: REST APIの詳細は、『Oracle Access ManagerでのOauth REST API』を参照してください
OARMのみのインストールの場合は、次のようにしてOAuthクライアントを更新します:curl --location --request PUT 'http://<OAuth_Host>:<OAuth_Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client?name=OAAClient' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic <ENCODED_OAMADMIN>' \ --data '{ "id": "OAAClient", "clientType": "PUBLIC_CLIENT", "idDomain": "OAADomain", "name": "OAAClient", "redirectURIs": [ { "url": "https://worker1.example.com:32721/oaa-admin", "isHttps": true }, { "url": "https://worker1.example.com:32721/oaa-admin/oidc/redirect", "isHttps": true } ] }'
3.9 OAAおよびOARMのインストールのトラブルシューティング
この項では、OAAおよびOARMのインストールに関するトラブルシューティングのヒントを示します。
OAA管理コンテナのインストール中のPodmanの問題
- イメージまたはファイル形式のエラーのために、Podmanがtarファイル内のOAAイメージをロードできません。たとえば:
原因として、インストール・ホストのルート・パーティションの空き領域が不足している(Podmanは一時ファイルをStoring signatures Getting image source signatures Copying blob 01092b6ac97d skipped: already exists Copying blob dba9a6800748 skipped: already exists Copying blob bae273a35c58 skipped: already exists Copying blob 7f4b55b885b0 skipped: already exists Copying blob 93e8a0807a49 skipped: already exists Copying blob fa5885774604 skipped: already exists Copying blob 3b8528487f10 skipped: already exists Copying blob 3a1c2e3e35f4 [==========================>-----------] 213.8MiB / 298.1MiB Copying blob 6d31843e131e [=================================>----] 210.5MiB / 236.5MiB Copying blob f35b9630ef38 [===========>--------------------------] 213.8MiB / 672.2MiB Copying blob ef894c2768e3 done Copying blob 846fd069f886 [==========>---------------------------] 197.7MiB / 672.2MiB Copying blob 257c48b76c82 done Error: payload does not match any of the supported image formats (oci, oci-archive, dir, docker-archive)
/var/tmp
に格納する)か、Podmanバージョンが3.3.0以降でないことが考えられます。このエラーが発生した場合は、問題に対処した後で、/var/tmp
下のすべてのファイルを削除してから、インストールを再試行してください。 - 権限の問題のために、Podmanがtarファイル内のOAAイメージをロードできません。たとえば:
Using image release files ./releaseimages.txt and ./nonreleaseimages.txt... tee: ./oaainstall-tmp/run.log: Permission denied Using install settings from ./installOAA.properties. tee: ./oaainstall-tmp/run.log: Permission denied Checking kubectl client version... WARNING: version difference between client (1.23) and server (1.21) exceeds the supported minor version skew of +/-1 tee: ./oaainstall-tmp/run.log: Permission denied kubectl version required major:1 minor:18, version detected major:1 minor:23 tee: ./oaainstall-tmp/run.log: Permission denied
原因として、あるユーザーとしてzipファイルを抽出したが、権限のない別のユーザーとして
installManagementContainer.sh
を実行したことが考えられます。この場合は、$WORKDIR/oaaimages/oaa-install/oaainstall-tmp
ディレクトリを削除して、zipファイルを抽出したユーザーと同じユーザーでインストールを再試行してください。 - Podmanは、前回のインストール試行でOAAイメージのロードに失敗した後、必要なすべてのイメージのプル/タグ/プッシュを実行しません。この場合は、
$WORKDIR/oaaimages/oaa-install/oaainstall-tmp
ディレクトリを削除して再試行してください。
OAA管理チャートのインストールの失敗
Executing 'helm install ... oaamgmt charts/oaa-mgmt'.
Continue? [Y/N]:
y
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(Deployment.spec.template.spec.containers[0]): unknown field "volumMounts" in io.k8s.api.core.v1.Container
OAA管理チャートのマニフェスト・ファイルが破損した可能性があります。installOAA.properties
、cert.p12
およびtrust.p12
を安全な場所にコピーし、インストール・ディレクトリ$WORKDIR/oaaimages/oaa-install
を削除してから、<OAA_Image>.zip
を抽出してインストールを再開します。
インストール・スクリプトがOAA管理コンテナ・ポッドの起動を待ってタイムアウトしました
NAME READY STATUS RESTARTS AGE
oaamgmt-oaa-mgmt-74c9ff789d-wq82h 0/1 ContainerCreating 0 2m3s
Waiting 15 secs for OAA mgmt deployment to run...
Executing 'kubectl get pods oaamgmt-oaa-mgmt-74c9ff789d-wq82h -n oaans'...
NAME READY STATUS RESTARTS AGE
oaamgmt-oaa-mgmt-74c9ff789d-wq82h 0/1 ContainerCreating 0 2m18s
Waiting 15 secs for OAA mgmt deployment to run...
...
OAA mgmt pod is not running after 450 secs, cannot proceed with install.
Critical error, exiting. Check ./oaainstall-tmp/run.log for additional information.
この場合は、次のコマンドを実行して追加情報を取得してください:$ kubectl get pods -n oaans
$ kubectl describe pod oaamgmt-<pod> -n oaans
- NFSのエラーの場合は、
installOAA.properties
のNFSボリューム情報が正しいことを確認します。この場合は、kubectl describe
で次のように表示されます:Output: mount.nfs: mounting <ipaddress>:/scratch/oaa/scripts-creds failed, reason given by server: No such file or directory Warning FailedMount 15s kubelet, <ipaddress> Unable to attach or mount volumes: unmounted volumes=[oaamgmt-oaa-mgmt-configpv oaamgmt-oaa-mgmt-credpv oaamgmt-oaa-mgmt-logpv], unattached volumes=[oaamgmt-oaa-mgmt-configpv oaamgmt-oaa-mgmt-credpv oaamgmt-oaa-mgmt-logpv oaamgmt-oaa-mgmt-vaultpv default-token-rsh62]: timed out waiting for the condition
- イメージ・プル・エラーの場合は、イメージ・プル・シークレット(
dockersecret
)が正しく作成され、installOAA.properties
のプロパティinstall.global.repo
、install.global.image.tagおよびinstall.global.imagePullSecrets\[0\].name
が正しいことを確認します。この場合は、kubectl describe pod
で次のように表示されます:Warning Failed 21s (x3 over 61s) kubelet, <ipaddress> Error: ErrImagePull Normal BackOff 7s (x3 over 60s) kubelet, <ipaddress> Back-off pulling image "container-registry.example.com/oracle/shared/oaa-mgmt:<tag>" Warning Failed 7s (x3 over 60s) kubelet, <ipaddress> Error: ImagePullBackOff
- 明らかなエラーがなくタイムアウトする場合、クラスタでOAA管理イメージのダウンロードに時間がかかりすぎている可能性があります。この場合、管理ポッドは最終的に起動されますが、インストールは中止されます。これが発生した場合は、
helm delete oaamgmt -n oaans
を使用してOAA管理helmリリースを削除し、インストール・スクリプトを再実行します。
OAA.shの実行中の一般的な失敗
OAA.sh
デプロイメントが失敗した場合、通常は問題を修正してOAA.sh
を再実行できます。インストールでは、データベース、OAuthおよびボールトに対して多数のチェックが実行されます。データベース・スキーマ、OAuth構成またはボールトがすでに存在するために、これらのチェックでOAA.sh
の再実行に失敗する場合は、installOAA.properties
で次のプロパティを設定してから、OAA.sh
を再試行してください:
- データベース・スキーマがすでに存在する場合:
database.createschema=false
- OAuth構成がすでに存在する場合:
oauth.createdomain=false
oauth.createresource=false
oauth.createclient=false
- ボールト構成が存在する場合:
vault.create.deploy=false
OAA.shの実行中にOAuthの作成に失敗する
インストール時に、OAuthドメイン、クライアントおよびリソース・サーバーが作成されます。失敗した場合は、OAuthのパラメータが正しいかどうかを確認します「OAM OAuthのインストールおよび構成」を参照してください
OAA.shの実行中にOAuthの作成に失敗する
これは、httpd.conf
およびmod_wl_ohs.conf
ファイルが更新されない場合に発生します。値を更新するには、「OAM OAuthのインストールおよび構成」を参照してください
コンテナ作成中ステータスのポッドが原因でOAA.shのインストールに失敗する
kubectl logs oaainstall-email-6fd7c9b9dd-lr5lm
describe pod
コマンドを実行します。たとえば:kubectl describe pod oaainstall-email-6fd7c9b9dd-lr5lm
OAA.shの実行中にポッドの起動に失敗し、CrashLoopBackOffが表示される
エラーが表示されたポッドに対してkubectl logs <pod>
コマンドを実行します。エラーの原因の1つとして、次のことが考えられます:
そのエントリのmod_wl_ohs.conf
のPathTrim
およびPathPrepend
が更新されなかったため、ポッドはhttp://www.example.oracle.com:7791/.well-known/openid-configuration
に接続できませんでした。「OAM OAuthのインストールおよび構成」を参照してください
OAA.shのインストールがタイムアウトしたのにポッドが実行中と表示される
OAAインストールがタイムアウトしたのに、OAAポッドにエラーが表示されず、最終的に実行中状態になった場合、クラスタでOAAイメージのダウンロードに時間がかかりすぎていた可能性があります。この場合、OAAポッドは最終的に起動されますが、インストールは完了しません。これが発生した場合は、インストールをクリーン・アップし、インストール・スクリプトを再実行します。
kubectlで"Unable to connect to the server: net/http: TLS handshake timeout"と報告される
- プロキシは環境で定義されていますが、
no_proxy
環境変数にクラスタ・ノードが含まれていません。この問題を解決するには、クラスタ・ノードのIPまたはホスト名をno_proxy
環境変数に追加する必要があります。 - kube構成ファイル
~/.kube/config
または/etc/kubernetes/admin.conf
が無効です。
クリーンアップ中にOAuthからOAAドメインを削除できない
- コマンドを使用して、OAM管理者ユーザーとそのパスワードをエンコードします:
たとえば:echo -n <username>:<password> | base64
この値は、次の例のecho -n weblogic:<password> | base64
<ENCODED_OAMADMIN>
に使用する必要があります。 - 次を実行します:
$ curl --location --request DELETE 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain?name=OAADomain' \ --header 'Authorization: Basic <ENCODED_OAMADMIN>' OAuth Identity Domain is not empty. Kindly remove (resource/client) entities from identity domain $ curl --location --request GET 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client?identityDomainName=OAADomain' --header 'Content-Type: application/json' --header 'Authorization: Basic <ENCODED_OAMADMIN>' $ curl --location --request GET 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/application?identityDomainName=OAADomain' --header 'Content-Type: application/json' --header 'Authorization: Basic <ENCODED_OAMADMIN>'
3.10 インストールのクリーン・アップ
OAAまたはOAA-OARMインストールを完全にクリーン・アップするには、次のステップを実行します。
- インストール・ホストから管理コンテナに接続し、ファイル・ベースのボールトおよびログをそれぞれのNFSマウントから削除します:
kubectl exec -n <namespace> -ti oaamgmt-oaa-mgmt-7d7597c694-tzzdz -- /bin/bash $ rm -rf /u01/oracle/logs/* $ rm -rf /u01/oracle/service/store/oaa/.* $ exit
- 次を実行して、インストールされているhelmチャートを検索します:
たとえば:helm ls -n <namespace>
出力は次のようになります:helm ls -n oaans
OAAチャートを削除します:NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION oaainstall oaans 1 <date> deployed oaa-1.0.0-<tag> 0.1.0 oaamgmt oaans 1 <date> deployed oaa-mgmt-1.0.0-<tag> 0.1.0
helm delete oaainstall -n oaans helm delete oaamgmt -n oaans
coherence-operator
を削除するには、次のステップを実行します:helm delete coherence-operator -n coherence
kubectl get sts
kubectl get coherence.coherence.oracle.com
kubectl delete mutatingwebhookconfigurations coherence-operator-mutating-webhook-configuration
- コンテナの外部で、次を実行します:
kubectl get pods -n oaans
kubectl get pods -n coherence
ポッドが残っている場合は、次を実行します:kubectl delete <pod_name> -n <namespace>
- OAuthクライアントおよびリソースを削除します:
- コマンドを使用して、OAM管理者ユーザーとそのパスワードをエンコードします:
たとえば:echo -n <username>:<password> | base64
この値は、次の例のecho -n weblogic:<password> | base64
<ENCODED_OAMADMIN>
に使用する必要があります。 - OAuthクライアントを更新します。たとえば:
curl --location --request DELETE 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/client?name=OAAClient&identityDomainName=OAADomain' \ --header 'Authorization: Basic <ENCODED_OAMADMIN>'
- OAuthリソース・サーバーを削除します。たとえば:
curl --location --request DELETE 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/application?name=OAAResource&identityDomainName=OAADomain' \ --header 'Authorization: Basic <ENCODED_OAMADMIN>'
- OAuthドメインを削除します。たとえば:
curl --location --request DELETE 'http://<OAuth_Host>:<OAuth_port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain?name=OAADomain' \ --header 'Authorization: Basic <ENCODED_OAMADMIN>'
- コマンドを使用して、OAM管理者ユーザーとそのパスワードをエンコードします:
- 次のようにデータベース・スキーマを削除します:
sqlplus sys/<password> as SYSDBA alter session set "_oracle_script"=TRUE; ** Required for PDB’s only ** drop user <OAA_RCU_PREFIX>_OAA cascade; delete from SCHEMA_VERSION_REGISTRY where comp_name='Oracle Advanced Authentication' and OWNER=UPPER('<OAA_RCU_PREFIX>_OAA'); commit; set pages 0 set feedback off spool /tmp/drop_directories.sql select 'drop directory '||directory_name||';' from all_directories where directory_name like 'EXPORT%' / spool off @/tmp/drop_directories
- OAAイメージのプル/タグ/プッシュを繰り返すためには、ディレクトリ
$WORKDIR/oaaimages/OAA-install/oaainstall-tmp
を削除してから、installManagementContainer.sh
スクリプトを再実行します。