概要

このガイドでは、KubernetesでOracle WebCenter Portalインスタンスをプロビジョニングおよび管理する方法について説明します。

はじめに

このガイドでは、Kubernetes環境内でOracle WebCenter Portalインスタンスをプロビジョニングおよび管理するプロセスの概要を示します。これは、Kubernetesでこれらのインスタンスを効果的に作成および管理しようとするユーザーのリソースとして機能します。

対象読者

このガイドは、KubernetesでOracle WebCenter Portalインスタンスを作成および管理するユーザーを対象としています。

Oracle WebCenter Portal on Kubernetes

WebLogic Kubernetes Operatorは、Kubernetes上でのWebLogic ServerおよびFusion Middleware Infrastructureドメインの実行をサポートして、Kubernetes環境でのOracle WebCenter Portalのデプロイメントを容易にします。

このリリースでは、Oracle WebCenter Portalドメインは、ドメイン・ホームが永続ボリュームに格納される「永続ボリューム上のドメイン」モデルのみを中心に構成されます。

このリリースには、ポートレット管理対象サーバーのサポートが含まれており、Oracle WebCenter Portal環境内でのポートレット・アプリケーションのデプロイメントおよび管理が可能です。

オペレータは、KubernetesでのOracle WebCenter Portalドメインのデプロイおよび管理に役立ついくつかの主要な機能を提供します。これらの機能では次が可能です:

現在のリリース

KubernetesでのOracle WebCenter Portalドメイン・デプロイメントの現在のリリースは、24.4.3です。このリリースでは、WebLogic Kubernetes Operatorバージョン4.2.9を使用します。

最近の変更および既知の問題

KubernetesでのOracle WebCenter Portalドメイン・デプロイメントの最近の変更および既知の問題については、リリース・ノートを参照してください。

このドキュメントについて

このドキュメントには、様々な読者を対象とした項が含まれています。より簡単に探している内容を見つけるには、この目次を使用してください:

リリース・ノート

最近の変更

Oracle WebCenter Portal on Kubernetesのリリース・ノートを確認します。

日付 バージョン 変更
2024年12月 14.1.2.0.0
GitHubリリース・バージョン24.4.3		 Oracle WebCenter Portal on Kubernetes 14.1.2.0.0の最初のリリース。

インストール・ガイド

WebLogic Kubernetes Operatorをインストールし、Oracle WebCenter Portalドメインを準備してデプロイします。

要件および制限事項

WebLogic Kubernetes Operatorを使用してOracle WebCenter Portalをデプロイおよび実行するためのシステム要件および制限事項を理解します。

概要

このドキュメントでは、WebLogic Kubernetes Operatorを使用してWebCenter Portalドメインをデプロイおよび実行する際の具体的な考慮事項について説明します。ここで説明する考慮事項の他に、WebCenter PortalドメインはFusion Middleware InfrastructureおよびWebLogic Serverドメインと同様に動作します。

このリリースでは、WebCenter Portalドメインは、ドメインが永続ボリューム(PV)に存在する「永続ボリューム上のドメイン」モデルに基づいています。

システム要件

リリース24.4.3には、次のシステム要件があります:

プロキシ設定: 次のプロキシ構成を使用して、必要なバイナリおよびソース・コードをそれぞれのリポジトリからプルします:

export NO_PROXY="localhost,127.0.0.0/8,$(hostname -i),.your-company.com,/var/run/docker.sock"
export no_proxy="localhost,127.0.0.0/8,$(hostname -i),.your-company.com,/var/run/docker.sock"
export http_proxy=http://www-proxy-your-company.com:80
export https_proxy=http://www-proxy-your-company.com:80
export HTTP_PROXY=http://www-proxy-your-company.com:80
export HTTPS_PROXY=http://www-proxy-your-company.com:80

制限事項

オペレータを使用したKubernetesでのWebLogic Serverドメインの実行と比較して、現在、WebCenter Portalドメインには次の制限があります:

環境の準備

Oracle WebCenter Portalドメインの作成を準備します。この準備には、必要なシークレット、永続ボリューム、ボリューム要求およびデータベース・スキーマの作成が含まれますが、これらに限定されません。

KubernetesクラスタおよびWebLogic Kubernetes Operatorの確立など、環境を設定します。

  1. Kubernetesクラスタの設定

  2. Helmのインストール

  3. 他の依存イメージのプル

  4. Oracle WebCenter Portal Dockerイメージの取得

  5. Oracle WebCenter Portalドメインをデプロイするためのコード・リポジトリの設定

  6. ロールの付与および失効したリソースの消去

  7. WebLogic Kubernetes Operatorのインストール

  8. WebCenter Portalドメインの環境の準備

    1. Oracle WebCenter Portalドメインのネームスペースの作成

    2. ドメイン資格証明を使用したKubernetesシークレットの作成

    3. RCU資格証明を使用したKubernetesシークレットの作成

    4. Oracle WebCenter Portalドメインの永続ストレージの作成

    5. データベースへのアクセスの構成

    6. リポジトリ作成ユーティリティの実行によるデータベース・スキーマの設定

Kubernetesクラスタの設定

公式のKubernetesの設定ドキュメントを参照して、本番グレードのKubernetesクラスタを確立します。

Kubernetesクラスタの作成後、オプションで次のことができます:

Helmのインストール

オペレータは、Helmを使用して必要なリソースを作成およびデプロイし、Kubernetesクラスタでオペレータを実行します。Helmのインストールおよび使用方法の詳細は、ここを参照してください。

他の依存イメージのプル

依存イメージには、WebLogic Kubernetes Operator、データベースおよびTraefikが含まれます。これらのイメージをプルして、ローカル・レジストリに追加します:

  1. これらのdockerイメージをプルして、次に示すように再度タグ付けします:

    Oracle Container Registryからイメージをプルするには、Webブラウザでhttps://container-registry.oracle.comに移動し、Oracle Single Sign-On認証サービスを使用してログインします。SSO資格証明がまだない場合は、ページの上部にある「Sign In」リンクをクリックして作成します。

    Webインタフェースを使用して、デプロイするOracleソフトウェア・イメージのオラクル社標準の条件および規制に同意します。これらの条件の同意は、ソフトウェア・イメージをOracle Single Sign-Onログイン資格証明にリンクするデータベースに格納されます。

    次に、これらのdockerイメージをプルします:

    #This step is required once at every node to get access to the Oracle Container Registry.

docker login https://container-registry.oracle.com (enter your Oracle email Id and password)

    WebLogic Kubernetes Operatorイメージ:

    docker pull ghcr.io/oracle/weblogic-kubernetes-operator:4.2.9

  2. ビルドおよびプルされたすべてのイメージをクラスタ内のすべてのノードにコピーするか、クラスタがアクセスできるDockerレジストリに追加します。

    ノート: 開発マシンでKubernetesを実行していない場合は、Kubernetesクラスタから認識できるレジストリでDockerイメージを使用できるようにする必要があります。

    次のように、DockerおよびKubernetesを実行しているマシンにイメージをアップロードします:

    # on your build machine
docker save Image_Name:Tag > Image_Name-Tag.tar
scp Image_Name-Tag.tar YOUR_USER@YOUR_SERVER:/some/path/Image_Name-Tag.tar

# on the Kubernetes server
docker load < /some/path/Image_Name-Tag.tar

Oracle WebCenter Portal Dockerイメージの取得

Oracle Container Registry (OCR)からのOracle WebCenter Portalイメージの取得

初回のユーザーの場合、次のステップに従ってOracle Container Registryからイメージをプルします:

  1. Oracle Container Registryに移動し、Oracle Single Sign-On (SSO)認証サービスを使用してログインします。

    ノート: SSO資格証明がまだない場合は、ここでOracleアカウントを作成できます。

  2. Webインタフェースを使用して、デプロイするOracleソフトウェア・イメージのオラクル社標準の条件および規制に同意します。

    ノート: これらの条件の同意は、Oracle Single Sign-On資格証明にリンクされたデータベースに格納されます。

  3. 次のコマンドを使用して、Oracle Container Registryにログインします:

   docker login container-registry.oracle.com
  1. 次のコマンドを実行して、事前ビルドされたOracle WebCenter Portalイメージを検索してプルします:
docker pull container-registry.oracle.com/middleware/webcenter-portal_cpu:14.1.2.0-<TAG>
Oracle WebCenter Portalコンテナ・イメージのビルド

別の方法として、追加バンドルまたは個別パッチを含め、WebLogic Image ToolでOracle WebCenter Portalコンテナ・イメージをビルドして使用する場合は、これらのステップに従ってイメージを作成します。

ノート:

Oracle WebCenter Portalドメインをデプロイするためのコード・リポジトリの設定

KubernetesでのOracle WebCenter Portalドメイン・デプロイメントでは、WebLogic Kubernetes Operatorインフラストラクチャを利用します。Oracle WebCenter Portalドメインをデプロイするには、次のようにデプロイメント・スクリプトを設定する必要があります:

  1. ソース・コードを設定する作業ディレクトリを作成します。

    mkdir $HOME/wcp_14.1.2.0
cd $HOME/wcp_14.1.2.0

  2. GithubリポジトリからOracle WebCenter Portal Kubernetesデプロイメント・スクリプトをダウンロードします。必要なアーティファクトは、FMW-DockerImages/OracleWeCenterPortal/kubernetesにあります。

    git clone https://github.com/oracle/fmw-kubernetes.git
export WORKDIR=$HOME/wcp_14.1.2.0/fmw-kubernetes/OracleWebCenterPortal/kubernetes/

このドキュメントで後述するように、<$WORKDIR>のデプロイメント・スクリプトを使用してWebCenter Portalドメインを設定できるようになりました。

ロールの付与および失効したリソースの消去

  1. WebLogicカスタム・リソース定義がすでに存在するかどうかを確認するには、次のコマンドを実行します:

    kubectl get crd

    サンプル出力:

    NAME                      CREATED AT
domains.weblogic.oracle   2020-03-14T12:10:21Z

  2. 次のコマンドを実行して、WebLogicカスタム・リソース定義(見つかった場合)を削除します:

    kubectl delete crd domains.weblogic.oracle

    サンプル出力:

    customresourcedefinition.apiextensions.k8s.io "domains.weblogic.oracle" deleted

WebLogic Kubernetes Operatorのインストール

WebLogic Kubernetes Operatorは、Kubernetes環境でのOracle WebCenter Portalドメインのデプロイメントをサポートします。

このドキュメントのステップに従って、オペレータをインストールします。

オプションで、これらのステップに従って、オペレータのログの内容をElasticsearchに送信できます。

WebLogic Kubernetes Operatorをインストールする次のコマンド例では、opnsはネームスペースで、op-saはオペレータ用に作成されたサービス・アカウントです:

kubectl create namespace operator-ns
kubectl create serviceaccount -n operator-ns operator-sa
helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update 
helm install weblogic-kubernetes-operator weblogic-operator/weblogic-operator  --version 4.2.9 --namespace operator-ns --set serviceAccount=operator-sa --set "javaLoggingLevel=FINE" --wait

ノート: この手順では、ネームスペースはoperator-nsと呼ばれていますが、任意の名前を使用できます。

次の値を使用できます:
- ドメインUID/ドメイン名: wcp-domain
- ドメイン・ネームスペース: wcpns
- オペレータ・ネームスペース: operator-ns
- Traefikネームスペース: traefik

WebCenter Portalドメインの環境の準備

Oracle WebCenter Portalドメインのネームスペースの作成

デフォルト・ネームスペースを使用する場合を除き、ドメインのKubernetesネームスペース(wcpnsなど)を作成します。詳細は、ドメイン実行の準備を参照してください。

kubectl create namespace wcpns

サンプル出力:

namespace/wcpns created

このネームスペースのドメインを管理するには、helmを使用してオペレータを構成します:

Helmはweblogic-operatorをアップグレードします

 helm upgrade --reuse-values --set "domainNamespaces={wcpns}" \
 --wait weblogic-kubernetes-operator charts/weblogic-operator --namespace operator-ns

サンプル出力:

 NAME: weblogic-kubernetes-operator
 LAST DEPLOYED: Wed Jan  6 01:52:58 2021
 NAMESPACE: operator-ns
 STATUS: deployed
 REVISION: 2
ドメイン資格証明を使用したKubernetesシークレットの作成

ドメインと同じKubernetesネームスペースで、管理アカウントのKubernetesシークレットusernameおよびpasswordを作成します:

 cd ${WORKDIR}/create-weblogic-domain-credentials
 ./create-weblogic-credentials.sh -u weblogic -p welcome1 -n wcpns -d wcp-domain -s wcp-domain-domain-credentials

サンプル出力:

secret/wcp-domain-domain-credentials created
secret/wcp-domain-domain-credentials labeled
The secret wcp-domain-domain-credentials has been successfully created in the wcpns namespace.

説明:

ノート: 次のように資格証明を検査できます:

 kubectl get secret wcp-domain-domain-credentials -o yaml -n wcpns

詳細は、このドキュメントを参照してください。

RCU資格証明を使用したKubernetesシークレットの作成

ドメインと同じKubernetesネームスペースでcreate-rcu-credentials.shスクリプトを使用して、リポジトリ構成ユーティリティのKubernetesシークレット(ユーザー名とパスワード)を作成します:

 cd ${WORKDIR}/create-rcu-credentials
 sh create-rcu-credentials.sh \
    -u username \
    -p password \
    -a sys_username \
    -q sys_password \
    -d domainUID \
    -n namespace \
    -s secretName

サンプル出力:

 secret/wcp-domain-rcu-credentials created
 secret/wcp-domain-rcu-credentials labeled
 The secret wcp-domain-rcu-credentials has been successfully created in the wcpns namespace.

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

  -u username for schema owner (regular user), must be specified.
  -p password for schema owner (regular user), must be provided using the -p argument or user will be prompted to enter a value.
  -a username for SYSDBA user, must be specified.
  -q password for SYSDBA user, must be provided using the -q argument or user will be prompted to enter a value.
  -d domainUID, optional. The default value is wcp-domain. If specified, the secret will be labeled with the domainUID unless the given value is an empty string.
  -n namespace, optional. Use the wcpns namespace if not specified.
  -s secretName, optional. If not specified, the secret name will be determined based on the domainUID value.

ノート: 次のように資格証明を検査できます:

 kubectl get secret wcp-domain-rcu-credentials -o yaml -n wcpns
Oracle WebCenter Portalドメインの永続ストレージの作成

Kubernetes PVおよびPVC (永続ボリュームおよび永続ボリューム要求)を作成します:

作成したKubernetesネームスペースで、create-pv-pvc.shスクリプトを実行してドメインのPVおよびPVCを作成します。スクリプトを使用する手順に従って、Oracle WebCenter Portalドメイン専用のPVおよびPVCを作成します。

データベース・アクセスの構成

Oracle WebCenter Portalドメインには、特定のスキーマで構成されたデータベースが必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)を使用して作成できます。ドメインを作成する前にデータベースを設定することが不可欠です。

本番環境では、Kubernetesの外部で実行されているスタンドアロン(非コンテナ化)データベースを使用することをお薦めします。

ドメインの作成に進む前に、必要なスキーマがデータベースに設定されていることを確認してください。

リポジトリ作成ユーティリティの実行によるデータベース・スキーマの設定

Oracle WebCenter Portalドメインのデータベース・スキーマを作成するには、create-rcu-schema.shスクリプトを実行します。

cd ${WORKDIR}/create-rcu-schema

./create-rcu-schema.sh \
    -s WCP1 \
    -t wcp \
    -d xxx.oraclevcn.com:1521/DB1129_pdb1.xxx.wcpcluster.oraclevcn.com \
    -i iad.ocir.io/xxxxxxxx/oracle/wcportal:14.1.2.0 \
    -n wcpns \
    -c wcp-domain-rcu-credentials \
    -r ANALYTICS_WITH_PARTITIONING=N

使用方法:

 ./create-rcu-schema.sh -s <schemaPrefix> [-t <schemaType>] [-d <dburl>] [-n <namespace>] [-c <credentialsSecretName>] [-p <docker-store>] [-i <image>] [-u <imagePullPolicy>] [-o <rcuOutputDir>] [-r <customVariables>] [-l <timeoutLimit>] [-e <edition>] [-h]
  -s RCU Schema Prefix (required)
  -t RCU Schema Type (optional)
      (supported values: wcp,wcpp) 
  -d RCU Oracle Database URL (optional) 
      (default: oracle-db.default.svc.cluster.local:1521/devpdb.k8s) 
  -n Namespace for RCU pod (optional)
      (default: default)
  -c Name of credentials secret (optional).
       (default: oracle-rcu-secret)
       Must contain SYSDBA username at key 'sys_username',
       SYSDBA password at key 'sys_password',
       and RCU schema owner password at key 'password'.
  -p OracleWebCenterPortal ImagePullSecret (optional) 
      (default: none) 
  -i OracleWebCenterPortal Image (optional) 
      (default: oracle/wcportal:release-version) 
  -u OracleWebCenterPortal ImagePullPolicy (optional) 
      (default: IfNotPresent) 
  -o Output directory for the generated YAML file. (optional)
      (default: rcuoutput)
  -r Comma-separated custom variables in the format variablename=value. (optional).
      (default: none)
  -l Timeout limit in seconds. (optional).
      (default: 300)
  -e The edition name. This parameter is only valid if you specify databaseType=EBR. (optional).
      (default: 'ORA$BASE')
  -h Help

Note: The c, p, i, u, and o arguments are ignored if an rcu pod is already running in the namespace.

ノート:

WebCenter Portalドメインの作成

既存のPVまたはPVCにOracle WebCenter Portalドメイン・ホームを作成し、生成されたOracle WebCenter Portalドメインをデプロイするためのドメイン・リソースYAMLファイルを作成します。

概要

サンプル・スクリプトを使用して、既存のKubernetes永続ボリューム(PV)および永続ボリューム要求(PVC)にWebCenter Portalドメイン・ホームを作成できます。このスクリプトは、対応するドメインのKubernetesアーティファクトを起動するのに役立つドメインYAMLファイルも生成します。

前提条件
WebCenter Portalドメイン作成の入力ファイルの準備

必要に応じて、create-domain-inputs.yamlファイルでドメインの作成に使用するパラメータをカスタマイズできます。

WebCenter Portalドメイン・デプロイメントのサンプル・スクリプトは、以前にダウンロードしたリポジトリ(${WORKDIR}/create-wcp-domain/domain-home-on-pv/)から入手できます。

デフォルト値を更新する前に、create-domain-inputs.yamlファイルのコピーを作成します。

スクリプトによって作成されたデフォルト・ドメインには、次の特性があります:

構成パラメータ

入力ファイルには、次のパラメータを指定できます:

パラメータ 定義 デフォルト
sslEnabled SSLモード有効化フラグ false
configurePortletServer ポートレット・サーバー・クラスタを構成します false
adminPort Kubernetesクラスタ内の管理サーバーのポート番号。 7001
adminServerSSLPort Kubernetesクラスタ内の管理サーバーのSSLポート番号。 7002
adminAdministrationPort Kubernetesクラスタ内の管理サーバーの管理ポート番号。 9002
adminServerName 管理サーバーの名前。 AdminServer
domainUID この特定のドメインを識別する一意のID。生成されたWebLogicドメインの名前およびKubernetesドメイン・リソースの名前として使用されます。このIDは、Kubernetesクラスタ内のすべてのドメインで一意である必要があります。このIDには、Kubernetesサービス名で有効ではない文字を含めることはできません。 wcp-domain
domainHome WebCenter Portalドメインのホーム・ディレクトリ。ノート: このフィールドは変更できません。 /u01/oracle/user_projects/domains/wcp-domain
serverStartPolicy WebLogic Kubernetes Operatorによって起動されるWebLogic Serverインスタンスを決定します。有効な値: Never、IfNeeded、AdminOnly。Neverは、サーバーを起動しないことを意味し、IfNeededは、必要に応じて管理サーバーと管理対象サーバーの両方を起動します。AdminOnlyは、管理サーバーのみを起動します。 IfNeeded
clusterName ドメイン用に生成するWebLogicクラスタ・インスタンスの名前。デフォルトでは、WebCenter Portalドメイン用のクラスタ名はwcp-clusterです。 wcp-cluster
configuredManagedServerCount ドメインの管理対象サーバー・インスタンスの数。 5
initialManagedServerReplicas ドメインで最初に起動する管理対象サーバーの数。 2
managedServerNameBase 管理対象サーバー名の生成に使用されるベース文字列。 wcpserver
managedServerPort 各管理対象サーバーのポート番号。デフォルトでは、wcpserverのmanagedServerPortは8888で、wcportletserverのmanagedServerPortは8889です。 8888
managedServerSSLPort 各管理対象サーバーのSSLポート番号。デフォルトでは、wcpserverのmanagedServerPortは8788で、wcportletserverのmanagedServerPortは8789です。 8788
managedAdministrationPort 各管理対象サーバーの管理ポート番号。このポートは、管理対象サーバーとの管理通信に使用されます。 9008
portletClusterName ドメイン用に生成するポートレット・クラスタ・インスタンスの名前。デフォルトでは、ポートレットのクラスタ名はwcportlet-clusterです。 wcportlet-cluster
portletServerNameBase ポートレット・サーバー名の生成に使用されるベース文字列。 wcportletserver
portletServerPort 各ポートレット・サーバーのポート番号。デフォルトでは、wcportletserverのportletServerPortは8889です。 8889
portletServerSSLPort 各ポートレット・サーバーのSSLポート番号。デフォルトでは、wcportletserverのportletServerSSLPortは8789です。 8789
portletAdministrationPort 各ポートレット・サーバーの管理ポート番号。このポートは、ポートレット・サーバーとの管理通信に使用されます。 9009
image WebCenter Portal Dockerイメージ。WebLogic Kubernetes Operatorには、WebCenter Portalリリース14.1.2.0が必要です。イメージを取得または作成する方法の詳細は、WebCenter Portal Dockerイメージを参照してください。 oracle/wcportal:14.1.2.0
imagePullPolicy WebLogic Dockerイメージがリポジトリからプルされる場合を定義します。有効な値: IfNotPresent (デフォルト。イメージがノードに存在しない場合のみプルします)、Always (すべてのデプロイメントでイメージをプルします)、およびNever (イメージをプルしません。イメージはローカルで使用可能である必要があります)。 IfNotPresent
productionModeEnabled ドメインが本番モードで実行されているかどうかを示すブール・フラグ。本番モードでは、WebLogic Serverはより厳密なセキュリティおよびリソース管理設定を適用します。 true
secureEnabled ドメインでセキュア・モードが有効かどうかを示すブール。trueに設定すると、WebLogicはSSL構成などの追加のセキュリティ設定を有効にし、より厳密な認証および暗号化プロトコルを適用します。これは、セキュリティがクリティカルな本番環境に適切です。これは、WebLogicを本番モード(productionModeEnabledがtrue)で実行する場合に重要です。falseに設定すると、ドメインはこれらの追加のセキュリティ対策なしで動作します。 false
weblogicCredentialsSecretName 管理サーバーのユーザー名とパスワードのKubernetesシークレットの名前。指定しない場合、値はdomainUIDから<domainUID>-weblogic-credentialsとして導出されます。 wcp-domain-domain-credentials
includeServerOutInPodLog ポッドのstdoutストリームにserver.outログを含めるかどうかを示すブール。trueに設定すると、WebLogic Serverの標準出力がポッドのログ出力にリダイレクトされ、Kubernetesログ管理ツールを介してログに簡単にアクセスできるようになります。 true
logHome ドメイン・ログ、サーバー・ログ、サーバー出力およびノード・マネージャ・ログ・ファイルのポッド内の場所。ノート: このフィールドは変更できません。 /u01/oracle/user_projects/logs/wcp-domain
httpAccessLogInLogHome HTTPアクセス・ログ・ファイルが書き込まれる場所を示すブール。trueに設定すると、ログはlogHomeディレクトリに書き込まれ、falseに設定すると、WebLogic domain homeディレクトリに書き込まれます。 true
t3ChannelPort NetworkAccessPointのT3チャネルのポート。 30012
exposeAdminT3Channel 管理サーバーのT3チャネルをサービスとして公開するかどうかを示すブール。falseに設定すると、T3チャネルはクラスタの内部に残ります。 false
adminNodePort Kubernetesクラスタ外部の管理サーバーのポート番号。これにより、WebLogic管理サーバーへの外部アクセスが可能になります。 30701
exposeAdminNodePort 管理サーバーがKubernetesクラスタの外部に公開されているかどうかを示すブール。 false
namespace WebLogicドメインを作成するKubernetesネームスペースで、リソースを分離し、クラスタ内での管理を容易にします。 wcpns
javaOptions 管理サーバーおよび管理対象サーバーを起動するためのJavaオプション。Javaオプションには、WebLogicドメイン情報を取得するための事前定義された次の1つ以上の変数への参照を含めることができます: $(DOMAIN_NAME)、$(DOMAIN_HOME)、$(ADMIN_NAME)、$(ADMIN_PORT)および$(SERVER_NAME)。 -Dweblogic.StdoutDebugEnabled=false
persistentVolumeClaimName ドメイン・ホームをホストするために作成された永続ボリューム要求の名前。指定しない場合、値はdomainUIDから<domainUID>-weblogic-sample-pvcとして導出されます。 wcp-domain-domain-pvc
domainPVMountPath ドメイン永続ボリュームのマウント・パス。ノート: このフィールドは変更できません。 /u01/oracle/user_projects/domains
createDomainScriptsMountPath ドメイン作成スクリプトがポッド内にあるマウント・パス。create-domain.shスクリプトは、ドメイン・ホームを作成するKubernetesポッドでスクリプト(createDomainScriptNameプロパティで指定)を実行するKubernetesジョブを作成します。createDomainFilesDirディレクトリ内のファイルはポッドのこの場所にマウントされるため、Kubernetesポッドはスクリプトおよびサポート・ファイルを使用してドメイン・ホームを作成できます。 /u01/weblogic
createDomainScriptName ドメイン作成スクリプトがWebLogicドメインの作成に使用するスクリプト。create-domain.shスクリプトは、ドメイン・ホームを作成するこのスクリプトを実行するKubernetesジョブを作成します。このスクリプトは、createDomainScriptsMountPathプロパティで指定されたポッド内のディレクトリにあります。組込みスクリプトを使用するかわりに、ドメイン・ホームを作成するための独自のスクリプトを指定する必要がある場合は、このプロパティを使用して、ドメイン作成ジョブで実行するスクリプトの名前を設定する必要があります。 create-domain-job.sh
createDomainFilesDir createDomainScriptNameプロパティで指定されたスクリプトを含め、WebLogicドメインの作成に必要なすべてのファイルを検索するホスト・マシン上のディレクトリ。デフォルトでは、このディレクトリは相対パスwlstに設定され、作成スクリプトは、wlstディレクトリの組込みWLSTオフライン・スクリプトを使用してWebLogicドメインを作成します。絶対パスも、ファイル・システム内の任意のディレクトリを指すようにサポートされています。組込みスクリプトは、ファイルが指定されたディレクトリにあるかぎり、ユーザーが指定したスクリプトまたはモデル・ファイルに置き換えることができます。このディレクトリ内のファイルは、Kubernetes構成マップに配置され、さらにcreateDomainScriptsMountPathにマウントされます。これにより、Kubernetesポッドがスクリプトおよびサポート・ファイルを使用してドメイン・ホームを作成できるようになります。 wlst
rcuSchemaPrefix データベースで使用するスキーマ接頭辞(WCP1など)。RCUスキーマとの一致ドメインを簡略化するために、これをdomainUIDと同じにできます。 WCP1
rcuDatabaseURL データベースURL。 dbhostname:dbport/servicename
rcuCredentialsSecret データベース資格証明を含むKubernetesシークレット。 wcp-domain-rcu-credentials
loadBalancerHostName K8S環境の外部でアクセス可能な最終URLのホスト名。 abc.def.com
loadBalancerPortNumber K8S環境の外部でアクセス可能な最終URLのポート。 30305
loadBalancerProtocol K8S環境の外部でアクセス可能な最終URLのプロトコル。 http
loadBalancerType ロード・バランサ名。例: Traefikまたは"" traefik
unicastPort アプリケーションが使用するユニキャスト・ポートの開始範囲。 50000

生成されたYAMLファイル内のKubernetesリソースの名前は、create-domain-inputs.yamlファイルで指定されたプロパティ(adminServerName、clusterNameおよびmanagedServerNameBase)の値を使用して構成できます。Kubernetesサービス名で無効な文字は、生成されたYAMLファイルで有効な値に変換されます。たとえば、大文字は小文字に変換され、アンダースコア(_)はハイフン(-)に変換されます。

サンプルでは、1つのクラスタのみを持つドメインに対して、WebCenter Portalドメイン・ホームおよび関連するKubernetesリソースを作成する方法を示します。また、このサンプルでは、他のユース・ケース用にドメイン・ホームを作成するためのユーザー独自のスクリプトを提供する機能も示します。他のユース・ケースを含めるように、生成されたドメインYAMLファイルを変更できます。

WebCenter Portalドメインの作成

入力ファイルと、生成されたアーティファクトを格納する出力ディレクトリを指定して、ドメイン作成スクリプトを実行します:

 ./create-domain.sh \
    -i create-domain-inputs.yaml \
    -o /<path to output-directory>

このスクリプトは、次のステップを実行します:

  1. create-domain.shサンプル・スクリプトを実行し、次のようにcreate-domain-inputs.yaml入力ファイルおよび出力ディレクトリを指すようにします:

    cd ${WORKDIR}/create-wcp-domain/
sh create-domain.sh  -i create-domain-inputs.yaml  -o output

    サンプル出力:

      Input parameters being used
  export version="create-weblogic-sample-domain-inputs-v1"
  export sslEnabled="false"
  export adminPort="7001"
  export adminServerSSLPort="7002"
  export adminServerName="AdminServer"
  export domainUID="wcp-domain"
  export domainHome="/u01/oracle/user_projects/domains/$domainUID"
  export serverStartPolicy="IF_NEEDED"
  export clusterName="wcp-cluster"
  export configuredManagedServerCount="5"
  export initialManagedServerReplicas="2"
  export managedServerNameBase="wcpserver"
  export managedServerPort="8888"
  export managedServerSSLPort="8788"
  export portletServerPort="8889"
  export portletServerSSLPort="8789"
  export image="oracle/wcportal:14.1.2.0"
  export imagePullPolicy="IfNotPresent"
  export productionModeEnabled="true"
  export weblogicCredentialsSecretName="wcp-domain-domain-credentials"
  export includeServerOutInPodLog="true"
  export logHome="/u01/oracle/user_projects/domains/logs/$domainUID"
  export httpAccessLogInLogHome="true"
  export t3ChannelPort="30012"
  export exposeAdminT3Channel="false"
  export adminNodePort="30701"
  export exposeAdminNodePort="false"
  export namespace="wcpns"
  javaOptions=-Dweblogic.StdoutDebugEnabled=false
  export persistentVolumeClaimName="wcp-domain-domain-pvc"
  export domainPVMountPath="/u01/oracle/user_projects/domains"
  export createDomainScriptsMountPath="/u01/weblogic"
  export createDomainScriptName="create-domain-job.sh"
  export createDomainFilesDir="wlst"
  export rcuSchemaPrefix="WCP1"
  export rcuDatabaseURL="oracle-db.wcpns.svc.cluster.local:1521/devpdb.k8s"
  export rcuCredentialsSecret="wcp-domain-rcu-credentials"
  export loadBalancerHostName="abc.def.com"
  export loadBalancerPortNumber="30305"
  export loadBalancerProtocol="http"
  export loadBalancerType="traefik"
  export unicastPort="50000"

  Generating output/weblogic-domains/wcp-domain/create-domain-job.yaml
  Generating output/weblogic-domains/wcp-domain/delete-domain-job.yaml
  Generating output/weblogic-domains/wcp-domain/domain.yaml
  Checking to see if the secret wcp-domain-domain-credentials exists in namespace wcpns
  configmap/wcp-domain-create-wcp-infra-sample-domain-job-cm created
  Checking the configmap wcp-domain-create-wcp-infra-sample-domain-job-cm was created
  configmap/wcp-domain-create-wcp-infra-sample-domain-job-cm labeled
  Checking if object type job with name wcp-domain-create-wcp-infra-sample-domain-job exists
  Deleting wcp-domain-create-wcp-infra-sample-domain-job using output/weblogic-domains/wcp-domain/create-domain-job.yaml
  job.batch "wcp-domain-create-wcp-infra-sample-domain-job" deleted
  $loadBalancerType is NOT empty
  Creating the domain by creating the job output/weblogic-domains/wcp-domain/create-domain-job.yaml
  job.batch/wcp-domain-create-wcp-infra-sample-domain-job created
  Waiting for the job to complete...
  status on iteration 1 of 20
  pod wcp-domain-create-wcp-infra-sample-domain-job-b5l6c status is Running
  status on iteration 2 of 20
  pod wcp-domain-create-wcp-infra-sample-domain-job-b5l6c status is Running
  status on iteration 3 of 20
  pod wcp-domain-create-wcp-infra-sample-domain-job-b5l6c status is Running
  status on iteration 4 of 20
  pod wcp-domain-create-wcp-infra-sample-domain-job-b5l6c status is Running
  status on iteration 5 of 20
  pod wcp-domain-create-wcp-infra-sample-domain-job-b5l6c status is Running
  status on iteration 6 of 20
  pod wcp-domain-create-wcp-infra-sample-domain-job-b5l6c status is Running
  status on iteration 7 of 20
  pod wcp-domain-create-wcp-infra-sample-domain-job-b5l6c status is Completed

  Domain wcp-domain was created and will be started by the WebLogic Kubernetes Operator

  The following files were generated:
    output/weblogic-domains/wcp-domain/create-domain-inputs.yaml
    output/weblogic-domains/wcp-domain/create-domain-job.yaml
    output/weblogic-domains/wcp-domain/domain.yaml

  Completed

  2. 前述のドメイン作成ログをモニターするには:

    $ kubectl get pods -n wcpns |grep wcp-domain-create

    サンプル出力:

    wcp-domain-create-fmw-infra-sample-domain-job-8jr6k   1/1     Running   0          6s
    $ kubectl get pods -n wcpns | grep wcp-domain-create | awk '{print $1}' | xargs kubectl -n wcpns logs -f

    サンプル出力:

    The domain will be created using the script /u01/weblogic/create-domain-script.sh

Initializing WebLogic Scripting Tool (WLST) ...


Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

=================================================================
    WebCenter Portal Weblogic Operator Domain Creation Script
                        14.1.2.0
=================================================================
Creating Base Domain...
Creating Admin Server...
Creating cluster...
managed server name is wcpserver1
managed server name is wcpserver2
managed server name is wcpserver3
managed server name is wcpserver4
managed server name is wcpserver5
['wcpserver1', 'wcpserver2', 'wcpserver3', 'wcpserver4', 'wcpserver5']
Creating porlet cluster...
managed server name is wcportletserver1
managed server name is wcportletserver2
managed server name is wcportletserver3
['wcportletserver1', 'wcportletserver2', 'wcportletserver3', 'wcportletserver4', 'wcportletserver5']
Managed servers created...
Creating Node Manager...
Will create Base domain at /u01/oracle/user_projects/domains/wcp-domain
Writing base domain...
Base domain created at /u01/oracle/user_projects/domains/wcp-domain
Extending Domain...
Extending domain at /u01/oracle/user_projects/domains/wcp-domain
Database  oracle-db.wcpns.svc.cluster.local:1521/devpdb.k8s
ExposeAdminT3Channel false with 100.111.157.155:30012
Applying JRF templates...
Applying WCPortal templates...
Extension Templates added...
WC_Portal Managed server deleted...
Configuring the Service Table DataSource...
fmwDatabase  jdbc:oracle:thin:@oracle-db.wcpns.svc.cluster.local:1521/devpdb.k8s
Getting Database Defaults...
Targeting Server Groups...
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcpserver1
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcpserver2
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcpserver3
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcpserver4
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcpserver5
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcportletserver1
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcportletserver2
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcportletserver3
Targeting Cluster ...
Set CoherenceClusterSystemResource to defaultCoherenceCluster for cluster:wcp-cluster
Set WLS clusters as target of defaultCoherenceCluster:wcp-cluster
Set CoherenceClusterSystemResource to defaultCoherenceCluster for cluster:wcportlet-cluster
Set WLS clusters as target of defaultCoherenceCluster:wcportlet-cluster
Preparing to update domain...
Jan 12, 2021 10:30:09 AM oracle.security.jps.az.internal.runtime.policy.AbstractPolicyImpl initializeReadStore
INFO: Property for read store in parallel: oracle.security.jps.az.runtime.readstore.threads = null
Domain updated successfully
Domain Creation is done...
Successfully Completed
WebCenter Portalドメインの初期化

ドメインを起動するには、前述のdomain.yamlを適用します:

kubectl apply -f output/weblogic-domains/wcp-domain/domain.yaml

サンプル出力:

domain.weblogic.oracle/wcp-domain created
WebCenter Portalドメインの検証

ドメインおよびサーバーのポッドとサービスが作成され、READY状態であることを検証します:

サンプル実行は次のとおりです:

kubectl get pods -n wcpns -w

サンプル出力:

NAME                                                    READY   STATUS          RESTARTS    AGE
wcp-domain-create-fmw-infra-sample-domain-job-8jr6k     0/1     Completed         0             15m
wcp-domain-adminserver                                  1/1     Running         0          8m9s
wcp-domain-create-fmw-infra-sample-domain-job-8jr6k     0/1     Completed       0          3h6m
wcp-domain-wcp-server1                                  0/1     Running         0          6m5s
wcp-domain-wcp-server2                                  0/1     Running         0          6m4s
wcp-domain-wcp-server2                                  1/1     Running         0          6m18s
wcp-domain-wcp-server1                                  1/1     Running         0          6m54s
kubectl get all -n wcpns

サンプル出力:

NAME                                                      READY   STATUS      RESTARTS   AGE
pod/wcp-domain-adminserver                                1/1     Running     0          13m
pod/wcp-domain-create-fmw-infra-sample-domain-job-8jr6k   0/1     Completed   0          3h12m
pod/wcp-domain-wcp-server1                                1/1     Running     0          11m
pod/wcp-domain-wcp-server2                                1/1     Running     0          11m
pod/wcp-domain-wcportletserver1                           1/1     Running     1          21h


NAME                                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/wcp-domain-adminserver                   ClusterIP   None            <none>        7001/TCP   13m
service/wcp-domain-cluster-wcp-cluster           ClusterIP   10.98.145.173   <none>        8888/TCP   11m
service/wcp-domain-wcp-server1                   ClusterIP   None            <none>        8888/TCP   11m
service/wcp-domain-wcp-server2                   ClusterIP   None            <none>        8888/TCP   11m
service/wcp-domain-cluster-wcportlet-cluster     ClusterIP   10.98.145.173   <none>        8889/TCP   11m
service/wcp-domain-wcportletserver1              ClusterIP   None            <none>        8889/TCP   11m


NAME                                                      COMPLETIONS   DURATION   AGE
job.batch/wcp-domain-create-fmw-infra-sample-domain-job   1/1           16m        3h12m

管理サーバーおよび管理対象サーバーのログを参照するには、ポッド・ログを確認します:

$ kubectl logs -f wcp-domain-adminserver -n wcpns
$ kubectl logs -f wcp-domain-wcp-server1  -n wcpns
ポッドの検証

次のコマンドを使用して、サーバーを実行しているポッドを表示します:

$ kubectl get pods -n NAMESPACE

次に、このコマンドの出力例を示します:

kubectl get pods -n wcpns

サンプル出力:

NAME                                                  READY   STATUS      RESTARTS   AGE
rcu                                                   1/1     Running     1          14d
wcp-domain-adminserver                                1/1     Running     0          16m
wcp-domain-create-fmw-infra-sample-domain-job-8jr6k   0/1     Completed   0          3h14m
wcp-domain-wcp-server1                                1/1     Running     0          14m
wcp-domain-wcp-server2                                1/1     Running     0          14m
wcp-domain-wcportletserver1                           1/1     Running     1          14m
サービスの検証

次のコマンドを使用して、ドメインのサービスを表示します:

$ kubectl get services -n NAMESPACE

次に、このコマンドの出力例を示します:

kubectl get services -n wcpns

サンプル出力:

NAME                                    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
wcp-domain-adminserver                  ClusterIP   None            <none>        7001/TCP   17m
wcp-domain-cluster-wcp-cluster          ClusterIP   10.98.145.173   <none>        8888/TCP   14m
wcp-domain-wcp-server1                  ClusterIP   None            <none>        8888/TCP   14m
wcp-domain-wcp-server2                  ClusterIP   None            <none>        8888/TCP   14m
wcp-domain-cluster-wcportlet-cluster    ClusterIP   10.98.145.173   <none>        8889/TCP   14m
wcp-domain-wcportletserver1             ClusterIP   None            <none>        8889/TCP   14m
WebCenter Portalの管理

管理対象サーバーを停止するには:

kubectl patch domain wcp-domain -n wcpns --type='json' -p='[{"op": "replace", "path": "/spec/clusters/0/replicas", "value": 0 }]'

構成されたすべての管理対象サーバーを起動するには:

kubectl patch domain wcp-domain -n wcpns --type='json' -p='[{"op": "replace", "path": "/spec/clusters/0/replicas", "value": 3 }]' 
kubectl get pods -n wcpns -w

サンプル出力:

NAME                                                    READY   STATUS          RESTARTS    AGE
wcp-domain-create-fmw-infra-sample-domain-job-8jr6k     0/1     Completed       0           15m
wcp-domain-adminserver                                  1/1     Running         0          8m9s
wcp-domain-create-fmw-infra-sample-domain-job-8jr6k     0/1     Completed       0          3h6m
wcp-domain-wcp-server1                                  0/1     Running         0          6m5s
wcp-domain-wcp-server2                                  0/1     Running         0          6m4s
wcp-domain-wcp-server2                                  1/1     Running         0          6m18s
wcp-domain-wcp-server1                                  1/1     Running         0          6m54s

管理ガイド

様々なユーティリティ・ツールおよび構成を使用して、WebCenter Portalドメインを管理する方法について説明します。

Kubernetes環境でOracle WebCenter Portalドメインを管理します。

ロード・バランサの設定

Oracle WebCenter Portalドメインの様々なロード・バランサを設定します。

WebLogic Kubernetes Operatorは、TraefikやNGINX (kubernetes/ingress-nginx)などのイングレスベースのロード・バランサをサポートしています。また、Apache Web層ロード・バランサでも動作します。

Traefik

Oracle WebCenter PortalドメインのTraefikイングレスベースのロード・バランサを設定します。

Oracle WebCenter Portalドメイン・クラスタをロード・バランシングするには、イングレスベースのTraefikロード・バランサ(本番環境ではバージョン2.6.0以降)をインストールし、アプリケーションURLの非SSL、SSL終端およびエンドツーエンドSSLアクセス用に構成します。次のステップに従って、TraefikをKubernetesクラスタ内のOracle WebCenter Portalドメインのロード・バランサとして構成します:

非SSLおよびSSL終端
Traefik (イングレスベース)ロード・バランサのインストール

  1. Helmを使用して、Traefik (イングレスベース)ロード・バランサをインストールします。次のvalues.yamlサンプル・ファイルを使用して、必要に応じてkubernetes.namespacesを設定できます。

     cd ${WORKDIR}
 kubectl create namespace traefik
 helm repo add traefik https://helm.traefik.io/traefik --force-update

    サンプル出力:

     "traefik" has been added to your repositories

  2. Traefikをインストールします:

     helm install traefik  traefik/traefik \
   --namespace traefik \
   --values charts/traefik/values.yaml \
   --set  "kubernetes.namespaces={traefik}" \
   --set "service.type=NodePort" --wait

    サンプル出力:

     LAST DEPLOYED: Sun Sep 13 21:32:00 2020
 NAMESPACE: traefik
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None

    次に、Traefikをデプロイするためのサンプルvalues.yamlを示します:

    image:
  name: traefik
  pullPolicy: IfNotPresent

ingressRoute:
  dashboard:
    enabled: true
    # Additional ingressRoute annotations (e.g. for kubernetes.io/ingress.class)
    annotations: {}
    # Additional ingressRoute labels (e.g. for filtering IngressRoute by custom labels)
    labels: {}

providers:
  kubernetesCRD:
    enabled: true
  kubernetesIngress:
    enabled: true
    # IP used for Kubernetes Ingress endpoints

ports:
  traefik:
    port: 9000
    # The exposed port for this service
    exposedPort: 9000
    # The port protocol (TCP/UDP)
    protocol: TCP
  web:
    port: 8000
    exposedPort: 30305
    nodePort: 30305
    # The port protocol (TCP/UDP)
    protocol: TCP
    # Use nodeport if set. This is useful if you have configured Traefik in a
    # LoadBalancer
    # nodePort: 32080
    # Port Redirections
    # Added in 2.2, you can make permanent redirects via entrypoints.
    # https://docs.traefik.io/routing/entrypoints/#redirection
    # redirectTo: websecure
  websecure:
    port: 8443
    exposedPort: 30443
    # The port protocol (TCP/UDP)
    protocol: TCP
    nodePort: 30443

  3. Traefikステータスを確認し、SSLおよび非SSLサービスのポート番号を見つけます:

     kubectl get all -n traefik

    サンプル出力:

     NAME                          READY   STATUS    RESTARTS   AGE
 pod/traefik-f9cf58697-29dlx   1/1     Running   0          35s

 NAME              TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                                          AGE
 service/traefik   NodePort   10.100.113.37   <none>        9000:30070/TCP,30305:30305/TCP,30443:30443/TCP   35s

 NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
 deployment.apps/traefik   1/1     1            1           36s

 NAME                                DESIRED   CURRENT   READY   AGE
 replicaset.apps/traefik-f9cf58697   1         1         1       36s

  4. HTTPホストtraefik.example.comを使用してURL http://$(hostname -f):30070を介してTraefikダッシュボードにアクセスします:

     curl -H "host: $(hostname -f)" http://$(hostname -f):30070/dashboard/

    ノート: $(hostname -f)には必ず完全修飾ノード名を指定してください

イングレスを管理するためのTraefikの構成

このネームスペースで作成されたイングレスを管理するようにTraefikを構成します。次のサンプルでは、traefikはTraefikネームスペースで、wcpnsはドメインのネームスペースです:

helm upgrade traefik traefik/traefik \
--reuse-values \
--namespace traefik \
--set "kubernetes.namespaces={traefik,wcpns}" \
--wait

サンプル出力:

Release "traefik" has been upgraded. Happy Helming!
NAME: traefik
LAST DEPLOYED: Tue Jan 12 04:33:15 2021
NAMESPACE: traefik
STATUS: deployed
REVISION: 2
TEST SUITE: None
ドメインのイングレスの作成

ドメイン・ネームスペース内にドメインのイングレスを作成するには、イングレスのパスベースのルーティングを実装するサンプルのHelmチャートを使用します。デフォルト構成のサンプル値は、${WORKDIR}/charts/ingress-per-domain/values.yamlファイルにあります。

デフォルトでは、typeはTRAEFIKに設定され、tlsはNon-SSLとして構成されます。これらの値をオーバーライドするには、コマンドラインを介してそれらを渡すか、構成タイプ(非SSLまたはSSL)に従ってサンプルvalues.yamlファイルを編集します。

ノート: これは、ルールの完全なリストではありません。外部アクセスが必要なアプリケーションURLを含めるように変更できます。

必要に応じて、イングレスYAMLファイルを更新して、外部アクセスが必要なドメイン・アプリケーションURLに基づいてspec.rules.host.http.pathsセクションに追加のパス・ルールを定義できます。Traefik (イングレスベース)ロード・バランサのテンプレートYAMLファイルは、${WORKDIR}/charts/ingress-per-domain/templates/traefik-ingress.yamlにあります。次に示すとおり、新しいパス・ルールを追加できます。

 - path: /NewPathRule
   backend:
     serviceName: 'Backend Service Name'
     servicePort: 'Backend Service Port'

  1. 非SSL構成用にHelmを使用してingress-per-domainをインストールします:

      cd ${WORKDIR}
  helm install wcp-traefik-ingress  \
     charts/ingress-per-domain \
     --namespace wcpns \
     --values charts/ingress-per-domain/values.yaml \
     --set "traefik.hostname=$(hostname -f)"

    サンプル出力:

      NAME: wcp-traefik-ingress
  LAST DEPLOYED: Mon Jul 20 11:44:13 2020
  NAMESPACE: wcpns
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None

  2. Oracle WebCenter Portalアプリケーションへのセキュア・アクセス(SSL)の場合は、証明書を作成してKubernetesシークレットを生成します:

      openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt -subj "/CN=*"
  kubectl -n wcpns create secret tls wcp-domain-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt

    ノート: CNの値は、このイングレスがデプロイされるホストです。

  3. Traefik TLSStoreカスタム・リソースを作成します。

    SSL終端の場合は、ユーザー定義のSSL証明書を使用するようにTraefikを構成する必要があります。ユーザー定義のSSL証明書が構成されていない場合、TraefikはデフォルトのSSL証明書を作成します。Traefikのユーザー定義のSSL証明書を構成するには、TLSStoreカスタム・リソースを使用します。SSL証明書を使用して作成されたKubernetesシークレットは、TLSStoreオブジェクトで参照される必要があります。次のコマンドを実行して、TLSStoreを作成します:

    cat <<EOF | kubectl apply -f -
apiVersion: traefik.containo.us/v1alpha1
kind: TLSStore
metadata:
  name: default
  namespace: wcpns
spec:
  defaultCertificate:
    secretName:  wcp-domain-tls-cert   
EOF

  4. SSL構成用にHelmを使用してingress-per-domainをインストールします。

    Kubernetesシークレット名は、テンプレート・ファイルで更新する必要があります。

    テンプレート・ファイルには、次の注釈も含まれています:

     traefik.ingress.kubernetes.io/router.entrypoints: websecure
 traefik.ingress.kubernetes.io/router.tls: "true"
 traefik.ingress.kubernetes.io/router.middlewares: wcpns-wls-proxy-ssl@kubernetescrd

    SSLアクセスのエントリ・ポイントおよびミドルウェア名を注釈で更新する必要があります。ミドルウェア名は、<namespace>-<middleware name>@kubernetescrdという形式にする必要があります。

     cd ${WORKDIR}
 helm install wcp-traefik-ingress  \
     charts/ingress-per-domain \
     --namespace wcpns \
     --values charts/ingress-per-domain/values.yaml \
     --set "traefik.hostname=$(hostname -f)" \
     --set sslType=SSL

    サンプル出力:

     NAME: wcp-traefik-ingress
 LAST DEPLOYED: Mon Jul 20 11:44:13 2020
 NAMESPACE: wcpns
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None

  5. Oracle WebCenter Portalアプリケーションへの非SSLアクセスの場合は、イングレスによってサービスの詳細を取得します:

     kubectl describe ingress wcp-domain-traefik -n wcpns

    前述のデプロイ済イングレスでサポートされるサンプル・サービス:

    Name:             wcp-domain-traefik
Namespace:        wcpns
Address:
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
  Host                                          Path  Backends
  ----                                          ----  --------
  www.example.com
                                                /webcenter   wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /console     wcp-domain-adminserver:7001 (10.244.0.51:7001)
                                                /rsscrawl    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /rest        wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /webcenterhelp    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)        
                                                /em          wcp-domain-adminserver:7001 (10.244.0.51:7001)
                                                /wsrp-tools     wcp-domain-cluster-wcportlet-cluster:8889 (10.244.0.52:8889,10.244.0.53:8889)
Annotations:                                    kubernetes.io/ingress.class: traefik
                                                meta.helm.sh/release-name: wcp-traefik-ingress
                                                meta.helm.sh/release-namespace: wcpns
Events:                                         <none>

  6. Oracle WebCenter PortalアプリケーションへのSSLアクセスの場合は、前述のデプロイ済イングレスによってサービスの詳細を取得します:

    kubectl describe ingress wcp-domain-traefik -n wcpns

    前述のデプロイ済イングレスでサポートされるサンプル・サービス:

    Name:             wcp-domain-traefik
Namespace:        wcpns
Address:
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  wcp-domain-tls-cert terminates www.example.com
Rules:
  Host                                          Path  Backends
  ----                                          ----  --------
  www.example.com
                                                /webcenter   wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /console     wcp-domain-adminserver:7001 (10.244.0.51:7001)
                                                /rsscrawl    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /rest        wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /webcenterhelp    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /em          wcp-domain-adminserver:7001 (10.244.0.51:7001)
                                                /wsrp-tools     wcp-domain-cluster-wcportlet-cluster:8889 (10.244.0.52:8889,10.244.0.53:8889)
Annotations:                                    kubernetes.io/ingress.class: traefik
                                                meta.helm.sh/release-name: wcp-traefik-ingress
                                                meta.helm.sh/release-namespace: wcpns
                                                traefik.ingress.kubernetes.io/router.entrypoints: websecure
                                                traefik.ingress.kubernetes.io/router.middlewares: wcpns-wls-proxy-ssl@kubernetescrd
                                                traefik.ingress.kubernetes.io/router.tls: true
Events:                                         <none>

  7. ロード・バランサが新しいイングレスを認識し、ドメイン・サーバー・ポッドへのルーティングに成功したことを確認するには、次のようにHTTP 200ステータス・コードを返すWebLogic ReadyAppフレームワークのURLにリクエストを送信します:

     curl -v http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_PORT}/weblogic/ready

    サンプル出力:

     *   Trying 149.87.129.203...
 > GET http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_PORT}/weblogic/ready HTTP/1.1
 > User-Agent: curl/7.29.0
 > Accept: */*
 > Proxy-Connection: Keep-Alive
 > host: $(hostname -f)
 >
 < HTTP/1.1 200 OK
 < Date: Sat, 14 Mar 2020 08:35:03 GMT
 < Vary: Accept-Encoding
 < Content-Length: 0
 < Proxy-Connection: Keep-Alive
 <
 * Connection #0 to host localhost left intact
ドメイン・アプリケーションURLアクセスの検証

非SSL構成の場合

Traefik (イングレスベース)ロード・バランサを設定した後、HTTPアクセス用の非SSLロード・バランサ・ポート30305を介してドメイン・アプリケーションURLにアクセスできることを検証します。Oracle WebCenter PortalドメインのサンプルURLは、次のとおりです:

  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/webcenter
  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/console
  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/em
  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/rsscrawl
  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/rest
  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/webcenterhelp
  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/wsrp-tools

SSL構成の場合

Traefik (イングレスベース)ロード・バランサを設定した後、HTTPSアクセス用のSSLロード・バランサ・ポート30443を介してドメイン・アプリケーションにアクセスできることを検証します。Oracle WebCenter PortalドメインのサンプルURLは、次のとおりです:

  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenter
  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/console
  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/em
  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/rsscrawl
  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/rest
  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenterhelp
  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/wsrp-tools
Traefikイングレスのアンインストール

イングレス・デプロイメントをアンインストールして削除します:

 helm delete wcp-traefik-ingress  -n wcpns
エンドツーエンドSSL構成
エンドツーエンドSSLのTraefikロード・バランサのインストール

  1. Helmを使用して、Traefik (イングレスベース)ロード・バランサをインストールします。values.yamlサンプル・ファイルを使用して、必要に応じてkubernetes.namespacesを設定できます。

     cd ${WORKDIR}
 kubectl create namespace traefik
 helm repo add traefik https://containous.github.io/traefik-helm-chart

    サンプル出力:

     "traefik" has been added to your repositories

  2. Traefikをインストールします:

     helm install traefik  traefik/traefik \
 --namespace traefik \
 --values charts/traefik/values.yaml \
 --set  "kubernetes.namespaces={traefik}" \
 --set "service.type=NodePort" --wait

    サンプル出力:

     LAST DEPLOYED: Sun Sep 13 21:32:00 2020
 NAMESPACE: traefik
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None

  3. Traefikオペレータ・ステータスを確認し、SSLおよび非SSLサービスのポート番号を見つけます:

     kubectl get all -n traefik

    サンプル出力:

    
   NAME                           READY   STATUS    RESTARTS   AGE
   pod/traefik-845f5d6dbb-swb96   1/1     Running   0          32s

   NAME              TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                          AGE
   service/traefik   NodePort       10.99.52.249   <none>        9000:31288/TCP,30305:30305/TCP,30443:30443/TCP   32s

   NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/traefik   1/1     1            1           33s

   NAME                                 DESIRED   CURRENT   READY   AGE
   replicaset.apps/traefik-845f5d6dbb   1         1         1       33s

  4. HTTPホストtraefik.example.comを使用してURL http://$(hostname -f):31288を介してTraefikダッシュボードにアクセスします:

     curl -H "host: $(hostname -f)" http://$(hostname -f):31288/dashboard/

    ノート: $(hostname -f)には必ず完全修飾ノード名を指定してください。

ドメインを管理するためのTraefikの構成

このネームスペースで作成されたドメイン・アプリケーション・サービスを管理するようにTraefikを構成します。次のサンプルでは、traefikはTraefikネームスペースで、wcpnsはドメインのネームスペースです:

 helm upgrade traefik traefik/traefik --namespace traefik --reuse-values \
  --set "kubernetes.namespaces={traefik,wcpns}"

サンプル出力:

  Release "traefik" has been upgraded. Happy Helming!
  NAME: traefik
  LAST DEPLOYED: Sun Sep 13 21:32:12 2020
  NAMESPACE: traefik
  STATUS: deployed
  REVISION: 2
  TEST SUITE: None
IngressRouteTCPの作成

  1. Traefikでは、注釈ssl-passthroughによる複数のパスまたはルールがサポートされていないため、バックエンド・サービスごとに異なるイングレスを作成します。たとえば、wcp-domain-adminserverおよびwcp-domain-cluster-wcp-clusterでは、異なるイングレスを作成する必要があります。

  2. TraefikでSSLパススルーを有効にするには、TCPルーターを構成します。IngressRouteTCPのサンプルYAMLは、${WORKDIR}/charts/ingress-per-domain/tls/traefik-tls.yamlにあります。traefik-tls.yamlで次を更新する必要があります:

    • サービス名とSSLポートは、servicesで更新する必要があります。
    • ロード・バランサ・ホスト名は、HostSNIルールで更新する必要があります。

    サンプルtraefik-tls.yaml:

    apiVersion: traefik.containo.us/v1alpha1
kind: IngressRouteTCP
metadata:
  name: wcp-domain-cluster-routetcp
  namespace: wcpns
spec:
  entryPoints:
    - websecure
  routes:
  - match: HostSNI(`${LOADBALANCER_HOSTNAME}`)
    services:
    - name: wcp-domain-cluster-wcp-cluster
      port: 8888
      weight: 3
      TerminationDelay: 400
  tls:
    passthrough: true

  3. IngressRouteTCPを作成します:

    kubectl apply -f traefik-tls.yaml
エンドツーエンドSSLアクセスの検証

構成済のサービスを介して公開されたアプリケーションURLへのアクセスを検証します。構成済のWCPクラスタ・サービスによって、次のWCPドメインURLにアクセスできます:

https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenter
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/rsscrawl
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/rest
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenterhelp
Traefikのアンインストール
helm delete traefik -n traefik
cd ${WORKDIR}/charts/ingress-per-domain/tls
kubectl delete -f traefik-tls.yaml

NGINX

Oracle WebCenter PortalドメインのイングレスベースのNGINXロード・バランサを構成します。

Oracle WebCenter Portalドメイン・クラスタをロード・バランシングするには、イングレスベースのNGINXロード・バランサをインストールし、アプリケーションURLの非SSL、SSL終端およびエンドツーエンドSSLアクセス用にNGINXを構成します。次のステップに従って、NGINXをKubernetesクラスタ内のOracle WebCenter Portalドメインのロード・バランサとして設定します:

前提条件は、公式のインストール・ドキュメントを参照してください。

非SSLおよびSSL終端

リポジトリ情報を取得するには、次のHelmコマンドを入力します:

  helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
  helm repo update
NGINXロード・バランサのインストール

  1. ドメイン・ネームスペースでHelmを使用して、ingress-nginxコントローラをデプロイします:

     helm install nginx-ingress ingress-nginx/ingress-nginx -n wcpns \
   --set controller.service.type=NodePort \
   --set controller.admissionWebhooks.enabled=false

    サンプル出力

    NAME: nginx-ingress
    LAST DEPLOYED: Tue Jan 12 21:13:54 2021
    NAMESPACE: wcpns
    STATUS: deployed
    REVISION: 1
    TEST SUITE: None
    NOTES:
    The ingress-nginx controller has been installed.
    Get the application URL by running these commands:
      export HTTP_NODE_PORT=30305
      export HTTPS_NODE_PORT=$(kubectl --namespace wcpns get services -o jsonpath="{.spec.ports[1].nodePort}" nginx-ingress-ingress-nginx-controller)
      export NODE_IP=$(kubectl --namespace wcpns get nodes -o jsonpath="{.items[0].status.addresses[1].address}")
    
      echo "Visit http://$NODE_IP:$HTTP_NODE_PORT to access your application via HTTP."
      echo "Visit https://$NODE_IP:$HTTPS_NODE_PORT to access your application via HTTPS."
    
    An example Ingress that makes use of the controller:
    
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        annotations:
          kubernetes.io/ingress.class: nginx
        name: example
        namespace: foo
      spec:
        rules:
          - host: www.example.com
            http:
              paths:
                - backend:
                    serviceName: exampleService
                    servicePort: 80
                  path: /
        # This section is only required if TLS is to be enabled for the Ingress
        tls:
            - hosts:
                - www.example.com
              secretName: example-tls
    
    If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:
    
      apiVersion: v1
      kind: Secret
      metadata:
        name: example-tls
        namespace: foo
      data:
        tls.crt: <base64 encoded cert>
        tls.key: <base64 encoded key>
      type: kubernetes.io/tls

  1. デプロイされたイングレス・コントローラのステータスを確認します:

     kubectl --namespace wcpns get services | grep ingress-nginx-controller

    サンプル出力:

    nginx-ingress-ingress-nginx-controller   NodePort       10.101.123.106   <none>        80:30305/TCP,443:31856/TCP   2m12s
イングレスを管理するためのNGINXの構成
  1. サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します。ここでは、パスベースのルーティングがイングレスに使用されます。デフォルト構成のサンプル値は、${WORKDIR}/charts/ingress-per-domain/values.yamlファイルに示されています。デフォルトでは、typeはTRAEFIKで、tlsはNon-SSLです。これらの値をオーバーライドするには、コマンドラインを介して値を渡すか、サンプルvalues.yamlファイルでそれらを編集します。

ノート: これは、ルールの完全なリストではありません。外部からアクセスする必要があるアプリケーションURLに基づいてこれを拡張できます。

必要に応じて、イングレスYAMLファイルを更新して、アクセスが必要なドメイン・アプリケーションURLに基づいて(spec.rules.host.http.pathsセクションに)追加のパス・ルールを定義できます。${WORKDIR}/charts/ingress-per-domain/templates/nginx-ingress.yamlにあるNGINXロード・バランサのテンプレートYAMLファイルを更新します

次に示すような新しいパス・ルールを追加できます。

- path: /NewPathRule
  backend:
    serviceName: 'Backend Service Name'
    servicePort: 'Backend Service Port'
  cd ${WORKDIR}
  helm install wcp-domain-nginx charts/ingress-per-domain \
    --namespace wcpns \
    --values charts/ingress-per-domain/values.yaml \
    --set "nginx.hostname=$(hostname -f)" \
    --set type=NGINX

サンプル出力:

  NAME: wcp-domain-nginx
  LAST DEPLOYED: Fri Jul 24 09:34:03 2020
  NAMESPACE: wcpns
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None

  1. Oracle WebCenter Portalアプリケーションへのセキュア・アクセス(SSL)の場合は、証明書を作成してKubernetesシークレットを生成します:

      openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt -subj "/CN=*"
  kubectl -n wcpns create secret tls wcp-domain-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt

  2. SSL構成用にHelmを使用してingress-per-domainをインストールします:

      cd ${WORKDIR}
  helm install wcp-domain-nginx  charts/ingress-per-domain \
   --namespace wcpns \
   --values charts/ingress-per-domain/values.yaml \
   --set "nginx.hostname=$(hostname -f)" \
   --set type=NGINX --set sslType=SSL

  3. Oracle WebCenter Portalアプリケーションへの非SSLアクセスの場合は、イングレスによってサービスの詳細を取得します:

    kubectl describe ingress wcp-domain-nginx -n wcpns

    サンプル出力:

     Name:             wcp-domain-nginx
 Namespace:        wcpns
 Address:          10.101.123.106
 Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
 Rules:
   Host        Path  Backends
   ----        ----  --------
   *
               /webcenter   wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
               /console     wcp-domain-adminserver:7001 (10.244.0.51:7001)
               /rsscrawl    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.53:8888)
               /rest    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.53:8888)
               /webcenterhelp    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.53:8888)
               /wsrp-tools     wcp-domain-cluster-wcportlet-cluster:8889 (10.244.0.53:8889)
               /em          wcp-domain-adminserver:7001 (10.244.0.51:7001)
 Annotations:  meta.helm.sh/release-name: wcp-domain-nginx
               meta.helm.sh/release-namespace: wcpns
               nginx.com/sticky-cookie-services: serviceName=wcp-domain-cluster-wcp-cluster srv_id expires=1h path=/;
               nginx.ingress.kubernetes.io/proxy-connect-timeout: 1800
               nginx.ingress.kubernetes.io/proxy-read-timeout: 1800
               nginx.ingress.kubernetes.io/proxy-send-timeout: 1800
 Events:
   Type    Reason  Age                From                      Message
   ----    ------  ----               ----                      -------
   Normal  Sync    48m (x2 over 48m)  nginx-ingress-controller  Scheduled for sync

  4. Oracle WebCenter PortalアプリケーションへのSSLアクセスの場合は、前述のデプロイ済イングレスによってサービスの詳細を取得します:

    kubectl describe ingress wcp-domain-nginx -n wcpns

    サンプル出力:

    Name:             wcp-domain-nginx
Namespace:        wcpns
Address:          10.106.220.140
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  wcp-domain-tls-cert terminates mydomain.com
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /webcenter   wcp-domain-cluster-wcp-cluster:8888 (10.244.0.43:8888,10.244.0.44:8888)
              /console     wcp-domain-adminserver:7001 (10.244.0.42:7001)
              /rsscrawl    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.43:8888,10.244.0.44:8888)
              /webcenterhelp   wcp-domain-cluster-wcp-cluster:8888 (10.244.0.43:8888,10.244.0.44:8888)
              /rest     wcp-domain-cluster-wcp-cluster:8888 (10.244.0.43:8888,10.244.0.44:8888)
              /em          wcp-domain-adminserver:7001 (10.244.0.42:7001)
              /wsrp-tools     wcp-domain-cluster-wcportlet-cluster:8889 (10.244.0.43:8889,10.244.0.44:8889)
Annotations:  kubernetes.io/ingress.class: nginx
              meta.helm.sh/release-name: wcp-domain-nginx
              meta.helm.sh/release-namespace: wcpns
              nginx.ingress.kubernetes.io/affinity: cookie
              nginx.ingress.kubernetes.io/affinity-mode: persistent
              nginx.ingress.kubernetes.io/configuration-snippet:
                more_set_input_headers "X-Forwarded-Proto: https";
                more_set_input_headers "WL-Proxy-SSL: true";
              nginx.ingress.kubernetes.io/ingress.allow-http: false
              nginx.ingress.kubernetes.io/proxy-connect-timeout: 1800
              nginx.ingress.kubernetes.io/proxy-read-timeout: 1800
              nginx.ingress.kubernetes.io/proxy-send-timeout: 1800
              nginx.ingress.kubernetes.io/session-cookie-expires: 172800
              nginx.ingress.kubernetes.io/session-cookie-max-age: 172800
              nginx.ingress.kubernetes.io/session-cookie-name: stickyid
              nginx.ingress.kubernetes.io/ssl-redirect: false
Events:       <none>
非SSLおよびSSL終端アクセスの検証

Oracle WebCenter Portalドメイン・アプリケーションURLがnginx NodePort LOADBALANCER-NODEPORT 30305を介してアクセス可能であることを検証します:

  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/console
  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/em
  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/webcenter
  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/rsscrawl
  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/rest
  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/webcenterhelp
  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/wsrp-tools
イングレスのアンインストール

ingress-nginxデプロイメントをアンインストールして削除します:

 helm delete   wcp-domain-nginx -n wcpns
 helm delete nginx-ingress -n wcpns
エンドツーエンドSSL構成
エンドツーエンドSSLのNGINXロード・バランサのインストール

  1. Oracle WebCenter Portalアプリケーションへのセキュア・アクセス(SSL)の場合は、証明書を作成してシークレットを生成します:

     openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt -subj "/CN=domain1.org"
 kubectl -n wcpns create secret tls wcp-domain-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt

    ノート: CNの値は、このイングレスがデプロイされるホストです。

  2. ドメイン・ネームスペースでHelmを使用して、ingress-nginxコントローラをデプロイします:

     helm install nginx-ingress -n wcpns \
    --set controller.extraArgs.default-ssl-certificate=wcpns/wcp-domain-tls-cert \
    --set controller.service.type=NodePort \
    --set controller.admissionWebhooks.enabled=false \
    --set controller.extraArgs.enable-ssl-passthrough=true  \
    ingress-nginx/ingress-nginx

    サンプル出力:

      NAME: nginx-ingress
  LAST DEPLOYED: Tue Sep 15 08:40:47 2020
  NAMESPACE: wcpns
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None
  NOTES:
  The ingress-nginx controller has been installed.
  Get the application URL by running these commands:
  export HTTP_NODE_PORT=$(kubectl --namespace wcpns get services -o jsonpath="{.spec.ports[0].nodePort}" nginx-ingress-ingress-nginx-controller)
  export HTTPS_NODE_PORT=$(kubectl --namespace wcpns get services -o jsonpath="{.spec.ports[1].nodePort}" nginx-ingress-ingress-nginx-controller)
  export NODE_IP=$(kubectl --namespace wcpns get nodes -o jsonpath="{.items[0].status.addresses[1].address}")

  echo "Visit http://$NODE_IP:$HTTP_NODE_PORT to access your application via HTTP."
  echo "Visit https://$NODE_IP:$HTTPS_NODE_PORT to access your application via HTTPS."

  An example Ingress that makes use of the controller:

    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    metadata:
      annotations:
        kubernetes.io/ingress.class: nginx
      name: example
      namespace: foo
    spec:
      rules:
      - host: www.example.com
        http:
        paths:
          - backend:
            serviceName: exampleService
            servicePort: 80
          path: /
   # This section is only required if TLS is to be enabled for the Ingress
   tls:
    - hosts:
        - www.example.com
      secretName: example-tls

   If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:
  apiVersion: v1
  kind: Secret
  metadata:
    name: example-tls
    namespace: foo
  data:
   tls.crt: <base64 encoded cert>
   tls.key: <base64 encoded key>
  type: kubernetes.io/tls

  3. デプロイされたイングレス・コントローラのステータスを確認します:

     kubectl --namespace wcpns get services | grep ingress-nginx-controller

    サンプル出力:

      nginx-ingress-ingress-nginx-controller   NodePort    10.96.177.215    <none>        80:32748/TCP,443:31940/TCP   23s
サービスにアクセスするためのtlsのデプロイ

  1. tlsをデプロイしてサービスに安全にアクセスします。ssl-passthroughで構成できるアプリケーションは1つのみです。サービスwcp-domain-cluster-wcp-clusterおよびポート8889のNGINXのサンプルtlsファイルを次に示します。ポート8889で実行されているすべてのアプリケーションに、このイングレスを介して安全にアクセスできます。

  2. NGINXでは、注釈ssl-passthroughによる複数のパスまたはルールがサポートされていないため、バックエンド・サービスごとに異なるイングレスを作成します。たとえば、wcp-domain-adminserverおよびwcp-domain-cluster-wcp-clusterでは、異なるイングレスを作成する必要があります。

  3. NGINXのssl-passthroughは、個々のエンドポイントではなくバッキング・サービスのclusterIPで動作するため、clusterIPを使用してオペレータによって作成されたwcp-domain-cluster-wcp-clusterを公開する必要があります。

    例:

    1. wcp-domainクラスタ・サービスの名前を取得します:

       kubectl get svc  -n wcpns | grep  wcp-domain-cluster-wcp-cluster

      サンプル出力:

       wcp-domain-cluster-wcp-cluster           ClusterIP   10.102.128.124   <none>        8888/TCP,8889/TCP            62m

  4. 保護されたイングレスをデプロイします:

     cd ${WORKDIR}/charts/ingress-per-domain/tls
 kubectl create -f nginx-tls.yaml

    ノート: デフォルトのnginx-tls.yamlには、domainUID wcp-domainとともにWebCenter Portalサービスのバックエンドが含まれます。バックエンド・サービスごとに、同様のtls構成YAMLファイルを個別に作成する必要があります。

    nginx-tls.yamlファイルの内容:

    
     apiVersion: extensions/v1beta1
     kind: Ingress
     metadata:
       name: wcpns-ingress
       namespace: wcpns
       annotations:
         kubernetes.io/ingress.class: nginx
         nginx.ingress.kubernetes.io/ssl-passthrough: "true"
     spec:
       tls:
         - hosts:
             - domain1.org
           secretName: wcp-domain-tls-cert
       rules:
         - host: domain1.org
           http:
             paths:
               - path:
                 backend:
                   serviceName: wcp-domain-cluster-wcp-cluster
                   servicePort: 8889

    ノート: ホストは、このイングレスがデプロイされるサーバーです。

  5. イングレスでサポートされているサービスを確認します:

     kubectl describe ingress  wcpns-ingress -n wcpns
エンドツーエンドSSLアクセスの検証

Oracle WebCenter Portalドメイン・アプリケーションURLがLOADBALANCER-SSLPORT 30233を介してアクセス可能であることを検証します:

 https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenter
 https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/rsscrawl
 https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenterhelp
 https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/rest
 https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/wsrp-tools
ingress-nginx tlsのアンインストール
cd ${WORKDIR}/charts/ingress-per-domain/tls
kubectl  delete -f nginx-tls.yaml
helm delete nginx-ingress -n wcpns

Apache Web層

Oracle WebCenter PortalドメインのApache Web層ロード・バランサを構成します。

Oracle WebCenter Portalドメイン・クラスタをロード・バランシングするには、Apache Web層をインストールし、アプリケーションURLの非SSLおよびSSL終端アクセス用に構成します。次のステップに従って、Apache Web層をKubernetesクラスタ内のOracle WebCenter Portalドメインのロード・バランサとして設定します:

  1. Apache Web層イメージのビルド
  2. Apacheプラグイン構成ファイルの作成
  3. 証明書と秘密キーの準備
  4. Apache Web層Helmチャートのインストール
  5. ドメイン・アプリケーションURLアクセスの検証
  6. Apache Web層のアンインストール
Apache Web層イメージのビルド

Apache Web層Dockerイメージをビルドするには、サンプルを参照してください。

Apacheプラグイン構成ファイルの作成

  1. custom_mod_wl_apache.confという名前の構成ファイルには、外部からアクセスできる必要があるドメインにデプロイされたOracle WebCenter PortalアプリケーションのすべてのURLルーティング・ルールが必要です。このファイルを環境に基づいた値で更新します。ファイルの内容は次のようになります。

    wcp-domainドメインの構成ファイルcustom_mod_wl_apache.confのサンプル・コンテンツ:

    cat ${WORKDIR}/charts/apache-samples/custom-sample/custom_mod_wl_apache.conf

    サンプル出力:

    #Copyright (c) 2018 Oracle and/or its affiliates. All rights reserved.
#
# Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
#

<IfModule mod_weblogic.c>
WebLogicHost <WEBLOGIC_HOST>
WebLogicPort 7001
</IfModule>

# Directive for weblogic admin Console deployed on Weblogic Admin Server
<Location /console>
SetHandler weblogic-handler
WebLogicHost wcp-domain-adminserver
WebLogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost wcp-domain-adminserver
WebLogicPort 7001
</Location>

<Location /webcenter>
WLSRequest On
WebLogicCluster wcp-domain-cluster-wcp-cluster:8888
PathTrim /weblogic1
</Location>

<Location /rsscrawl>
WLSRequest On
WebLogicCluster wcp-domain-cluster-wcp-cluster:8888
PathTrim /weblogic1
</Location>  

<Location /rest>
WLSRequest On
WebLogicCluster wcp-domain-cluster-wcp-cluster:8888
PathTrim /weblogic1
</Location>

<Location /webcenterhelp>
WLSRequest On
WebLogicCluster wcp-domain-cluster-wcp-cluster:8888
PathTrim /weblogic1
</Location> 

<Location /wsrp-tools>
WLSRequest On
WebLogicCluster wcp-domain-cluster-wcportlet-cluster:8889
PathTrim /weblogic1
</Location>

  2. 独自のcustom_mod_wl_apache.confファイルを含む永続ボリュームを使用して、${WORKDIR}/charts/apache-samples/custom-sample/input.yamlのpersistentVolumeClaimNameを更新します。環境の準備時に作成したPV/PVCを使用して、custom_mod_wl_apache.confファイルを既存のPersistantVolumeにコピーします。

証明書と秘密キーの準備

  1. (SSL終端構成の場合のみ)次のコマンドを実行し、opensslを使用して独自の証明書と秘密キーを生成します。

     cd ${WORKDIR}/charts/apache-samples/custom-sample
 export VIRTUAL_HOST_NAME=WEBLOGIC_HOST
 export SSL_CERT_FILE=WEBLOGIC_HOST.crt
 export SSL_CERT_KEY_FILE=WEBLOGIC_HOST.key
 sh certgen.sh

    ノート: WEBLOGIC_HOSTは、Apache Web層がインストールされるホストの名前に置き換えます。

    証明書生成のサンプル出力:

     ls
 certgen.sh  custom_mod_wl_apache.conf  custom_mod_wl_apache.conf_orig  input.yaml  README.md

 sh certgen.sh

 Generating certs for WEBLOGIC_HOST
 Generating a 2048 bit RSA private key
 ........................+++
 .......................................................................+++
 unable to write 'random state'
 writing new private key to 'apache-sample.key'
 -----

 ls
 certgen.sh                 custom_mod_wl_apache.conf_orig                             WEBLOGIC_HOST.info
 config.txt                 input.yaml                                                 WEBLOGIC_HOST.key
 custom_mod_wl_apache.conf  WEBLOGIC_HOST.crt  README.md

  2. Apache Web層Helmチャートの入力値を準備します。

    次のコマンドを実行して、Apache Web層Helmチャートの入力値ファイルを準備します。

     base64 -i ${SSL_CERT_FILE} | tr -d '\n'
 base64 -i ${SSL_CERT_KEY_FILE} | tr -d '\n'
 touch input.yaml

    virtualHostNameを、${WORKDIR}/charts/apache-samples/custom-sample/input.yamlファイルのWEBLOGIC_HOSTの値で更新します

    サンプルinput.yamlファイルのスナップショット:

      cat apache-samples/custom-sample/input.yaml

  # Use this to provide your own Apache webtier configuration as needed; simply define this
  # path and put your own custom_mod_wl_apache.conf file under this path.
  persistentVolumeClaimName: wcp-domain-domain-pvc

  # The VirtualHostName of the Apache HTTP server. It is used to enable custom SSL configuration.
  virtualHostName: <WEBLOGIC_HOST>
Apache Web層Helmチャートのインストール

  1. 指定された入力パラメータを使用して、Apache Web層Helmチャートをドメインwcpnsネームスペースにインストールします:

    cd ${WORKDIR}/charts
kubectl create namespace apache-webtier
helm install  apache-webtier --values apache-samples/custom-sample/input.yaml --namespace wcpns apache-webtier --set image=oracle/apache:12.2.1.3

  2. Apache Web層のステータスを確認します:

     kubectl get all -n wcpns | grep apache

    Apache Web層のステータスのサンプル出力:

     pod/apache-webtier-apache-webtier-65f69dc6bc-zg5pj   1/1     Running     0          22h
 service/apache-webtier-apache-webtier   NodePort       10.108.29.98     <none>        80:30305/TCP,4433:30443/TCP   22h
 deployment.apps/apache-webtier-apache-webtier   1/1     1            1           22h
 replicaset.apps/apache-webtier-apache-webtier-65f69dc6bc   1         1         1       22h
ドメイン・アプリケーションURLアクセスの検証

Apache Web層ロード・バランサが起動したら、ロード・バランサ・ポート30305/30443を介してドメイン・アプリケーションにアクセスできることを検証します。タイプwcpのドメインのアプリケーションURLは、次のとおりです:

ノート: ポート30305はLOADBALANCER-Non-SSLPORTで、ポート30443はLOADBALANCER-SSLPORTです。

非SSL構成
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/console
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/em
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/webcenter
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/webcenterhelp
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/rest
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/rsscrawl
SSL構成
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenter
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/console
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/em
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/rsscrawl
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenterhelp
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/rest
Apache Web層のアンインストール
 helm delete apache-webtier -n wcpns

ドメインのモニターとログの公開

Oracle WebCenter Portalをモニターして、Elasticsearchにログを公開します。

ElasticsearchおよびKibanaのインストール

ElasticsearchおよびKibanaをインストールするには、次のコマンドを実行します:

cd ${WORKDIR}/elasticsearch-and-kibana
kubectl create -f elasticsearch_and_kibana.yaml

Elasticsearchへの公開

診断およびその他のログは、Logstashポッドを使用してElasticsearchサーバーにプッシュできます。Logstashポッドは、共有ドメイン・ホームまたはログの場所にアクセスできる必要があります。Oracle WebCenter Portalドメインの場合、ドメイン・ホームの永続ボリュームをLogstashポッドで使用できます。次のステップに従って、Logstashポッドを作成します:

  1. Oracle WebCenter Portalドメインのドメイン・ホーム永続ボリューム要求の詳細を取得します。次のコマンドは、ネームスペース(wcpns)の永続ボリューム要求の詳細をリストします。次の例では、永続ボリューム要求はwcp-domain-domain-pvcです。

     kubectl get pv -n wcpns

    サンプル出力:

      NAME                   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                         STORAGECLASS                      REASON   AGE
  wcp-domain-domain-pv   10Gi       RWX            Retain           Bound    wcpns/wcp-domain-domain-pvc   wcp-domain-domain-storage-class            175d

  2. logstash.confという名前のLogstash構成ファイルを作成します。サンプルのLogstash構成ファイルは、${WORKDIR}/logging-services/logstashにあります。次の構成では、診断およびすべてのドメイン・ログがプッシュされます。

    input {                                                                                                                
  file {
    path => "/u01/oracle/user_projects/domains/wcp-domain/servers/**/logs/*-diagnostic.log"
    start_position => beginning
  }
  file {
    path => "/u01/oracle/user_projects/domains/logs/wcp-domain/*.log"
    start_position => beginning
  }
}

filter {                                                                                                               
  grok {                                                                                                               
    match => [ "message", "<%{DATA:log_timestamp}> <%{WORD:log_level}> <%{WORD:thread}> <%{HOSTNAME:hostname}> <%{HOSTNAME:servername}> <%{DATA:timer}> <<%{DATA:kernel}>> <> <%{DATA:uuid}> <%{NUMBER:timestamp}> <%{DATA:misc}> <%{DATA:log_number}> <%{DATA:log_message}>" ]                                                                                        
  }                                                                                                                    
}                                                                                                                         
output {                                                                                                               
  elasticsearch {                                                                                                      
    hosts => ["elasticsearch.default.svc.cluster.local:9200"]
  }                                                                                                                    
}

  3. logstash.confファイルを/u01/oracle/user_projects/domainsにコピーして、Logstashデプロイメントで使用できるようにします。これは、管理サーバー・ポッド(たとえば、wcpnsネームスペースのwcp-domain-adminserverポッド)を使用して実行できます:

    kubectl cp ${WORKDIR}/logging-services/logstash/logstash.conf wcpns/wcp-domain-adminserver:/u01/oracle/user_projects/domains -n wcpns

  4. ドメイン・ホーム永続ボリューム要求を使用して、Logstashポッドのlogstash.yamlという名前のデプロイメントYAMLファイルを作成します。Logstash構成ファイルが正しい場所を指していることを確認し(たとえば、logstash.confを/u01/oracle/user_projects/domains/logstash.confにコピーします)、適切なドメイン・ホーム永続ボリューム要求を指定します。次に、サンプルのLogstashデプロイメントYAMLを示します:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: logstash
  namespace: wcpns
spec:
  selector:
    matchLabels:
      app: logstash
  template: 
    metadata:
      labels:
        app: logstash
    spec:
      volumes:
      - name: domain-storage-volume
        persistentVolumeClaim:
          claimName: wcp-domain-domain-pvc
      - name: shared-logs
        emptyDir: {}
      containers:
      - name: logstash
        image: logstash:6.6.0
        command: ["/bin/sh"]
        args: ["/usr/share/logstash/bin/logstash", "-f", "/u01/oracle/user_projects/domains/logstash.conf"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /u01/oracle/user_projects/domains
          name: domain-storage-volume
        - name: shared-logs
          mountPath: /shared-logs
        ports:
        - containerPort: 5044
          name: logstash

  5. Logstashをデプロイして、Elasticsearchへのログの公開を開始します:

     kubectl create -f ${WORKDIR}/logging-services/logstash/logstash.yaml

Kibanaでの索引パターンの作成

「Kibana」→「Management」で索引パターンlogstash*を作成するには、次のステップに従います。サーバーが起動すると、Kibanaダッシュボードにログ・データが反映されます:

WLS-Kibana-Dashboard

WebLogic Logging Exporterは、ログ・イベント・ハンドラをWebLogic Serverに追加し、Elasticsearch REST APIを使用してKubernetesのElasticsearchにログをプッシュできるようにします。詳細は、WebLogic Logging Exporterプロジェクトを参照してください。

このサンプルでは、WebLogic ServerログをElasticsearchに公開し、Kibanaで表示する方法を示します。オペレータ・ログの公開については、このサンプルを参照してください。

前提条件

このドキュメントでは、ログ収集用にElasticsearchおよびKibanaをすでに設定していることを前提としています。まだ行っていない場合は、このドキュメントを参照してください。

WebLogic Logging Exporterバイナリのダウンロード

事前ビルド済のバイナリは、WebLogic Logging Exporterのリリース・ページで入手できます。

ダウンロード:

サンプル・コマンドでは次の識別子が使用されます:

* `wcpns`: WebCenter Portal domain namespace
* `wcp-domain`: `domainUID`
* `wcp-domain-adminserver`: Administration Server pod name

WebLogicドメイン・ホームへのJARファイルのコピー

管理サーバー・ポッドのドメイン・ホーム・ディレクトリにweblogic-logging-exporter-1.0.0.jarおよびsnakeyaml-1.25.jarファイルをコピーします。

 kubectl cp <file-to-copy> <namespace>/<Administration-Server-pod>:<domainhome>
 kubectl cp snakeyaml-1.25.jar wcpns/wcp-domain-adminserver:/u01/oracle/user_projects/domains/wcp-domain/

 kubectl cp weblogic-logging-exporter-1.0.0.jar wcpns/wcp-domain-adminserver:/u01/oracle/user_projects/domains/wcp-domain/

ドメイン構成への起動クラスの追加

  1. WebLogic Server管理コンソールの左側のナビゲーション・ペインで、「環境」を展開して「起動クラスと停止クラス」を選択します。

  2. 新しい起動クラスを追加します。わかりやすい任意の名前を選択できますが、クラス名はweblogic.logging.exporter.Startupである必要があります。

    WLE-Startup-Shutdown-Class

  3. ログのエクスポート元となる各サーバーに起動クラスをターゲット指定します。

    WLE-Startup-Shutdown-Class-Targets

  4. 次に示すように、/u01/oracle/user_projects/domains/wcp-domain/config/config.xmlにあるconfig.xmlに、新しく追加されたstartup-classが存在する必要があります:

     kubectl exec -it wcp-domain-adminserver -n wcpns cat /u01/oracle/user_projects/domains/wcp-domain/config/config.xml
    <startup-class>
  <name>weblogic-logging-exporter</name>
  <target>AdminServer,wcp_cluster</target>
  <class-name>weblogic.logging.exporter.Startup</class-name>
</startup-class>

WebLogic Server CLASSPATHの更新

  1. setDomainEnv.shファイルをポッドからローカル・フォルダにコピーします:
 kubectl cp wcpns/wcp-domain-adminserver:/u01/oracle/user_projects/domains/wcp-domain/bin/setDomainEnv.sh $PWD/setDomainEnv.sh

 tar: Removing leading `/' from member names

例外を無視: tar: Removing leading '/' from member names

  1. setDomainEnv.shのサーバー・クラス・パスを更新します:

      CLASSPATH=/u01/oracle/user_projects/domains/wcp-domain/weblogic-logging-exporter-1.0.0.jar:/u01/oracle/user_projects/domains/wcp-domain/snakeyaml-1.25.jar:${CLASSPATH}
  export CLASSPATH

  2. 変更したsetDomainEnv.shファイルをポッドにコピーします:

     kubectl cp setDomainEnv.sh wcpns/wcp-domain-adminserver:/u01/oracle/user_projects/domains/wcp-domain/bin/setDomainEnv.sh

WebLogic Logging Exporterの構成ファイルの作成

  1. Elasticsearchサーバーのホストおよびポート番号を次のファイルに指定します: <$WORKDIR>/logging-services/weblogic-logging-exporter/WebLogicLoggingExporter.yaml

    例:

    weblogicLoggingIndexName: wls
publishHost: elasticsearch.default.svc.cluster.local
publishPort: 9300
domainUID: wcp-domain
weblogicLoggingExporterEnabled: true
weblogicLoggingExporterSeverity: TRACE
weblogicLoggingExporterBulkSize: 1

  2. WebLogicLoggingExporter.yamlファイルをWebLogic管理サーバー・ポッドのドメイン・ホーム・ディレクトリにコピーします:

     kubectl cp <$WORKDIR>/logging-services/weblogic-logging-exporter/WebLogicLoggingExporter.yaml wcpns/wcp-domain-adminserver:/u01/oracle/user_projects/domains/wcp-domain/config/

ドメイン内のサーバーの再起動

サーバーを再起動するには、次のコマンドを使用してサーバーを停止してから起動します:

サーバーを停止するには:

 kubectl patch domain wcp-domain -n wcpns --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "NEVER" }]'

サーバーを起動するには:

 kubectl patch domain wcp-domain -n wcpns --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IF_NEEDED" }]'

すべてのサーバーの再起動後、次に示すように、サーバー・ログを参照してweblogic-logging-exporterクラスがコールされていることを確認します:

======================= WebLogic Logging Exporter Startup class called                                                 
Reading configuration from file name: /u01/oracle/user_projects/domains/wcp-domain/config/WebLogicLoggingExporter.yaml   
Config{weblogicLoggingIndexName='wls', publishHost='domain.host.com', publishPort=9200, weblogicLoggingExporterSeverity='Notice', weblogicLoggingExporterBulkSize='2', enabled=true, weblogicLoggingExporterFilters=FilterConfig{expression='NOT(MSGID = 'BEA-000449')', servers=[]}], domainUID='wcp-domain'}

Kibanaでの索引パターンの作成

「Management」オプションを使用してダッシュボードに移動し、Kibanaで索引パターンwls*を作成します。サーバーが起動すると、Kibanaダッシュボードにログ・データが表示されます:

WLE-Kibana-Dashboard

概要

Fluentdを使用するようにWebLogicドメインを構成して、ログ情報をElasticsearchに送信できます。

次に、この仕組みを示します:

前提条件

既存のWebCenter Portalドメインを編集していることを前提としています。ただし、ドメインを作成する前に、ドメインYAMLに対するすべての変更を行うことができます。Fluentd構成を使用したドメイン定義の完全な例は、このドキュメントの最後にあります。

サンプル・コマンドでは次の識別子が使用されます:

サンプルのElasticsearch構成は次のとおりです:

    elasticsearchhost: elasticsearch.default.svc.cluster.local
    elasticsearchport: 9200
    elasticsearchuser: username
    elasticsearchpassword: password

Elasticsearchホストおよびポートは、ファイル${WORKDIR}/charts/weblogic-operator/values.yamlから参照できます

ElasticsearchおよびKibanaのインストール

ElasticsearchおよびKibanaをインストールするには、次のコマンドを実行します:

 cd ${WORKDIR}
 kubectl apply -f elasticsearch-and-kibana/elasticsearch_and_kibana.yaml

ボリュームを使用するためのログ・ファイルの構成

ドメイン・ログ・ファイルは、weblogic-serverとfluentdのコンテナ間で共有できるボリュームに書き込まれる必要があります。これを行うには次の要素が必要です:

ノート: 簡潔にするために、ここでは関連する構成へのパスのみを示します。

たとえば、kubectl edit domain wcp-domain -n wcpnsを実行して、次の編集を行います:

spec:
  logHome: /u01/oracle/user_projects/domains/logs/wcp-domain
  logHomeEnabled: true
  serverPod:
    volumes:
    - emptyDir: {}
      name: weblogic-domain-storage-volume
    volumeMounts:
    - mountPath: /scratch
      name: weblogic-domain-storage-volume

WebLogicドメイン資格証明へのElasticsearchシークレットの追加

fluentdコンテナを構成して、ドメイン資格証明でElasticsearchパラメータを検索します。ドメイン資格証明を編集し、次の例に示すパラメータを追加します。

たとえば、kubectl edit secret wcp-domain-domain-credentials -n wcpnsを実行して、各Elasticsearchパラメータのbase64エンコード値を追加します:

elasticsearchhost: ZWxhc3RpY3NlYXJjaC5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2Fs
elasticsearchport: OTIwMA==
elasticsearchuser: d2NjcmF3bGFkbWlu
elasticsearchpassword: d2VsY29tZTE=

Fluentd構成の作成

ドメインのネームスペースにfluentd-configという名前のConfigMapを作成します。ConfigMapには、解析ルールおよびElasticsearch構成が含まれます。

次に、ConfigMapに定義されているいくつかの要素の説明を示します:

次に、ConfigMapの作成方法の例を示します:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    weblogic.domainUID: wcp-domain
    weblogic.resourceVersion: domain-v2
  name: fluentd-config
  namespace: wcpns
data:
  fluentd.conf: |
    <match fluent.**>
      @type null
    </match>
    <source>
      @type tail
      path "#{ENV['LOG_PATH']}"
      pos_file /tmp/server.log.pos
      read_from_head true
      tag "#{ENV['DOMAIN_UID']}"
      # multiline_flush_interval 20s
      <parse>
        @type multiline
        format_firstline /^####/
        format1 /^####<(?<timestamp>(.*?))>/
        format2 / <(?<level>(.*?))>/
        format3 / <(?<subSystem>(.*?))>/
        format4 / <(?<serverName>(.*?))>/
        format5 / <(?<serverName2>(.*?))>/
        format6 / <(?<threadName>(.*?))>/
        format7 / <(?<info1>(.*?))>/
        format8 / <(?<info2>(.*?))>/
        format9 / <(?<info3>(.*?))>/
        format10 / <(?<sequenceNumber>(.*?))>/
        format11 / <(?<severity>(.*?))>/
        format12 / <(?<messageID>(.*?))>/
        format13 / <(?<message>(.*?))>/
      </parse>
    </source>
    <match **>
      @type elasticsearch
      host "#{ENV['ELASTICSEARCH_HOST']}"
      port "#{ENV['ELASTICSEARCH_PORT']}"
      user "#{ENV['ELASTICSEARCH_USER']}"
      password "#{ENV['ELASTICSEARCH_PASSWORD']}"
      index_name "#{ENV['DOMAIN_UID']}"
      scheme http
    </match>
EOF

weblogic-serverコンテナのボリュームとしてのConfigMapのマウント

ドメイン定義を編集し、fluentd構成を含むConfigMapのボリュームを構成します。

ノート: 簡潔にするために、関連する構成へのパスのみを示します。

たとえば、kubectl edit domain wcp-domain -n wcpnsを実行して、ドメイン定義に次の部分を追加します。

spec:
  serverPod:
    volumes:
    - configMap:
        defaultMode: 420
        name: fluentd-config
      name: fluentd-config-volume

fluentdコンテナの追加

ドメインにコンテナを追加して、管理サーバーおよび管理対象サーバーのポッドでfluentdを実行します。

コンテナ定義:

ノート: 簡潔にするために、関連する構成へのパスのみを示します。

たとえば、kubectl edit domain wcp-domain -n wcpcnsを実行して、次のコンテナ定義を追加します。

spec:
  serverPod:
    containers:
    - args:
      - -c
      - /etc/fluent.conf
      env:
      - name: DOMAIN_UID
        valueFrom:
          fieldRef:
            fieldPath: metadata.labels['weblogic.domainUID']
      - name: SERVER_NAME
        valueFrom:
          fieldRef:
            fieldPath: metadata.labels['weblogic.serverName']
      - name: LOG_PATH
        value: /u01/oracle/user_projects/domains/logs/wcp-domain/$(SERVER_NAME).log
      - name: FLUENTD_CONF
        value: fluentd.conf
      - name: FLUENT_ELASTICSEARCH_SED_DISABLE
        value: "true"
      - name: ELASTICSEARCH_HOST
        valueFrom:
          secretKeyRef:
            key: elasticsearchhost
            name: wcp-domain-domain-credentials
      - name: ELASTICSEARCH_PORT
        valueFrom:
          secretKeyRef:
            key: elasticsearchport
            name: wcp-domain-domain-credentials
      - name: ELASTICSEARCH_USER
        valueFrom:
          secretKeyRef:
            key: elasticsearchuser
            name: wcp-domain-domain-credentials
            optional: true
      - name: ELASTICSEARCH_PASSWORD
        valueFrom:
          secretKeyRef:
            key: elasticsearchpassword
            name: wcp-domain-domain-credentials
            optional: true
      image: fluent/fluentd-kubernetes-daemonset:v1.3.3-debian-elasticsearch-1.3
      imagePullPolicy: IfNotPresent
      name: fluentd
      resources: {}
      volumeMounts:
      - mountPath: /fluentd/etc/fluentd.conf
        name: fluentd-config-volume
        subPath: fluentd.conf
      - mountPath: /scratch
        name: weblogic-domain-storage-volume

Elasticsearchにエクスポートされたログの検証

前述の変更を行った後に管理サーバーおよび管理対象サーバーのポッドを起動すると、Elasticsearchにログが送信されます。

kubectl logs -f wcp-domain-adminserver -n wcpns fluentdなどのコマンドを実行すると、fluentdコンテナがログを正常に監視しているかどうかを確認できます。ログ出力は次のようになります:

2019-10-01 16:23:44 +0000 [info]: #0 starting fluentd worker pid=13 ppid=9 worker=0
2019-10-01 16:23:44 +0000 [warn]: #0 /scratch/logs/bobs-bookstore/managed-server1.log not found. Continuing without tailing it.
2019-10-01 16:23:44 +0000 [info]: #0 fluentd worker is now running worker=0
2019-10-01 16:24:01 +0000 [info]: #0 following tail of /scratch/logs/bobs-bookstore/managed-server1.log

Kibanaに接続すると、domainUIDに対して作成された索引が表示されます。

ドメインの例

次に、fluentdコンテナが構成されたドメイン・カスタム・リソースの完全な例を示します。

apiVersion: weblogic.oracle/v8
kind: Domain
metadata:
  labels:
    weblogic.domainUID: wcp-domain
  name: wcp-domain
  namespace: wcpns
spec:
  domainHome: /u01/oracle/user_projects/domains/wcp-domain
  domainHomeSourceType: PersistentVolume
  image: "oracle/wcportal:14.1.2.0"
  imagePullPolicy: "IfNotPresent"
  webLogicCredentialsSecret:
    name: wcp-domain-domain-credentials
  includeServerOutInPodLog: true
  logHomeEnabled: true 
  httpAccessLogInLogHome: true
  logHome: /u01/oracle/user_projects/domains/logs/wcp-domain
  dataHome: ""
  serverStartPolicy: "IF_NEEDED"
  adminServer:
    serverStartState: "RUNNING"
  clusters:
  - clusterName: wcp_cluster
    serverStartState: "RUNNING"
    serverPod:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"     
  replicas: 2
  serverPod:
    containers:
    - args:
      - -c
      - /etc/fluent.conf
      env:
      - name: DOMAIN_UID
        valueFrom:
          fieldRef:
            fieldPath: metadata.labels['weblogic.domainUID']
      - name: SERVER_NAME
        valueFrom:
          fieldRef:
            fieldPath: metadata.labels['weblogic.serverName']
      - name: LOG_PATH
        value: /u01/oracle/user_projects/domains/logs/wcp-domain/$(SERVER_NAME).log
      - name: FLUENTD_CONF
        value: fluentd.conf
      - name: FLUENT_ELASTICSEARCH_SED_DISABLE
        value: "true"
      - name: ELASTICSEARCH_HOST
        valueFrom:
          secretKeyRef:
            key: elasticsearchport
            name: wcp-domain-domain-credentials
      - name: ELASTICSEARCH_PORT
        valueFrom:
          secretKeyRef:
            key: elasticsearchhost
            name: wcp-domain-domain-credentials
      - name: ELASTICSEARCH_USER
        valueFrom:
          secretKeyRef:
            key: elasticsearchuser
            name: wcp-domain-domain-credentials
      - name: ELASTICSEARCH_PASSWORD
        valueFrom:
          secretKeyRef:
            key: elasticsearchpassword
            name: wcp-domain-domain-credentials
      image: fluent/fluentd-kubernetes-daemonset:v1.11.5-debian-elasticsearch6-1.0
      imagePullPolicy: IfNotPresent
      name: fluentd
      resources: {}
      volumeMounts:
      - mountPath: /fluentd/etc/fluentd.conf
        name: fluentd-config-volume
        subPath: fluentd.conf
      - mountPath: /u01/oracle/user_projects/domains
        name: weblogic-domain-storage-volume
    env:
    - name: JAVA_OPTIONS
      value: -Dweblogic.StdoutDebugEnabled=false
    - name: USER_MEM_ARGS
      value: '-Djava.security.egd=file:/dev/./urandom -Xms1g -Xmx2g'
    volumeMounts:
    - mountPath: /u01/oracle/user_projects/domains
      name: weblogic-domain-storage-volume
    volumes:
    - name: weblogic-domain-storage-volume
      persistentVolumeClaim:
        claimName: wcp-domain-domain-pvc 
    - emptyDir: {}
      name: weblogic-domain-storage-volume
    - configMap:
        defaultMode: 420
        name: fluentd-config
      name: fluentd-config-volume
  serverStartPolicy: IF_NEEDED
  webLogicCredentialsSecret:
    name: wcp-domain-domain-credentials
次に示すように、Kibanaダッシュボードのポート情報を取得します:
kubectl get pods -w

サンプル出力:

NAME                            READY   STATUS    RESTARTS   AGE
elasticsearch-8bdb7cf54-mjs6s   1/1     Running   0          4m3s
kibana-dbf8964b6-n8rcj          1/1     Running   0          4m3s
 kubectl get svc

サンプル出力:

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
elasticsearch   ClusterIP   10.100.11.154   <none>        9200/TCP,9300/TCP   4m32s
kibana          NodePort    10.97.205.0     <none>        5601:31884/TCP      4m32s
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP             71d

Kibanaダッシュボードにはhttp://mycompany.com:kibana-nodeport/でアクセスできます。この例では、ノード・ポートは31884です。

Kibanaでの索引パターンの作成

「Management」オプションを使用してダッシュボードに移動し、Kibanaで索引パターンwcp-domain*を作成します。サーバーが起動すると、Kibanaダッシュボードにログ・データが表示されます。

WCP-Kibana-Dashboard

イメージの作成または更新

WebLogic Image Toolを使用して、(バンドルまたは個別)パッチを含む本番デプロイメント用のOracle WebCenter Portalイメージをビルドできます。My Oracle Support (MOS)にアクセスして、(バンドルまたは個別)パッチをダウンロードする必要があります。

WebLogic Image Toolを使用したOracle WebCenter Portal Dockerイメージの作成または更新

WebLogic Image Toolを使用すると、新しいOracle WebCenter Portal Dockerイメージを作成したり(パッチを含めることも可能)、1つ以上のパッチ(バンドル・パッチおよび個別パッチ)で既存のイメージを更新したりできます。

推奨事項:

前提条件

環境が次の前提条件を満たしていることを確認します:

WebLogic Image Toolの設定

WebLogic Image Toolを設定するには:

  1. 作業ディレクトリを作成してそれに移動します。このステップでは、このディレクトリはimagetool-setupです。

    mkdir imagetool-setup
cd imagetool-setup

  2. リリース・ページから最新バージョンのWebLogic Image Toolをダウンロードします。

  3. リリースZIPファイルをimagetool-setupディレクトリに解凍します。

  4. 次のコマンドを実行して、Linux環境でWebLogic Image Toolを設定します:

    cd imagetool-setup/imagetool/bin
source setup.sh
設定の検証

WebLogic Image Toolの設定を検証するには:

  1. 次のコマンドを入力して、WebLogic Image Toolのバージョンを取得します:

    imagetool --version

  2. imagetoolと入力し、[Tab]キーを押して、使用可能なimagetoolコマンドを表示します:

    imagetool <TAB>

    サンプル出力:

    cache   create  help    rebase  update
WebLogic Image Toolビルド・ディレクトリ

WebLogic Image Toolは、実行されるたびに、wlsimgbuilder_tempという接頭辞が付いた一時的なDockerコンテキスト・ディレクトリを作成します。通常の状況では、このコンテキスト・ディレクトリは削除されます。ただし、プロセスが中断された場合や、ツールがディレクトリを削除できない場合は、手動で安全に削除できます。デフォルトでは、WebLogic Image Toolは、ユーザーのホーム・ディレクトリの下にDockerコンテキスト・ディレクトリを作成します。一時コンテキストに別のディレクトリを使用する場合は、環境変数WLSIMG_BLDDIRを設定します:

 export WLSIMG_BLDDIR="/path/to/buid/dir"
WebLogic Image Toolキャッシュ

WebLogic Image Toolは、ローカル・ファイル・キャッシュ・ストアを保持しています。このストアは、Java、WebLogic ServerインストーラおよびWebLogic Serverパッチが存在するローカル・ファイル・システム内の場所を参照するために使用されます。デフォルトでは、キャッシュ・ストアはユーザーの$HOME/cacheディレクトリにあります。このディレクトリでは、参照情報は.metadataファイルに格納されます。自動的にダウンロードされたすべてのパッチもこのディレクトリにあります。デフォルトのキャッシュ・ストアの場所を変更するには、環境変数WLSIMG_CACHEDIRを設定します:

 export WLSIMG_CACHEDIR="/path/to/cachedir"
追加のビルド・スクリプトの設定

WebLogic Image Toolを使用してOracle WebCenter Portal Dockerイメージを作成するには、Oracle WebCenter Portalドメイン用の追加のコンテナ・スクリプトが必要です。

  1. docker-imagesリポジトリをクローニングして、これらのスクリプトを設定します。このステップでは、このディレクトリはDOCKER_REPOです:

     cd imagetool-setup
 git clone https://github.com/oracle/docker-images.git

  2. 追加のWebLogic Image Toolビルド・ファイルを、オペレータ・ソース・リポジトリからimagetool-setupの場所にコピーします:

     mkdir -p imagetool-setup/docker-images/OracleWebCenterPortal/imagetool/14.1.2.0.0
 cd imagetool-setup/docker-images/OracleWebCenterPortal/imagetool/14.1.2.0.0
 cp -rf ${WORKDIR}/imagetool-scripts/* .

ノート: イメージを作成するには、次のステップに進みます。イメージを更新するには、「イメージの更新」を参照してください。

イメージの作成

WebLogic Image Toolの設定および必要なビルド・スクリプトの構成後、前述のようにWebLogic Image Toolを使用して新しいOracle WebCenter Portal Dockerイメージを作成します。

Oracle WebCenter Portalインストール・バイナリおよびパッチのダウンロード

Oracle Software Delivery Cloudから、次にリストされている必要なOracle WebCenter Portalインストール・バイナリおよびパッチをダウンロードし、任意のディレクトリに保存する必要があります。このステップでは、ディレクトリはdownload locationです。

リリース24.4.3に必要なインストール・バイナリおよびパッチは次のとおりです:

必要なビルド・ファイルの更新

コード・リポジトリの場所<imagetool-setup-location>/docker-images/OracleWebCenterPortal/imagetool/14.1.2.0.0にある次のファイルは、イメージの作成に使用されます:

  1. buildArgsファイルで、%DOCKER_REPO%のすべての出現箇所をdocker-imagesリポジトリの場所で更新します(これは<imagetool-setup-location>/docker-imagesの完全なパスです)。

    たとえば、次を更新します:

    %DOCKER_REPO%/OracleWebCenterPortal/imagetool/14.1.2.0.0/

    更新後:

    <imagetool-setup-location>/docker-images/OracleWebCenterPortal/imagetool/14.1.2.0.0/

  2. 同様に、プレースホルダ%JDK_VERSION%および%BUILDTAG%を適切な値で更新します。

  3. レスポンス・ファイル<imagetool-setup-location>/docker-images/OracleFMWInfrastructure/dockerfiles/14.1.2.0/install.fileを更新して、[GENERIC]セクションにパラメータINSTALL_TYPE="Fusion Middleware Infrastructure"を追加します。

イメージの作成

  1. JDKパッケージをWebLogic Image Toolキャッシュに追加します:

     imagetool cache addInstaller --type jdk --version 8u281 --path <download location>/jdk-8u281-linux-x64.tar.gz

  2. ダウンロードしたインストール・バイナリをWebLogic Image Toolキャッシュに追加します:

     imagetool cache addInstaller --type fmw --version 14.1.2.0.0 --path <download location>/fmw_14.1.2.0.0_infrastructure.jar

 imagetool cache addInstaller --type wcp --version 14.1.2.0.0 --path <download location>/fmw_14.1.2.0.0_wcportal.jar

  3. ダウンロードしたOPatchパッチをWebLogic Image Toolキャッシュに追加します:

     imagetool cache addEntry --key 28186730_13.9.4.2.5 --value <download location>/p28186730_139425_Generic.zip

  4. buildArgsファイルのcreateコマンドに、--opatchBugNumberフラグとOPatchパッチ・キーを追加します:

     --opatchBugNumber 28186730_13.9.4.2.5

  5. ダウンロードした製品パッチをWebLogic Image Toolキャッシュに追加します:

     imagetool cache addEntry --key 32253037_14.1.2.0.0 --value <download location>/p32253037_122140_Generic.zip
 imagetool cache addEntry --key 32124456_14.1.2.0.0 --value <download location>/p32124456_122140_Generic.zip   
 imagetool cache addEntry --key 32357288_14.1.2.0.0 --value <download location>/p32357288_122140_Generic.zip
 imagetool cache addEntry --key 32224021_14.1.2.0.0 --value <download location>/p32224021_122140_Generic.zip   
 imagetool cache addEntry --key 31666198_14.1.2.0.0 --value <download location>/p31666198_122140_Generic.zip    
 imagetool cache addEntry --key 31544353_14.1.2.0.0 --value <download location>/p31544353_122140_Linux-x86-64.zip   
 imagetool cache addEntry --key 31852495_14.1.2.0.0 --value <download location>/p31852495_122140_Generic.zip

  6. buildArgsファイルのcreateコマンドに、--patchesフラグと製品パッチ・キーを追加します。--patchesリストは、前述のimagetool cache addEntryコマンドで使用されたパッチ--key値のカンマ区切りコレクションである必要があります。

    キャッシュに追加された製品パッチのサンプルの--patchesリスト:

     --patches 32253037_14.1.2.0.0,32124456_14.1.2.0.0,32357288_14.1.2.0.0,32224021_14.1.2.0.0

    OPatchパッチおよび製品パッチを追加した後のbuildArgsファイルの例:

    create
--jdkVersion=8u281
--type wcp
--version=14.1.2.0.0
--tag=oracle/wcportal:14.1.2.0
--pull
--fromImage ghcr.io/oracle/oraclelinux:7-slim
--additionalBuildCommands <imagetool-setup-location>/docker-images/OracleWebCenterPortal/imagetool/14.1.2.0.0/additionalBuildCmds.txt
--additionalBuildFiles <imagetool-setup-location>/docker-images/OracleWebCenterPortal/dockerfiles/14.1.2.0/container-scripts
--opatchBugNumber 28186730_13.9.4.2.5
--patches 32253037_14.1.2.0.0,32124456_14.1.2.0.0,32357288_14.1.2.0.0,32224021_14.1.2.0.0,31666198_14.1.2.0.0,31544353_14.1.2.0.0,31852495_14.1.2.0.0
    ノート: buildArgsファイルで:
    • --jdkVersion値は、--type jdkのimagetool cache addInstallerコマンドで使用される--version値と一致する必要があります。
    • --version値は、--type wcpのimagetool cache addInstallerコマンドで使用される--version値と一致する必要があります。
    • --pullは、常に最新のベースLinuxイメージoraclelinux:7-slimをDockerレジストリからプルします。このフラグは、Linuxイメージoraclelinux:7-slimを使用する場合は削除できます。これは、WCPイメージが作成されたホストですでに使用可能です。

    WebLogic Image Toolのcreateコマンドで使用可能なオプションの完全なリストは、このページを参照してください。

  7. Oracle WebCenter Portalイメージを作成します:

     imagetool @<absolute path to buildargs file>

    ノート: 前述の例に示したように、buildargsファイルの絶対パスの前に@文字を付加してください。

    例:

     imagetool @<imagetool-setup-location>/docker-images/OracleWebCenterPortal/imagetool/14.1.2.0.0/buildArgs

    imagetoolコマンドで生成されたサンプルのDockerfile:

        ########## BEGIN DOCKERFILE ##########
    #
    # Copyright (c) 2019, 2021, Oracle and/or its affiliates.
    #
    # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
    #
    #
    FROM ghcr.io/oracle/oraclelinux:7-slim as os_update
    LABEL com.oracle.weblogic.imagetool.buildid="dabe3ff7-ec35-4b8d-b62a-c3c02fed5571"
    USER root

    RUN yum -y --downloaddir=/tmp/imagetool install gzip tar unzip libaio jq hostname procps sudo zip  \
     && yum -y --downloaddir=/tmp/imagetool clean all \
     && rm -rf /var/cache/yum/* \
     && rm -rf /tmp/imagetool

    ## Create user and group
    RUN if [ -z "$(getent group oracle)" ]; then hash groupadd &> /dev/null && groupadd oracle || exit -1 ; fi \
     && if [ -z "$(getent passwd oracle)" ]; then hash useradd &> /dev/null && useradd -g oracle oracle || exit -1; fi \
     && mkdir -p /u01 \
     && chown oracle:oracle /u01 \
     && chmod 775 /u01

    # Install Java
    FROM os_update as jdk_build
    LABEL com.oracle.weblogic.imagetool.buildid="dabe3ff7-ec35-4b8d-b62a-c3c02fed5571"

    ENV JAVA_HOME=/u01/jdk

    COPY --chown=oracle:oracle jdk-8u251-linux-x64.tar.gz /tmp/imagetool/

    USER oracle


    RUN tar xzf /tmp/imagetool/jdk-8u251-linux-x64.tar.gz -C /u01 \
     && $(test -d /u01/jdk* && mv /u01/jdk* /u01/jdk || mv /u01/graal* /u01/jdk) \
     && rm -rf /tmp/imagetool \
     && rm -f /u01/jdk/javafx-src.zip /u01/jdk/src.zip


    # Install Middleware
    FROM os_update as wls_build
    LABEL com.oracle.weblogic.imagetool.buildid="dabe3ff7-ec35-4b8d-b62a-c3c02fed5571"

    ENV JAVA_HOME=/u01/jdk \
        ORACLE_HOME=/u01/oracle \
        OPATCH_NO_FUSER=true

    RUN mkdir -p /u01/oracle \
     && mkdir -p /u01/oracle/oraInventory \
     && chown oracle:oracle /u01/oracle/oraInventory \
     && chown oracle:oracle /u01/oracle

    COPY --from=jdk_build --chown=oracle:oracle /u01/jdk /u01/jdk/

    COPY --chown=oracle:oracle fmw_14.1.2.0.0_infrastructure.jar fmw.rsp /tmp/imagetool/
    COPY --chown=oracle:oracle fmw_14.1.2.0.0_wcportal.jar wcp.rsp /tmp/imagetool/
    COPY --chown=oracle:oracle oraInst.loc /u01/oracle/

        COPY --chown=oracle:oracle p28186730_139425_Generic.zip /tmp/imagetool/opatch/

        COPY --chown=oracle:oracle patches/* /tmp/imagetool/patches/

    USER oracle


    RUN echo "INSTALLING MIDDLEWARE" \
     && echo "INSTALLING fmw" \
     &&  \
        /u01/jdk/bin/java -Xmx1024m -jar /tmp/imagetool/fmw_14.1.2.0.0_infrastructure.jar -silent ORACLE_HOME=/u01/oracle \
        -responseFile /tmp/imagetool/fmw.rsp -invPtrLoc /u01/oracle/oraInst.loc -ignoreSysPrereqs -force -novalidation \
     && echo "INSTALLING wcp" \
     &&  \
        /u01/jdk/bin/java -Xmx1024m -jar /tmp/imagetool/fmw_14.1.2.0.0_wcportal.jar -silent ORACLE_HOME=/u01/oracle \
        -responseFile /tmp/imagetool/wcp.rsp -invPtrLoc /u01/oracle/oraInst.loc -ignoreSysPrereqs -force -novalidation \
     && chmod -R g+r /u01/oracle

    RUN cd /tmp/imagetool/opatch \
     && /u01/jdk/bin/jar -xf /tmp/imagetool/opatch/p28186730_139425_Generic.zip \
     && /u01/jdk/bin/java -jar /tmp/imagetool/opatch/6880880/opatch_generic.jar -silent -ignoreSysPrereqs -force -novalidation oracle_home=/u01/oracle

            # Apply all patches provided at the same time
            RUN /u01/oracle/OPatch/opatch napply -silent -oh /u01/oracle -phBaseDir /tmp/imagetool/patches \
            && test $? -eq 0 \
            && /u01/oracle/OPatch/opatch util cleanup -silent -oh /u01/oracle \
            || (cat /u01/oracle/cfgtoollogs/opatch/opatch*.log && exit 1)



    FROM os_update as final_build

    ARG ADMIN_NAME
    ARG ADMIN_HOST
    ARG ADMIN_PORT
    ARG MANAGED_SERVER_PORT

    ENV ORACLE_HOME=/u01/oracle \
        JAVA_HOME=/u01/jdk \
        PATH=${PATH}:/u01/jdk/bin:/u01/oracle/oracle_common/common/bin:/u01/oracle/wlserver/common/bin:/u01/oracle

    LABEL com.oracle.weblogic.imagetool.buildid="dabe3ff7-ec35-4b8d-b62a-c3c02fed5571"

        COPY --from=jdk_build --chown=oracle:oracle /u01/jdk /u01/jdk/

    COPY --from=wls_build --chown=oracle:oracle /u01/oracle /u01/oracle/



    USER oracle
    WORKDIR /u01/oracle

    #ENTRYPOINT /bin/bash


        ENV ORACLE_HOME=/u01/oracle \
            SCRIPT_FILE=/u01/oracle/container-scripts/* \
            USER_MEM_ARGS="-Djava.security.egd=file:/dev/./urandom" \
            PATH=$PATH:/usr/java/default/bin:/u01/oracle/oracle_common/common/bin:/u01/oracle/wlserver/common/bin:/u01/oracle/container-scripts

        USER root

        RUN env && \
            mkdir -p /u01/oracle/container-scripts && \
            mkdir -p /u01/oracle/logs && \
            mkdir -p /u01/esHome/esNode && \
            chown oracle:oracle -R /u01 $VOLUME_DIR && \
            chmod a+xr /u01

        COPY --chown=oracle:oracle files/container-scripts/ /u01/oracle/container-scripts/
        RUN chmod +xr $SCRIPT_FILE && \
            rm /u01/oracle/oracle_common/lib/ons.jar /u01/oracle/oracle_common/modules/oracle.jdbc/simplefan.jar

        USER oracle
        EXPOSE $WCPORTAL_PORT $ADMIN_PORT

        WORKDIR ${ORACLE_HOME}
        CMD ["/u01/oracle/container-scripts/configureOrStartAdminServer.sh"]



    ########## END DOCKERFILE ##########

  8. docker imagesコマンドを使用して、作成したイメージを確認します:

      docker images | grep wcportal

イメージの更新

WebLogic Image Toolの設定およびビルド・スクリプトの構成後、WebLogic Image Toolを使用して既存のOracle WebCenter Portal Dockerイメージを更新します:

  1. 次のコマンドを入力して、OPatchパッチをWebLogic Image Toolキャッシュに追加します:

     imagetool cache addEntry --key 28186730_13.9.4.2.5 --value <downloaded-patches-location>/p28186730_139425_Generic.zip

  2. パッチごとにimagetool cache addEntryコマンドを実行して、必要なパッチをWebLogic Image Toolキャッシュに追加します。たとえば、パッチp30761841_122140_Generic.zipを追加するには:

     imagetool cache addEntry --key=32224021_14.1.2.0.0 --value <downloaded-patches-location>/p32224021_122140_Generic.zip

  3. WebLogic Image Toolのupdateコマンドに次の引数を指定します:

    • –-fromImage - 更新される必要があるイメージを識別します。次の例では、更新されるイメージはoracle/wcportal:14.1.2.0です。
    • –-patches - 複数のパッチをカンマ区切りリストとして指定できます。
    • --tag - ビルドするイメージに適用する新しいタグを指定します。

    WebLogic Image Toolのupdateコマンドで使用可能なオプションの完全なリストは、ここを参照してください。

    ノート: WebLogic Image Toolキャッシュには、最新のOPatch zipが必要です。WebLogic Image Toolは、OPatchがイメージでまだ更新されていない場合は更新します。

例

updateコマンドの例:

      imagetool update --fromImage oracle/wcportal:14.1.2.0 --tag=wcportal:14.1.2.0-32224021 --patches=32224021_14.1.2.0.0

      [INFO   ] Image Tool build ID: 50f9b9aa-596c-4bae-bdff-c47c16b4c928
      [INFO   ] Temporary directory used for docker build context: /scratch/imagetoolcache/builddir/wlsimgbuilder_temp5130105621506307568
      [INFO   ] Using patch 28186730_13.9.4.2.5 from cache: /home/imagetool-setup/jars/p28186730_139425_Generic.zip
      [INFO   ] Updating OPatch in final image from version 13.9.4.2.1 to version 13.9.4.2.5
      [WARNING] Skipping patch conflict check, no support credentials provided
      [WARNING] No credentials provided, skipping validation of patches
      [INFO   ] Using patch 32224021_14.1.2.0 from cache: /home/imagetool-setup/jars/p32224021_122140_Generic.zip
      [INFO   ] docker cmd = docker build --no-cache --force-rm --tag wcportal:14.1.2.0-32224021 --build-arg http_proxy=http://<YOUR-COMPANY-PROXY> --build-arg https_proxy=http://<YOUR-COMPANY-PROXY> --build-arg no_proxy=<IP addresses and Domain address for no_proxy>,/var/run/docker.sock <work-directory>/wlstmp/wlsimgbuilder_temp5130105621506307568
      Sending build context to Docker daemon  192.4MB
      
      Step 1/9 : FROM oracle/wcportal:14.1.2.0 as final_build
       ---> 5592ff7e5a02
      Step 2/9 : USER root
       ---> Running in 0b3ff2600f11
      Removing intermediate container 0b3ff2600f11
       ---> faad3a32f39c
      Step 3/9 : ENV OPATCH_NO_FUSER=true
       ---> Running in 2beab0bfe88b
      Removing intermediate container 2beab0bfe88b
       ---> 6fd9e1664818
      Step 4/9 : LABEL com.oracle.weblogic.imagetool.buildid="50f9b9aa-596c-4bae-bdff-c47c16b4c928"
       ---> Running in 9a5f8fc172c9
      Removing intermediate container 9a5f8fc172c9
       ---> 499620a1f857
      Step 5/9 : USER oracle
       ---> Running in fe28af056858
      Removing intermediate container fe28af056858
       ---> 3507971c35d5
      Step 6/9 : COPY --chown=oracle:oracle p28186730_139425_Generic.zip /tmp/imagetool/opatch/
       ---> c44c3c7b17f7
      Step 7/9 : RUN cd /tmp/imagetool/opatch     && /u01/jdk/bin/jar -xf /tmp/imagetool/opatch/p28186730_139425_Generic.zip     && /u01/jdk/bin/java -jar /tmp/imagetool/opatch/6880880/opatch_generic.jar -silent -ignoreSysPrereqs -force -novalidation oracle_home=/u01/oracle     && rm -rf /tmp/imagetool
       ---> Running in 8380260fe62d
      Launcher log file is /tmp/OraInstall2021-04-08_05-18-14AM/launcher2021-04-08_05-18-14AM.log.
      Extracting the installer . . . . Done
      Checking if CPU speed is above 300 MHz.   Actual 2195.098 MHz    Passed
      Checking swap space: must be greater than 512 MB.   Actual 14999 MB    Passed
      Checking if this platform requires a 64-bit JVM.   Actual 64    Passed (64-bit not required)
      Checking temp space: must be greater than 300 MB.   Actual 152772 MB    Passed
      Preparing to launch the Oracle Universal Installer from /tmp/OraInstall2021-04-08_05-18-14AM
      Installation Summary
      
      
      Disk Space : Required 34 MB, Available 152,736 MB
      Feature Sets to Install:
              Next Generation Install Core 13.9.4.0.1
              OPatch 13.9.4.2.5
              OPatch Auto OPlan 13.9.4.2.5
      Session log file is /tmp/OraInstall2021-04-08_05-18-14AM/install2021-04-08_05-18-14AM.log
      
      Loading products list. Please wait.
       1%
       40%
      
      Loading products. Please wait.
       
       98%
       99%
      
      Updating Libraries
      
      Starting Installations
       1%
       94%
       95%
       96%
      
      Install pending
      
      Installation in progress
      
       Component : oracle.glcm.logging 1.6.4.0.0
      
      Copying files for oracle.glcm.logging 1.6.4.0.0
      
       Component : oracle.glcm.comdev 7.8.4.0.0
      
      Copying files for oracle.glcm.comdev 7.8.4.0.0
      
       Component : oracle.glcm.dependency 1.8.4.0.0
      
      Copying files for oracle.glcm.dependency 1.8.4.0.0
      
       Component : oracle.glcm.xmldh 3.4.4.0.0
      
      Copying files for oracle.glcm.xmldh 3.4.4.0.0
      
       Component : oracle.glcm.wizard 7.8.4.0.0
      
      Copying files for oracle.glcm.wizard 7.8.4.0.0
      
       Component : oracle.glcm.opatch.common.api 13.9.4.0.0
      
      Copying files for oracle.glcm.opatch.common.api 13.9.4.0.0
      
       Component : oracle.nginst.common 13.9.4.0.0
      
      Copying files for oracle.nginst.common 13.9.4.0.0
      
       Component : oracle.nginst.core 13.9.4.0.0
      
      Copying files for oracle.nginst.core 13.9.4.0.0
      
       Component : oracle.glcm.encryption 2.7.4.0.0
      
      Copying files for oracle.glcm.encryption 2.7.4.0.0
      
       Component : oracle.swd.opatch 13.9.4.2.5
      
      Copying files for oracle.swd.opatch 13.9.4.2.5
      
       Component : oracle.glcm.osys.core 13.9.1.0.0
      
      Copying files for oracle.glcm.osys.core 13.9.1.0.0
      
       Component : oracle.glcm.oplan.core 13.9.4.2.0
      
      Copying files for oracle.glcm.oplan.core 13.9.4.2.0
      
      Install successful
      
      Post feature install pending
      
      Post Feature installing
      
       Feature Set : glcm_common_lib
      
       Feature Set : glcm_common_logging_lib
      
      Post Feature installing glcm_common_lib
      
      Post Feature installing glcm_common_logging_lib
      
       Feature Set : commons-cli_1.3.1.0.0
      
      Post Feature installing commons-cli_1.3.1.0.0
      
       Feature Set : oracle.glcm.opatch.common.api.classpath
      
      Post Feature installing oracle.glcm.opatch.common.api.classpath
      
       Feature Set : glcm_encryption_lib
      
      Post Feature installing glcm_encryption_lib
      
       Feature Set : oracle.glcm.osys.core.classpath
      
      Post Feature installing oracle.glcm.osys.core.classpath
      
       Feature Set : oracle.glcm.oplan.core.classpath
      
      Post Feature installing oracle.glcm.oplan.core.classpath
      
       Feature Set : oracle.glcm.opatchauto.core.classpath
      
      Post Feature installing oracle.glcm.opatchauto.core.classpath
      
       Feature Set : oracle.glcm.opatchauto.core.binary.classpath
      
      Post Feature installing oracle.glcm.opatchauto.core.binary.classpath
      
       Feature Set : oracle.glcm.opatchauto.core.actions.classpath
      
      Post Feature installing oracle.glcm.opatchauto.core.actions.classpath
      
       Feature Set : oracle.glcm.opatchauto.core.wallet.classpath
      
      Post Feature installing oracle.glcm.opatchauto.core.wallet.classpath
      
      Post feature install complete
      
      String substitutions pending
      
      String substituting
      
       Component : oracle.glcm.logging 1.6.4.0.0
      
      String substituting oracle.glcm.logging 1.6.4.0.0
      
       Component : oracle.glcm.comdev 7.8.4.0.0
      
      String substituting oracle.glcm.comdev 7.8.4.0.0
      
       Component : oracle.glcm.dependency 1.8.4.0.0
      
      String substituting oracle.glcm.dependency 1.8.4.0.0
      
       Component : oracle.glcm.xmldh 3.4.4.0.0
      
      String substituting oracle.glcm.xmldh 3.4.4.0.0
      
       Component : oracle.glcm.wizard 7.8.4.0.0
      
      String substituting oracle.glcm.wizard 7.8.4.0.0
      
       Component : oracle.glcm.opatch.common.api 13.9.4.0.0
      
      String substituting oracle.glcm.opatch.common.api 13.9.4.0.0
      
       Component : oracle.nginst.common 13.9.4.0.0
      
      String substituting oracle.nginst.common 13.9.4.0.0
      
       Component : oracle.nginst.core 13.9.4.0.0
      
      String substituting oracle.nginst.core 13.9.4.0.0
      
       Component : oracle.glcm.encryption 2.7.4.0.0
      
      String substituting oracle.glcm.encryption 2.7.4.0.0
      
       Component : oracle.swd.opatch 13.9.4.2.5
      
      String substituting oracle.swd.opatch 13.9.4.2.5
      
       Component : oracle.glcm.osys.core 13.9.1.0.0
      
      String substituting oracle.glcm.osys.core 13.9.1.0.0
      
       Component : oracle.glcm.oplan.core 13.9.4.2.0
      
      String substituting oracle.glcm.oplan.core 13.9.4.2.0
      
      String substitutions complete
      
      Link pending
      
      Linking in progress
      
       Component : oracle.glcm.logging 1.6.4.0.0
      
      Linking oracle.glcm.logging 1.6.4.0.0
      
       Component : oracle.glcm.comdev 7.8.4.0.0
      
      Linking oracle.glcm.comdev 7.8.4.0.0
      
       Component : oracle.glcm.dependency 1.8.4.0.0
      
      Linking oracle.glcm.dependency 1.8.4.0.0
      
       Component : oracle.glcm.xmldh 3.4.4.0.0
      
      Linking oracle.glcm.xmldh 3.4.4.0.0
      
       Component : oracle.glcm.wizard 7.8.4.0.0
      
      Linking oracle.glcm.wizard 7.8.4.0.0
      
       Component : oracle.glcm.opatch.common.api 13.9.4.0.0
      
      Linking oracle.glcm.opatch.common.api 13.9.4.0.0
      
       Component : oracle.nginst.common 13.9.4.0.0
      
      Linking oracle.nginst.common 13.9.4.0.0
      
       Component : oracle.nginst.core 13.9.4.0.0
      
      Linking oracle.nginst.core 13.9.4.0.0
      
       Component : oracle.glcm.encryption 2.7.4.0.0
      
      Linking oracle.glcm.encryption 2.7.4.0.0
      
       Component : oracle.swd.opatch 13.9.4.2.5
      
      Linking oracle.swd.opatch 13.9.4.2.5
      
       Component : oracle.glcm.osys.core 13.9.1.0.0
      
      Linking oracle.glcm.osys.core 13.9.1.0.0
      
       Component : oracle.glcm.oplan.core 13.9.4.2.0
      
      Linking oracle.glcm.oplan.core 13.9.4.2.0
      
      Linking in progress
      
      Link successful
      
      Setup pending
      
      Setup in progress
      
       Component : oracle.glcm.logging 1.6.4.0.0
      
      Setting up oracle.glcm.logging 1.6.4.0.0
      
       Component : oracle.glcm.comdev 7.8.4.0.0
      
      Setting up oracle.glcm.comdev 7.8.4.0.0
      
       Component : oracle.glcm.dependency 1.8.4.0.0
      
      Setting up oracle.glcm.dependency 1.8.4.0.0
      
       Component : oracle.glcm.xmldh 3.4.4.0.0
      
      Setting up oracle.glcm.xmldh 3.4.4.0.0
      
       Component : oracle.glcm.wizard 7.8.4.0.0
      
      Setting up oracle.glcm.wizard 7.8.4.0.0
      
       Component : oracle.glcm.opatch.common.api 13.9.4.0.0
      
      Setting up oracle.glcm.opatch.common.api 13.9.4.0.0
      
       Component : oracle.nginst.common 13.9.4.0.0
      
      Setting up oracle.nginst.common 13.9.4.0.0
      
       Component : oracle.nginst.core 13.9.4.0.0
      
      Setting up oracle.nginst.core 13.9.4.0.0
      
       Component : oracle.glcm.encryption 2.7.4.0.0
      
      Setting up oracle.glcm.encryption 2.7.4.0.0
      
       Component : oracle.swd.opatch 13.9.4.2.5
      
      Setting up oracle.swd.opatch 13.9.4.2.5
      
       Component : oracle.glcm.osys.core 13.9.1.0.0
      
      Setting up oracle.glcm.osys.core 13.9.1.0.0
      
       Component : oracle.glcm.oplan.core 13.9.4.2.0
      
      Setting up oracle.glcm.oplan.core 13.9.4.2.0
      
      Setup successful
      
      Save inventory pending
      
      Saving inventory
       97%
      
      Saving inventory complete
       98%
      
      Configuration complete
      
       Component : glcm_common_logging_lib
      
      Saving the inventory glcm_common_logging_lib
      
       Component : glcm_encryption_lib
      
       Component : oracle.glcm.opatch.common.api.classpath
      
      Saving the inventory oracle.glcm.opatch.common.api.classpath
      
      Saving the inventory glcm_encryption_lib
      
       Component : cieCfg_common_rcu_lib
      
       Component : glcm_common_lib
      
      Saving the inventory cieCfg_common_rcu_lib
      
      Saving the inventory glcm_common_lib
      
       Component : oracle.glcm.logging
      
      Saving the inventory oracle.glcm.logging
      
       Component : cieCfg_common_lib
      
      Saving the inventory cieCfg_common_lib
      
       Component : svctbl_lib
      
      Saving the inventory svctbl_lib
      
       Component : com.bea.core.binxml_dependencies
      
      Saving the inventory com.bea.core.binxml_dependencies
      
       Component : svctbl_jmx_client
      
      Saving the inventory svctbl_jmx_client
      
       Component : cieCfg_wls_shared_lib
      
      Saving the inventory cieCfg_wls_shared_lib
      
       Component : rcuapi_lib
      
      Saving the inventory rcuapi_lib
      
       Component : rcu_core_lib
      
      Saving the inventory rcu_core_lib
      
       Component : cieCfg_wls_lib
      
      Saving the inventory cieCfg_wls_lib
      
       Component : cieCfg_wls_external_lib
      
      Saving the inventory cieCfg_wls_external_lib
      
       Component : cieCfg_wls_impl_lib
      
      Saving the inventory cieCfg_wls_impl_lib
      
       Component : rcu_dependencies_lib
      
      Saving the inventory rcu_dependencies_lib
      
       Component : oracle.fmwplatform.fmwprov_lib
      
      Saving the inventory oracle.fmwplatform.fmwprov_lib
      
       Component : fmwplatform-wlst-dependencies
      
      Saving the inventory fmwplatform-wlst-dependencies
      
       Component : oracle.fmwplatform.ocp_lib
      
      Saving the inventory oracle.fmwplatform.ocp_lib
      
       Component : oracle.fmwplatform.ocp_plugin_lib
      
      Saving the inventory oracle.fmwplatform.ocp_plugin_lib
      
       Component : wlst.wls.classpath
      
      Saving the inventory wlst.wls.classpath
      
       Component : maven.wls.classpath
      
      Saving the inventory maven.wls.classpath
      
       Component : com.oracle.webservices.fmw.ws-assembler
      
      Saving the inventory com.oracle.webservices.fmw.ws-assembler
      
       Component : sdpmessaging_dependencies
      
      Saving the inventory sdpmessaging_dependencies
      
       Component : sdpclient_dependencies
      
      Saving the inventory sdpclient_dependencies
      
       Component : com.oracle.jersey.fmw.client
      
      Saving the inventory com.oracle.jersey.fmw.client
      
       Component : com.oracle.webservices.fmw.client
      
      Saving the inventory com.oracle.webservices.fmw.client
      
       Component : oracle.jrf.wls.classpath
      
      Saving the inventory oracle.jrf.wls.classpath
      
       Component : oracle.jrf.wlst
      
      Saving the inventory oracle.jrf.wlst
      
       Component : fmwshare-wlst-dependencies
      
      Saving the inventory fmwshare-wlst-dependencies
      
       Component : oracle.fmwshare.pyjar
      
      Saving the inventory oracle.fmwshare.pyjar
      
       Component : com.oracle.webservices.wls.jaxws-owsm-client
      
      Saving the inventory com.oracle.webservices.wls.jaxws-owsm-client
      
       Component : glcm_common_logging_lib
      
       Component : glcm_common_lib
      
      Saving the inventory glcm_common_lib
      
       Component : glcm_encryption_lib
      
      Saving the inventory glcm_encryption_lib
      
       Component : oracle.glcm.opatch.common.api.classpath
      
      Saving the inventory oracle.glcm.opatch.common.api.classpath
      
       Component : cieCfg_common_rcu_lib
      
      Saving the inventory cieCfg_common_rcu_lib
      
      Saving the inventory glcm_common_logging_lib
      
       Component : oracle.glcm.logging
      
      Saving the inventory oracle.glcm.logging
      
       Component : cieCfg_common_lib
      
      Saving the inventory cieCfg_common_lib
      
       Component : svctbl_lib
      
      Saving the inventory svctbl_lib
      
       Component : com.bea.core.binxml_dependencies
      
      Saving the inventory com.bea.core.binxml_dependencies
      
       Component : svctbl_jmx_client
      
      Saving the inventory svctbl_jmx_client
      
       Component : cieCfg_wls_shared_lib
      
      Saving the inventory cieCfg_wls_shared_lib
      
       Component : rcuapi_lib
      
      Saving the inventory rcuapi_lib
      
       Component : rcu_core_lib
      
      Saving the inventory rcu_core_lib
      
       Component : cieCfg_wls_lib
      
      Saving the inventory cieCfg_wls_lib
      
       Component : cieCfg_wls_external_lib
      
      Saving the inventory cieCfg_wls_external_lib
      
       Component : cieCfg_wls_impl_lib
      
      Saving the inventory cieCfg_wls_impl_lib
      
       Component : soa_com.bea.core.binxml_dependencies
      
      Saving the inventory soa_com.bea.core.binxml_dependencies
      
       Component : glcm_common_logging_lib
      
      Saving the inventory glcm_common_logging_lib
      
       Component : glcm_common_lib
      
      Saving the inventory glcm_common_lib
      
       Component : glcm_encryption_lib
      
      Saving the inventory glcm_encryption_lib
      
       Component : oracle.glcm.opatch.common.api.classpath
      
       Component : oracle.glcm.oplan.core.classpath
      
      Saving the inventory oracle.glcm.oplan.core.classpath
      
      Saving the inventory oracle.glcm.opatch.common.api.classpath
      
      The install operation completed successfully.
      
      Logs successfully copied to /u01/oracle/.inventory/logs.
      Removing intermediate container 8380260fe62d
       ---> d57be7ffa162
      Step 8/9 : COPY --chown=oracle:oracle patches/* /tmp/imagetool/patches/
       ---> dd421aae5aaf
      Step 9/9 : RUN /u01/oracle/OPatch/opatch napply -silent -oh /u01/oracle -phBaseDir /tmp/imagetool/patches         && test $? -eq 0         && /u01/oracle/OPatch/opatch util cleanup -silent -oh /u01/oracle         || (cat /u01/oracle/cfgtoollogs/opatch/opatch*.log && exit 1)
       ---> Running in 323e7ae70339
      Oracle Interim Patch Installer version 13.9.4.2.5
      Copyright (c) 2021, Oracle Corporation.  All rights reserved.
      
      
      Oracle Home       : /u01/oracle
      Central Inventory : /u01/oracle/.inventory
         from           : /u01/oracle/oraInst.loc
      OPatch version    : 13.9.4.2.5
      OUI version       : 13.9.4.0.0
      Log file location : /u01/oracle/cfgtoollogs/opatch/opatch2021-04-08_05-20-25AM_1.log
      
      
      OPatch detects the Middleware Home as "/u01/oracle"
      
      Verifying environment and performing prerequisite checks...
      OPatch continues with these patches:   32224021
      
      Do you want to proceed? [y|n]
      Y (auto-answered by -silent)
      User Responded with: Y
      All checks passed.
      
      Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
      (Oracle Home = '/u01/oracle')
      
      
      Is the local system ready for patching? [y|n]
      Y (auto-answered by -silent)
      User Responded with: Y
      Backing up files...
      Applying interim patch '32224021' to OH '/u01/oracle'
      ApplySession: Optional component(s) [ oracle.webcenter.sca, 14.1.2.0.0 ] , [ oracle.webcenter.sca, 14.1.2.0.0 ] , [ oracle.webcenter.ucm, 14.1.2.0.0 ] , [ oracle.webcenter.ucm, 14.1.2.0.0 ]  not present in the Oracle Home or a higher version is found.
      
      Patching component oracle.webcenter.portal, 14.1.2.0...
      
      Patching component oracle.webcenter.portal, 14.1.2.0...
      
      Patching component oracle.rcu.webcenter.portal, 12.2.1.0...
      
      Patching component oracle.rcu.webcenter.portal, 12.2.1.0...
      Patch 32224021 successfully applied.
      Log file location: /u01/oracle/cfgtoollogs/opatch/opatch2021-04-08_05-20-25AM_1.log
      
      OPatch succeeded.
      Oracle Interim Patch Installer version 13.9.4.2.5
      Copyright (c) 2021, Oracle Corporation.  All rights reserved.
      
      
      Oracle Home       : /u01/oracle
      Central Inventory : /u01/oracle/.inventory
         from           : /u01/oracle/oraInst.loc
      OPatch version    : 13.9.4.2.5
      OUI version       : 13.9.4.0.0
      Log file location : /u01/oracle/cfgtoollogs/opatch/opatch2021-04-08_05-27-11AM_1.log
      
      
      OPatch detects the Middleware Home as "/u01/oracle"
      
      Invoking utility "cleanup"
      OPatch will clean up 'restore.sh,make.txt' files and 'scratch,backup' directories.
      You will be still able to rollback patches after this cleanup.
      Do you want to proceed? [y|n]
      Y (auto-answered by -silent)
      User Responded with: Y
      
      Backup area for restore has been cleaned up. For a complete list of files/directories
      deleted, Please refer log file.
      
      OPatch succeeded.
      Removing intermediate container 323e7ae70339
       ---> 0e7c514dcf7b
      Successfully built 0e7c514dcf7b
      Successfully tagged wcportal:14.1.2.0-32224021
      [INFO   ] Build successful. Build time=645s. Image tag=wcportal:14.1.2.0-32224021

–dryRunオプション付きのWebLogic Image Toolによって生成されたDockerfileの例:

   $ imagetool update --fromImage oracle/wcportal:14.1.2.0 --tag=wcportal:14.1.2.0-30761841 --patches=30761841_14.1.2.0.0 --dryRun
   [INFO   ] Image Tool build ID: a473ba32-84b6-4374-9425-9e92ac90ee87
   [INFO   ] Temporary directory used for docker build context: /scratch/imagetoolcache/builddir/wlsimgbuilder_temp874401188519547557
   [INFO   ] Using patch 28186730_13.9.4.2.5 from cache: /home/imagetool-setup/jars/p28186730_139425_Generic.zip
   [INFO   ] Updating OPatch in final image from version 13.9.4.2.1 to version 13.9.4.2.5
   [WARNING] Skipping patch conflict check, no support credentials provided
   [WARNING] No credentials provided, skipping validation of patches
   [INFO   ] Using patch 32224021_14.1.2.0 from cache: /home/imagetool-setup/jars/p32224021_122140_Generic.zip
   [INFO   ] docker cmd = docker build --no-cache --force-rm --tag wcportal:14.1.2.0-32224021 --build-arg http_proxy=http://<YOUR-COMPANY-PROXY> --build-arg https_proxy=http://<YOUR-COMPANY-PROXY> --build-arg no_proxy=<IP addresses and Domain address for no_proxy>,/var/run/docker.sock <work-directory>/wlstmp/wlsimgbuilder_temp874401188519547557
   ########## BEGIN DOCKERFILE ##########
   #
   # Copyright (c) 2019, 2021, Oracle and/or its affiliates.
   #
   # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
   #
   #
   
   FROM oracle/wcportal:14.1.2.0 as final_build
   USER root
   
   ENV OPATCH_NO_FUSER=true
   
   
   LABEL com.oracle.weblogic.imagetool.buildid="a473ba32-84b6-4374-9425-9e92ac90ee87"
   
   USER oracle
   
       COPY --chown=oracle:oracle p28186730_139425_Generic.zip /tmp/imagetool/opatch/
       RUN cd /tmp/imagetool/opatch \
       && /u01/jdk/bin/jar -xf /tmp/imagetool/opatch/p28186730_139425_Generic.zip \
       && /u01/jdk/bin/java -jar /tmp/imagetool/opatch/6880880/opatch_generic.jar -silent -ignoreSysPrereqs -force -novalidation oracle_home=/u01/oracle \
       && rm -rf /tmp/imagetool
   
       COPY --chown=oracle:oracle patches/* /tmp/imagetool/patches/
   
           # Apply all patches provided at the same time
           RUN /u01/oracle/OPatch/opatch napply -silent -oh /u01/oracle -phBaseDir /tmp/imagetool/patches \
           && test $? -eq 0 \
           && /u01/oracle/OPatch/opatch util cleanup -silent -oh /u01/oracle \
           || (cat /u01/oracle/cfgtoollogs/opatch/opatch*.log && exit 1)
   
   ########## END DOCKERFILE ##########

docker imagesコマンドを使用して、ビルドしたイメージを確認します:

 docker images | grep wcportal

サンプル出力:

  wcportal   14.1.2.0-30761841
  2ef2a67a685b        About a minute ago   3.58GB

Dockerfileを使用したOracle WebCenter Portal Dockerイメージの作成

テストおよび開発の目的で、Dockerfileを使用してOracle WebCenter Portalイメージを作成できます。Server JRE Dockerイメージ、Oracle Fusion Middleware Infrastructure Dockerイメージのビルドまたはプル、Oracle WebCenter Portalインストーラおよびバンドル・パッチ・バイナリのダウンロードなど、重要な前提条件ステップについては、READMEファイルを参照してください。

事前ビルドされたOracle Fusion Middleware Infrastructureイメージcontainer-registry.oracle.com/middleware/fmw-infrastructure:14.1.2.0は、container-registry.oracle.comにあります。このイメージをプルして名前を変更し、Oracle WebCenter Portalイメージをビルドすることをお薦めします。

  docker pull container-registry.oracle.com/middleware/fmw-infrastructure:14.1.2.0
  docker tag container-registry.oracle.com/middleware/fmw-infrastructure:14.1.2.0  oracle/fmw-infrastructure:14.1.2.0

Oracle Fusion Middleware Infrastructureイメージをビルドし、その上にレイヤーとしてOracle WebCenter Portalイメージをビルドするには、次のステップに従います:

  1. サンプル・リポジトリのローカル・クローンを作成します:

     git clone https://github.com/oracle/docker-images

  2. Oracle Technology NetworkまたはE-DeliveryからOracle WebCenter Portalインストーラをダウンロードします。

    ノート: インストーラ・バイナリをDockerfileと同じ場所にコピーします。

  3. 付属のスクリプトを実行して、Oracle WebCenter Portalイメージを作成します:

     cd docker-images/OracleWebCenterPortal/dockerfiles
 ./buildDockerImage.sh -v 14.1.2.0 -s

    生成されるイメージの名前はoracle/wcportal:14.1.2.0です。サンプルと手順は、Oracle WebCenter Portalイメージの名前がoracle/wcportal:14.1.2.0であることを前提としています。この名前と一致するようにイメージの名前を変更するか、作成したイメージを参照するようにサンプルを更新する必要があります。

OKE環境の設定

内容

要塞およびワーカー・ノードにアクセスするための公開SSHキーの生成

Linux端末でssh-keygenコマンドを使用して、OCIのコンピュート・インスタンス(ワーカー/要塞)にアクセスするためのSSHキーを生成します。

 ssh-keygen -t rsa -N "" -b 2048 -C demokey -f id_rsa

OKEのコンパートメントの作成

テナンシ内で、必要なネットワーク・リソース(VCN、サブネット、インターネット・ゲートウェイ、ルート表、セキュリティ・リスト)を含むコンパートメントを作成する必要があります。

  1. OCIコンソールで、左上のメニューを使用して、「アイデンティティ」→「コンパートメント」に移動します。
  2. 「コンパートメントの作成」ボタンをクリックします。
  3. コンパートメント名(WCPStorageなど)と説明(OKEコンパートメントなど)を入力し、「コンパートメントの作成」ボタンをクリックします。

コンテナ・クラスタ(OKE)の作成

  1. コンソールで、ナビゲーション・メニューを開きます。「開発者サービス」に移動して、「Kubernetesクラスタ(OKE)」をクリックします。

    OKE-CLUSTER

  2. 作業する権限があるコンパートメントを選択します。ここでは、WCPStorageコンパートメントを使用します。

  3. 「クラスタ・リスト」ページで、コンパートメントを選択し、「クラスタの作成」をクリックします。

    OKE-CLUSTER

  4. 「クラスタの作成」ダイアログで、「クイック作成」を選択して「ワークフローの起動」をクリックします。

    OKE-CLUSTER

  5. 「クラスタの作成」ページで、環境に応じて(次に示すサンプル値のように)値を指定します

    • 名前: wcpcluster
    • コンパートメント: WCPStorage
    • Kubernetesバージョン: v1.23.4 (kubectlバージョンの互換性については、Kubernetesバージョン・スキュー・ポリシーを参照してください。)
    • 可視性タイプの選択: プライベート
    • シェイプ: VM.Standard.E3.Flex (ワーカー・ノード・プールで使用可能なシェイプを選択します。リストには、Container Engine for Kubernetesでサポートされているテナンシで使用可能なシェイプのみが表示されます。「ワーカー・ノードでサポートされているイメージおよびシェイプ」を参照してください。)
    • ノードの数: 3 (ノード・プールに作成するワーカー・ノードの数で、クイック・クラスタ用に作成されたリージョナル・サブネットに配置されます)。
    • 「拡張オプションの表示」をクリックし、PUBLIC SSK KEY: ssh-rsa AA……bmVnWgX/ demokeyを入力します。
      >ノート: 公開キーid_rsa.pubはステップ1で作成しました

    OKE-CLUSTER

  6. 「次」をクリックして、新しいクラスタ用に入力した詳細を確認します。

    OKE-CLUSTER

  7. 「クラスタの作成」をクリックして、新しいネットワーク・リソースと新しいクラスタを作成します。

    OKE-CLUSTER

  8. Container Engine for Kubernetesでリソースの作成が開始されます(「クラスタと関連ネットワーク・リソースの作成」ダイアログに表示されます)。「閉じる」をクリックしてコンソールに戻ります。

    OKE-CLUSTER

  9. 最初は、新しいクラスタは「作成中」のステータスでコンソールに表示されます。クラスタが作成されると、ステータスは「アクティブ」になります。

    OKE-CLUSTER

  10. 「リソース」で「ノード・プール」をクリックし、「表示」をクリックしてノード・プールおよびワーカー・ノードのステータスを表示します

OKE-CLUSTER

  1. ワーカー・ノードのステータスを表示し、すべてのノード状態が「アクティブ」で、「Kubernetesのノード条件」が「準備完了」であることを確認します。「Kubernetesのノード条件」が「準備完了」になると、kubectlコマンドでワーカー・ノードがリストされます。

OKE-CLUSTER

  1. クラスタにアクセスするには、クラスタwcpclusterのページで「クラスタへのアクセス」をクリックします。

OKE-CLUSTER

  1. 次に要塞ノードを作成して、クラスタにアクセスします。

クラスタにアクセスするための要塞ノードの作成

内部リソースにアクセスするための要塞ノードを設定します。次のステップを使用して同じVCN内に要塞ノードを作成し、ワーカー・ノードへのSSHアクセスを許可します。

この設定では、CIDRブロック: 10.0.0.0/16を選択します。必要に応じて別のブロックを選択できます。

  1. 次に示すように、クラスタ・ページからVCN名をクリックします

    Bastion-Node

  2. 次に、「セキュリティ・リスト」、「セキュリティ・リストの作成」の順にクリックします

    Bastion-Node

  3. 次のイングレス・ルールとエグレス・ルールを使用してbastion-private-sec-listセキュリティを作成します。

    イングレス・ルール:

    Bastion-Node

    エグレス・ルール:

    Bastion-Node

  4. 次のイングレス・ルールとエグレス・ルールを使用してbastion-public-sec-listセキュリティを作成します。

    イングレス・ルール:

    Bastion-Node

    エグレス・ルール:

    Bastion-Node

  5. インターネット・ゲートウェイを使用してbastion-route-tableを作成し、インターネット・アクセスのために要塞インスタンスに追加できるようにします

    Bastion-Node

  6. 次に、bastion-subnetという名前で、次の詳細を使用して要塞インスタンスのリージョナル・パブリック・サブネットを作成します:

    • CIDRブロック: 10.0.22.0/24

    • ルート表: oke-bastion-routetables

    • サブネット・アクセス: パブリック・サブネット

    • セキュリティ・リスト: bastion-public-sec-list

    • DHCPオプション: 「デフォルトDHCPオプション」を選択

      Bastion-Node

      Bastion-Node

  7. 次に、ワーカー・ノードがあるプライベート・サブネットをクリックします

    Bastion-Node

  8. 次に、bastion-private-sec-listをワーカー・プライベート・サブネットに追加して、要塞インスタンスがワーカー・ノードにアクセスできるようにします

    Bastion-Node

  9. 次に、次の詳細を使用してコンピュート・インスタンスoke-bastionを作成します

    • 名前: BastionHost

    • イメージ: Oracle Linux 7.X/8.x

    • 可用性ドメイン: インスタンスの作成に制限がある任意のADを選択

    • 仮想クラウド・ネットワーク・コンパートメント: WCPStorage (つまり、OKEコンパートメント)

    • 仮想クラウド・ネットワークの選択: クイック・クラスタによって作成されたVCNを選択

    • サブネット・コンパートメント: WCPStorage (つまり、OKEコンパートメント)

    • サブネット: bastion-subnet (前に作成済)

    • 「パブリックIPアドレスの割当て」を選択

    • SSHキー: ステップ1で作成したid_rsa.pubの内容をコピー

      Bastion-Node

      Bastion-Node

  10. 要塞インスタンスBastionHostが作成されたら、パブリックIPを取得して要塞インスタンスにsshで接続します

Bastion-Node

  1. 次のように要塞ホストにログインします
 ssh -i <your_ssh_bastion.key> opc@123.456.xxx.xxx

OCI CLIの設定

  1. OCI CLIをインストールします

     bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"

  2. インストール・スクリプトのプロンプトに応答します。

    exec -l $SHELLを実行してシェルを再起動します。

  3. 後で設定後にkubeconfigをダウンロードするには、oci構成ファイルを設定する必要があります。次のコマンドに従って、プロンプトに応じて詳細を入力します

     oci setup config

    サンプル出力:

    oci setup config

This command provides a walkthrough of creating a valid CLI config file.

The following links explain where to find the information required by this
script:

 User API Signing Key, OCID and Tenancy OCID:

     https://docs.cloud.oracle.com/Content/API/Concepts/apisigningkey.htm#Other

 Region:

     https://docs.cloud.oracle.com/Content/General/Concepts/regions.htm

 General config documentation:

     https://docs.cloud.oracle.com/Content/API/Concepts/sdkconfig.htm


Enter a location for your config [/home/opc/.oci/config]:
Enter a user OCID: ocid1.user.oc1..aaaaaaaao3qji52eu4ulgqvg3k4yf7xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Enter a tenancy OCID: ocid1.tenancy.oc1..aaaaaaaaf33wodv3uhljnn5etiuafoxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Enter a region (e.g. ap-hyderabad-1, ap-melbourne-1, ap-mumbai-1, ap-osaka-1, ap-seoul-1, ap-sydney-1, ap-tokyo-1, ca-montreal-1, ca-toronto-1, eu-amsterdam-1, eu-frankfurt-1, eu-zurich-1, me-jeddah-1, sa-saopaulo-1, uk-gov-london-1, uk-london-1, us-ashburn-1, us-gov-ashburn-1, us-gov-chicago-1, us-gov-phoenix-1, us-langley-1, us-luke-1, us-phoenix-1): us-phoenix-1
Do you want to generate a new API Signing RSA key pair? (If you decline you will be asked to supply the path to an existing key.) [Y/n]: Y
Enter a directory for your keys to be created [/home/opc/.oci]:
Enter a name for your key [oci_api_key]:
Public key written to: /home/opc/.oci/oci_api_key_public.pem
Enter a passphrase for your private key (empty for no passphrase):
Private key written to: /home/opc/.oci/oci_api_key.pem
Fingerprint: 74:d2:f2:db:62:a9:c4:bd:9b:4f:6c:d8:31:1d:a1:d8
Config written to /home/opc/.oci/config


 If you haven't already uploaded your API Signing public key through the
 console, follow the instructions on the page linked below in the section
 'How to upload the public key':

     https://docs.cloud.oracle.com/Content/API/Concepts/apisigningkey.htm#How2

  4. ここで、$HOME/.ociに作成された公開キー(oci_api_key_public.pem)をOCIコンソールにアップロードする必要があります。OCIコンソールにログインし、ページの右上隅のOCIユーザー・プロファイルのドロップダウンにある「ユーザー設定」に移動します。

    Bastion-Node

  5. 「ユーザーの詳細」ページで、ページの左下隅にある「APIキー」リンクをクリックし、次に「APIキーの追加」ボタンをクリックします。oci_api_key_public.pemの内容をコピーして、「追加」をクリックします。

    Bastion-Node

  6. これで、oci cliを使用してOCIリソースにアクセスできるようになりました。

  7. クラスタにアクセスするには、クラスタwcpclusterのページで「クラスタへのアクセス」をクリックします

    Bastion-Node

  8. 要塞ノードからクラスタにアクセスするには、「ローカル・アクセス」に従ってステップを実行します。

    Bastion-Node

     oci -v
 mkdir -p $HOME/.kube

 oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.iad.aXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXara4e44gq --file $HOME/.kube/config --region us-ashburn-1 --token-version 2.0.0   --kube-endpoint PRIVATE_ENDPOINT
 --file $HOME/.kube/config --region us-phoenix-1 --token-version 2.0.0

 export KUBECONFIG=$HOME/.kube/config

  9. クラスタにアクセスするためのkubectlクライアントをインストールします

     curl -LO https://dl.k8s.io/release/v1.23.4/bin/linux/amd64/kubectl
 sudo mv kubectl  /bin/
 sudo chmod +x /bin/kubectl

  10. 要塞ノードからクラスタにアクセスします

kubectl get nodes

サンプル出力:

NAME          STATUS   ROLES   AGE   VERSION
10.0.10.171   Ready    node    10d   v1.23.4
10.0.10.31    Ready    node    10d   v1.23.4
10.0.10.63    Ready    node    10d   v1.23.4
  1. Oracle WebCenter Portalクラスタ設定に必要なアドオンをインストールします

ファイル・システムの準備

OCIでのファイル・ストレージ・システムの作成

ファイル・ストレージ・システム(FSS)のファイルシステムおよびセキュリティ・リストの作成

ノート: OKEで作成されたVCNにファイルシステムおよびセキュリティ・リストを作成してください。

OCIRの準備

OCIでOracle WebCenter Portalイメージを管理するためのOracleコンテナ・イメージ・リポジトリの構成

OCIRへのイメージの公開

必要なすべてのイメージをOCIRにプッシュして、後でそこから使用します。OCIRにイメージをプッシュするには、次のステップに従います

認証トークンの作成

OCIRからイメージをプッシュおよびプルするためのDockerパスワードとして使用される「認証トークン」を作成します。OCIコンソールにログインし、OCIコンソール・ページの右上隅のOCIユーザー・プロファイルのドロップダウンにある「ユーザー設定」に移動します。

OCIR

OCIRの使用

Docker CLIを使用したOCIRへのログイン 1. docker login <region-key>.ocir.io (<region-key>はフェニックスの場合はphx、アッシュバーンの場合はiadなど) 1.ユーザー名の入力を求められたら、Dockerユーザー名をOCIR <tenancy-namespace>/<username>として入力します。ここで、<tenancy-namespace>は、テナンシの自動生成されたオブジェクト・ストレージ・ネームスペース文字列です
(例: idcmmdmzqtqg/myemailid@oracle.com)
テナンシがOracle Identity Cloud Serviceとフェデレートされている場合、
<tenancy-namespace>/oracleidentitycloudservice/<username>という形式を使用します。1.パスワードの入力を求められたら、生成された認証トークンを入力します 1.これで、WebCenter Portal Dockerイメージをタグ付けして、OCIRにプッシュできます。サンプル・ステップは次のとおりです

docker login iad.ocir.io

#username - idcmmdmzqtqg/oracleidentitycloudservice/myemailid@oracle.com
#password - abCXYz942,vcde     (Token Generated for OCIR using user setting)

docker tag oracle/wcportal:14.1.2.0.0 iad.ocir.io/idcmmdmzqtqg/oracle/wcportal:14.1.2.0.0

docker push iad.ocir.io/idcmmdmzqtqg/oracle/wcportal:14.1.2.0.0

ノート: Docker CLIを使用して、ローカル・サーバーのすべてのイメージに対してこれを行う必要があります。

OCIRイメージの検証

Oracle Cloud Infrastructureコンソールにログインして、OCIRリポジトリ名を取得します。OCIコンソールで、ナビゲーション・メニューを開きます。「ソリューションおよびプラットフォーム」で、「開発者サービス」に移動して「コンテナ・レジストリ(OCIR)」をクリックし、ルート・コンパートメントを選択します。

OCIR

データベースの準備

OCIでのデータベースの作成には、クラウドベースのOracleデータベース・サービスのプロビジョニングおよび構成が含まれます。

WCPドメインの環境の準備

Oracle Kubernetes Engine (OKE)でWCPドメインの環境を設定します。

Kubernetes OKE環境内にOracle WebCenter Portalドメインを確立するには、次のステップに従います:

内容

  1. Oracle WebCenter Portalドメインをデプロイするためのコード・リポジトリの設定

  2. すべてのノードでのイメージのプル

  3. WebLogic Kubernetes Operatorのインストール

  4. WebCenter Portalドメインの環境の準備

    1. Oracle WebCenter Portalドメインのネームスペースの作成

    2. ドメイン資格証明を使用したKubernetesシークレットの作成

    3. RCU資格証明を使用したKubernetesシークレットの作成

    4. Oracle WebCenter Portalドメインの永続ストレージの作成

    5. データベースへのアクセスの構成

    6. リポジトリ作成ユーティリティの実行によるデータベース・スキーマの設定

  5. OKEでのOracle WebCenter Portalドメインの作成

Oracle WebCenter Portalドメインをデプロイするためのコード・リポジトリの設定

KubernetesでのOracle WebCenter Portalドメインのデプロイメントでは、WebLogic Kubernetes Operatorインフラストラクチャを利用します。Oracle WebCenter Portalドメインをデプロイするには、次に示すようにデプロイメント・スクリプトを設定する必要があります。

  1. ソース・コードを設定する作業ディレクトリを作成します:

     mkdir $HOME/wcp_14.1.2.0
 cd $HOME/wcp_14.1.2.0

  2. GithubリポジトリからWebLogic Kubernetes Operatorソース・コードおよびOracle WebCenter Portal Suite Kubernetesデプロイメント・スクリプトをダウンロードします。必要なアーティファクトは、OracleWebCenterPortal/kubernetesにあります。

     git clone https://github.com/oracle/fmw-kubernetes.git
 export WORKDIR=$HOME/wcp_14.1.2.0/fmw-kubernetes/OracleWebCenterPortal/kubernetes

    このドキュメントで後述するように、<$WORKDIR>のデプロイメント・スクリプトを使用してWebCenter Portalドメインを設定できるようになりました。

すべてのノードでのイメージのプル

Kubernetesデプロイメントでイメージを使用できるように、すべてのノードで必要なイメージをすべてプルします。

  1. 各ノードにログインします。

    ノート: 次のコマンドでは、要塞サーバーをプロキシとして使用し、Kubernetesプライベート・ノードに直接ログインします。要塞サーバーにログインせずに、ターミナルから直接次のコマンドを実行します。

     ssh -i <path_to_private_key> -o ProxyCommand="ssh -W %h:%p \
   -i <path_to_private_key> opc@<bastion_public_ip>" opc@<node_private_ip>

 # Example : 
 ssh -i id_rsa -o ProxyCommand="ssh -W %h:%p -i id_rsa opc@132.145.192.108" opc@10.0.10.201

  2. 各ノードで必要なイメージをプルします

     sudo crictl pull <image-name>

 # Example :
 sudo crictl pull iad.ocir.io/idpgxxxxxcag/oracle/wcportal:14.1.2.0

    アップストリームKubernetesプロジェクトは、Kubernetesバージョン1.20より後のコンテナ・ランタイムとしてDockerを非推奨にしています。
    以前にDocker CLIを使用してホストでコマンドを実行していた場合、かわりにcrictl (CRI互換コンテナ・ランタイム用のCLI)を使用する必要があります。

WebLogic Kubernetes Operatorのインストール

WebLogic Kubernetes Operatorは、Kubernetes環境でのOracle WebCenter Portalドメインのデプロイメントをサポートします。

このドキュメントのステップに従って、オペレータをインストールします。

オプションで、これらのステップに従って、オペレータのログの内容をElasticsearchに送信できます。

WebLogic Kubernetes Operatorをインストールする次のコマンド例では、opnsはネームスペースで、op-saはオペレータ用に作成されたサービス・アカウントです:

kubectl create namespace operator-ns
kubectl create serviceaccount -n operator-ns operator-sa
helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update 
helm install weblogic-kubernetes-operator weblogic-operator/weblogic-operator  --version 4.2.9 --namespace operator-ns --set serviceAccount=operator-sa --set "javaLoggingLevel=FINE" --wait

ノート: この手順では、ネームスペースはoperator-nsと呼ばれていますが、任意の名前を使用できます。

次の値を使用できます:
- ドメインUID/ドメイン名: wcp-domain
- ドメイン・ネームスペース: wcpns
- オペレータ・ネームスペース: operator-ns
- Traefikネームスペース: traefik

WebCenter Portalドメインの環境の準備

Oracle WebCenter Portalドメインのネームスペースの作成

デフォルト・ネームスペースを使用する場合を除き、ドメインのKubernetesネームスペース(wcpnsなど)を作成します。詳細は、ドメイン実行の準備を参照してください。

kubectl create namespace wcpns
kubectl label namespace wcpns weblogic-operator=enabled

このネームスペースのドメインを管理するには、helmを使用してオペレータを構成します:

Helmはweblogic-operatorをアップグレードします

helm upgrade --reuse-values --set "domainNamespaces={wcpns}" \
  --wait weblogic-kubernetes-operator charts/weblogic-operator --namespace operator-ns

サンプル出力:

 NAME: weblogic-kubernetes-operator
 LAST DEPLOYED: Wed Jan  6 01:52:58 2021
 NAMESPACE: operator-ns
 STATUS: deployed
 REVISION: 2

ドメイン資格証明を使用したKubernetesシークレットの作成

ドメインと同じKubernetesネームスペースで、管理アカウントのKubernetesシークレットusernameおよびpasswordを作成します:

cd ${WORKDIR}/create-weblogic-domain-credentials
./create-weblogic-credentials.sh -u weblogic -p welcome1 -n wcpns -d wcp-domain -s wcp-domain-domain-credentials

サンプル出力:

secret/wcp-domain-domain-credentials created
secret/wcp-domain-domain-credentials labeled
The secret wcp-domain-domain-credentials has been successfully created in the wcpns namespace.

説明:

ノート: 次のように資格証明を検査できます:

kubectl get secret wcp-domain-domain-credentials -o yaml -n wcpns

詳細は、このドキュメントを参照してください。

RCU資格証明を使用したKubernetesシークレットの作成

ドメインと同じKubernetesネームスペースでcreate-rcu-credentials.shスクリプトを使用して、リポジトリ構成ユーティリティのKubernetesシークレット(ユーザー名とパスワード)を作成します:

 cd ${WORKDIR}/create-rcu-credentials
 sh create-rcu-credentials.sh \
    -u username \
    -p password \
    -a sys_username \
    -q sys_password \
    -d domainUID \
    -n namespace \
    -s secretName

サンプル出力:

 secret/wcp-domain-rcu-credentials created
 secret/wcp-domain-rcu-credentials labeled
 The secret wcp-domain-rcu-credentials has been successfully created in the wcpns namespace.

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

  -u username for schema owner (regular user), must be specified.
  -p password for schema owner (regular user), must be provided using the -p argument or user will be prompted to enter a value.
  -a username for SYSDBA user, must be specified.
  -q password for SYSDBA user, must be provided using the -q argument or user will be prompted to enter a value.
  -d domainUID, optional. The default value is wcp-domain. If specified, the secret will be labeled with the domainUID unless the given value is an empty string.
  -n namespace, optional. Use the wcpns namespace if not specified.
  -s secretName, optional. If not specified, the secret name will be determined based on the domainUID value.

ノート: 次のように資格証明を検査できます:

 kubectl get secret wcp-domain-rcu-credentials -o yaml -n wcpns

Oracle WebCenter Portalドメインの永続ストレージの作成

Kubernetes PVおよびPVC (永続ボリュームおよび永続ボリューム要求)を作成します:

作成したKubernetesネームスペースで、create-pv-pvc.shスクリプトを実行してドメインのPVおよびPVCを作成します。スクリプトを使用する手順に従って、Oracle WebCenter Portalドメイン専用のPVおよびPVCを作成します。

データベースへのアクセスの構成

Oracle WebCenter Portalドメインには、必要なスキーマで構成されたデータベースが必要です。リポジトリ作成ユーティリティ(RCU)によって、これらのスキーマを作成できます。ドメインを作成する前に、データベースを設定する必要があります。

本番デプロイメントでは、Kubernetesの外部で実行されているスタンドアロン(非コンテナ)データベースを設定して使用する必要があります。

ドメインを作成する前に、データベースに必要なスキーマを設定する必要があります。

データベースを作成するには、このドキュメントを参照してください。

リポジトリ作成ユーティリティの実行によるデータベース・スキーマの設定

Oracle WebCenter Portalドメインのデータベース・スキーマを作成するには、create-rcu-schema.shスクリプトを実行します。

cd ${WORKDIR}/create-rcu-schema
./create-rcu-schema.sh -h

使用方法:

  ./create-rcu-schema.sh -s <schemaPrefix> [-t <schemaType>] [-d <dburl>] [-n <namespace>] [-c <credentialsSecretName>] [-p <docker-store>] [-i <image>] [-u <imagePullPolicy>] [-o <rcuOutputDir>] [-r <customVariables>] [-l <timeoutLimit>] [-e <edition>] [-h]
    -s RCU Schema Prefix (required)
    -t RCU Schema Type (optional)
        (supported values: wcp,wcpp)
    -d RCU Oracle Database URL (optional)
        (default: oracle-db.default.svc.cluster.local:1521/devpdb.k8s)
    -n Namespace for RCU pod (optional)
        (default: default)
    -c Name of credentials secret (optional).
        (default: oracle-rcu-secret)
        Must contain SYSDBA username at key 'sys_username',
        SYSDBA password at key 'sys_password',
        and RCU schema owner password at key 'password'.
    -p OracleWebCenterPortal ImagePullSecret (optional)
        (default: none)
    -i OracleWebCenterPortal Image (optional)
        (default: oracle/wcportal:release-version)
    -u OracleWebCenterPortal ImagePullPolicy (optional)
        (default: IfNotPresent)
    -o Output directory for the generated YAML file. (optional)
        (default: rcuoutput)
    -r Comma-separated custom variables in the format variablename=value. (optional).
        (default: none)
    -l Timeout limit in seconds. (optional).
        (default: 300)
    -e The edition name. This parameter is only valid if you specify databaseType=EBR. (optional).
        (default: 'ORA$BASE')
    -h Help

  Note: The c, p, i, u, and o arguments are ignored if an rcu pod is already running in the namespace.

  ./create-rcu-schema.sh \
        -s WCP1 \
        -t wcp \
        -d xxx.oraclevcn.com:1521/DB1129_pdb1.xxx.wcpcluster.oraclevcn.com \
        -i iad.ocir.io/xxxxxxxx/oracle/wcportal:14.1.2.0 \
        -n wcpns \
        -c wcp-domain-rcu-credentials \
        -r ANALYTICS_WITH_PARTITIONING=N

ノート:

OKEでのOracle WebCenter Portalドメインの作成

これでRCUスキーマが完成したため、ドメインを作成する準備ができました。詳細なステップは、「WebCenter Portalドメインの作成」を参照してください。

管理サーバーのロード・バランサの構成

この項では、管理サーバーをロード・バランシングするようにOCIロード・バランサを構成する方法について説明します。

次のステップに従って、Kubernetesクラスタで管理サーバーのOCIロード・バランサを設定します:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: wcpinfra-admin-loadbalancer
  namespace: wcpns
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-shape: 100Mbps
spec:
  ports:
  - name: http
    port: 7001
    protocol: TCP
    targetPort: 7001
  - name: https
    port: 7002
    protocol: TCP
    targetPort: 7002
  selector:
    weblogic.domainUID: wcp-domain
    weblogic.serverName: AdminServer
  sessionAffinity: None
  type: LoadBalancer
EOF

管理サーバーURLアクセスの検証

ロード・バランサを設定した後、管理URLにアクセスできることを検証します。
サンプルURLは次のとおりです:

  http://${LOADBALANCER_IP}:${LOADBALANCER-PORT}/console
  http://${LOADBALANCER_IP}:${LOADBALANCER-PORT}/em

イングレスを管理するためのNGINX

Oracle WebCenter PortalドメインのイングレスベースのNGINXロード・バランサを構成します。SAML 2.0 (IDCS)シングル・サインオンを構成するために、エンドツーエンドSSL構成を使用します。

Oracle WebCenter Portalドメイン・クラスタをロード・バランシングするには、イングレスベースのNGINXロード・バランサをインストールし、アプリケーションURLのSSL終端およびエンドツーエンドSSLアクセス用にNGINXを構成します。SAML 2.0 (IDCS)シングル・サインオンを構成するために、エンドツーエンドSSL構成を使用します。
次のステップに従って、NGINXをKubernetesクラスタ内のOracle WebCenter Portalドメインのロード・バランサとして設定します:

前提条件は、公式のインストール・ドキュメントを参照してください。

SSL終端

リポジトリ情報を取得するには、次のHelmコマンドを入力します:

 helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
 helm repo update

NGINXロード・バランサのインストール

  1. ドメイン・ネームスペースでHelmを使用して、ingress-nginxコントローラをデプロイします:

    helm install nginx-ingress ingress-nginx/ingress-nginx -n wcpns \
 --set controller.service.type=LoadBalancer \
 --set controller.admissionWebhooks.enabled=false

    サンプル出力:

       NAME: nginx-ingress
   LAST DEPLOYED: Tue Jan 12 21:13:54 2021
   NAMESPACE: wcpns
   STATUS: deployed
   REVISION: 1
   TEST SUITE: None
   NOTES:
   The ingress-nginx controller has been installed.
   Get the application URL by running these commands:
     export HTTP_NODE_PORT=30305
     export HTTPS_NODE_PORT=$(kubectl --namespace wcpns get services -o jsonpath="{.spec.ports[1].nodePort}" nginx-ingress-ingress-nginx-controller)
     export NODE_IP=$(kubectl --namespace wcpns get nodes -o jsonpath="{.items[0].status.addresses[1].address}")

     echo "Visit http://$NODE_IP:$HTTP_NODE_PORT to access your application via HTTP."
     echo "Visit https://$NODE_IP:$HTTPS_NODE_PORT to access your application via HTTPS."

   An example Ingress that makes use of the controller:

     apiVersion: networking.k8s.io/v1beta1
     kind: Ingress
     metadata:
       annotations:
         kubernetes.io/ingress.class: nginx
       name: example
       namespace: foo
     spec:
       rules:
         - host: www.example.com
           http:
             paths:
               - backend:
                   serviceName: exampleService
                   servicePort: 80
                 path: /
       # This section is only required if TLS is to be enabled for the Ingress
       tls:
           - hosts:
               - www.example.com
             secretName: example-tls

   If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:

     apiVersion: v1
     kind: Secret
     metadata:
       name: example-tls
       namespace: foo
     data:
       tls.crt: <base64 encoded cert>
       tls.key: <base64 encoded key>
     type: kubernetes.io/tls

  2. デプロイされたイングレス・コントローラのステータスを確認します:

    nginx-controllerサービスのEXTERNAL-IPを書き留めてください。

    これは、WebLogic Server管理コンソールおよびWebCenter Portal URLへのアクセスに使用するロード・バランサのパブリックIPアドレスです。

    ノート: LoadBalancer IP(EXTERNAL-IP)が使用可能になるまで数分かかる場合があります。

    kubectl --namespace wcpns get services | grep ingress-nginx-controller

    サンプル出力:

    nginx-ingress-ingress-nginx-controller   LoadBalancer       10.101.123.106   144.24.xx.xx        80:30305/TCP,443:31856/TCP   2m12s

    NGINX EXTERNAL-IPのみを出力するには、次のコマンドを実行します:

    NGINX_PUBLIC_IP=`kubectl describe svc nginx-ingress-ingress-nginx-controller --namespace wcpns | grep Ingress | awk '{print $3}'`

$ echo $NGINX_PUBLIC_IP   
144.24.xx.xx

イングレスを管理するためのNGINXの構成

  1. サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します。ここでは、パスベースのルーティングがイングレスに使用されます。デフォルト構成のサンプル値は、${WORKDIR}/charts/ingress-per-domain/values.yamlファイルに示されています。デフォルトでは、typeはTRAEFIKで、tlsはNon-SSLです。これらの値をオーバーライドするには、コマンドラインを介して値を渡すか、サンプルvalues.yamlファイルでそれらを編集します。

    ノート: これは、ルールの完全なリストではありません。外部からアクセスする必要があるアプリケーションURLに基づいてこれを拡張できます。

    必要に応じて、イングレスYAMLファイルを更新して、アクセスが必要なドメイン・アプリケーションURLに基づいて(spec.rules.host.http.pathsセクションに)追加のパス・ルールを定義できます。${WORKDIR}/charts/ingress-per-domain/templates/nginx-ingress.yamlにあるNGINXロード・バランサのテンプレートYAMLファイルを更新します

    次に示すような新しいパス・ルールを追加できます。

     - path: /NewPathRule
   backend:
     serviceName: 'Backend Service Name'
     servicePort: 'Backend Service Port'

    SSL終端構成用にHelmを使用してingress-per-domainをインストールします:

     export LB_HOSTNAME=<NGINX load balancer DNS name>

 #OR leave it empty to point to NGINX load-balancer IP, by default
 export LB_HOSTNAME=''

    ノート: NGINXロード・バランサのホスト名を指すようにDNS名を指定するか、NGINXロード・バランサのIPを指すように空のままにしてください。

証明書の作成およびSSL構成のKubernetesシークレットの生成

  1. Oracle WebCenter Portalアプリケーションへのセキュア・アクセス(SSL)の場合は、証明書を作成してKubernetesシークレットを生成します:

     openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt -subj "/CN=<NGINX load balancer DNS name>"

 #OR use the following command if you chose to leave LB_HOSTNAME empty in the previous step
 openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt -subj "/CN=*"

  2. Kubernetesシークレットを生成します:

     kubectl -n wcpns create secret tls wcp-domain-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt

SSL終端構成のイングレスのインストール

  1. SSL構成用にHelmを使用してingress-per-domainをインストールします:

     cd ${WORKDIR}
 helm install wcp-domain-nginx  charts/ingress-per-domain \
     --namespace wcpns \
     --values charts/ingress-per-domain/values.yaml \
     --set "nginx.hostname=$LB_HOSTNAME" \
     --set "nginx.hostnameorip=$NGINX_PUBLIC_IP" \
     --set type=NGINX --set sslType=SSL

  2. Oracle WebCenter PortalアプリケーションへのSSLアクセスの場合は、前述のデプロイ済イングレスによってサービスの詳細を取得します:

     kubectl describe ingress wcp-domain-nginx -n wcpns

    前述のデプロイ済イングレスでサポートされるサービスのサンプル出力:

    Name:             wcp-domain-nginx
Namespace:        wcpns
Address:          10.106.220.140
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  wcp-domain-tls-cert terminates mydomain.com
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /webcenter   wcp-domain-cluster-wcp-cluster:8888 (10.244.0.43:8888,10.244.0.44:8888)
              /console     wcp-domain-adminserver:7001 (10.244.0.42:7001)
              /rsscrawl    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.43:8888,10.244.0.44:8888)
              /webcenterhelp   wcp-domain-cluster-wcp-cluster:8888 (10.244.0.43:8888,10.244.0.44:8888)
              /rest     wcp-domain-cluster-wcp-cluster:8888 (10.244.0.43:8888,10.244.0.44:8888)
              /em          wcp-domain-adminserver:7001 (10.244.0.42:7001)
              /wsrp-tools     wcp-domain-cluster-wcportlet-cluster:8889 (10.244.0.43:8889,10.244.0.44:8889)
Annotations:  kubernetes.io/ingress.class: nginx
              meta.helm.sh/release-name: wcp-domain-nginx
              meta.helm.sh/release-namespace: wcpns
              nginx.ingress.kubernetes.io/affinity: cookie
              nginx.ingress.kubernetes.io/affinity-mode: persistent
              nginx.ingress.kubernetes.io/configuration-snippet:
                more_set_input_headers "X-Forwarded-Proto: https";
                more_set_input_headers "WL-Proxy-SSL: true";
              nginx.ingress.kubernetes.io/ingress.allow-http: false
              nginx.ingress.kubernetes.io/proxy-connect-timeout: 1800
              nginx.ingress.kubernetes.io/proxy-read-timeout: 1800
              nginx.ingress.kubernetes.io/proxy-send-timeout: 1800
              nginx.ingress.kubernetes.io/session-cookie-expires: 172800
              nginx.ingress.kubernetes.io/session-cookie-max-age: 172800
              nginx.ingress.kubernetes.io/session-cookie-name: stickyid
              nginx.ingress.kubernetes.io/ssl-redirect: false
Events:       <none>

SSL終端アクセスの検証

Oracle WebCenter Portalドメイン・アプリケーションURLがLOADBALANCER-HOSTNAMEを介してアクセス可能であることを検証します:

  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/console
  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/em
  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/webcenter
  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/rsscrawl
  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/rest
  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/webcenterhelp
  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-NODEPORT}/wsrp-tools

イングレスのアンインストール

ingress-nginxデプロイメントをアンインストールして削除します:

helm delete wcp-domain-nginx -n wcpns
helm delete nginx-ingress -n wcpns

エンドツーエンドSSL構成

エンドツーエンドSSLのNGINXロード・バランサのインストール

  1. Oracle WebCenter Portalアプリケーションへのセキュア・アクセス(SSL)の場合は、証明書を作成してシークレットを生成します: ここをクリック

  2. ドメイン・ネームスペースでHelmを使用して、ingress-nginxコントローラをデプロイします:

    helm install nginx-ingress -n wcpns \
  --set controller.extraArgs.default-ssl-certificate=wcpns/wcp-domain-tls-cert \
  --set controller.service.type=LoadBalancer  \
  --set controller.admissionWebhooks.enabled=false \
  --set controller.extraArgs.enable-ssl-passthrough=true  \
  ingress-nginx/ingress-nginx

    サンプル出力:

      NAME: nginx-ingress
  LAST DEPLOYED: Tue Sep 15 08:40:47 2020
  NAMESPACE: wcpns
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None
  NOTES:
  The ingress-nginx controller has been installed.
  Get the application URL by running these commands:
  export HTTP_NODE_PORT=$(kubectl --namespace wcpns get services -o jsonpath="{.spec.ports[0].nodePort}" nginx-ingress-ingress-nginx-controller)
  export HTTPS_NODE_PORT=$(kubectl --namespace wcpns get services -o jsonpath="{.spec.ports[1].nodePort}" nginx-ingress-ingress-nginx-controller)
  export NODE_IP=$(kubectl --namespace wcpns get nodes -o jsonpath="{.items[0].status.addresses[1].address}")

  echo "Visit http://$NODE_IP:$HTTP_NODE_PORT to access your application via HTTP."
  echo "Visit https://$NODE_IP:$HTTPS_NODE_PORT to access your application via HTTPS."

  An example Ingress that makes use of the controller:

    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    metadata:
      annotations:
        kubernetes.io/ingress.class: nginx
      name: example
      namespace: foo
    spec:
      rules:
      - host: www.example.com
        http:
        paths:
          - backend:
            serviceName: exampleService
            servicePort: 80
          path: /
   # This section is only required if TLS is to be enabled for the Ingress
   tls:
    - hosts:
        - www.example.com
      secretName: example-tls

   If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:
  apiVersion: v1
  kind: Secret
  metadata:
    name: example-tls
    namespace: foo
  data:
   tls.crt: <base64 encoded cert>
   tls.key: <base64 encoded key>
  type: kubernetes.io/tls

  3. デプロイされたイングレス・コントローラのステータスを確認します:

     kubectl --namespace wcpns get services | grep ingress-nginx-controller

    サンプル出力:

      NAME                                     TYPE          CLUSTER-IP       EXTERNAL-IP         PORT(S) 
  nginx-ingress-ingress-nginx-controller   LoadBalancer  10.96.177.215    144.24.xx.xx        80:32748/TCP,443:31940/TCP

サービスにアクセスするためのtlsのデプロイ

  1. tlsをデプロイしてサービスに安全にアクセスします。ssl-passthroughで構成できるアプリケーションは1つのみです。サービスwcp-domain-cluster-wcp-clusterおよびポート8889のNGINXのサンプルtlsファイルを次に示します。ポート8889で実行されているすべてのアプリケーションに、このイングレスを介して安全にアクセスできます。

  2. NGINXでは、注釈ssl-passthroughによる複数のパスまたはルールがサポートされていないため、バックエンド・サービスごとに異なるイングレスを作成します。たとえば、wcp-domain-adminserverおよびwcp-domain-cluster-wcp-clusterでは、異なるイングレスを作成する必要があります。

  3. NGINXのssl-passthroughは、個々のエンドポイントではなくバッキング・サービスのclusterIPで動作するため、clusterIPを使用してオペレータによって作成されたwcp-domain-cluster-wcp-clusterを公開する必要があります。

    例:

    1. wcp-domainクラスタ・サービスの名前を取得します:

       kubectl get svc  -n wcpns | grep  wcp-domain-cluster-wcp-cluster

      サンプル出力:

       wcp-domain-cluster-wcp-cluster           ClusterIP   10.102.128.124   <none>        8888/TCP,8889/TCP            62m

  4. 保護されたイングレスをデプロイします:

    cd ${WORKDIR}/charts/ingress-per-domain/tls
kubectl create -f nginx-tls.yaml

    ノート: デフォルトのnginx-tls.yamlには、domainUID wcp-domainとともにWebCenter Portalサービスのバックエンドが含まれます。バックエンド・サービスごとに、同様のtls構成YAMLファイルを個別に作成する必要があります。

    nginx-tls.yamlファイルの内容:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wcpns-ingress
  namespace: wcpns
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    nginx.ingress.kubernetes.io/affinity-mode: 'persistent'
    nginx.ingress.kubernetes.io/affinity: 'cookie'
    nginx.ingress.kubernetes.io/session-cookie-name: 'stickyid'
    nginx.ingress.kubernetes.io/session-cookie-expires: '172800'
    nginx.ingress.kubernetes.io/session-cookie-max-age: '172800'
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - '<NGINX_PUBLIC_IP>'
      secretName: wcp-domain-tls-cert
  rules:
    - host: '<NGINX load balancer DNS name>' 
      http:
        paths:
        - backend:
              service:
                name: wcp-domain-cluster-wcp-cluster
                port:
                  number: 8788
          pathType: ImplementationSpecific

    ノート: NGINXロード・バランサのホスト名を指すようにDNS名を指定してください。

  5. イングレスでサポートされているサービスを確認します:

    kubectl describe ingress  wcpns-ingress -n wcpns

エンドツーエンドSSLアクセスの検証

Oracle WebCenter Portalドメイン・アプリケーションURLがLOADBALANCER-HOSTNAMEを介してアクセス可能であることを検証します:

  https://${LOADBALANCER-HOSTNAME}/webcenter
  https://${LOADBALANCER-HOSTNAME}/rsscrawl
  https://${LOADBALANCER-HOSTNAME}/webcenterhelp
  https://${LOADBALANCER-HOSTNAME}/rest
  https://${LOADBALANCER-HOSTNAME}/wsrp-tools

ingress-nginx tlsのアンインストール

  cd ${WORKDIR}/charts/ingress-per-domain/tls
  kubectl  delete -f nginx-tls.yaml
  helm delete nginx-ingress -n wcpns

イングレスを管理するためのTraefik

Oracle WebCenter PortalドメインのイングレスベースのTraefikロード・バランサを構成します。

この項では、Oracle WebCenter Portalドメイン・クラスタをロード・バランシングするように、イングレス・ベースのTraefikロード・バランサ(本番デプロイメントではバージョン2.10.6以降)をインストールおよび構成する方法について説明します。

次のステップに従って、TraefikをKubernetesクラスタ内のOracle WebCenter Portalドメインのロード・バランサとして設定します:

SSL終端

Traefik (イングレスベース)ロード・バランサのインストール

  1. Helmを使用して、Traefik (イングレスベース)ロード・バランサをインストールします。次のvalues.yamlサンプル・ファイルを使用して、必要に応じてkubernetes.namespacesを設定できます。

     cd ${WORKDIR}
 kubectl create namespace traefik
 helm repo add traefik https://helm.traefik.io/traefik --force-update

    サンプル出力:

     "traefik" has been added to your repositories

  2. Traefikをインストールします:

     helm install traefik  traefik/traefik \
     --namespace traefik \
     --values charts/traefik/values.yaml \
     --version 25.0.0" \
     --wait

    サンプル出力:

        LAST DEPLOYED: Sun Sep 13 21:32:00 2020
    NAMESPACE: traefik
    STATUS: deployed
    REVISION: 1
    TEST SUITE: None

    Traefik 2.6.0のデプロイメント用のサンプルvalues.yamlは、次のようになります:

        # Default values for Traefik
image:
  # -- Traefik image host registry
  registry: docker.io
  # -- Traefik image repository
  repository: traefik
  # -- defaults to appVersion
  tag: v2.10.6
  # -- Traefik image pull policy
  pullPolicy: IfNotPresent

# -- Add additional label to all resources
commonLabels: {}

deployment:
  # -- Enable deployment
  enabled: true
  # -- Deployment or DaemonSet
  kind: Deployment
  # -- Number of pods of the deployment (only applies when kind == Deployment)
  replicas: 2
providers:
  kubernetesCRD:
    # -- Load Kubernetes IngressRoute provider
    enabled: true
    # -- Allows IngressRoute to reference resources in namespace other than theirs
    allowCrossNamespace: true
    # -- Array of namespaces to watch. If left empty, Traefik watches all namespaces.
    namespaces: []

  kubernetesIngress:
    # -- Load Kubernetes Ingress provider
    enabled: true
    # -- Array of namespaces to watch. If left empty, Traefik watches all namespaces.
    namespaces: []

additionalArguments:
  - "--api.insecure=true"

ports:
  traefik:
    port: 9000
    expose: true
    exposedPort: 9000
    protocol: TCP
  web:
    port: 8000
    expose: true
    exposedPort: 80
    protocol: TCP
  websecure:
    port: 8443
    expose: true
    exposedPort: 443
    protocol: TCP

service:
  enabled: true
  ## -- Single service is using `MixedProtocolLBService` feature gate.
  ## -- When set to false, it will create two Service, one for TCP and one for UDP.
  single: true
  type: LoadBalancer

  3. Traefikステータスを確認し、サービスのポート番号を見つけます:

     kubectl get all -n traefik

    サンプル出力:

    NAME                           READY   STATUS    RESTARTS   AGE
pod/traefik-78d654477b-4wq79   1/1     Running   0          3d16h
pod/traefik-78d654477b-bmc8r   1/1     Running   0          3d16h

NAME              TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                                     AGE
service/traefik   LoadBalancer   10.96.163.229   100.110.36.28   9000:30921/TCP,80:30302/TCP,443:31008/TCP   3d16h

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/traefik   2/2     2            2           3d16h

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/traefik-78d654477b   2         2         2       3d16h

  4. HTTPホストtraefik.example.comを使用してURL http://$(EXTERNAL-IP):9000を介してTraefikダッシュボードにアクセスします:

     curl -H "host: traefik.example.com" http://$(EXTERNAL-IP):9000/dashboard/

    ノート: $(hostname -f)には必ず完全修飾ノード名を指定してください

ドメインのイングレスの作成

サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します。ここでは、パスベースのルーティングがイングレスに使用されます。デフォルト構成のサンプル値は、${WORKDIR}/charts/ingress-per-domain/values.yamlファイルに示されています。

これらの値をオーバーライドするには、コマンドラインを介して値を渡すか、構成のタイプに基づいてサンプルvalues.yamlファイルでそれらを編集します。

ノート: これは、ルールの完全なリストではありません。外部からアクセスする必要があるアプリケーションURLに基づいてこれを拡張できます。

必要に応じて、イングレスYAMLファイルを更新して、アクセスが必要なドメイン・アプリケーションURLに基づいて(spec.rules.host.http.pathsセクションに)追加のパス・ルールを定義できます。Traefik (イングレスベース)ロード・バランサのテンプレートYAMLファイルは、${WORKDIR}/charts/ingress-per-domain/templates/traefik-ingress.yamlにあります

次に示すような新しいパス・ルールを追加できます:

 - path: /NewPathRule
   backend:
     serviceName: 'Backend Service Name'
     servicePort: 'Backend Service Port'

  1. Oracle WebCenter Portalアプリケーションへのセキュア・アクセス(SSL)の場合は、証明書を作成してKubernetesシークレットを生成します:

     openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt -subj "/CN=*"
 kubectl -n wcpns create secret tls wcp-domain-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt

    ノート: CNの値は、このイングレスがデプロイされるホストです。

  2. Traefik TLSStoreカスタム・リソースを作成します。

    SSL終端の場合は、ユーザー定義のSSL証明書を使用するようにTraefikを構成する必要があります。ユーザー定義のSSL証明書が構成されていない場合、TraefikはデフォルトのSSL証明書を作成します。Traefikのユーザー定義のSSL証明書を構成するには、TLSStoreカスタム・リソースを使用します。SSL証明書を使用して作成されたKubernetesシークレットは、TLSStoreオブジェクトで参照される必要があります。次のコマンドを実行して、TLSStoreを作成します:

    cat <<EOF | kubectl apply -f -
apiVersion: traefik.io/v1alpha1
kind: TLSStore
metadata:
  name: default
  namespace: wcpns
spec:
  defaultCertificate:
    secretName:  wcp-domain-tls-cert   
EOF

  3. SSL構成用にHelmを使用してingress-per-domainをインストールします。

    Kubernetesシークレット名は、テンプレート・ファイルで更新する必要があります。

    テンプレート・ファイルには、次の注釈も含まれています:

     traefik.ingress.kubernetes.io/router.entrypoints: websecure
 traefik.ingress.kubernetes.io/router.tls: "true"
 traefik.ingress.kubernetes.io/router.middlewares: wcpns-wls-proxy-ssl@kubernetescrd

    SSLアクセスのエントリ・ポイントおよびミドルウェア名を注釈で更新する必要があります。ミドルウェア名は、<namespace>-<middleware name>@kubernetescrdという形式にする必要があります。

     cd ${WORKDIR}
 helm install wcp-traefik-ingress  \
   charts/ingress-per-domain \
   --namespace wcpns \
   --values charts/ingress-per-domain/values.yaml \
   --set "traefik.hostname=${LOADBALANCER_HOSTNAME}" \
   --set sslType=SSL

    サンプル出力:

      NAME: wcp-traefik-ingress
  LAST DEPLOYED: Mon Jul 20 11:44:13 2020
  NAMESPACE: wcpns
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None

  4. イングレスでサービスの詳細を取得します:

     kubectl describe ingress wcp-domain-traefik -n wcpns

    前述のデプロイ済イングレスでサポートされるサンプル・サービス:

    Name:             wcp-domain-traefik
Namespace:        wcpns
Address:
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
wcp-domain-tls-cert terminates www.example.com
Rules:
  Host                                          Path  Backends
  ----                                          ----  --------
  www.example.com
                                                /webcenter   wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /console     wcp-domain-adminserver:7001 (10.244.0.51:7001)
                                                /rsscrawl    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /rest        wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)
                                                /webcenterhelp    wcp-domain-cluster-wcp-cluster:8888 (10.244.0.52:8888,10.244.0.53:8888)        
                                                /em          wcp-domain-adminserver:7001 (10.244.0.51:7001)
                                                /wsrp-tools     wcp-domain-cluster-wcportlet-cluster:8889 (10.244.0.52:8889,10.244.0.53:8889)
Annotations:                                    kubernetes.io/ingress.class: traefik
                                                meta.helm.sh/release-name: wcp-traefik-ingress
                                                meta.helm.sh/release-namespace: wcpns
                                                traefik.ingress.kubernetes.io/router.entrypoints: websecure
                                                traefik.ingress.kubernetes.io/router.middlewares: wcpns-wls-proxy-ssl@kubernetescrd
                                                traefik.ingress.kubernetes.io/router.tls: true
Events:                                         <none>

  5. ロード・バランサが新しいイングレスを認識し、ドメイン・サーバー・ポッドへのルーティングに成功したことを確認するには、次のようにHTTP 200ステータス・コードを返すWebLogic ReadyAppフレームワークのURLにリクエストを送信します:

     curl -v https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/weblogic/ready

    サンプル出力:

     *   Trying 149.87.129.203...
 > GET https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/weblogic/ready HTTP/1.1
 > User-Agent: curl/7.29.0
 > Accept: */*
 > Proxy-Connection: Keep-Alive
 > host: $(hostname -f)
 >
 < HTTP/1.1 200 OK
 < Date: Sat, 14 Mar 2020 08:35:03 GMT
 < Vary: Accept-Encoding
 < Content-Length: 0
 < Proxy-Connection: Keep-Alive
 <
 * Connection #0 to host localhost left intact

ドメイン・アプリケーションURLアクセスの検証

Traefik (イングレスベース)ロード・バランサを設定した後、ドメイン・アプリケーションURLにアクセスできることを検証します。Oracle WebCenter PortalドメインのサンプルURLは、次のとおりです:

    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenter
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/console
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/em
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/rsscrawl
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/rest
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/webcenterhelp
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/wsrp-tools

Traefikイングレスのアンインストール

イングレス・デプロイメントをアンインストールして削除します:

helm delete wcp-traefik-ingress  -n wcpns

ElasticsearchへのWebLogic Serverログの公開

ElasticsearchにWebLogic Serverログを公開するには、Logstashを使用するようにWebCenter Portalドメインを構成します。

ElasticsearchおよびKibanaのインストール

ElasticsearchおよびKibanaをインストールするには、次のコマンドを実行します:

cd ${WORKDIR}/elasticsearch-and-kibana
kubectl create -f elasticsearch_and_kibana.yaml

Elasticsearchへの公開

診断またはその他のログは、logstashポッドを使用してElasticsearchサーバーにプッシュできます。logstashポッドは、共有ドメイン・ホームまたはログの場所にアクセスできる必要があります。Oracle WebCenter Portalドメインの場合、ドメイン・ホームの永続ボリュームをlogstashポッドで使用できます。logstashポッドを作成するステップは、次のとおりです。

  1. Oracle WebCenter Portalドメインのドメイン・ホーム永続ボリューム要求の詳細を取得します。次のコマンドは、ネームスペース(wcpns)の永続ボリューム要求の詳細をリストします。次の例では、永続ボリューム要求はwcp-domain-domain-pvcです。

    kubectl get pv -n wcpns

    サンプル出力:

      NAME                   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                         STORAGECLASS                      REASON   AGE
  wcp-domain-domain-pv   10Gi       RWX            Retain           Bound    wcpns/wcp-domain-domain-pvc   wcp-domain-domain-storage-class            175d

  2. logstash構成ファイルlogstash.confを作成します。次のサンプルのLogstash構成ファイルは、${WORKDIR}/logging-services/logstashにあります。次の構成では、診断およびすべてのドメイン・ログがプッシュされます。

    input {                                                                                                                
  file {
    path => "/u01/oracle/user_projects/domains/wcp-domain/servers/**/logs/*-diagnostic.log"
    start_position => beginning
  }
  file {
    path => "/u01/oracle/user_projects/domains/logs/wcp-domain/*.log"
    start_position => beginning
  }
}

filter {                                                                                                               
  grok {                                                                                                               
    match => [ "message", "<%{DATA:log_timestamp}> <%{WORD:log_level}> <%{WORD:thread}> <%{HOSTNAME:hostname}> <%{HOSTNAME:servername}> <%{DATA:timer}> <<%{DATA:kernel}>> <> <%{DATA:uuid}> <%{NUMBER:timestamp}> <%{DATA:misc}> <%{DATA:log_number}> <%{DATA:log_message}>" ]                                                                                        
  }                                                                                                                    
}                                                                                                                         
output {                                                                                                               
  elasticsearch {                                                                                                      
    hosts => ["elasticsearch.default.svc.cluster.local:9200"]
  }                                                                                                                    
}

  3. 管理サーバー・ポッド(ネームスペースwcpnsのwcp-domain-adminserverポッドなど)を使用してlogstashデプロイメントに使用できるように、logstash.confを/u01/oracle/user_projects/domainsなどにコピーします:

     kubectl cp ${WORKDIR}/logging-services/logstash/logstash.conf wcpns/wcp-domain-adminserver:/u01/oracle/user_projects/domains -n wcpns

  4. ドメイン・ホーム永続ボリューム要求を使用して、logstashポッドのデプロイメントYAML logstash.yamlを作成します。logstash構成ファイルが正しい場所を指すように設定し(例: ここではlogstash.confを/u01/oracle/user_projects/domains/logstash.confにコピーしました)、同様に、正しいドメイン・ホーム永続ボリューム要求を指すようにします。サンプルのLogstashデプロイメントは、${WORKDIR}/logging-services/logstash/logstash.yamlにあります:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: logstash
  namespace: wcpns
spec:
  selector:
    matchLabels:
      app: logstash
  template: 
    metadata:
      labels:
        app: logstash
    spec:
      volumes:
      - name: domain-storage-volume
        persistentVolumeClaim:
          claimName: wcp-domain-domain-pvc
      - name: shared-logs
        emptyDir: {}
      containers:
      - name: logstash
        image: logstash:6.6.0
        command: ["/bin/sh"]
        args: ["/usr/share/logstash/bin/logstash", "-f", "/u01/oracle/user_projects/domains/logstash.conf"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /u01/oracle/user_projects/domains
          name: domain-storage-volume
        - name: shared-logs
          mountPath: /shared-logs
        ports:
        - containerPort: 5044
          name: logstash

  5. logstashをデプロイして、Elasticsearchへのログの公開を開始します。

      kubectl create -f  ${WORKDIR}/logging-services/logstash/logstash.yaml

  6. 次のコマンドを入力して、Kibanaダッシュボードへの外部アクセスを提供します。

      kubectl patch svc kibana -n default \
   --type=json -p '[{"op": "replace", "path": "/spec/type", "value": "LoadBalancer" }]'

  7. 管理サーバーおよび管理対象サーバーを再起動します。

Kibanaでの索引パターンの作成

「Kibana」→「Management」で索引パターンlogstash*を作成します。サーバーが起動すると、Kibanaダッシュボードにログ・データが表示されます:

WLS-Kibana-Dashboard

WebCenter Portalドメインのモニター

PrometheusおよびGrafanaを使用してWebCenter Portalドメインをモニターするには、WebLogic Monitoring Exporterを使用してドメイン・インスタンスからメトリックをエクスポートします。このサンプルでは、データをPrometheusにプッシュするようにWebLogic Monitoring Exporterを設定する方法を示します。

前提条件

OracleWebCenterPortalドメインのモニタリングの設定

WebLogic Serverメトリックを収集してOracleWebCenterPortalドメインをモニターするWebLogic Monitoring Exporterを設定します。

ノート: 次のいずれかの方法を使用して、OracleWebCenterPortalドメインのモニタリングを設定できます。setup-monitoring.shを使用すると、設定が自動的に行われます。

  1. 手動による設定
  2. setup-monitoring.shを使用した設定

手動による設定

PrometheusおよびGrafanaのデプロイ

Kube Prometheusの互換性マトリックスを参照し、クラスタのKubernetesバージョンに従ってkube-prometheusリポジトリのリリース・バージョンをクローニングします。

  1. kube-prometheusリポジトリをクローニングします:

    git clone https://github.com/coreos/kube-prometheus.git

  2. フォルダkube-prometheusに移動し、次のコマンドを入力してネームスペースおよびCRDを作成し、残りのリソースを作成する前にそれらが使用可能になるのを待機します:

    cd kube-prometheus
kubectl create -f manifests/setup
until kubectl get servicemonitors --all-namespaces ; do date; sleep 1; echo ""; done
kubectl create -f manifests/

  3. kube-prometheusでは、Kubernetesクラスタ内のすべてのノードにkubernetes.io/os=linuxというラベルが付けられている必要があります。このラベルが付けられていないノードがある場合は、次のコマンドを使用してラベルを付ける必要があります:

    kubectl label nodes --all kubernetes.io/os=linux

  4. Grafanaに外部アクセスを提供するには、サービスをロード・バランサとして公開します。

     kubectl patch svc grafana -n monitoring --type=json -p '[{"op": "replace", "path": "/spec/type", "value": "LoadBalancer" },{"op": "replace", "path": "/spec/ports/0/nodePort", "value": 32100 }]'

    PrometheusおよびAlertmanagerへの外部アクセスを取得するには、LBaaSを作成します。

    cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: wcpinfra-prometheus-loadbalancer
  namespace: monitoring
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-shape: 100Mbps
spec:
  ports:
  - name: http
    port: 9090
    protocol: TCP
    targetPort: 9090
  selector:
    app.kubernetes.io/component: prometheus
  sessionAffinity: None
  type: LoadBalancer
EOF

WebLogic Monitoring Exporterデプロイメント・パッケージの生成

wls-exporter.warパッケージは、ドメイン内のリスニング・ポート(管理サーバーおよび管理対象サーバー)ごとに更新および作成する必要があります。環境に基づいて次の環境値を設定し、スクリプトget-wls-exporter.shを実行して、${WORKDIR}/monitoring-service/scripts/wls-exporter-deployに必要なWARファイルを生成します: - adminServerPort - wlsMonitoringExporterTowcpCluster - wcpManagedServerPort - wlsMonitoringExporterTowcpPortletCluster - wcpPortletManagedServerPort

例:

 cd ${WORKDIR}/monitoring-service/scripts
 export adminServerPort=7001 
 export wlsMonitoringExporterTowcpCluster=true
 export wcpManagedServerPort=8888
 export wlsMonitoringExporterTowcpPortletCluster=true
 export wcpPortletManagedServerPort=8889
 sh get-wls-exporter.sh

必要なWARファイルが${WORKDIR}/monitoring-service/scripts/wls-exporter-deployに生成されたかどうかを検証します。

 ls ${WORKDIR}/monitoring-service/scripts/wls-exporter-deploy

OracleWebCenterPortalドメインへのWebLogic Monitoring Exporterのデプロイ

次のステップに従って、WebLogic Monitoring ExporterのWARファイルをOracleWebCenterPortalドメインにコピーしてデプロイします。

ノート: <xxxx>は、環境に基づいて適切な値に置き換えます:

 cd ${WORKDIR}/monitoring-service/scripts
 kubectl cp wls-exporter-deploy <namespace>/<admin_pod_name>:/u01/oracle
 kubectl cp deploy-weblogic-monitoring-exporter.py <namespace>/<admin_pod_name>:/u01/oracle/wls-exporter-deploy
 kubectl exec -it -n <namespace> <admin_pod_name> -- /u01/oracle/oracle_common/common/bin/wlst.sh /u01/oracle/wls-exporter-deploy/deploy-weblogic-monitoring-exporter.py \
 -domainName <domainUID> -adminServerName <adminServerName> -adminURL <adminURL> \
 -wcpClusterName <wcpClusterName> -wlsMonitoringExporterTowcpCluster <wlsMonitoringExporterTowcpCluster> \
 -wcpPortletClusterName <wcpPortletClusterName> -wlsMonitoringExporterTowcpPortletCluster <wlsMonitoringExporterTowcpPortletCluster> \
 -username <username> -password <password>

例:

 cd ${WORKDIR}/monitoring-service/scripts
 kubectl cp wls-exporter-deploy wcpns/wcp-domain-adminserver:/u01/oracle
 kubectl cp deploy-weblogic-monitoring-exporter.py wcpns/wcp-domain-adminserver:/u01/oracle/wls-exporter-deploy
 kubectl exec -it -n wcpns wcp-domain-adminserver -- /u01/oracle/oracle_common/common/bin/wlst.sh /u01/oracle/wls-exporter-deploy/deploy-weblogic-monitoring-exporter.py \
 -domainName wcp-domain -adminServerName AdminServer -adminURL wcp-domain-adminserver:7001 \
 -wcpClusterName wcp-cluster -wlsMonitoringExporterTowcpCluster true \
 -wcpPortletClusterName wcportlet-cluster -wlsMonitoringExporterTowcpPortletCluster true \
 -username weblogic -password Welcome1

Prometheus Operatorの構成

Prometheusを使用すると、WebLogic Monitoring Exporterからメトリックを収集できます。Prometheus Operatorは、サービス検出を使用してターゲットを識別します。WebLogic Monitoring Exporterのエンド・ポイントをターゲットとして検出するには、サービスを指すサービス・モニターを作成する必要があります。

サービス・モニター・デプロイメントのYAML構成ファイルは、${WORKDIR}/monitoring-service/manifests/wls-exporter-ServiceMonitor.yaml.templateにあります。ファイルをwls-exporter-ServiceMonitor.yamlとしてコピーし、次に示すように適切な値で更新します。

wls-exporterからのメトリックのエクスポートにはbasicAuthが必要であるため、base64でエンコードされたユーザー名とパスワードを使用してKubernetesシークレットが作成されます。このシークレットは、ServiceMonitorデプロイメントで使用されます。wls-exporter-ServiceMonitor.yamlには、wcpnsというネームスペースがあり、username: %USERNAME%およびpassword: %PASSWORD%という資格証明を持つbasicAuthがあります。base64エンコードで%USERNAME%および%PASSWORD%を更新し、環境に基づいてwcpnsのすべての出現箇所を更新します。

base64エンコードでは次の例を使用します:

 echo -n "Welcome1" | base64
 V2VsY29tZTE=

KubernetesクラスタでWebLogic Serverポッドが実行されているネームスペース(wcpns)にRoleBindingおよびRoleを追加する必要があります。これらは、WebLogic Monitoring Exporterによって提供されるエンドポイントにPrometheusがアクセスするために必要です。wcpnsネームスペースのYAML構成ファイルは、"${WORKDIR}/monitoring-service/manifests/"で提供されています。

wcpns以外のネームスペースを使用している場合は、prometheus-roleBinding-domain-namespace.yamlおよびprometheus-roleSpecific-domain-namespace.yamlでネームスペースの詳細を更新します。

PrometheusがWebLogic Monitoring Exporterからメトリックを収集できるようにするには、次のステップを実行します:

 cd ${WORKDIR}/monitoring-service/manifests
 kubectl apply -f .

WebLogic Monitoring Exporterのサービス検出の検証

サービス・モニターのデプロイ後、Prometheusはwls-exporterを検出してメトリックを収集できる必要があります。

  1. Prometheusダッシュボード(http://<<LOADBALANCER-IP>>:9090/)にアクセスします

  2. 「Status」に移動して、「Service Discovery」の詳細を参照します。

  3. 検出されたサービスにwls-exporterがリストされていることを確認します。

Grafanaダッシュボードのデプロイ

Grafanaダッシュボードにはhttp://LOADBALANCER-IP:3000/でアクセスできます。

  1. ユーザー名: adminおよびパスワード: adminを使用してGrafanaダッシュボードにログインします。

  2. 「+」(Create)→「Import」に移動し、weblogic-server-dashboard-import.jsonファイル(${WORKDIR}/monitoring-service/config/weblogic-server-dashboard-import.jsonで提供)をアップロードします。

setup-monitoring.shを使用した設定

設定モニタリング・スクリプトを使用する準備

OracleWebCenterPortalドメインの設定モニタリングのサンプル・スクリプトは、${WORKDIR}/monitoring-serviceにあります。

monitoring-inputs.yaml(またはそのコピー)を編集して、ドメインの詳細を指定する必要があります。このファイルに指定する必要がある情報を理解するには、次の構成パラメータを参照してください。

構成パラメータ

入力ファイルには、次のパラメータを指定できます。

パラメータ 説明 デフォルト
domainUID OracleWebCenterPortalドメインのdomainUID。 wcp-domain
domainNamespace OracleWebCenterPortalドメインのKubernetesネームスペース。 wcpns
setupKubePrometheusStack kube-prometheus-stack (Prometheus、GrafanaおよびAlertmanager)をインストールするかどうかを示すブール値 true
additionalParamForKubePrometheusStack このスクリプトは、service.typeをNodePortとして、service.nodePortの値をmonitoring-inputs.yamlに定義されたパラメータに従って、kube-prometheus-stackをインストールします。additionalParamForKubePrometheusStackパラメータを使用して、values.yamlに従って追加パラメータでさらに構成します。NodeExporter、Prometheus-Operator TLSサポート、およびPrometheusRulesリソースのアドミッションWebフック・サポートを無効にするサンプル値は、--set nodeExporter.enabled=false --set prometheusOperator.tls.enabled=false --set prometheusOperator.admissionWebhooks.enabled=falseです
monitoringNamespace モニタリング設定のKubernetesネームスペース。 monitoring
adminServerName 管理サーバーの名前。 AdminServer
adminServerPort Kubernetesクラスタ内の管理サーバーのポート番号。 7001
wcpClusterName wcpClusterの名前。 wcp_cluster
wcpManagedServerPort wcpCluster内の管理対象サーバーのポート番号。 8888
wlsMonitoringExporterTowcpCluster WebLogic Monitoring ExporterをwcpClusterにデプロイするかどうかを示すブール値。 false
wcpPortletClusterName wcpPortletClusterの名前。 wcportlet-cluster
wcpManagedServerPort wcpPortletCluster内のポートレット管理対象サーバーのポート番号。 8889
wlsMonitoringExporterTowcpPortletCluster WebLogic Monitoring ExporterをwcpPortletClusterにデプロイするかどうかを示すブール値。 false
exposeMonitoringNodePort モニタリング・サービス(Prometheus、GrafanaおよびAlertmanager)がKubernetesクラスタの外部に公開されているかどうかを示すブール値。 false
prometheusNodePort Kubernetesクラスタ外部のPrometheusのポート番号。 32101
grafanaNodePort Kubernetesクラスタ外部のGrafanaのポート番号。 32100
alertmanagerNodePort Kubernetesクラスタ外部のAlertmanagerのポート番号。 32102
weblogicCredentialsSecretName 管理サーバーのユーザー名とパスワードを含むKubernetesシークレットの名前。 wcp-domain-domain-credentials

monitoring-inputs.yamlファイルで指定された値は、install kube-prometheus-stack (Prometheus、GrafanaおよびAlertmanager)のインストールおよびWebLogic Monitoring ExporterのOracleWebCenterPortalドメインへのデプロイに使用されます。そのため、ドメイン固有の値は、ドメイン作成時に使用された値と同じにしてください。

設定モニタリング・スクリプトの実行

要件に従ってmonitoring-inputs.yamlの値を更新し、入力ファイルを指定してsetup-monitoring.shスクリプトを実行します:

 cd ${WORKDIR}/monitoring-service
 ./setup-monitoring.sh \
   -i monitoring-inputs.yaml

このスクリプトは、次のステップを実行します:

結果の検証

設定モニタリング・スクリプトは、エラーが発生すると失敗をレポートします。ただし、必要なリソースがスクリプトによって作成されていることを確認してください。

kube-prometheus-stackの検証

setupKubePrometheusStackがtrueに設定されているときにprometheus-community/kube-prometheus-stackがインストールされたことを確認するには、次のコマンドを実行します:

 helm ls -n monitoring

サンプル出力:

NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
monitoring      monitoring      1               2021-06-18 12:58:35.177221969 +0000 UTC deployed        kube-prometheus-stack-16.5.0    0.48.0
Prometheus、GrafanaおよびAlertmanagerの設定の検証

exposeMonitoringNodePortがtrueに設定されている場合、モニタリング・サービスがKubernetesクラスタの外部でアクセス可能であることを検証します:

WebLogic Monitoring Exporterのサービス検出の検証

Prometheusがwls-exporterを検出してメトリックを収集できるかどうかを検証します:

  1. Prometheusダッシュボード(http://mycompany.com:32101/)にアクセスします

  2. 「Status」に移動して、「Service Discovery」の詳細を参照します。

  3. 検出されたサービスにwls-exporterがリストされていることを確認します。

WebLogic Serverダッシュボードの検証

Grafanaダッシュボードにはhttp://mycompany.com:32100/でアクセスできます

  1. ユーザー名: adminおよびパスワード: adminを使用してGrafanaダッシュボードにログインします。

  2. 「General」の下の「WebLogic Server Dashboard」に移動して確認します。

    WebLogic Serverダッシュボードが表示されます。

    Wme-GP-WLS-Dashboard

モニタリング設定の削除

「設定モニタリング・スクリプトの実行」で作成したモニタリング設定を削除するには、次のコマンドを実行します:

 cd ${WORKDIR}/monitoring-service
 ./delete-monitoring.sh \
   -i monitoring-inputs.yaml

SAML 2.0 (IDCS)シングル・サインオンの構成

この項では、Oracle WebCenter Portal用にIDCSを使用してSAML 2.0 SSOを構成するステップについて説明します。

内容

前提条件

Oracle WebCenter PortalのIDCSでは、次のロード・バランサ構成を使用します:

  1. エンドツーエンドSSL構成を使用したNGINXロード・バランサのOracle WebCenter Portalクラスタ

  2. LBaaSの管理サーバー

SAML 2.0アサータの構成

SAML 2.0アサータを構成するには:

  1. Oracle WebLogic Server管理コンソールにログインします。

  2. 「ドメイン構造」ペインの「セキュリティ・レルム」をクリックします。

  3. 「セキュリティ・レルムのサマリー」ページで、レルムの名前(myrealmなど)を選択します。「myrealm」をクリックします。「myrealmの設定」ページが表示されます。

  4. 「プロバイダ」、「認証」の順にクリックします。新しい認証プロバイダを作成するには、認証プロバイダの表で「新規」をクリックします。

  5. 「新しい認証プロバイダの作成」ページで、新しいアサータの名前(SAML2Asserterなど)を入力し、ドロップダウン・リストから認証プロバイダの「SAML2IdentityAsserter」タイプを選択して、「OK」をクリックします。

  6. SAML2Asserterが「認証プロバイダ」表に表示されます。

  7. 「セキュリティ・レルム」、「myrealm」、「プロバイダ」の順に選択します。認証プロバイダの表で、「並替え」をクリックします。

  8. 「認証プロバイダ」ページで、SAML2Asserterを一番上に移動し、「OK」をクリックします。

  9. /bin/setUserOverrides.shにOSSOプロパティを追加します。(存在しない場合はファイルを作成します)

#add below line in the setUserOverrides.sh file

EXTRA_JAVA_PROPERTIES="-Doracle.webcenter.spaces.osso=true ${EXTRA_JAVA_PROPERTIES}"
 
export EXTRA_JAVA_PROPERTIES

**管理サーバーおよび管理対象サーバーを再起動します。

SAML 2.0 SSOサービス・プロバイダとしてのOracle WebCenter Portal管理対象サーバーの構成

WebLogic管理対象サーバーをSAML 2.0 SSOサービス・プロバイダとして構成するには:

  1. WebLogic Server管理コンソールにログインします。

  2. 「ドメイン構造」ペインで、「環境」をクリックします。「環境のサマリー」ページが表示されます。

  3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  4. (WebCenter Portalサーバーの)管理対象サーバーに移動し、「フェデレーション・サービス」、「SAML 2.0サービス・プロバイダ」の順にクリックします。「サービス・プロバイダ」ページで次のようにします:

  5. 「有効」チェック・ボックスを選択します。

  6. 「優先バインド」フィールドで、ドロップダウン・リストから値「POST」を選択します。

  7. 「デフォルトURL」フィールドに、http://<HOST/IP>:\<PORT>/webcenterまたはhttps://<HOST/IP>:\<SSL_PORT>/webcenterを入力します

  8. 「保存」をクリックします。すべてのOracle WebCenter Portal管理対象サーバーに対して前述のステップを繰り返します。Oracle WebCenter PortalのデフォルトURLは、http://<HOST/IP>:\<PORT>/webcenterまたはhttps://<HOST/IP>:\<SSL_PORT>/webcenterです

  9. (Oracle WebCenter Portalサーバーの)管理対象サーバーに移動し、「フェデレーション・サービス」、「SAML 2.0全般」の順にクリックします。

  10. 「レプリケートされたキャッシュの有効化」チェック・ボックスを選択します。

  11. 「公開サイトのURL」フィールドに、http://<HOST/IP>:\<PORT>/saml2またはhttps://<HOST/IP>:\<PORT>/saml2を入力します

  12. 「エンティティID」フィールドに、値wcpを入力します。任意の名前(wcpなど)にできますが、一意である必要があります。このIDは、IDCSでSAMLを構成する際に使用するため、ノートにとっておきます。

  13. 「保存」をクリックします。管理対象サーバーを再起動します。

  14. SPメタデータをファイル<DOMAIN_HOME>/<Entity_ID>_sp_metadata.xmlに公開します。他のSAML IDPとは異なり、IDCSではこれをインポートする必要はありませんが、参照目的で役立つ場合もあります。

SAML 2.0アイデンティティ・アサータ構成の完了

SAML 2.0アイデンティティ・アサータ構成を完了するには:

  1. IDCSメタデータ・ファイルをhttps://<IDCS_HOST>/fed/v1/metadataからダウンロードします。これは、SP (この場合はWebLogic Server)にインポートする必要があるIdP (この場合はIDCS)メタデータです。ファイルを管理サーバーにコピーします。> ノート: 「署名証明書へのアクセス」はデフォルトで無効になっています。有効にするには > IDCS管理コンソールにログオンします。https://<my_tenancy_id>.identity.oraclecloud.com/ui/v1/adminconsole > IDCSコンソール >「設定」>「デフォルト設定」>「署名証明書へのアクセス」>「有効」の順に移動します。

  2. 「ドメイン構造」ペインの「セキュリティ・レルム」をクリックします。

  3. 「セキュリティ・レルムのサマリー」ページで、レルムの名前(myrealmなど)を選択します。「myrealm」をクリックします。「myrealmの設定」ページが表示されます。

  4. 「レルム名の設定」ページで、「プロバイダ」→「認証」を選択します。「認証プロバイダ」表で、SAML 2.0アイデンティティ・アサーション・プロバイダ(SAML2Asserterなど)を選択します。「SAML2Asserterの設定」ページが表示されます。

  5. 「SAML2Asserterの設定」ページで、「管理」を選択します。

  6. 「アイデンティティ・プロバイダ・パートナ」の下の表で、「新規」→「新しいWebシングル・サインオンのアイデンティティ・プロバイダ・パートナの追加」をクリックします。

  7. 「SAML 2.0 Webシングル・サインオンのアイデンティティ・プロバイダ・パートナの作成」ページで、アイデンティティ・プロバイダ・パートナの名前を指定します。「パス」フィールドで、IDCSメタデータ・ファイルの場所を指定します。「OK」をクリックします。

  8. 「SAML 2.0アイデンティティ・アサーション・プロバイダの設定」ページの「アイデンティティ・プロバイダ・パートナ」表で、新しく作成したWebシングル・サインオンのアイデンティティ・プロバイダ・パートナの名前を選択します。

  9. 「一般」ページで、「有効」チェック・ボックスを選択します。サーバーに固有のリダイレクトURIを指定します。WebCenter Portalの場合、/adfAuthentication /webcenter/adfAuthenticationです。

  10. 「保存」をクリックします。

  11. 「セキュリティ・レルム」→「myrealm」→「プロバイダ」を選択します。認証プロバイダの表で、「並替え」をクリックします。

  12. 「認証プロバイダの並替え」ページで、SAML2Asserterをオーセンティケータのリストの一番上に移動して、「OK」をクリックします。管理サーバーおよび管理対象サーバーを再起動します。

IDCSでのSAMLアプリケーションの作成

IDCSでSAMLアプリケーションを作成するには:

  1. IDCS管理コンソールにログインします。

  2. IDCS管理コンソールの「アプリケーション」アイコンで、「アプリケーションの追加」をクリックします。アプリケーションのリストが表示されます。「SAMLアプリケーション」を選択します。

  3. SAMLアプリケーション詳細の追加ページで、アプリケーションの名前およびそのURLを入力します。たとえば、http://<HOST/IP>:\<PORT>/webcenterまたはhttps://<HOST/IP>:\<SSL_PORT>/webcenterです。

  4. アプリケーション名は一意である必要があります(WCPSAMLなど)。

  5. SAMLアプリケーションSSO構成の追加ページで、次を実行します:

  6. 「エンティティID」フィールドに、値wcpを入力します。これは、管理対象サーバーのサービス・プロバイダで設定されている「エンティティID」と同じです。

  7. 「アサーション・コンシューマのURL」フィールドに、http://<HOST/IP>:\<PORT>/saml2/sp/acs/postまたはhttps://<HOST/IP>:\<SSL_PORT>/saml2/sp/acs/postを入力します(場所はSPメタデータxmlファイル(wcp_sp_metadata.xmlなど)のmd:AssertionConsumerService属性からコピーします)。

  8. 「NameID形式」フィールドで、ドロップダウン・リストから「指定なし」オプションを選択します。

  9. 「NameID値」フィールドで、ドロップダウン・リストから「ユーザー名」オプションを選択します。

  10. 「詳細設定」で、次を実行します

  11. 「ログアウト・バインド」フィールドで、ドロップダウン・リストから「POST」オプションを選択します。

  12. 「シングル・ログアウトURL」フィールドで、http://<HOST/IP>:\<PORT>/adfAuthentication?logout=trueまたはhttps://<HOST/IP>:\<SSL_PORT>/adfAuthentication?logout=trueを入力します

  13. 「ログアウト・レスポンスURL」フィールドで、http://<HOST/IP>:\<PORT>/adfAuthentication?logout=trueまたはhttps://<HOST/IP>:\<SSL_PORT>/adfAuthentication?logout=trueを入力します

  14. 「終了」をクリックして、SAMLアプリケーションを作成し、アプリケーションをアクティブ化します。

Oracle WebLogic ServerでのSAMLアプリケーションへのグループの割当ておよびユーザーの作成

IDCS SAMLを介してユーザーを認証するためには、SAMLアプリケーションにユーザーを追加する必要があります。ユーザーがIDCSグループのメンバーである場合、そのグループをアプリケーションに追加すると、それらのユーザーが認証されます。

グループをSAMLアプリケーションに割り当てるには:

  1. IDCSでグループ(WebcenterPortalGroupなど)を作成し、それをSAMLアプリケーションに割り当てます。
  2. SAMLアプリケーションに移動します。「グループ」→「割当て」をクリックします。WebcenterPortalGroupグループを割り当てます。
  3. IDCSユーザーをWebcenterGroupグループに追加します。

ノート: このグループに属するユーザーのみが、WebCenter Portalアプリケーションを使用できるようになります。

ユーザーもOracle WebLogic Serverで作成する必要があります 1.管理コンソール(http://<HOST/IP>:\<PORT>/consoleまたはhttps://<HOST/IP>:\<PORT>/console)にログインします 1.セキュリティ・レルム「myrealm」をクリックし、「ユーザーとグループ」タブを選択します 1.新規ユーザーを作成し、関連情報を入力します。1.WebcenterGroupグループに属するすべてのユーザーを作成する必要があります。

SAML 2.0の場合、Cookieパスは「/」に設定する必要があります。次のステップに従って、WebCenter PortalのCookieパスを「/」に更新します:

  1. DOMAIN_HOMEにplan.xmlファイルを作成します。plan.xmlのconfig-root要素は、DOMAIN_HOMEディレクトリ(/u01/oracle/user_projects/domains/wcp-domainなど)を指している必要があります

    サンプルplan.xml:

    <?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-deployment-plan.xsd" global-variables="false">
<application-name>webcenter</application-name>
<variable-definition>
<variable>
<name>newCookiePath</name>
<value>/</value>
</variable>
</variable-definition>

<module-override>
<module-name>spaces.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
<variable-assignment>
<name>newCookiePath</name>
<xpath>/weblogic-web-app/session-descriptor/cookie-path</xpath>
<operation>replace</operation>
</variable-assignment>
</module-descriptor>
</module-override>
<config-root>/u01/oracle/user_projects/domains/wcp-domain</config-root>
</deployment-plan>

  2. weblogic.Deployerを使用して再デプロイします:

     kubectl exec -n wcpns -it wcp-domain-adminserver -- /bin/bash
 java -cp /u01/oracle/wlserver/server/lib/weblogic.jar:. weblogic.Deployer -username weblogic -password welcome1 -adminurl t3://wcp-domain-adminserver:7001 -plan /u01/oracle/user_projects/domains/wcp-domain/plan.xml -deploy /u01/oracle/wcportal/archives/applications/webcenter.ear -targets wcp-cluster

'wcp-cluster'をターゲットにするには、すべてのOracle WebCenter Portalサーバーが実行されていることを確認します。

付録

この項では、KubernetesでのOracle WebCenter Portalデプロイメントに関連するその他のタスクについて説明します。

ドメイン・リソースのサイズ設定

KubernetesクラスタでのOracle WebCenter Portalドメイン設定のリソース・サイズ設定情報について説明します。

Oracle WebCenter Portalクラスタのサイズ設定に関する推奨事項

WebCenter Portal 通常の使用状況 中程度の使用状況 高水準の使用状況
管理サーバー CPU数: 1、メモリー: 4GB CPU数: 1、メモリー: 4GB CPU数: 1、メモリー: 4GB
管理対象サーバーの数 サーバー数: 2 サーバー数: 2 サーバー数: 3
管理対象サーバー当たりの構成 CPU数: 2、メモリー: 16GB CPU数: 4、メモリー: 16GB CPU数: 6、メモリー: 16-32GB
PVストレージ 最小250GB 最小250GB 最小500GB

オンプレミスでのクイック・スタート・デプロイメント

開発およびテスト目的で(特別なことをせずにデフォルト設定を使用して) Oracle WebCenter Portalドメイン・インスタンスを迅速に実行する方法を説明します。

このクイック・スタートを使用して、WebLogic Kubernetes OperatorでKubernetesクラスタ(オンプレミス環境)にOracle WebCenter Portalドメイン・デプロイメントを作成します。この段階的な手順は、デモンストレーションのみを目的としており、本番では使用できないことに注意してください。これらの手順は、ユーザーがKubernetesをすでによく理解していることを前提としています。詳細な手順が必要な場合は、「インストール・ガイド」を参照してください。

ハードウェア要件

オペレータを使用してOracle WebCenter Portalドメインをデプロイおよび実行するためにサポートされているLinuxカーネルは、Oracle Linux 7 (UL6+)およびRed Hat Enterprise Linux 7 (スタンドアロンKubernetesでのみUL3+)です。詳細は、前提条件を参照してください。

この演習で、単一ノードのKubernetesクラスタを作成し、コンテナとして実行されるOracle Databaseとともに1つの管理対象サーバーを含むドメイン・タイプをデプロイするための最小ハードウェア要件は、次のとおりです:

ハードウェア サイズ
RAM 32GB
ディスク領域 250GB+
CPUコア 6

KubernetesクラスタでのOracle WebCenter Portalドメイン設定のリソース・サイズ設定情報は、ここを参照してください。

オンプレミス環境でのOracle WebCenter Portalの設定

このトピックのステップを使用して、単一インスタンスのオンプレミスKubernetesクラスタを作成し、次にOracle WebCenter Portalドメインを作成します。

1. Kubernetesクラスタ用の仮想マシンの準備

説明目的のため、これらの手順はOracle Linux 8用です。Linuxの異なるフレーバを使用している場合は、それに応じてステップを調整する必要があります。

ノート: これらのステップは、特に指定がないかぎり、rootユーザーで実行する必要があります。コマンドにYOUR_USERIDが見つかった場合は、常に実際のuseridに置き換える必要があります。

1.1 前提条件

  1. Kubernetesファイルを格納するディレクトリを選択します。Kubernetesディレクトリは、/var/lib/kubeletファイル・システムおよび永続ボリューム・ストレージに使用されます。

     export kubelet_dir=/u01/kubelet
 mkdir -p $kubelet_dir
 ln -s $kubelet_dir /var/lib/kubelet

  2. ホストでIPv4転送が有効になっていることを確認します。

    ノート: eth0は、コンピュート・リソースのイーサネット・インタフェース名に置き換えます(異なる場合)。

     /sbin/sysctl -a 2>&1|grep -s 'net.ipv4.conf.eth0.forwarding'
 /sbin/sysctl -a 2>&1|grep -s 'net.ipv4.conf.lo.forwarding'
 /sbin/sysctl -a 2>&1|grep -s 'net.ipv4.ip_nonlocal_bind'

    例: すべてが1に設定されていることを確認します:

     net.ipv4.conf.eth0.forwarding = 1
 net.ipv4.conf.lo.forwarding = 1
 net.ipv4.ip_nonlocal_bind = 1

    解決策: すべての値を即座に1に設定します:

     /sbin/sysctl net.ipv4.conf.eth0.forwarding=1
 /sbin/sysctl net.ipv4.conf.lo.forwarding=1
 /sbin/sysctl net.ipv4.ip_nonlocal_bind=1

  3. 設定を永続的に保持するには: /usr/lib/sysctl.d/、/run/sysctl.d/および/etc/sysctl.d/にあるファイルで、前述の値を1に更新します。

  4. 転送用のiptablesルールを確認します。

    転送用のiptablesルールを確認します。Kubernetesは、iptablesを使用して様々なネットワーキングおよびポート転送ルールを管理します。標準のコンテナ・インストールでは、転送を妨げるファイアウォール・ルールが作成されることがあります。転送トラフィックを受け入れるiptablesルールが設定されているかどうかを確認します:

     /sbin/iptables -L -n | awk '/Chain FORWARD / {print $4}' | tr -d ")"

    出力が"DROP"の場合は、次のコマンドを実行します:

     /sbin/iptables -P FORWARD ACCEPT

    iptablesルールが"ACCEPT"に正しく設定されているかどうかを確認します:

     /sbin/iptables -L -n | awk '/Chain FORWARD / {print $4}' | tr -d ")"

  5. firewalldを無効化および停止します:

     systemctl disable firewalld
 systemctl stop firewalld

CRI-OおよびPodmanのインストール

ノート: すでにCRI-OおよびPodmanを構成している場合は、Kubernetesのインストールおよび構成を続行できます。

  1. オペレーティング・システムのバージョンが適切であることを確認します:

     uname -a
 more /etc/oracle-release

    出力例:

    Linux xxxxxx 5.15.0-100.96.32.el8uek.x86_64 #2 SMP Tue Feb 27 18:08:15 PDT 2024 x86_64 x86_64 x86_64 GNU/Linux
Oracle Linux Server release 8.6

  2. CRI-Oをインストールします:

    ### Add OLCNE( Oracle Cloud Native Environment ) Repository to dnf config-manager. This allows dnf to install the additional packages required for CRI-O installation.
dnf config-manager --add-repo https://yum.oracle.com/repo/OracleLinux/OL9/olcne18/x86_64

### Installing cri-o
dnf install -y cri-o

ノート: 別のバージョンのCRI-Oをインストールするか、別のオペレーティング・システムにインストールするには、CRI-Oのインストール手順を参照してください。

  1. CRI-Oサービスを起動します:

カーネル・モジュールおよびプロキシの設定

### Enable kernel modules overlay and br_netfilter which are required for Kubernetes Container Network Interface (CNI) plugins
modprobe overlay
modprobe br_netfilter

### To automatically load these modules at system start up create config as below
cat <<EOF > /etc/modules-load.d/crio.conf
overlay
br_netfilter
EOF
sysctl --system

### Set the environmental variable CONTAINER_RUNTIME_ENDPOINT to crio.sock to use crio as the container runtime
$ export CONTAINER_RUNTIME_ENDPOINT=unix:///var/run/crio/crio.sock

### Setup Proxy for CRIO service
cat <<EOF > /etc/sysconfig/crio
http_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
https_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
HTTPS_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
HTTP_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
no_proxy=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock
NO_PROXY=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock
EOF

CRI-Oのランタイムの設定

 ### Setting the runtime for crio
 ## Update crio.conf
 vi /etc/crio/crio.conf

 ## Append following under [crio.runtime]
 conmon_cgroup = "kubepods.slice"
 cgroup_manager = "systemd"

 ## Uncomment following under [crio.network]
 network_dir="/etc/cni/net.d"
 plugin_dirs=[
    "/opt/cni/bin",
    "/usr/libexec/cni",
 ]

CRI-Oサービスの起動

 ## Restart crio service
 systemctl restart crio.service
 systemctl enable --now crio
  1. Podmanをインストールします。Oracle Linux 8で、podmanが使用できない場合は、次のコマンド構文を使用してPodmanおよび関連ツールをインストールします:
 sudo dnf module install container-tools:ol8

Oracle Linux 9で、podmanが使用できない場合は、次のコマンド構文を使用してPodmanおよび関連ツールをインストールします:

 sudo dnf install container-tools

設定ではdocker CLIコマンドが使用されるため、Oracle Linux 8/9では、次のコマンド構文を使用してpodman-dockerパッケージをインストールしてください(使用できない場合)。これにより、dockerコマンドが有効にpodmanにエイリアスされます:

 sudo dnf install podman-docker
  1. Podmanルートレスを構成します:

ユーザーIDでpodmanを使用する場合(ルートレス環境)、Podmanでは、それを実行しているユーザーに、ファイル/etc/subuidおよび/etc/subgidにリストされているUIDの範囲が必要です。ファイルを直接更新するのではなく、usermodプログラムを使用して、次のコマンドでUIDとGIDをユーザーに割り当てることができます:

 sudo /sbin/usermod --add-subuids 100000-165535 --add-subgids 100000-165535 <REPLACE_USER_ID>
 podman system migrate

ノート: 前述の"podman system migrate"は、rootではなくユーザーIDで実行する必要があります。

user-id追加の検証

 cat /etc/subuid
 cat /etc/subgid

予想される同様の出力

 opc:100000:65536
 <user-id>:100000:65536

1.3 Kubernetesのインストールおよび構成

  1. 外部Kubernetesリポジトリを追加します:
  cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
  [kubernetes]
  name=Kubernetes
  baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/
  enabled=1
  gpgcheck=1
  gpgkey=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key
  exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
  EOF

  1. SELinuxを許可モードに設定します(実質的に無効化します):

      export PATH=/sbin:$PATH
  setenforce 0
  sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

  2. プロキシをエクスポートし、kubeletを有効化します:

     ### Get the nslookup IP address of the master node to use with apiserver-advertise-address during setting up Kubernetes master
 ### as the host may have different internal ip (hostname -i) and nslookup $HOSTNAME
 ip_addr=`nslookup $(hostname -f) | grep -m2 Address | tail -n1| awk -F: '{print $2}'| tr -d " "`
 echo $ip_addr

 ### Set the proxies
 export NO_PROXY=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock,$ip_addr,.svc
 export no_proxy=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock,$ip_addr,.svc
 export http_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
 export https_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
 export HTTPS_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
 export HTTP_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT

 ### Install the kubernetes components and enable the kubelet service so that it automatically restarts on reboot
 dnf install -y kubeadm kubelet kubectl
 systemctl enable --now kubelet

  3. トラフィック・ルーティングの問題を回避するために、sysctlでnet.bridge.bridge-nf-call-iptablesが1に設定されていることを確認します:

     cat <<EOF >  /etc/sysctl.d/k8s.conf
 net.bridge.bridge-nf-call-ip6tables = 1
 net.bridge.bridge-nf-call-iptables = 1
 EOF
 sysctl --system

  4. スワップ・チェックを無効化します:

     sed -i 's/KUBELET_EXTRA_ARGS=/KUBELET_EXTRA_ARGS="--fail-swap-on=false"/' /etc/sysconfig/kubelet
 cat /etc/sysconfig/kubelet

 ### Reload and restart kubelet
 systemctl daemon-reload
 systemctl restart kubelet

  5. crioを使用してイメージをプルします:

     kubeadm config images pull --cri-socket unix:///var/run/crio/crio.sock

1.4 Helmの設定

  1. Helm v3.10.2+をインストールします。

    1. https://github.com/helm/helm/releasesからHelmをダウンロードします。

      たとえば、Helm v3.10.2をダウンロードするには:

       wget https://get.helm.sh/helm-v3.10.2-linux-amd64.tar.gz

    2. tar.gzを解凍します:

       tar -zxvf helm-v3.10.2-linux-amd64.tar.gz

    3. 解凍したディレクトリでHelmバイナリを検索し、目的の宛先に移動します:

       mv linux-amd64/helm /usr/bin/helm

  2. helm versionを実行して、インストールを確認します:

     helm version

 version.BuildInfo{Version:"v3.10.2", GitCommit:"50f003e5ee8704ec937a756c646870227d7c8b58", GitTreeState:"clean", GoVersion:"go1.18.8"}

2. 単一インスタンスのKubernetesクラスタの設定

ノート:

2.1 マスター・ノードの設定

  1. 必要な環境変数を設定するシェル・スクリプトを作成します。これは、ログイン時に実行されるようにユーザーの.bashrcに追加できます。HTTPプロキシの背後にいる場合は、ここでプロキシ設定を構成する必要もあります:

    ## grab my IP address to pass into  kubeadm init, and to add to no_proxy vars
ip_addr=`nslookup $(hostname -f) | grep -m2 Address | tail -n1| awk -F: '{print $2}'| tr -d " "`
export pod_network_cidr="10.244.0.0/16"
export service_cidr="10.96.0.0/12"
export PATH=$PATH:/sbin:/usr/sbin

### Set the proxies
export NO_PROXY=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/docker.sock,$ip_addr,$pod_network_cidr,$service_cidr
export no_proxy=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/docker.sock,$ip_addr,$pod_network_cidr,$service_cidr
export http_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
export https_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
export HTTPS_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
export HTTP_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT

  2. スクリプトを調達して環境変数を設定します:

     ~/.bashrc

  3. コマンド補完を実装するには、スクリプトに次を追加します:

     [ -f /usr/share/bash-completion/bash_completion ] && . /usr/share/bash-completion/bash_completion
 source <(kubectl completion bash)

  4. kubeadm initを実行して、マスター・ノードを作成します:

     kubeadm init \
  --pod-network-cidr=$pod_network_cidr \
  --apiserver-advertise-address=$ip_addr \
  --ignore-preflight-errors=Swap  > /tmp/kubeadm-init.out 2>&1

  5. YOUR_USERID:YOUR_GROUPを使用してターミナルにログインします。次に、YOUR_USERID:YOUR_GROUPを使用して、ステップ1から3と同様に~/.bashrcを設定します。

    ノート: 今後は、rootではなくYOUR_USERID:YOUR_GROUPを使用して、任意のkubectlコマンドを実行します。

  6. KubernetesクラスタにアクセスするためのYOUR_USERID:YOUR_GROUPを設定します:

     mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config

  7. kubectlコマンドを使用して、KubernetesクラスタにアクセスするためのYOUR_USERID:YOUR_GROUPが設定されていることを確認します:

     kubectl get nodes

    ノート: このステップでは、ポッド・ネットワーク・アドオンがまだインストールされていないため、ノードは準備完了状態ではありません。次のステップの後、ノードのステータスはReadyと表示されます。

  8. ポッド・ネットワーク・アドオン(flannel)をインストールして、ポッドが相互に通信できるようにします。

    ノート: 10.244.0.0/16とは異なるCIDRブロックを使用している場合は、クラスタにデプロイする前に、kube-flannel.ymlをダウンロードして正しいCIDRアドレスで更新します:

     wget https://github.com/flannel-io/flannel/releases/download/v0.25.1/kube-flannel.yml

 ### Update the CIDR address if you are using a CIDR block other than the default 10.244.0.0/16
 kubectl apply -f kube-flannel.yml

  9. マスター・ノードがReadyステータスであることを確認します:

    $ kubectl get nodes

    サンプル出力:

    NAME              STATUS      ROLES        AGE   VERSION
mymasternode      Ready    control-plane   12h   v1.27.2

    または:

    $ kubectl get pods -n kube-system

    サンプル出力:

    NAME                                    READY       STATUS      RESTARTS    AGE
pod/coredns-86c58d9df4-58p9f                1/1         Running         0       3m59s
pod/coredns-86c58d9df4-mzrr5                1/1         Running         0       3m59s
pod/etcd-mymasternode                       1/1         Running         0       3m4s
pod/kube-apiserver-node                     1/1         Running         0       3m21s
pod/kube-controller-manager-mymasternode    1/1         Running         0       3m25s
pod/kube-flannel-ds-6npx4                   1/1         Running         0       49s
pod/kube-proxy-4vsgm                        1/1         Running         0       3m59s
pod/kube-scheduler-mymasternode             1/1         Running         0       2m58s

  10. マスター・ノードでポッドをスケジュールするには、ノードにtaintを実行します:

     kubectl taint nodes --all node-role.kubernetes.io/control-plane-

これで終了です。Kubernetesクラスタ環境は、Oracle WebCenter Portalドメインをデプロイする準備が完了しました。

Kubernetesクラスタを設定するには、公式のドキュメントを参照してください。

3. スクリプトおよびイメージの取得

3.1 Oracle WebCenter Portalをデプロイするためのコード・リポジトリの設定

これらのステップに従って、Oracle WebCenter Portalドメインのデプロイに必要なソース・コード・リポジトリを設定します。

3.2 必要なDockerイメージの取得とそのローカル・レジストリへの追加

  1. オペレータ・イメージをプルします:

     podman pull ghcr.io/oracle/weblogic-kubernetes-operator:4.2.9

  2. Oracle Container RegistryからOracle Databaseイメージを取得します:

    1. ユーザーが初めてOracle Container Registryからイメージをプルするには、https://container-registry.oracle.comに移動し、Oracle Single Sign-On (SSO)認証サービスを使用してログインします。SSO資格証明がまだない場合は、次を使用してOracleアカウントを作成できます:
      https://profile.oracle.com/myprofile/account/create-account.jspx。

      Webインタフェースを使用して、デプロイするOracleソフトウェア・イメージのオラクル社標準の条件および規制に同意します。これらの条件の同意は、ソフトウェア・イメージをOracle Single Sign-Onログイン資格証明にリンクするデータベースに格納されます。

      イメージを取得するには、Oracle Container Registryにログインします:

       podman login container-registry.oracle.com

    2. 12.2.0.1のOracle Databaseイメージを見つけてプルします:

       podman pull container-registry.oracle.com/database/enterprise:12.2.0.1-slim

    3. このドキュメントのステップに従って、Oracle WebCenter Portal 14.1.2.0イメージをビルドします。

4. WebLogic Kubernetes Operatorのインストール

WebLogic Kubernetes Operatorは、Kubernetes環境でのOracle WebCenter Portalドメインのデプロイメントをサポートします。

このドキュメントのステップに従って、オペレータをインストールします。

オプションで、これらのステップに従って、オペレータのログの内容をElasticsearchに送信できます。

WebLogic Kubernetes Operatorをインストールする次のコマンド例では、opnsはネームスペースで、op-saはオペレータ用に作成されたサービス・アカウントです:

kubectl create namespace operator-ns
kubectl create serviceaccount -n operator-ns operator-sa
helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update 
helm install weblogic-kubernetes-operator weblogic-operator/weblogic-operator  --version 4.2.9 --namespace operator-ns --set serviceAccount=operator-sa --set "javaLoggingLevel=FINE" --wait

ノート: この手順では、ネームスペースはoperator-nsと呼ばれていますが、任意の名前を使用できます。

次の値を使用できます:
- ドメインUID/ドメイン名: wcp-domain
- ドメイン・ネームスペース: wcpns
- オペレータ・ネームスペース: operator-ns
- Traefikネームスペース: traefik

5. Traefik (イングレスベース)ロード・バランサのインストール

WebLogic Kubernetes Operatorは、Traefik、NGINXおよびApacheの3つのロード・バランサをサポートしています。サンプルはドキュメントに記載されています。

このクイック・スタートでは、Traefikイングレス・コントローラをインストールして、Oracle WebCenter Portalドメインのロード・バランシングを提供する方法を示します。

  1. Traefikのネームスペースを作成します:

     kubectl create namespace traefik

  2. サード・パーティ・サービス用のHelmを設定します:

     helm repo add traefik https://helm.traefik.io/traefik --force-update

  3. 提供されているサンプル値を使用して、Traefikオペレータをtraefikネームスペースにインストールします:

     cd ${WORKDIR}
 helm install traefik traefik/traefik \
  --namespace traefik \
  --values charts/traefik/values.yaml \
  --set "kubernetes.namespaces={traefik}" \
  --set "service.type=NodePort" \
  --wait

6. Oracle WebCenter Portalドメインの作成および構成

6.1 Oracle WebCenter Portalドメインの準備

  1. Oracle WebCenter Portalドメインをホストできるネームスペースを作成します:

     kubectl create namespace wcpns

  2. Helmを使用して、このネームスペースでOracle WebCenter Portalドメインを管理するようにオペレータを構成します:

     cd ${WORKDIR}
 helm upgrade weblogic-kubernetes-operator charts/weblogic-operator \
   --reuse-values \
   --namespace operator-ns \
   --set "domainNamespaces={wcpns}" \
   --wait

  3. Kubernetesシークレットを作成します。

    1. ドメインと同じKubernetesネームスペースで、ドメインのKubernetesシークレットを作成します。この例では、ユーザー名はweblogic、パスワードはwelcome1、ネームスペースはwcpnsです:

       cd ${WORKDIR}/create-weblogic-domain-credentials
 sh create-weblogic-credentials.sh -u weblogic -p welcome1 -n wcpns -d wcp-domain -s wcp-domain-domain-credentials

    2. ドメインと同じKubernetesネームスペースで、RCUのKubernetesシークレットを作成します:

    • スキーマ・ユーザー: WCP1
    • スキーマ・パスワード: welcome1
    • DB sysユーザー・パスワード: Oradoc_db1
    • ドメイン名: wcp-domain
    • ドメイン・ネームスペース: wcpns
    • シークレット名: wcp-domain-rcu-credentials
     cd ${WORKDIR}/create-rcu-credentials
 sh create-rcu-credentials.sh -u WCP1 -p welcome1 -a sys -q Oradoc_db1 -n wcpns -d wcp-domain -s wcp-domain-rcu-credentials

  4. Kubernetes永続ボリュームおよび永続ボリューム要求を作成します。

    1. Oracle WebCenter Portalドメイン・ホーム・ディレクトリを作成します。uid:gidが1000のユーザーがホスト・システムにすでに存在するかどうかを確認します:

       sudo getent passwd 1000

      このコマンドでユーザー名(最初のフィールド)が返される場合は、次のuseraddコマンドをスキップできます。そうでない場合は、useraddを使用してoracleユーザーを作成します:

       sudo useradd -u 1000 -g 1000 oracle

      Oracle WebCenter Portalドメイン・ホームに使用するディレクトリを作成します:

       sudo mkdir /scratch/k8s_dir
 sudo chown -R 1000:1000 /scratch/k8s_dir

    2. 次の値でcreate-pv-pvc-inputs.yamlを更新します:

    • baseName: domain
    • domainUID: wcp-domain
    • namespace: wcpns
    • weblogicDomainStoragePath: /scratch/k8s_dir
     cd ${WORKDIR}/create-weblogic-domain-pv-pvc
 cp create-pv-pvc-inputs.yaml create-pv-pvc-inputs.yaml.orig
 sed -i -e "s:baseName\: weblogic-sample:baseName\: domain:g" create-pv-pvc-inputs.yaml
 sed -i -e "s:domainUID\::domainUID\: wcp-domain:g" create-pv-pvc-inputs.yaml
 sed -i -e "s:namespace\: default:namespace\: wcpns:g" create-pv-pvc-inputs.yaml
 sed -i -e "s:#weblogicDomainStoragePath\: /scratch/k8s_dir:weblogicDomainStoragePath\: /scratch/k8s_dir:g" create-pv-pvc-inputs.yaml

    1. create-pv-pvc.shスクリプトを実行して、PVおよびPVC構成ファイルを作成します:

      ./create-pv-pvc.sh -i create-pv-pvc-inputs.yaml -o output

    2. 前のステップで作成した構成ファイルを使用して、PVおよびPVCを作成します:

        kubectl create -f output/pv-pvcs/wcp-domain-domain-pv.yaml
  kubectl create -f output/pv-pvcs/wcp-domain-domain-pvc.yaml

  5. Oracle WebCenter Portalドメイン用のデータベースをインストールして構成します。

    このステップは、スタンドアロン・データベースがまだ設定されておらず、コンテナでデータベースを使用する場合にのみ必要です。

    ノート: Oracle Database Dockerイメージは、非本番環境の用途でのみサポートされています。詳細は、My Oracle Supportノート: Oracle Support for Database Running on Docker (Doc ID 2216342.1)を参照してください。本番環境では、スタンドアロン・データベースを使用することをお薦めします。この例では、コンテナにデータベースを作成するステップを示します。

    1. コンテナにデータベースを作成します:

       cd ${WORKDIR}/create-oracle-db-service
 ./start-db-service.sh -i  container-registry.oracle.com/database/enterprise:12.2.0.1-slim -p none

      データベースが正常に作成されると、データベース接続文字列oracle-db.default.svc.cluster.local:1521/devpdb.k8sをcreate-domain-inputs.yamlファイルのrcuDatabaseURLパラメータとして使用できます。

    2. Oracle WebCenter Portalスキーマを作成します。

      Oracle WebCenter Portalスキーマを作成するには、次のコマンドを実行します:

        ./create-rcu-schema.sh \
   -s WCP1 \
   -t wcp \
   -d oracle-db.default.svc.cluster.local:1521/devpdb.k8s \
   -i oracle/wcportal:14.1.2.0\
   -n wcpns \
   -q Oradoc_db1 \
   -r welcome1

これで、環境はOracle WebCenter Portalドメインの作成を開始する準備ができました。

6.2 Oracle WebCenter Portalドメインの作成

  1. Oracle WebCenter Portalドメイン・デプロイメントのサンプル・スクリプトは、create-wcp-domainにあります。create-domain-inputs.yaml (またはそのコピー)を編集して、ドメインの詳細を指定する必要があります。

    create-domain-inputs.yamlをドメイン作成の次の値で更新します:

    • rcuDatabaseURL: oracle-db.default.svc.cluster.local:1521/devpdb.k8s

  2. create-domain.shスクリプトを実行して、ドメインを作成します:

     cd ${WORKDIR}/create-wcp-domain/domain-home-on-pv/
 ./create-domain.sh -i create-domain-inputs.yaml -o output

  3. Kubernetesドメイン・オブジェクトを作成します:

    create-domain.shが成功すると、output/weblogic-domains/wcp-domain/domain.yamlが生成され、これを使用してKubernetesリソース・ドメインを作成し、ドメインおよびサーバーを起動できます:

     cd ${WORKDIR}/create-wcp-domain/domain-home-on-pv
 kubectl create -f output/weblogic-domains/wcp-domain/domain.yaml

  4. wcp-domainという名前のKubernetesドメイン・オブジェクトが作成されていることを確認します:

     kubectl get domain -n wcpns

    サンプル出力:

    NAME       AGE
wcp-domain   3m18s

  5. ドメインを作成すると、イントロスペクト・ポッドが作成されます。これにより、ドメイン・ホームが検査され、wcp-domain-adminserverポッドが起動されます。wcp-domain-adminserverポッドが正常に起動すると、管理対象サーバー・ポッドが並行して起動されます。wcpnsネームスペースで、ドメイン作成のステータスを確認します:

     kubectl get pods -n wcpns -w

  6. Oracle WebCenter Portalドメイン・サーバーのポッドおよびサービスが作成され、Ready状態であることを確認します:

     kubectl get all -n wcpns

6.3 Oracle WebCenter Portalドメイン・サービスにアクセスするためのTraefikの構成

  1. Oracle WebCenter Portalドメイン・ネームスペース(wcpns)で作成されたイングレスを管理するようにTraefikを構成します:

     helm upgrade traefik traefik/traefik \
   --reuse-values \
   --namespace traefik \
   --set "kubernetes.namespaces={traefik,wcpns}" \
   --wait

  2. サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します:

     cd ${WORKDIR}
 helm install wcp-traefik-ingress  \
 charts/ingress-per-domain \
    --namespace wcpns \
    --values charts/ingress-per-domain/values.yaml \
    --set "traefik.hostname=$(hostname -f)"

  3. ドメインごとに作成されたイングレスの詳細を確認します:

     kubectl describe ingress wcp-domain-traefik -n wcpns

6.4 Oracle WebCenter PortalドメインURLにアクセスできることの確認

  1. 現在の環境のLOADBALANCER_HOSTNAMEを取得します:

     export LOADBALANCER_HOSTNAME=$(hostname -f)

  2. Oracle WebCenter Portalドメインで次のURLが使用可能であることを確認します。

    資格証明:

    ユーザー名: weblogic パスワード: welcome1

    http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/webcenter
http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/console
http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/em
http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/rsscrawl
http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/rest
http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/webcenterhelp

セキュリティの強化

DockerおよびKubernetesクラスタの強化に関するリソースを確認します。

Kubernetesクラスタの保護には、APIサーバー、etcd、ノード、コンテナ・イメージ、コンテナ・ランタイムおよびクラスタ・ネットワークの保護など、複数の面での強化が含まれます。多層防御の原則、最小特権の原則を適用し、攻撃面を最小限に抑えます。Kube-Benchなどのセキュリティ・ツールを使用して、クラスタのセキュリティ状態を確認します。Kubernetesは急速に進化しているため、Kubernetesクラスタの保護に関する最新情報は、Kubernetesセキュリティの概要を参照してください。また、デプロイされたDockerコンテナがDockerセキュリティのガイダンスに従っていることも確認してください。

この項では、DockerおよびKubernetesを安全に構成する方法に関するリファレンスを提供します。

リファレンス

  1. Dockerの強化
    • https://docs.docker.com/engine/security/security/
    • https://blog.aquasec.com/docker-security-best-practices
  2. Kubernetesの強化
    • https://kubernetes.io/docs/concepts/security/overview/
    • https://kubernetes.io/docs/concepts/security/pod-security-standards/
    • https://blogs.oracle.com/developers/5-best-practices-for-kubernetes-security
  3. DockerおよびKubernetesで実行されるOracle WebLogic Serverのセキュリティ・ベスト・プラクティス
    • https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes

追加の構成

Oracle WebCenter Content Serverへの接続の作成

Oracle WebCenter Portal内のコンテンツ統合を有効にするには、JAX-WSを使用してOracle WebCenter Content Serverへの接続を作成します。ドキュメントのリンクのステップに従って接続を作成します。

ノート: Oracle WebCenter Content ServerがSSLで構成されている場合は、接続を作成する前に、ドメイン永続ボリュームのマウント・パスにある任意の場所にSSL証明書をインポートして、ポッドの再起動による証明書の損失を回避する必要があります。

SSL証明書のインポート

次のサンプル・コマンドを使用して証明書をインポートし、ドメイン永続ボリュームのマウント・パスにあるディレクトリにキーストアの場所を更新します:

 kubectl exec -it wcp-domain-adminserver -n wcpns /bin/bash
 cd $JAVA_HOME/bin
 ./keytool -importcert -trustcacerts -alias content_cert -file /filepath/sslcertificate/contentcert.pem -keystore /u01/oracle/user_projects/domains/wcpinfra/keystore/trust.p12

トラストストアの更新

トラストストアの場所を更新するには、domain.yamlファイルを編集し、-Djavax.net.ssl.trustStoreをspec.serverPod.env.JAVA_OPTIONS環境変数の値に追加します。-Djavax.net.ssl.trustStoreオプションで使用されるトラストストアの場所は、SSL証明書がインポートされたキーストアの場所と同じである必要があります。

serverPod:
  # an (optional) list of environment variable to be set on the servers
  env:
  - name: JAVA_OPTIONS
    value: "-Dweblogic.StdoutDebugEnabled=true -Dweblogic.ssl.Enabled=true -Dweblogic.security.SSL.ignoreHostnameVerification=true -Djavax.net.ssl.trustStore=/u01/oracle/user_projects/domains/wcpinfra/keystore/trust.p12"
  - name: USER_MEM_ARGS
    value: "-Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx1024m "
  volumes:
  - name: weblogic-domain-storage-volume
    persistentVolumeClaim:
      claimName: wcp-domain-domains-pvc
  volumeMounts:
  - mountPath: /u01/oracle/user_projects/domains
    name: weblogic-domain-storage-volume

domain.yamlファイルを適用して、Oracle WebCenter Portalドメインを再起動します。

 kubectl apply -f domain.yaml

検索サーバーへの接続の作成

WebCenter Portalで検索を構成するには、OCI Search Service with OpenSearchにWebCenter Portalを接続する必要があります。ドキュメントのステップに従って、OCIにOpenSearchインスタンスを作成します。

OCI検索サービスへの接続のテスト - OpenSearchエンドポイント

https://<opensearch_private_ip>:9200にアクセスして、上で指定した資格証明を入力します。

次のようなレスポンスが表示されます:

{
"name" : "opensearch-master-0",
"cluster_name" : "amaaaaaawyxhaxqayue3os5ai2uiezzbuf6urm3dllo43accuxse57ztsaeq",
"cluster_uuid" : "FncN4SpaT_em28b8gjb4hg",
"version" : {
"distribution" : "opensearch",
"number" : "2.11.0",
"build_type" : "tar",
"build_hash" : "unknown",
"build_date" : "2024-01-09T20:29:23.162321021Z",
"build_snapshot" : false,
"lucene_version" : "9.7.0",
"minimum_wire_compatibility_version" : "7.10.0",
"minimum_index_compatibility_version" : "7.0.0"
},
"tagline" : "The OpenSearch Project: https://opensearch.org/"
}

WebCenter Portalキーストアへの証明書の追加

クライアントとサーバー間の信頼を確立するには、OpenSearchサーバー証明書をWebCenter Portalキーストアに追加する必要があります。

OCI OpenSearchサーバーからの証明書のダウンロード

OCI OpenSearchサーバーから証明書を取得するには、次のステップを実行します:

  1. Firefoxブラウザを開き、次のコマンドを使用してOCI OpenSearchサーバーに接続します:

      https://host_name:9200

    ここで、host_nameはOCI OpenSearchサーバーの名前です。

  2. セキュリティ例外を受け入れて続行します。

  3. プロンプトが表示されたら、ログイン資格証明を指定します。

  4. 「URL」フィールドで「ロック」アイコンをクリックし、「安全でない接続」、「詳細情報」の順に移動します。ポップアップ・ウィンドウで、「証明書の表示」ボタンをクリックします。

  5. リンク「PEM (証明書)」をクリックして、.PEM形式で証明書をダウンロードします。

WebCenter Portalキーストアへの証明書の追加

証明書がダウンロードされたら、WebCenter Portalキーストアにインポートする必要があります。インポートするには:

  1. WebCenter Portalサーバーで次のコマンドを実行し、プロンプトが表示されたらキーストアのパスワードを入力します:

     kubectl exec -it wcp-domain-adminserver -n wcpns /bin/bash
 cd $JAVA_HOME/bin
 ./keytool -importcert -trustcacerts -alias opensearch_cert -file /filepath/sslcertificate/opensearchcert.pem -keystore /u01/oracle/user_projects/domains/wcpinfra/keystore/trust.p12

  2. ポータル管理対象サーバーを再起動します。

ホスト名検証の無効化

ホスト名の検証を無効化するには:

  1. リモート・コンソールにログインします。
  2. 「ロックして編集」ボタンをクリックします。
  3. 左側のナビゲーションから「サーバー」を選択し、「サーバー名」、「構成」、「SSL」、「拡張」の順に選択します。「ホスト名の検証」ドロップダウン・メニューから「なし」を選択します。「保存」をクリックして、変更をアクティブ化します。

OpenSearchを使用したOCI検索サービス用のWebCenter Portalの構成

WebCenter Portalの検索を構成するには、WebCenter PortalとOpenSearchを使用したOCI検索サービスの間の接続を構成し、クロール管理ユーザーにクロール・アプリケーション・ロールを付与する必要があります。

Oracleホーム・ディレクトリに移動してWLSTスクリプトを起動します。「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」を参照してください。

  1. Oracle WebCenter PortalドメインWC_Portalサーバーに接続します。

  2. WLSTコマンド・プロンプトでcreateSearchConnection WLSTコマンドを実行し、WebCenter PortalとOCI Search Service with OpenSearch間の接続を構成します:

     createSearchConnection(appName, name, url, indexAliasName, appUser, appPassword)

説明

ノート: 名前は小文字の英数字とし、すべてのポータル・サーバー間で一意にする必要があります。

次の例では、WebCenter Portal (webcenter)とhttps://<OpensearchPrivateIP>:9200にあるOCI Search Service with OpenSearchの間の接続を作成します:

 createSearchConnection (appName='webcenter',name='dev-es', url='https://<OpensearchPrivateIP>:9200', indexAliasName='webcenter_portal', appUser='mycrawladmin', appPassword='welcome1')