Oracle WebCenter Content on Kubernetes

WebLogic Kubernetes Operatorは、Oracle WebCenter Contentのデプロイメントをサポートします。このドキュメントの手順に従って、KubernetesでOracle WebCenter Contentドメインを設定します。

このリリースでは、Oracle WebCenter Contentドメインは、ドメイン・ホームが永続ボリューム(PV)にある「永続ボリューム上のドメイン」モデルのみを使用してサポートされます。

オペレータには、Kubernetes環境でのOracle WebCenter Contentドメインのデプロイおよび管理を支援するいくつかの重要な機能があります。次のことが可能です:

現在の製品リリース

Oracle WebCenter Contentドメイン・デプロイメント用に現在サポートされているOracle WebLogic Server Kubernetes Operatorの製品リリースは、4.2.9です

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

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

WebCenter Contentドメインの制限事項

このリリースでの制限事項については、ここを参照してください。

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

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

追加資料

KubernetesでのOracle WebCenter Contentドメインのデプロイメントでは、Oracle WebLogic Server Kubernetes Operatorフレームワークを利用します。

リリース・ノート

Oracle WebCenter Content on Kubernetesの最新の変更を確認します。

最近の変更

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

既知の問題

問題 説明
LoadBalancerエンドポイントによる公開 公開は現在、WebCenter Contentの設定の公開に関する項で説明されているとおり、NodePortを介してのみサポートされます。

インストール・ガイド

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

要件および制限事項

WebLogic Kubernetes Operatorを使用してOracle WebCenter Contentドメインをデプロイおよび実行するためのシステム要件および制限事項を理解します(WebCenter Contentドメイン・クラスタのサイズ設定に関する推奨事項など)。

内容

概要

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

このリリースでは、WebCenter Contentドメインは、WebCenter Contentドメインが永続ボリューム(PV)にある「永続ボリューム上のドメイン」モデルのみを使用してサポートされます。

システム要件

ノート: hostname -iおよびnslookup IPアドレスを使用して、ホストIPを前述のno_proxy、NO_PROXYリストに追加します。

制限事項

WebLogic Kubernetes Operatorを使用したKubernetesでのWebLogic Serverドメインの実行と比較して、現在、Oracle WebCenter Contentドメインには次の制限があります:

Kubernetes環境でサポートされているWebLogic Serverの機能に関する最新情報は、My Oracle SupportのDoc ID 2349228.1を参照してください。

WebCenter Contentクラスタのサイズ設定に関する推奨事項

WebCenter Content 通常の使用状況 中程度の使用状況 高水準の使用状況
管理サーバー CPU数: 1、メモリー: 4GB CPU数: 1、メモリー: 4GB CPU数: 1、メモリー: 4GB
管理対象サーバー サーバー数: 2、CPU数: 2、メモリー: 16GB サーバー数: 2、CPU数: 4、メモリー: 16GB サーバー数: 3、CPU数: 6、メモリー: 16-32GB
PVストレージ 最小250GB 最小250GB 最小500GB

環境の準備

Kubernetes環境でOracle WebCenter Contentを準備するには、次のステップを実行します:

  1. Kubernetesクラスタの設定

  2. Helmのインストール

  3. 依存イメージのプル

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

  5. Oracle WebCenter Content Dockerイメージの取得

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

  7. Oracle WebCenter Contentドメインの環境の準備

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

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

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

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

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

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

  8. Oracle WebCenter Contentドメインの作成

Kubernetesクラスタの設定

Kubernetes環境の設定に関するヘルプが必要な場合は、ドキュメントを確認してください。

Helmのインストール

WebLogic Kubernetes Operatorは、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イメージをプルして、再度タグ付けします:

docker login https://container-registry.oracle.com (enter your Oracle email Id and password)
This step is required once at every node to get access to the Oracle Container Registry.

WebLogic Kubernetes Operatorイメージ:

$ docker pull container-registry.oracle.com/middleware/weblogic-kubernetes-operator:4.2.9
$ docker tag container-registry.oracle.com/middleware/weblogic-kubernetes-operator:4.2.9 oracle/weblogic-kubernetes-operator:4.2.9

Traefikイメージのプル

$ docker pull traefik:2.6.0

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

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

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

    $ mkdir $HOME/wcc_4.2.9
$ cd $HOME/wcc_4.2.9

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

    $ git clone https://github.com/oracle/fmw-kubernetes.git
$ export WORKDIR=$HOME/wcc_4.2.9/fmw-kubernetes/OracleWebCenterContent/kubernetes

Oracle WebCenter Content Dockerイメージの取得

オプションのいずれかを使用して、Oracle WebCenter Contentイメージを取得します。

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

2 Oracle WebCenter Contentコンテナ・イメージのビルド

1. Oracle Container Registry (OCR)からのOracle WebCenter Contentイメージの取得:

ユーザーが初めて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にログインします:

$ docker login container-registry.oracle.com

事前ビルドされたOracle WebCenter Content Suiteイメージを検索してプルします:

$ docker pull container-registry.oracle.com/middleware/webcenter-content_cpu:14.1.2.0.0-<TAG>
2. Oracle WebCenter Contentコンテナ・イメージのビルド:

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

ノート: Oracle WebCenter Contentドメイン・デプロイメントに使用されるデフォルトのOracle WebCenter Contentイメージ名は、oracle/wccontent:14.1.2.0.0です。作成するイメージには、docker tagコマンドを使用してoracle/wccontent:14.1.2.0.0とタグ付けする必要があります。イメージに別の名前を使用する場合は、create-domain-inputs.yamlファイル内と、oracle/wccontent:14.1.2.0.0イメージ名が使用されている他のインスタンスで、新しいイメージ・タグ名を必ず更新してください。

WebLogic Kubernetes Operatorのインストール

WebLogic Kubernetes Operatorは、Kubernetes環境でのOracle WebCenter Contentドメインのデプロイメントをサポートします。このドキュメントのステップに従って、WebLogic Kubernetes Operatorをインストールします。> ノート: オプションで、これらのステップを実行して、オペレータのログの内容をElasticsearchに送信できます。

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

WebLogic Kubernetes Operatorのネームスペースおよびサービス・アカウントの作成

$ kubectl create namespace opns
$ kubectl create serviceaccount -n opns  op-sa

WebLogic Kubernetes Operatorのインストール

$ cd ${WORKDIR}

$ helm install weblogic-kubernetes-operator charts/weblogic-operator --namespace opns  --set image=oracle/weblogic-kubernetes-operator:4.2.9 --set serviceAccount=op-sa --set "domainNamespaces={}" --set "javaLoggingLevel=FINE" --wait

Oracle WebCenter Contentドメインの環境の準備

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

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

 $ kubectl create namespace wccns
 
 $ cd ${WORKDIR}
 $ helm upgrade --reuse-values --namespace opns --set "domainNamespaces={wccns}" --wait weblogic-kubernetes-operator charts/weblogic-operator

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

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

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

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

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

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

シークレットは、kubectl get secretコマンドを使用して確認できます。

例:

$ kubectl get secret wccinfra-domain-credentials -o yaml -n wccns
apiVersion: v1
data:
password: d2VsY29tZTE=
username: d2VibG9naWM=
kind: Secret
metadata:
creationTimestamp: "2020-09-16T08:22:50Z"
labels:
  weblogic.domainName: wccinfra
  weblogic.domainUID: wccinfra
managedFields:
- apiVersion: v1
  fieldsType: FieldsV1
  fieldsV1:
    f:data:
      .: {}
      f:password: {}
      f:username: {}
    f:metadata:
      f:labels:
        .: {}
        f:weblogic.domainName: {}
        f:weblogic.domainUID: {}
    f:type: {}
  manager: kubectl
  operation: Update
  time: "2020-09-16T08:22:50Z"
name: wccinfra-domain-credentials
namespace: wccns
resourceVersion: "3277100"
selfLink: /api/v1/namespaces/wccns/secrets/wccinfra-domain-credentials
uid: 35a8313f-1ec2-44b0-a2bf-fee381eed57f
type: Opaque
RCU資格証明を使用したKubernetesシークレットの作成

データベース・スキーマの資格証明を含むKubernetesシークレットも作成する必要があります。ドメインを作成すると、このシークレットからRCU資格証明が取得されます。

付属のサンプル・スクリプトを使用して、シークレットを作成します:

$ cd ${WORKDIR}/create-rcu-credentials

$ ./create-rcu-credentials.sh -u weblogic -p welcome1 -a sys -q welcome1 -d wccinfra -n wccns -s wccinfra-rcu-credentials

パラメータ値は次のとおりです:

-u スキーマ所有者(通常ユーザー)のユーザー名、必須。
-p スキーマ所有者(通常ユーザー)のパスワード、必須。
-a SYSDBAユーザーのユーザー名、必須。
-q SYSDBAユーザーのパスワード、必須。
-d domainUID。例: wccinfra
-n ネームスペース。例: wccns
-s secretName。例: wccinfra-rcu-credentials

シークレットが想定どおりに作成されたことを確認するには、kubectl get secretコマンドを使用します。

例:

$ kubectl get secret wccinfra-rcu-credentials -o yaml -n wccns
  apiVersion: v1
data:
  password: d2VsY29tZTE=
  sys_password: d2VsY29tZTE=
  sys_username: c3lz
  username: d2VibG9naWM=
kind: Secret
metadata:
  creationTimestamp: "2020-09-16T08:23:04Z"
  labels:
    weblogic.domainName: wccinfra
    weblogic.domainUID: wccinfra
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:password: {}
        f:sys_password: {}
        f:sys_username: {}
        f:username: {}
      f:metadata:
        f:labels:
          .: {}
          f:weblogic.domainName: {}
          f:weblogic.domainUID: {}
      f:type: {}
    manager: kubectl
    operation: Update
    time: "2020-09-16T08:23:04Z"
  name: wccinfra-rcu-credentials
  namespace: wccns
  resourceVersion: "3277132"
  selfLink: /api/v1/namespaces/wccns/secrets/wccinfra-rcu-credentials
  uid: b75f4e13-84e6-40f5-84ba-0213d85bdf30
type: Opaque
データベースへのアクセスの構成

コンテナを実行してrcu podを作成します

$ kubectl run rcu --image oracle/wccontent:14.1.2.0.0 -n wccns -- sleep infinity
   
#check the status of rcu pod
$ kubectl get pods -n wccns
リポジトリ作成ユーティリティの実行によるデータベース・スキーマの設定
スキーマの作成または削除

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

例:

# make sure rcu pod status is running before executing this 
kubectl exec -n wccns -ti rcu /bin/bash

# DB details 
export CONNECTION_STRING=your_db_host:1521/your_db_service
export RCUPREFIX=your_schema_prefix
echo -e welcome1"\n"welcome1> /tmp/pwd.txt
   
# Create schemas
/u01/oracle/oracle_common/bin/rcu -silent -createRepository -databaseType ORACLE -connectString $CONNECTION_STRING -dbUser sys -dbRole sysdba -useSamePasswordForAllSchemaUsers true -selectDependentsForComponents true -schemaPrefix $RCUPREFIX -component CONTENT -component MDS   -component STB -component OPSS  -component IAU -component IAU_APPEND -component IAU_VIEWER -component WLS  -tablespace USERS -tempTablespace TEMP -f < /tmp/pwd.txt
   
# Drop schemas
/u01/oracle/oracle_common/bin/rcu -silent -dropRepository -databaseType ORACLE -connectString $CONNECTION_STRING -dbUser sys -dbRole sysdba -selectDependentsForComponents true -schemaPrefix $RCUPREFIX -component CONTENT -component MDS  -component STB -component OPSS  -component IAU -component IAU_APPEND -component IAU_VIEWER -component WLS -f < /tmp/pwd.txt 

#exit from the container
exit

ノート: 前述のスキーマの作成および削除コマンドで、IPMおよびCAPTUREアプリケーションが有効になっている場合は、それぞれ追加のコンポーネント(-component IPM -component CAPTURE)を渡します。

これで必要なDockerイメージが用意され、RCUスキーマが作成されたため、ドメインを作成する準備ができました。続行するには、「Oracle WebCenter Contentドメインの作成」の手順に従います。

Oracle WebCenter Contentドメインの作成

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

内容

前提条件

始める前に、次のステップを実行してください。

  1. ドメイン・リソースのドキュメントを確認します。
  2. 要件および制限事項を確認します。
  3. 「環境の準備」のすべての準備ステップが実行されていることを確認します。
  4. データベース・スキーマが作成され、WebLogic Kubernetes Operatorが実行されていることを確認します。

ドメイン作成スクリプトを使用する準備

Oracle WebCenter Contentドメイン・デプロイメントのサンプル・スクリプトは、${WORKDIR}/create-wcc-domainにあります。

${WORKDIR}/create-wcc-domain/domian-home-on-pvにあるcreate-domain-inputs.yaml (またはそのコピー)を編集して、ドメインの詳細を指定する必要があります。このファイルに指定する必要がある情報を理解するには、次の構成パラメータを参照してください。

構成パラメータ

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

パラメータ 定義 デフォルト
sslEnabled 各WebLogic ServerインスタンスのSSLを有効にするかどうかを示すブール。 false
adminPort Kubernetesクラスタ内の管理サーバーのポート番号。 7001
adminServerSSLPort Kubernetesクラスタ内の管理サーバーのSSLポート番号。 7002
adminNodePort Kubernetesクラスタ外部の管理サーバーのポート番号。 30701
adminServerName 管理サーバーの名前。 AdminServer
clusterName ドメイン用に生成するWebLogicクラスタ・インスタンスの名前。デフォルトでは、WebCenter Contentドメイン用のクラスタ名はucm_clusterおよびibr_clusterです。 ucm_cluster
configuredManagedServerCount ドメインに対して生成する管理対象サーバー・インスタンスの数。 5
createDomainFilesDir createDomainScriptNameプロパティで指定されたスクリプトを含め、WebLogicドメインを作成するためのすべてのファイルを検索するホスト・マシン上のディレクトリ。デフォルトでは、このディレクトリは相対パスwlstに設定され、作成スクリプトは、wlstディレクトリの組込みWLSTオフライン・スクリプトを使用してWebLogicドメインを作成します。絶対パスも、ファイル・システム内の任意のディレクトリを指すようにサポートされています。組込みスクリプトは、ファイルが指定されたディレクトリにあるかぎり、ユーザーが指定したスクリプトに置き換えることができます。このディレクトリ内のファイルは、Kubernetes構成マップに配置され、さらにcreateDomainScriptsMountPathにマウントされます。これにより、Kubernetesポッドがスクリプトおよびサポート・ファイルを使用してドメイン・ホームを作成できるようになります。 wlst
createDomainScriptsMountPath ドメイン作成スクリプトがポッド内にあるマウント・パス。create-domain.shスクリプトは、ドメイン・ホームを作成するKubernetesポッドでスクリプト(createDomainScriptNameプロパティで指定)を実行するKubernetesジョブを作成します。createDomainFilesDirディレクトリ内のファイルはポッドのこの場所にマウントされるため、Kubernetesポッドはスクリプトおよびサポート・ファイルを使用してドメイン・ホームを作成できます。 /u01/weblogic
createDomainScriptName ドメイン作成スクリプトがWebLogicドメインの作成に使用するスクリプト。create-domain.shスクリプトは、ドメイン・ホームを作成するこのスクリプトを実行するKubernetesジョブを作成します。このスクリプトは、createDomainScriptsMountPathプロパティで指定されたポッド内のディレクトリにあります。組込みスクリプトを使用するかわりに、ドメイン・ホームを作成するための独自のスクリプトを指定する必要がある場合は、このプロパティを使用して、ドメイン作成ジョブで実行するスクリプトの名前を設定する必要があります。 create-domain-job.sh
domainHome WebCenter Contentドメインのホーム・ディレクトリ。指定しない場合、値はdomainUIDから/shared/domains/<domainUID>として導出されます。 /u01/oracle/user_projects/domains/wccinfra
domainPVMountPath ドメイン永続ボリュームのマウント・パス。 /u01/oracle/user_projects
domainUID この特定のドメインの識別に使用される一意のID。生成されたWebLogicドメインの名前およびKubernetesドメイン・リソースの名前として使用されます。このIDは、Kubernetesクラスタ内のすべてのドメインで一意である必要があります。このIDには、Kubernetesサービス名で有効ではない文字を含めることはできません。 wccinfra
exposeAdminNodePort 管理サーバーがKubernetesクラスタの外部に公開されているかどうかを示すブール。 false
exposeAdminT3Channel T3管理チャネルがKubernetesクラスタの外部に公開されているかどうかを示すブール。 false
image WebCenter Content Dockerイメージ。WebLogic Kubernetes Operatorには、Oracle WebCenter Content 14.1.2.0.0が必要です。イメージを取得または作成する方法の詳細は、「Oracle WebCenter Content Dockerイメージの取得」を参照してください。 oracle/wccontent:14.1.2.0.0
imagePullPolicy WebLogic Dockerイメージ・プル・ポリシー。有効な値は、IfNotPresent、AlwaysまたはNeverです。 IfNotPresent
imagePullSecretName Docker StoreにアクセスしてWebLogic Server DockerイメージをプルするためのKubernetesシークレットの名前。このパラメータを指定すると、シークレットの存在が検証されます。
includeServerOutInPodLog ポッドのstdoutにserver.outを含めるかどうかを示すブール。 true
initialManagedServerReplicas ドメインに対して最初に起動するUCM管理対象サーバーの数。 3
javaOptions 管理サーバーおよび管理対象サーバーを起動するためのJavaオプション。Javaオプションには、WebLogicドメイン情報を取得するための事前定義された次の1つ以上の変数への参照を含めることができます: $(DOMAIN_NAME)、$(DOMAIN_HOME)、$(ADMIN_NAME)、$(ADMIN_PORT)および$(SERVER_NAME)。sslEnabledがtrueに設定されており、WebLogicデモ証明書が使用されている場合は、-Dweblogic.security.SSL.ignoreHostnameVerification=trueを追加して、起動中に管理対象サーバーを管理サーバーに接続できるようにします。この環境で生成されたWebLogicデモ証明書には、通常、ランタイム・コンテナのホスト名とは異なるホスト名が含まれます。 -Dweblogic.StdoutDebugEnabled=false
logHome ドメイン・ログ、サーバー・ログ、サーバー出力およびノード・マネージャ・ログ・ファイルのポッド内の場所。指定しない場合、値はdomainUIDから/shared/logs/<domainUID>として導出されます。 /u01/oracle/user_projects/domains/logs/wccinfra
managedServerNameBase 管理対象サーバー名の生成に使用されるベース文字列。 ucm_server
managedServerPort 各管理対象サーバーのポート番号。デフォルトでは、ucm_serverのmanagedServerPortは16200で、ibr_serverのmanagedServerPortは16250です。 16200
managedServerSSLPort 各管理対象サーバーのSSLポート番号。デフォルトでは、ucm_serverのmanagedServerSSLPortは16201で、ibr_serverのmanagedServerSSLPortは16251です。 16201
managedServerAdministrationPort 管理対象サーバーの管理ポート番号。 9200
namespace ドメインを作成するKubernetesネームスペース。 wccns
persistentVolumeClaimName ドメイン・ホームをホストするために作成された永続ボリューム要求の名前。指定しない場合、値はdomainUIDから<domainUID>-weblogic-sample-pvcとして導出されます。 wccinfra-domain-pvc
productionModeEnabled ドメインで本番モードが有効かどうかを示すブール。 true
serverStartPolicy 起動するWebLogic Serverインスタンスを決定します。有効な値は、NEVER、IF_NEEDED、ADMIN_ONLYです。 IF_NEEDED
t3ChannelPort NetworkAccessPointのt3チャネルのポート。 30012
t3PublicAddress T3チャネルのパブリック・アドレス。これは、Kubernetesクラスタのパブリック・アドレスに設定する必要があります。これは通常、ロード・バランサのアドレスになります。 指定しない場合、スクリプトはこれをKubernetesクラスタのIPアドレスに設定しようとします
weblogicCredentialsSecretName 管理サーバーのユーザー名とパスワードのKubernetesシークレットの名前。指定しない場合、値はdomainUIDから<domainUID>-weblogic-credentialsとして導出されます。 wccinfra-domain-credentials
weblogicImagePullSecretName WebLogic Serverイメージをプルするために使用されるDocker StoreのKubernetesシークレットの名前。
serverPodCpuRequest、serverPodMemoryRequest、serverPodCpuCLimit、serverPodMemoryLimit サーバー・ポッドごとに許可されるコンピュート・リソースの最大量および必要なコンピュート・リソースの最小量。詳細は、コンテナのコンピュート・リソースの管理に関するKubernetesドキュメントを参照してください。 リソース・リクエストおよびリソース制限は指定されていません。
rcuSchemaPrefix データベースで使用するスキーマ接頭辞(WCC1など)。RCUスキーマとの一致ドメインを簡略化するために、これをdomainUIDと同じにできます。 WCC1
rcuDatabaseURL データベースURL。 <YOUR DATABASE CONNECTION DETAILS>
rcuCredentialsSecret データベース資格証明を含むKubernetesシークレット。 wccinfra-rcu-credentials
ipmEnabled WebCenter Imagingアプリケーションを有効にするかどうかを示すブール false
captureEnabled WebCenter Captureアプリケーションを有効にするかどうかを示すブール false
adfuiEnabled WebCenter ADF UIアプリケーションを有効にするかどうかを示すブール false
initialIpmServerReplicas ドメインに対して最初に起動するIPM管理対象サーバーの数。 0
initialCaptureServerReplicas ドメインに対して最初に起動するCAPTURE管理対象サーバーの数。 0
initialAdfuiServerReplicas ドメインに対して最初に起動するADFUI管理対象サーバーの数。 0

生成されたYAMLファイル内のKubernetesリソースの名前は、create-inputs.yamlファイルに指定された一部のプロパティの値で構成される可能性があることに注意してください。これらのプロパティには、adminServerName、clusterNameおよびmanagedServerNameBaseが含まれます。これらの値にKubernetesサービス名で無効な文字が含まれている場合、それらの文字は生成されたYAMLファイルで有効な値に変換されます。たとえば、大文字は小文字に変換され、アンダースコア(_)はハイフン(-)に変換されます。

ノート: プロパティipmEnabled、captureEnabled、adfuiEnabledはデフォルトでfalseに設定されており、各アプリケーションを有効にする必要がある場合は、trueに更新する必要があります。これらの3つのアプリケーション(IPM、CAPTUREおよびADFUI)のいずれかが有効な場合、それぞれの初期レプリカ数はゼロ以外の数値である必要があります。

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

ドメイン作成スクリプトの実行

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

$ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/

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

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

managed-server-wrapperスクリプトの実行

ドメインYAMLを内部的に適用するmanaged-server-wrapperスクリプトを実行します。このスクリプトは、管理対象サーバー・コンテナの初期構成も適用し、将来のコンテナ間通信のために管理対象サーバーを準備します。

$ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/

$ ./start-managed-servers-wrapper.sh -o <path_to_output_directory> -p <load_balancer_port> -n <ibr_node_port> -m <ucm_node_port> -s <ssl_termination>

ノート: 前述のコマンドで、パラメータ-nおよび-mは、それぞれIBR intradocポートおよびUCM intradocポートの公開に使用されるノード・ポートを示します。これらのノード・ポートの両方に推奨される値は、30000-32767の範囲内である必要があります。<ibr_node_port>値は常に指定する必要がありますが、<ucm_node_port>値は、IPMおよびADFUI管理対象サーバーが有効な場合にのみ必要であることに留意してください。

パラメータ-sの値は、ロード・バランサでSSL終端が使用されている場合にのみ指定する必要があります。許容される値は、trueまたはfalseです。このパラメータ値が指定されていない場合、スクリプトはロード・バランサでSSL終端が使用されていないと想定し、デフォルトでこの値はfalseとみなされます。

必要に応じてIPMおよびWCCADFアプリケーションの起動構成スクリプトを実行

IPMが有効になっている場合は、スクリプトconfigure-IPM-connection.shを実行して起動構成を実行します。

$ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/
$ ./configure-ipm-connection.sh -l <load_balancer_external_ip> -p <load_balancer_port> -s <ssl_or_ssl_termination>

ADFUIが有効になっている場合は、スクリプトconfigure-wccadf-domain.shを実行して起動構成を実行します。

$ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/
$ ./configure-wccadf-domain.sh -n <node_ip> -m <ucm_node_port>

変更がドメインに適用されるようにドメインにパッチを適用します。

#STOP
$ kubectl patch domain DOMAINUID -n NAMESPACE --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "NEVER" }]'

$ sleep 2m

#START
$ kubectl patch domain DOMAINUID -n NAMESPACE --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IF_NEEDED" }]'

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

結果の検証

ドメイン作成スクリプトは、ドメインが作成されたことを検証し、エラーが発生した場合は失敗をレポートします。ただし、スクリプトによって作成された様々なKubernetesオブジェクトに慣れるためだけであっても、ドメインを手動で検証することが望ましい場合があります。

デフォルト入力で生成されたYAMLファイル

生成されたdomain.yamlのサンプル・コンテンツ:

$ cat output/weblogic-domains/wccinfra/domain.yaml
# Copyright (c) 2021, Oracle and/or its affiliates.
# Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
#
# This is an example of how to define a Domain resource.
#
apiVersion: "weblogic.oracle/v8"
kind: Domain
metadata:
  name: wccinfra
  namespace: wccns
  labels:
    weblogic.domainUID: wccinfra
spec:
  # The WebLogic Domain Home
  domainHome: /u01/oracle/user_projects/domains/wccinfra
  maxClusterConcurrentStartup: 1

  # The domain home source type
  # Set to PersistentVolume for domain-in-pv, Image for domain-in-image, or FromModel for model-in-image
  domainHomeSourceType: PersistentVolume

  # The WebLogic Server Docker image that WebLogic Kubernetes Operator uses to start the domain
  image: "oracle/wccontent:14.1.2.0.0"

  # imagePullPolicy defaults to "Always" if image version is :latest
  imagePullPolicy: "IfNotPresent"

  # Identify which Secret contains the credentials for pulling an image
  #imagePullSecrets:
  #- name: 

  # Identify which Secret contains the WebLogic Admin credentials (note that there is an example of
  # how to create that Secret at the end of this file)
  webLogicCredentialsSecret: 
    name: wccinfra-domain-credentials

  # Whether to include the server out file into the pod's stdout, default is true
  includeServerOutInPodLog: true

  # Whether to enable log home
  logHomeEnabled: true

  # Whether to write HTTP access log file to log home
  httpAccessLogInLogHome: true

  # The in-pod location for domain log, server logs, server out, and Node Manager log files
  logHome: /u01/oracle/user_projects/domains/logs/wccinfra
  # An (optional) in-pod location for data storage of default and custom file stores.
  # If not specified or the value is either not set or empty (e.g. dataHome: "") then the
  # data storage directories are determined from the WebLogic domain home configuration.
  dataHome: ""


  # serverStartPolicy legal values are "NEVER", "IF_NEEDED", or "ADMIN_ONLY"
  # This determines which WebLogic Servers the WebLogic Kubernetes Operator will start up when it discovers this Domain
  # - "NEVER" will not start any server in the domain
  # - "ADMIN_ONLY" will start up only the administration server (no managed servers will be started)
  # - "IF_NEEDED" will start all non-clustered servers, including the administration server and clustered servers up to the replica count
  serverStartPolicy: "IF_NEEDED"

  serverPod:
    # an (optional) list of environment variable to be set on the servers
    env:
    - name: JAVA_OPTIONS
      value: "-Dweblogic.StdoutDebugEnabled=false"
    - name: USER_MEM_ARGS
      value: "-Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx512m "
    volumes:
    - name: weblogic-domain-storage-volume
      persistentVolumeClaim:
        claimName: wccinfra-domain-pvc
    volumeMounts:
    - mountPath: /u01/oracle/user_projects/domains
      name: weblogic-domain-storage-volume

  # adminServer is used to configure the desired behavior for starting the administration server.
  adminServer:
    # serverStartState legal values are "RUNNING" or "ADMIN"
    # "RUNNING" means the listed server will be started up to "RUNNING" mode
    # "ADMIN" means the listed server will be start up to "ADMIN" mode
    serverStartState: "RUNNING"
    adminService:
      channels:
    # The Admin Server's NodePort
       - channelName: default
         nodePort: 30701
    # Uncomment to export the T3Channel as a service
    #    - channelName: T3Channel

  # clusters is used to configure the desired behavior for starting member servers of a cluster.  
  # If you use this entry, then the rules will be applied to ALL servers that are members of the named clusters.
  clusters:
  - clusterName: ibr_cluster
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 1
    serverStartPolicy: "IF_NEEDED"
  # The number of managed servers to start for unlisted clusters
  # replicas: 1

  # Istio
  # configuration:
  #   istio:
  #     enabled: 
  #     readinessPort: 

  - clusterName: ucm_cluster
    clusterService:
         annotations:
            traefik.ingress.kubernetes.io/affinity: "true"
            traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
            traefik.ingress.kubernetes.io/session-cookie-name: JSESSIONID
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 3
    serverStartPolicy: "IF_NEEDED"
  # The number of managed servers to start for unlisted clusters
  # replicas: 1
  - clusterName: ipm_cluster
    clusterService:
         annotations: 
            traefik.ingress.kubernetes.io/affinity: "true"
            traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
            traefik.ingress.kubernetes.io/session-cookie-name: JSESSIONID
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 3
  # The number of managed servers to start for unlisted clusters
  # replicas: 1
  - clusterName: capture_cluster
    clusterService:
         annotations: 
            traefik.ingress.kubernetes.io/affinity: "true"
            traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
            traefik.ingress.kubernetes.io/session-cookie-name: JSESSIONID
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 3
  # The number of managed servers to start for unlisted clusters
  # replicas: 1
  - clusterName: wccadf_cluster
    clusterService:
         annotations: 
            traefik.ingress.kubernetes.io/affinity: "true"
            traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
            traefik.ingress.kubernetes.io/session-cookie-name: WCCSID
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 3
  # The number of managed servers to start for unlisted clusters
  # replicas: 1

ドメインの検証

ドメインが作成されたことを確認するには、次のコマンドを入力します:

$ kubectl describe domain DOMAINUID -n NAMESPACE

DOMAINUIDはdomainUIDに、NAMESPACEは実際のネームスペースに置き換えます。

サンプル・ドメインの説明:

$ kubectl describe domain wccinfra -n wccns
Name:         wccinfra
Namespace:    wccns
Labels:       weblogic.domainUID=wccinfra
Annotations:  API Version:  weblogic.oracle/v8
Kind:         Domain
Metadata:
  Creation Timestamp:  2020-11-23T12:48:13Z
  Generation:          7
  Managed Fields:
    API Version:  weblogic.oracle/v8
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:kubectl.kubernetes.io/last-applied-configuration:
        f:labels:
          .:
          f:weblogic.domainUID:
    Manager:      kubectl
    Operation:    Update
    Time:         2020-11-23T13:50:28Z
    API Version:  weblogic.oracle/v8
    Fields Type:  FieldsV1
    fieldsV1:
      f:status:
        .:
        f:clusters:
        f:conditions:
        f:servers:
        f:startTime:
    Manager:         OpenAPI-Generator
    Operation:       Update
    Time:            2020-12-03T10:20:52Z
  Resource Version:  18267402
  Self Link:         /apis/weblogic.oracle/v8/namespaces/wccns/domains/wccinfra
  UID:               1a866c30-9b29-4281-bd2b-df80914efdff
Spec:
  Admin Server:
    Admin Service:
      Channels:
        Channel Name:    default
        Node Port:       30701
    Server Start State:  RUNNING
  Clusters:
    Cluster Name:  ibr_cluster
    Replicas:      1
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:  true
    Server Start Policy:  IF_NEEDED
    Server Start State:   RUNNING
    Cluster Name:         ucm_cluster
    Cluster Service:
      Annotations:
        traefik.ingress.kubernetes.io/affinity:               true
        traefik.ingress.kubernetes.io/service.sticky.cookie:  true
        traefik.ingress.kubernetes.io/session-cookie-name:    JSESSIONID
    Replicas:                                                 3
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:           true
    Server Start Policy:           IF_NEEDED
    Server Start State:            RUNNING
    Cluster Name:         ipm_cluster
    Cluster Service:
      Annotations:
        traefik.ingress.kubernetes.io/affinity:               true
        traefik.ingress.kubernetes.io/service.sticky.cookie:  true
        traefik.ingress.kubernetes.io/session-cookie-name:    JSESSIONID
    Replicas:                                                 3
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:  true
    Server Start State:   RUNNING
    Cluster Name:         capture_cluster
    Cluster Service:
      Annotations:
        traefik.ingress.kubernetes.io/affinity:               true
        traefik.ingress.kubernetes.io/service.sticky.cookie:  true
        traefik.ingress.kubernetes.io/session-cookie-name:    JSESSIONID
    Replicas:                                                 3
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:  true
    Server Start State:   RUNNING
    Cluster Name:         wccadf_cluster
    Cluster Service:
      Annotations:
        traefik.ingress.kubernetes.io/affinity:               true
        traefik.ingress.kubernetes.io/service.sticky.cookie:  true
        traefik.ingress.kubernetes.io/session-cookie-name:    WCCSID
    Replicas:                                                 3
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:  true
    Server Start State:   RUNNING
  Data Home:
  Domain Home:                     /u01/oracle/user_projects/domains/wccinfra
  Domain Home Source Type:         PersistentVolume
  Http Access Log In Log Home:     true
  Image:                           oracle/wccontent_ora_final_it:14.1.2.0.0
  Image Pull Policy:               IfNotPresent
  Include Server Out In Pod Log:   true
  Log Home:                        /u01/oracle/user_projects/domains/logs/wccinfra
  Log Home Enabled:                true
  Max Cluster Concurrent Startup:  1
  Server Pod:
    Env:
      Name:   JAVA_OPTIONS
      Value:  -Dweblogic.StdoutDebugEnabled=false
      Name:   USER_MEM_ARGS
      Value:  -Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx512m
    Volume Mounts:
      Mount Path:  /u01/oracle/user_projects/domains
      Name:        weblogic-domain-storage-volume
    Volumes:
      Name:  weblogic-domain-storage-volume
      Persistent Volume Claim:
        Claim Name:     wccinfra-domain-pvc
  Server Start Policy:  IF_NEEDED
  Web Logic Credentials Secret:
    Name:  wccinfra-domain-credentials
Status:
  Clusters:
    Cluster Name:      ibr_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    1
    Replicas:          1
    Replicas Goal:     1
    Cluster Name:      ucm_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    3
    Replicas:          3
    Replicas Goal:     3
    Cluster Name:      ipm_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    3
    Replicas:          3
    Replicas Goal:     3
    Cluster Name:      capture_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    3
    Replicas:          3
    Replicas Goal:     3
    Cluster Name:      wccadf_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    3
    Replicas:          3
    Replicas Goal:     3
  Conditions:
    Last Transition Time:  2020-11-23T13:58:41.070Z
    Reason:                ServersReady
    Status:                True
    Type:                  Available
  Servers:
    Desired State:  RUNNING
    Health:
      Activation Time:  2020-11-25T16:55:24.930Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    AdminServer
    State:          RUNNING
    Cluster Name:   ibr_cluster
    Desired State:  RUNNING
    Health:
      Activation Time:  2020-11-30T12:23:27.603Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    ibr_server1
    State:          RUNNING
    Cluster Name:   ibr_cluster
    Desired State:  SHUTDOWN
    Server Name:    ibr_server2
    Cluster Name:   ibr_cluster
    Desired State:  SHUTDOWN
    Server Name:    ibr_server3
    Cluster Name:   ibr_cluster
    Desired State:  SHUTDOWN
    Server Name:    ibr_server4
    Cluster Name:   ibr_cluster
    Desired State:  SHUTDOWN
    Server Name:    ibr_server5
    Cluster Name:   ucm_cluster
    Desired State:  RUNNING
    Health:
      Activation Time:  2020-12-02T14:10:37.992Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    ucm_server1
    State:          RUNNING
    Cluster Name:   ucm_cluster
    Desired State:  RUNNING
    Health:
      Activation Time:  2020-12-01T04:51:19.886Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    ucm_server2
    State:          RUNNING
    Cluster Name:   ucm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ucm_server3
    Cluster Name:   ucm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ucm_server4
    Cluster Name:   ucm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ucm_server5
    Cluster Name:   ipm_cluster
    Desired State:  RUNNING
    Health:
      Activation Time:  2020-12-01T04:51:19.886Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    ipm_server1
    State:          RUNNING
    Cluster Name:   ipm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ipm_server2
    Cluster Name:   ipm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ipm_server3
    Cluster Name:   ipm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ipm_server4
    Cluster Name:   ipm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ipm_server5
    Cluster Name:   capture_cluster
    Desired State:  RUNNING
    Health:         
      Activation Time:  2020-12-01T04:51:19.886Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime 
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    capture_server1
    State:          RUNNING
    Cluster Name:   capture_cluster
    Desired State:  SHUTDOWN
    Server Name:    capture_server2
    Cluster Name:   capture_cluster
    Desired State:  SHUTDOWN
    Server Name:    capture_server3
    Cluster Name:   capture_cluster
    Desired State:  SHUTDOWN
    Server Name:    capture_server4
    Cluster Name:   capture_cluster
    Desired State:  SHUTDOWN
    Server Name:    capture_server5
    Cluster Name:   wccadf_cluster
    Desired State:  RUNNING
    Health:         
      Activation Time:  2020-12-01T04:51:19.886Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime 
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    wccadf_server1
    State:          RUNNING
    Cluster Name:   wccadf_cluster
    Desired State:  SHUTDOWN
    Server Name:    wccadf_server2
    Cluster Name:   wccadf_cluster
    Desired State:  SHUTDOWN
    Server Name:    wccadf_server3
    Cluster Name:   wccadf_cluster
    Desired State:  SHUTDOWN
    Server Name:    wccadf_server4
    Cluster Name:   wccadf_cluster
    Desired State:  SHUTDOWN
    Server Name:    wccadf_server5
  Start Time:       2020-11-23T12:48:13.756Z
Events:             <none>

出力のStatusセクションに、使用可能なサーバーおよびクラスタがリストされます。このコマンドがスクリプトの終了後すぐに発行された場合、まだ使用可能なサーバーがないか、管理サーバーのみで管理対象サーバーがない可能性があることに注意してください。WebLogic Kubernetes Operatorは、最初に管理サーバーを起動し、その準備が完了するまで待機してから管理対象サーバーを起動します。

ポッドの検証

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

$ kubectl get pods -n NAMESPACE

次に、このコマンドの出力例を示します。ucm、ibr、ipm、captureおよびwccadfクラスタの管理サーバーと管理対象サーバーが実行されていることを確認できます。

$ kubectl get pod -n wccns
NAME                                                READY   STATUS      RESTARTS   AGE
rcu                                                 1/1     Running     0          78d
wccinfra-adminserver                                1/1     Running     0          9d
wccinfra-create-fmw-infra-sample-domain-job-l8r9d   0/1     Completed   0          9d
wccinfra-ibr-server1                                1/1     Running     0          9d
wccinfra-ucm-server1                                1/1     Running     0          9d
wccinfra-ucm-server2                                1/1     Running     0          9d
wccinfra-ucm-server3                                1/1     Running     0          9d
wccinfra-ipm-server1                                1/1     Running     0          9d
wccinfra-ipm-server2                                1/1     Running     0          9d
wccinfra-ipm-server3                                1/1     Running     0          9d
wccinfra-capture-server1                            1/1     Running     0          9d
wccinfra-capture-server2                            1/1     Running     0          9d
wccinfra-capture-server3                            1/1     Running     0          9d
wccinfra-wccadf-server1                             1/1     Running     0          9d
wccinfra-wccadf-server2                             1/1     Running     0          9d
wccinfra-wccadf-server3                             1/1     Running     0          9d

サービスの検証

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

$ kubectl get services -n NAMESPACE

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

サービスのサンプル・リスト:

$ kubectl get services -n wccns
NAME                               TYPE        CLUSTER-IP       EXTERNAL-IP       PORT(S)          AGE
wccinfra-adminserver               ClusterIP   None             <none>            7001/TCP         9d
wccinfra-adminserver-external      NodePort    10.104.100.193   <none>            7001:30701/TCP   9d
wccinfra-cluster-ibr-cluster       ClusterIP   10.98.100.212    <none>            16250/TCP        9d
wccinfra-cluster-ibr-cluster-ext   NodePort    10.109.247.52    <none>            5555:30555/TCP   9d
wccinfra-cluster-ucm-cluster       ClusterIP   10.108.47.178    <none>            16200/TCP        9d
wccinfra-cluster-ipm-cluster       ClusterIP   10.108.217.111   <none>            16000/TCP        9d
wccinfra-cluster-capture-cluster   ClusterIP   10.110.193.252   <none>            16400/TCP        9d
wccinfra-cluster-wccadf-cluster    ClusterIP   10.109.191.247   <none>            16225/TCP        9d
wccinfra-ibr-server1               ClusterIP   None             <none>            16250/TCP        9d
wccinfra-ibr-server2               ClusterIP   10.97.253.44     <none>            16250/TCP        9d
wccinfra-ibr-server3               ClusterIP   10.110.183.48    <none>            16250/TCP        9d
wccinfra-ibr-server4               ClusterIP   10.108.228.158   <none>            16250/TCP        9d
wccinfra-ibr-server5               ClusterIP   10.101.29.140    <none>            16250/TCP        9d
wccinfra-ucm-server1               ClusterIP   None             <none>            16200/TCP        9d
wccinfra-ucm-server2               ClusterIP   None             <none>            16200/TCP        9d
wccinfra-ucm-server3               ClusterIP   None             <none>            16200/TCP        9d
wccinfra-ucm-server4               ClusterIP   10.109.25.242    <none>            16200/TCP        9d
wccinfra-ucm-server5               ClusterIP   10.109.193.26    <none>            16200/TCP        9d
wccinfra-ipm-server1               ClusterIP   None             <none>            16000/TCP        9d
wccinfra-ipm-server2               ClusterIP   None             <none>            16000/TCP        9d
wccinfra-ipm-server3               ClusterIP   None             <none>            16000/TCP        9d
wccinfra-ipm-server4               ClusterIP   10.111.215.108   <none>            16000/TCP        9d
wccinfra-ipm-server5               ClusterIP   10.109.220.10    <none>            16000/TCP        9d
wccinfra-capture-server1           ClusterIP   None             <none>            16400/TCP        9d
wccinfra-capture-server2           ClusterIP   None             <none>            16400/TCP        9d
wccinfra-capture-server3           ClusterIP   None             <none>            16400/TCP        9d
wccinfra-capture-server4           ClusterIP   10.109.72.216    <none>            16400/TCP        9d
wccinfra-capture-server5           ClusterIP   10.102.90.234    <none>            16400/TCP        9d
wccinfra-wccadf-server1            ClusterIP   None             <none>            16225/TCP        9d
wccinfra-wccadf-server2            ClusterIP   None             <none>            16225/TCP        9d
wccinfra-wccadf-server3            ClusterIP   None             <none>            16225/TCP        9d
wccinfra-wccadf-server4            ClusterIP   10.99.91.229     <none>            16225/TCP        9d
wccinfra-wccadf-server5            ClusterIP   10.105.114.38    <none>            16225/TCP        9d

管理対象サーバー数のスケールアップ/ダウン

既存のドメインでは、(十分なアクセス権を持つ顧客によって処理されるように) domain.yamlを変更することで、これらの管理対象サーバーのレプリカ数を相互に独立して変更できます。既存のドメインの管理対象サーバー数をスケール・アップまたはスケール・ダウンするには、次のステップを実行する必要があります。

$ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/output/weblogic-domains/wccinfra/

# modify respective managed server replicas to scale up or scale down and save it.
$ vim domain.yaml

# Apply the updated domain.yaml configuration file
$ kubectl apply -f domain.yaml

UCMでIBRプロバイダを構成するために必要な詳細

  1. IBR intradocポートにマップされたNodePortのサービスwccinfra-cluster-ibr-cluster-extの詳細を取得します

    NAME                            TYPE      CLUSTER-IP    EXTERNAL-IP PORT(S)                      
wccinfra-cluster-ibr-cluster-ext NodePort 10.109.247.52 <none>     5555:30555/TCP

  2. 次の詳細を指定して送信プロバイダを作成し、サーバーを再起動します。

    NodePort値(前述のサンプルでは30555)をServer Portとして指定してください。

    Server Host Name:  <hostname in which IBR Server pod is deployed>

Server Port: 30555

    wcc-provider-ucm-ibr

ImagingおよびCaptureのドメインへの追加のマウントまたは共有領域の構成

オプションで、WebCenter ImagingおよびWebCenter Captureアプリケーションでのファイル・インポート用にドメインに追加のマウントまたは共有領域を構成する場合は、[ImagingおよびCaptureのドメインへの追加のマウントまたは共有領域の構成]({{< relref “/wccontent-domains/adminguide/configure-mount-share.md” >}})を参照してください。

コンテナでのOracle Webcenter Contentネイティブ・アプリケーションの起動

この項では、ユーザー・インタフェースで製品ネイティブ・バイナリを使用するために必要なステップについて説明します。

Oracle WebCenter Contentネイティブ・バイナリのヘッドフル・ユーザー・インタフェースの起動に関する問題

Oracle WebCenter Content (UCM)は、製品コンテナ・イメージの一部として提供されるヘッドフルUIを備えたネイティブ・バイナリのセットを提供します。WebCenter Contentコンテナ・イメージは、デフォルトでOracle slim linuxイメージで作成されます。このイメージには、UIが起動されるヘッドフル・アプリケーションをサポートするために事前インストールされるパッケージの一部が付属していません。UCMには、UIサポートにJAVA AWTを使用するこのような多くのネイティブ・バイナリが用意されています。現在のOracle WebCenter Contentコンテナ・イメージでは、ネイティブ・アプリケーションの実行に失敗するため、UIを起動できません。

次の各項では、一連の手順を提供して、ユーザーがUIを備えたUCMネイティブ・アプリケーションを実行できるようにする解決策について説明します。

これらの手順は2つの部分に分かれています - 1.既存のコンテナ・イメージを更新するステップ 1.VNCセッションを使用してネイティブ・アプリケーションを起動するステップ

WebLogic Image Toolを使用して初期設定のOracle WebCenter Contentコンテナ・イメージを更新するステップ

この項では、WebLogic Image Toolを使用してOSパッケージでイメージを更新する方法について説明します。WebLogic Image Toolの設定については、ここを参照してください。#### 追加のビルド・コマンド

必要なOSパッケージをイメージにインストールするには、WebLogic Image Toolで使用可能な追加のビルド・コマンド・オプションでyumコマンドを使用します。次に示すサンプルのadditionalBuildCmds.txtファイルを使用して、必要なLinuxパッケージ(libXext.x86_64、libXrender.x86_64およびlibXtst.x86_64)をインストールします。

[final-build-commands]
USER root
RUN yum -y --downloaddir=/tmp/imagetool install libXext libXrender libXtst  \
        && yum -y --downloaddir=/tmp/imagetool clean all \
    && rm -rf /var/cache/yum/* \
    && rm -rf /tmp/imagetool
USER oracle

ノート: ユーザーをoracleに変更することが重要です。そうしないと、コンテナ実行中のユーザーはrootになります。#### ビルド引数

イメージの更新に必要な引数は、ファイルとしてWebLogic Image Toolに渡すことができます。

'update' is the sub command to Image Tool for updating an existing docker image.
'--fromImage' option provides the existing docker image that has to be updated.
'--tag' option should be provided with the new tag for the updated image.
'--additionalBuildCommands' option should be provided with the above created additional build commands file.
'--chown oracle:root' option should be provided to update file permissions.

次に、イメージの更新に使用するサンプルのビルド引数(buildArgs)ファイルを示します。

  update
  --fromImage <existing_WCContent_image_without_dependent_packages>
  --tag <name_of_updated_WCContent_image_to_be_built>
  --additionalBuildCommands ./additionalBuildCmds.txt
  --chown oracle:root

Oracle WebCenter Contentコンテナ・イメージの更新

ここで、前述のビルド引数ファイルを使用して、WebLogic Image Toolを実行し、初期設定のイメージを更新します -

$ imagetool @buildArgs

WebLogic Image Toolには、イメージを更新するための複数のオプションが用意されています。更新オプションの詳細は、このドキュメントを参照してください。

イメージを更新しても、追加のビルド・コマンドで変更されないかぎり、ソース・イメージの'CMD'は変更されません。

$ docker inspect -f '{{.Config.Cmd}}' <name_of_updated_Wccontent_image>
[/u01/oracle/container-scripts/createDomainandStartAdmin.sh]

VNCセッションを使用してOracle WebCenter Contentネイティブ・アプリケーションを起動するステップ。

更新されたイメージが正常にビルドされ、必要なすべてのノードで使用可能になったら、次を実行します: a.更新されたイメージ名でdomain.yamlファイルを更新し、domain.yamlファイルを適用します。

$ kubectl apply -f domain.yaml
  1. 変更されたdomain.yamlを適用すると、ポッドが再起動され、必要なパッケージで更新されたイメージで実行が開始されます。
$ kubectl get pods -n <namespace_being_used_for_wccontent_domain>

  1. マスター・ノードでVNCセッションを作成し、ネイティブ・アプリケーションを起動します。これらのステップにはVNCセッションを使用して従う必要があります。

  2. 各VNCセッションで次のコマンドを実行します:

$ xhost + <HOST-IP or HOST-NAME of the node, on which POD is deployed>

ノート: 前述のコマンドは、マルチノード・クラスタ(マスター・ノードとワーカー・ノードが異なるホストにデプロイされ、ポッドがワーカー・ノード間で分散されて異なるホストで実行されているクラスタ)に対して動作します。単一ノード・クラスタ(マスター・ノードのみが存在し、ワーカー・ノードがなく、マスター・ノードが実行されているホストにすべてのポッドがデプロイされている場合)では、マスター・ノード自体のHOST-IPではなく、コンテナ/ポッドのIPを使用する必要があります。

コンテナIPを取得するには、ステップgに記載されているコマンドをそのコンテナのシェル内から実行します。

$ xhost + <IP of the container, from which binaries are to be run >
  1. ポッド(wccinfra-ucm-server1など)のシェルを実行します:
$ kubectl exec -n wccns -it wccinfra-ucm-server1 -- /bin/bash
  1. バイナリの場所に移動します:
$ cd /u01/oracle/user_projects/domains/wccinfra/ucm/cs/bin
  1. コンテナIPを取得します:
$ hostname -i
  1. コンテナ内でDISPLAY変数を設定します:
$ export DISPLAY=<HOST-IP/HOST-NAME of the master node, where VNC session was
created>:vnc-session display-id
  1. 次のように、コンテナ内から任意のネイティブUCMアプリケーションを起動します:
$ ./SystemProperties

アプリケーションにUIがある場合は、すぐに起動されます。

管理ガイド

Oracle WebCenter Contentドメインを管理するための一般的なユーティリティ・ツールおよび構成のいくつかを使用する方法を説明します。

ロード・バランサの設定

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

Traefik

この項では、Oracle WebCenter Contentドメイン・クラスタをロード・バランシングするように、イングレス・ベースのTraefikロード・バランサ(本番デプロイメントではバージョン2.6.0以降)をインストールおよび構成する方法について説明します。アプリケーションURLの非SSL、SSL終端およびエンドツーエンドSSLアクセス用にTraefikを構成できます。

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

非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をインストールします:

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

    サンプル出力:

        NAME: traefik
    LAST DEPLOYED: Sun Jan 17 23:30:20 2021
    NAMESPACE: traefik
    STATUS: deployed
    REVISION: 1
    TEST SUITE: None

    Traefik 2.6.0のデプロイメント用のサンプルvalues.yaml:

    image:
name: traefik
tag: 2.6.0
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
   expose: true
   # The exposed port for this service
   exposedPort: 9000
   # The port protocol (TCP/UDP)
   protocol: TCP
web:
   port: 8000
   # hostPort: 8000
   expose: true
   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
#    # hostPort: 8443
   expose: true
   exposedPort: 30443
   # The port protocol (TCP/UDP)
   protocol: TCP
   nodePort: 30443
additionalArguments:
  - "--log.level=INFO"

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

     $ kubectl get all -n traefik

サンプル出力:

   NAME                                    READY   STATUS    RESTARTS   AGE
   pod/traefik-f9cf58697-p57nt             1/1     Running   0          22d
   
   NAME                                    TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                                          AGE
   service/traefik                         NodePort   10.96.95.253   <none>        9000:32306/TCP,30305:30305/TCP,30443:30443/TCP   22d
   
   NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/traefik                 1/1     1            1           22d
   
   NAME                                    DESIRED   CURRENT   READY   AGE
   replicaset.apps/traefik-f9cf58697       1         1         1       22d

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

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

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

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

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

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

サンプル出力:

Release "traefik" has been upgraded. Happy Helming!
NAME: traefik
LAST DEPLOYED: Sun Jan 17 23:43:02 2021
NAMESPACE: traefik
STATUS: deployed
REVISION: 2
TEST SUITE: None

ドメインのイングレスの作成

サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します。ここでは、パスベースのルーティングがイングレスに使用されます。デフォルト構成のサンプル値は、${WORKDIR}/charts/ingress-per-domain/values.yamlファイルに示されています。デフォルトでは、typeはTRAEFIK、tlsはNon-SSLで、domainTypeはwccinfraです。これらの値をオーバーライドするには、コマンドラインを介して値を渡すか、構成のタイプ(非SSLまたはSSL)に基づいてサンプル・ファイルvalues.yamlでそれらを編集します。必要に応じて、イングレスYAMLファイルを更新して、アクセスが必要なドメイン・アプリケーションURLに基づいて(spec.rules.host.http.pathsセクションに)追加のパス・ルールを定義できます。Traefik (イングレスベース)ロード・バランサのテンプレートYAMLファイルは、${WORKDIR}/charts/ingress-per-domain/templates/traefik-ingress.yamlにあります

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

     $ cd ${WORKDIR}
 $ helm install wcc-traefik-ingress  \
     charts/ingress-per-domain \
     --set type=TRAEFIK \
     --namespace wccns \
     --values charts/ingress-per-domain/values.yaml \
     --set "traefik.hostname=$(hostname -f)" \
     --set tls=NONSSL

    サンプル出力:

      NAME: wcc-traefik-ingress
  LAST DEPLOYED: Sun Jan 17 23:49:09 2021
  NAMESPACE: wccns
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None

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

     $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt \
 -subj "/CN=<your_host_name>" \
 -extensions san -config \
 <(echo "[req]";
 echo distinguished_name=req;
 echo "[san]";
 echo subjectAltName=DNS:<your_host_name>
 )

 $ kubectl -n wccns create secret tls domain1-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt

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

  3. Traefikミドルウェア・カスタム・リソースの作成

    SSL終端の場合、Traefikはカスタム・ヘッダーWL-Proxy-SSL:trueをWebLogic Serverエンドポイントに渡す必要があります。次のコマンドを使用して、ミドルウェアを作成します:

    $ cat <<EOF | kubectl apply -f -
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: wls-proxy-ssl
  namespace: wccns
spec:
  headers:
    customRequestHeaders:
       WL-Proxy-SSL: "true"
EOF

  4. 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: wccns
spec:
  defaultCertificate:
    secretName:  domain1-tls-cert   
EOF

  5. 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: wccns-wls-proxy-ssl@kubernetescrd

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

     $ cd ${WORKDIR}
 $ helm install wcc-traefik-ingress  \
     charts/ingress-per-domain \
     --set type=TRAEFIK \
     --namespace wccns \
     --values charts/ingress-per-domain/values.yaml \
     --set "traefik.hostname=$(hostname -f)" \
     --set "traefik.hostnameorip=$(hostname -f)" \
     --set tls=SSL

    サンプル出力:

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

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

     $ kubectl describe ingress wccinfra-traefik  -n wccns

これらは、前述のデプロイ済イングレスでサポートされるすべてのサービスです:

    Name:             wccinfra-traefik
    Namespace:        wccns
    Address:
    Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
    Rules:
  Host                                        Path  Backends
  ----                                        ----  --------
  domain1.org
                                             /em                      wccinfra-adminserver:7001 (10.244.0.201:7001)
                                             /wls-exporter            wccinfra-adminserver:7001 (10.244.0.201:7001)
                                             /cs                      wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /adfAuthentication       wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /_ocsh                   wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /_dav                    wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /idcws                   wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /idcnativews             wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /wsm-pm                  wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /ibr                     wccinfra-cluster-ibr-cluster:16250 (10.244.0.203:16250)
                                             /ibr/adfAuthentication   wccinfra-cluster-ibr-cluster:16250 (10.244.0.203:16250)
                                             /weblogic/ready          wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /imaging                 wccinfra-cluster-ipm-cluster:16000 (10.244.0.206:16000,10.244.0.209:16000,10.244.0.213:16000)
                                             /dc-console              wccinfra-cluster-capture-cluster:16400 (10.244.0.204:16400,10.244.0.208:16400,10.244.0.212:16400)
                                             /dc-client               wccinfra-cluster-capture-cluster:16400 (10.244.0.204:16400,10.244.0.208:16400,10.244.0.212:16400)
                                             /wcc                     wccinfra-cluster-wccadf-cluster:16225 (10.244.0.205:16225,10.244.0.210:16225,10.244.0.214:16225)
Annotations:                                    kubernetes.io/ingress.class: traefik
                                             meta.helm.sh/release-name: wcc-traefik-ingress
                                             meta.helm.sh/release-namespace: wccns
Events:                                         <none>

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

     $ kubectl describe  ingress wccinfra-traefik  -n wccns

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

  Name:             wccinfra-traefik
Namespace:        wccns
Address:
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
Host                                        Path  Backends
----                                        ----  --------
domain1.org
                                             /em                      wccinfra-adminserver:7001 (10.244.0.201:7001)
                                             /wls-exporter            wccinfra-adminserver:7001 (10.244.0.201:7001)
                                             /cs                      wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /adfAuthentication       wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /_ocsh                   wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /_dav                    wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /idcws                   wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /idcnativews             wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /wsm-pm                  wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /ibr                     wccinfra-cluster-ibr-cluster:16250 (10.244.0.203:16250)
                                             /ibr/adfAuthentication   wccinfra-cluster-ibr-cluster:16250 (10.244.0.203:16250)
                                             /weblogic/ready          wccinfra-cluster-ucm-cluster:16200 (10.244.0.202:16200,10.244.0.207:16200,10.244.0.211:16200)
                                             /imaging                 wccinfra-cluster-ipm-cluster:16000 (10.244.0.206:16000,10.244.0.209:16000,10.244.0.213:16000)
                                             /dc-console              wccinfra-cluster-capture-cluster:16400 (10.244.0.204:16400,10.244.0.208:16400,10.244.0.212:16400)
                                             /dc-client               wccinfra-cluster-capture-cluster:16400 (10.244.0.204:16400,10.244.0.208:16400,10.244.0.212:16400)
                                             /wcc                     wccinfra-cluster-wccadf-cluster:16225 (10.244.0.205:16225,10.244.0.210:16225,10.244.0.214:16225)
Annotations:                                    kubernetes.io/ingress.class: traefik
                                             meta.helm.sh/release-name: wcc-traefik-ingress
                                             meta.helm.sh/release-namespace: wccns
Events:                                         <none>

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

     $ curl -v http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_PORT}/weblogic/ready
 * About to connect() to abc.com port 30305 (#0)
 *   Trying 100.111.156.246...
 * Connected to abc.com (100.111.156.246) port 30305 (#0)
 > GET /weblogic/ready HTTP/1.1
 > User-Agent: curl/7.29.0
 > Host: domain1.org:30305
 > Accept: */*
 >
 < HTTP/1.1 200 OK
 < Content-Length: 0
 < Date: Thu, 03 Dec 2020 13:16:19 GMT
 < Vary: Accept-Encoding
 <
 * Connection #0 to host abc.com left intact

    ドメイン・アプリケーションURLアクセスの検証

非SSL構成の場合

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

    http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/weblogic/ready
    http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/cs
    http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/ibr
    http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/em
    http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/imaging
    http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/dc-console
    http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/wcc
SSL構成の場合

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

    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/weblogic/ready
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/cs
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/ibr
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/em
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/imaging
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/dc-console
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/wcc

エンドツーエンド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をインストールします:

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

    サンプル出力:

        NAME: traefik
    LAST DEPLOYED: Sun Jan 17 23:30:20 2021
    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-operator-676fc64d9c-skppn   1/1     Running   0          78d

   NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
   service/traefik-operator             NodePort    10.109.223.59   <none>        443:30443/TCP,80:30305/TCP   78d
   service/traefik-operator-dashboard   ClusterIP   10.110.85.194   <none>        80/TCP                       78d

   NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/traefik-operator   1/1     1            1           78d

   NAME                                          DESIRED   CURRENT   READY   AGE
   replicaset.apps/traefik-operator-676fc64d9c   1         1         1       78d
   replicaset.apps/traefik-operator-cb78c9dc9    0         0         0       78d

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

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

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

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

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

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

サンプル出力:

      Release "traefik" has been upgraded. Happy Helming!
      NAME: traefik
      LAST DEPLOYED: Sun Jan 17 23:43:02 2021
      NAMESPACE: traefik
      STATUS: deployed
      REVISION: 2
      TEST SUITE: None

IngressRouteTCPの作成

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

    ノート: エンドツーエンドSSL構成のロード・バランサには、制限があります。複数のタイプのサーバー(異なる管理対象サーバーや管理サーバー)に同時にアクセスすることは、現在サポートされていません。一度に1つの管理対象サーバーにのみアクセスできます。

    traefik-tls.yamlで次を更新する必要があります:

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

    サンプルtraefik-tls.yaml:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRouteTCP
metadata:
  name: wcc-ucm-routetcp
  namespace: wccns
spec:
  entryPoints:
    - websecure
  routes:
  - match: HostSNI(`your_host_name`)
    services:
    - name: wccinfra-cluster-ucm-cluster
      port: 16201
      weight: 3
      terminationDelay: 400
  tls:
    passthrough: true
  1. IngressRouteTCPを作成します:
cd ${WORKDIR}/charts/ingress-per-domain/tls

$ kubectl apply -f traefik-tls.yaml

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

構成済のサービスを介して公開されたアプリケーションURLへのアクセスを検証します。次のOracle WebCenter ContentドメインURLにアクセスできる必要があります:

LOADBALANCER-SSLPORTは30443です

https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/cs
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/ibr
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/imaging
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/dc-console
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/wcc

IngressRouteTCPの削除

cd ${WORKDIR}/charts/ingress-per-domain/tls

$ kubectl delete -f traefik-tls.yaml

Traefikのアンインストール

$ helm delete wcc-traefik-ingress -n wccns

$ helm delete traefik -n wccns

$ kubectl delete namespace traefik

NGINX

この項では、Oracle WebCenter Contentドメイン・クラスタをロード・バランシングするように、イングレス・ベースのNGINXロード・バランサをインストールおよび構成する方法について説明します。アプリケーションURLの非SSL、SSL終端およびエンドツーエンドSSLアクセス用にNGINXを構成できます。

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

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

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

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

非SSLおよびSSL終端

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

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

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

    サンプル出力:

NAME: nginx-ingress
LAST DEPLOYED: Fri Jul 29 00:14:19 2022
NAMESPACE: wccns
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 wccns get services -o jsonpath="{.spec.ports[0].nodePort}" nginx-ingress-ingress-nginx-controller)
  export HTTPS_NODE_PORT=$(kubectl --namespace wccns get services -o jsonpath="{.spec.ports[1].nodePort}" nginx-ingress-ingress-nginx-controller)
  export NODE_IP=$(kubectl --namespace wccns 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/v1
  kind: Ingress
  metadata:
    name: example
    namespace: foo
  spec:
    ingressClassName: nginx
    rules:
      - host: www.example.com
        http:
          paths:
            - pathType: Prefix
              backend:
                service:
                  name: exampleService
                  port:
                    number: 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 wccns get services | grep ingress-nginx-controller

    サンプル出力:

     nginx-ingress-ingress-nginx-controller    NodePort    10.97.189.122    <none>            80:30993/TCP,443:30232/TCP    7d2h

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

  1. サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します。ここでは、パスベースのルーティングがイングレスに使用されます。デフォルト構成のサンプル値は、${WORKDIR}/charts/ingress-per-domain/values.yamlファイルに示されています。デフォルトでは、typeはTRAEFIK、tlsはNon-SSLで、domainTypeはwccinfraです。これらの値をオーバーライドするには、コマンドラインを介して値を渡すか、サンプル・ファイルvalues.yamlでそれらを編集します。必要に応じて、イングレスYAMLファイルを更新して、アクセスが必要なドメイン・アプリケーションURLに基づいて(spec.rules.host.http.pathsセクションに)追加のパス・ルールを定義できます。${WORKDIR}/charts/ingress-per-domain/templates/nginx-ingress.yamlにあるNGINXロード・バランサのテンプレートYAMLファイルを更新します

    $ cd ${WORKDIR}
$ helm install wccinfra-nginx-ingress charts/ingress-per-domain \
--namespace wccns \
--values charts/ingress-per-domain/values.yaml \
--set "nginx.hostname=$(hostname -f)" \
--set type=NGINX \
--set tls=NONSSL

    サンプル出力:

    NAME: wccinfra-nginx-ingress
LAST DEPLOYED: Sun Feb  7 23:52:38 2021
NAMESPACE: wccns
STATUS: deployed
REVISION: 1
TEST SUITE: None

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

     $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt \
 -subj "/CN=<your_host_name>" \
 -extensions san -config \
 <(echo "[req]";
 echo distinguished_name=req;
 echo "[san]";
 echo subjectAltName=DNS:<your_host_name>
 )

 $ kubectl -n wccns create secret tls domain1-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt

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

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

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

    サンプル出力:

     NAME: wccinfra-nginx-ingress
 LAST DEPLOYED: Mon Feb  8 00:01:13 2021
 NAMESPACE: wccns
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None

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

      $ kubectl describe ingress wccinfra-nginx  -n wccns

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

Name:             wccinfra-nginx
Namespace:        wccns
Address:          10.97.189.122
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  domain1-tls-cert terminates domain1.org
Rules:
  Host                                        Path  Backends
  ----                                        ----  --------
  domain1.org
                                              /em                      wccinfra-adminserver:7001 (10.244.0.58:7001)
                                              /servicebus              wccinfra-adminserver:7001 (10.244.0.58:7001)
                                              /cs                      wccinfra-cluster-ucm-cluster:16200 (10.244.0.60:16200,10.244.0.61:16200)
                                              /adfAuthentication       wccinfra-cluster-ucm-cluster:16200 (10.244.0.60:16200,10.244.0.61:16200)
                                              /ibr                     wccinfra-cluster-ibr-cluster:16250 (10.244.0.59:16250)
                                              /ibr/adfAuthentication   wccinfra-cluster-ibr-cluster:16250 (10.244.0.59:16250)
                                              /weblogic/ready          wccinfra-cluster-ucm-cluster:16200 (10.244.0.60:16200,10.244.0.61:16200)
                                              /imaging                 wccinfra-cluster-ipm-cluster:16000 (10.244.0.206:16000,10.244.0.209:16000,10.244.0.213:16000)
                                              /dc-console              wccinfra-cluster-capture-cluster:16400 (10.244.0.204:16400,10.244.0.208:16400,10.244.0.212:16400)
                                              /dc-client               wccinfra-cluster-capture-cluster:16400 (10.244.0.204:16400,10.244.0.208:16400,10.244.0.212:16400)
                                              /wcc                     wccinfra-cluster-wccadf-cluster:16225 (10.244.0.205:16225,10.244.0.210:16225,10.244.0.214:16225)
Annotations:                                  kubernetes.io/ingress.class: nginx
                                              meta.helm.sh/release-name: wccinfra-nginx-ingress
                                              meta.helm.sh/release-namespace: wccns
                                              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
Events:                                       <none>

非SSLおよびSSL終端アクセスの検証

非SSL構成

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

  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/weblogic/ready
  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/em
  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/cs
  http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/ibr
  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/imaging
  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/dc-console
  http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/wcc
SSL構成

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

  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/weblogic/ready
  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/em
  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/cs
  https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/ibr
  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/imaging
  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/dc-console
  https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/wcc

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

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

  $ helm delete wccinfra-nginx -n wccns

エンドツーエンドSSL構成

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

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

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

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

     $ helm install nginx-ingress -n wccns \     
 --set controller.extraArgs.default-ssl-certificate=wccns/domain1-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: Thu Sep  8 23:59:54 2022
NAMESPACE: wccns
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 wccns get services -o jsonpath="{.spec.ports[0].nodePort}" nginx-ingress-ingress-nginx-controller)
  export HTTPS_NODE_PORT=$(kubectl --namespace wccns get services -o jsonpath="{.spec.ports[1].nodePort}" nginx-ingress-ingress-nginx-controller)
  export NODE_IP=$(kubectl --namespace wccns 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/v1
  kind: Ingress
  metadata:
    name: example
    namespace: foo
  spec:
    ingressClassName: nginx
    rules:
      - host: www.example.com
        http:
          paths:
            - pathType: Prefix
              backend:
                service:
                  name: exampleService
                  port:
                    number: 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 wccns get services | grep ingress-nginx-controller

    サンプル出力:

      nginx-ingress-ingress-nginx-controller   NodePort    10.97.189.122    <none>            80:30993/TCP,443:30232/TCP    168m

個々の管理対象サーバーにアクセスするためのtlsのデプロイ

  1. tlsをデプロイしてサービスに安全にアクセスします。ssl-passthroughで構成できるアプリケーションは1つのみです。サービスwccinfra-cluster-ucm-clusterおよびポート16201のNGINXのサンプルtlsファイルを次に示します。ポート16201で実行されているすべてのアプリケーションに、このイングレスを介して安全にアクセスできます。NGINXでは、注釈ssl-passthroughによる複数のパス/ルールがサポートされていないため、バックエンド・サービスごとに異なるイングレスを作成します。つまり、wccinfra-cluster-ucm-cluster、wccinfra-cluster-ibr-cluster、wccinfra-cluster-ipm-cluster、wccinfra-cluster-capture-cluster、wccinfra-cluster-wccadf-clusterおよびwccinfra-adminserverでは、異なるイングレスを作成する必要があります。

    ノート: エンドツーエンドSSL構成のロード・バランサには、制限があります。複数のタイプのサーバー(異なる管理対象サーバーや管理サーバー)に同時にアクセスすることは、現在サポートされていません。一度に1つの管理対象サーバーにのみアクセスできます。

     $ cd ${WORKDIR}/charts/ingress-per-domain/tls

    サンプルnginx-ucm-tls.yaml:

nginx-ucm-tls.yamlの内容:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wcc-ucm-ingress
  namespace: wccns
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  tls:
  - hosts:
    - 'your_host_name'
    secretName: domain1-tls-cert
  rules:
  - host: 'your_host_name'
    http:
      paths:
      - path:
        pathType: ImplementationSpecific
        backend:
          service:
            name: wccinfra-cluster-ucm-cluster
            port: 
              number: 16201

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

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

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

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

    $ kubectl describe ingress wcc-ucm-ingress -n wccns

イングレスでサポートされているサービス:

Name:             wcc-ucm-ingress
Namespace:        wccns
Address:          10.102.97.237
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  domain1-tls-cert terminates domain1.org
Rules:
  Host                                         Path  Backends
  ----                                         ----  --------
  domain1.org
                                                  wccinfra-cluster-ucm-cluster:16201 (10.244.238.136:16201,10.244.253.132:16201)
Annotations:                                   kubernetes.io/ingress.class: nginx
                                               nginx.ingress.kubernetes.io/ssl-passthrough: true
Events:
  Type    Reason  Age                 From                      Message
  ----    ------  ----                ----                      -------
  Normal  Sync    62s (x2 over 106s)  nginx-ingress-controller  Scheduled for sync

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

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

   https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/cs

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

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

NGINXのアンインストール

//Uninstall and delete the `ingress-nginx` deployment
$ helm delete wccinfra-nginx-ingress -n wccns
  
//Uninstall NGINX
$ helm delete nginx-ingress -n wccns

Oracle WebCenter Contentドメインのモニター

PrometheusおよびGrafanaを使用してWebCenter Contentドメインをモニターするには、WebLogic Monitoring Exporterを使用してドメイン・インスタンスからメトリックをエクスポートします。

OracleWebCenterContentドメインのモニタリングの設定

WebLogic Monitoring Exporterを使用すると、実行中のOracle WebCenter Content Suiteインスタンスからランタイム情報をスクレイピングし、PrometheusおよびGrafanaを使用してモニターできます。これらのステップに従って、Oracle WebCenter Content Suiteインスタンスのモニタリングを設定します。WebLogic Monitoring Exporterの詳細は、ここを参照してください。

Grafanaダッシュボードを使用したモニタリングの検証

設定の完了後、ドメイン・メトリックを表示するには、http://mycompany.com:32100/でGrafanaダッシュボードにアクセスします。

WebLogic Serverダッシュボードが表示されます。

wcc-gp-dashboard

ログのElasticsearch統合

Oracle WebCenter Contentドメインをモニターし、WebLogic ServerログをElasticsearchに公開します。

1. ElasticsearchとWebLogic Kubernetes Operatorの統合

参照情報は、WebLogic Kubernetes OperatorのElasticsearch統合を参照してください。

Elasticsearch統合を有効にするには、WebLogic Kubernetes Operatorをデプロイする前にファイル${WORKDIR}/charts/weblogic-operator/values.yamlを編集する必要があります。

# elkIntegrationEnabled specifies whether or not ELK integration is enabled.                                            
elkIntegrationEnabled: true                                                                                             
                                                                                                                        
# logStashImage specifies the docker image containing logstash.                                                         
# This parameter is ignored if 'elkIntegrationEnabled' is false.                                                        
logStashImage: "logstash:6.8.23"                                                                                         
                                                                                                                        
# elasticSearchHost specifies the hostname of where Elasticsearch is running.                                           
# This parameter is ignored if 'elkIntegrationEnabled' is false.                                                        
elasticSearchHost: "elasticsearch.default.svc.cluster.local"                                                            
                                                                                                                        
# elasticSearchPort specifies the port number of where Elasticsearch is running.                                        
# This parameter is ignored if 'elkIntegrationEnabled' is false.                                                        
elasticSearchPort: 9200

WebLogic Kubernetes Operatorをデプロイして前述の変更を行うと、weblogic-operatorポッドに追加のLogstashコンテナが含まれるようになります。Logstashコンテナは、構成されたElasticsearchサーバーにweblogic-operatorログをプッシュします。

2. Logstashポッドを使用したWebLogic ServerおよびWebCenter Contentログの公開

Logstashポッドを使用して、WebLogic ServerログをElasticsearchサーバーに公開できます。このLogstashポッドは、共有ドメイン・ホームにアクセスできる必要があります。WebCenter Content wccinfraでは、Logstashポッドのドメイン・ホームの永続ボリュームを使用できます。Logstashポッドを作成するステップは、次のとおりです:

WebLogic Serverのドメイン・ホームの永続ボリュームの詳細を取得します。次のコマンドは、ネームスペース(wccns)の永続ボリュームの詳細をリストします:

$ kubectl get pv -n wccns
NAME                 CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                       STORAGECLASS                    REASON   AGE
wccinfra-domain-pv   10Gi       RWX            Retain           Bound    wccns/wccinfra-domain-pvc   wccinfra-domain-storage-class            33d

構成に従って、$WORKDIR/logging-services/logstash/logstash.yamlにあるlogstash.yamlを更新して、Logstashポッドのデプロイメントyamlを作成します。ドメイン・ホームのマウントされた永続ボリュームは、LogstashポッドにWebLogic Serverログへのアクセスを提供します。次に、サンプルのLogstashデプロイメントyamlを示します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: logstash
  namespace: wccns
spec:
  selector:
    matchLabels:
      app: logstash
  template: # create pods using pod definition in this template
    metadata:
      labels:
        app: logstash
    spec:
      volumes:
      - name: weblogic-domain-storage-volume
        persistentVolumeClaim:
          claimName: wccinfra-domain-pvc
      - name: shared-logs
        emptyDir: {}
      containers:
      - name: logstash
        image: logstash:6.8.23
        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: weblogic-domain-storage-volume
        - name: shared-logs
          mountPath: /shared-logs
        ports:
        - containerPort: 5044
          name: logstash

サンプルのLogstash構成ファイルは、$WORKDIR/logging-services/logstash/logstash.confにあります

$ vi $WORKDIR/logging-services/logstash/logstash.conf
input {                                                                                                                
  file {                                                                                                               
    path => "/u01/oracle/user_projects/domains/wccinfra/servers/**/logs/*-diagnostic.log"                                          
    start_position => beginning                                                                                        
  }              
  file {                                                                                                               
    path => "/u01/oracle/user_projects/domains/logs/wccinfra/*.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"]                                                          
  }                                                                                                                    
}

このサンプル構成では、wccinfraにあるすべてのサーバーおよび診断ログをLogstashに公開します。

$ kubectl cp $WORKDIR/logging-services/logstash/logstash.conf wccns/wccinfra-adminserver:/u01/oracle/user_projects/domains/logstash.conf

Logstashポッドのデプロイ

LogstashデプロイメントyamlおよびLogstash構成ファイルを作成したら、次のコマンドを使用してLogstashをデプロイします:

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

3. ElasticsearchおよびKibanaのデプロイメントのテスト

WebLogic Kubernetes Operatorは、テスト目的でElasticsearchおよびKibanaのサンプル・デプロイメントも提供します。次に示すように、KubernetesクラスタにElasticsearchおよびKibanaをデプロイできます:

$ cd ${WORKDIR}/elasticsearch-and-kibana/
$ kubectl create -f elasticsearch_and_kibana.yaml
次に示すように、Kibanaダッシュボードのポート情報を取得します:

ポッドの起動を待機します:

-bash-4.2$ 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
-bash-4.2$ kubectl get svc
NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
elasticsearch   ClusterIP   10.105.205.157   <none>        9200/TCP,9300/TCP   10d
kibana          NodePort    10.98.104.41     <none>        5601:30412/TCP      10d
kubernetes      ClusterIP   10.96.0.1        <none>        443/TCP             42d

Kibanaダッシュボードにはhttp://<your_hostname>:30412/でアクセスできます。この例では、ノード・ポートは30412になります。

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

「Kibana」→「Management」で索引パターンlogstash-*を作成します。サーバーが起動すると、Kibanaダッシュボードにログ・データが表示されます。

Elasticsearchへのログの公開

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

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

前提条件

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

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

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

ダウンロード:

$ wget https://github.com/oracle/weblogic-logging-exporter/releases/download/v1.0.1/weblogic-logging-exporter.jar
$ wget -O snakeyaml-1.27.jar https://search.maven.org/remotecontent?filepath=org/yaml/snakeyaml/1.27/snakeyaml-1.27.jar

ノート: このドキュメントのサンプル・コマンドでは次の識別子が使用されます。

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

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

$ kubectl cp <file-to-copy>   <namespace>/<administration-server-pod>:<domainhome>

$ kubectl cp weblogic-logging-exporter.jar wccns/wccinfra-adminserver:/u01/oracle/user_projects/domains/wccinfra/

$ kubectl cp snakeyaml-1.27.jar wccns/wccinfra-adminserver:/u01/oracle/user_projects/domains/wccinfra/

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

このステップでは、ログを収集するWebLogic Serverの起動クラスとしてweblogic-logging-exporter JARを構成します。

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

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

    wle-startup-class1

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

    wle-startup-class2

  4. これを確認するには、次の例のようなconfig.xmlファイル(/u01/oracle/user_projects/domains/wccinfra/config/config.xml)で更新をチェックします:

    $ kubectl exec -n wccns -it wccinfra-adminserver  cat /u01/oracle/user_projects/domains/wccinfra/config/config.xml
    <startup-class>
  <name>weblogic-logging-exporter</name>
  <target>adminServer,ucm_cluster,ibr_cluster,ipm_cluster,capture_cluster,wccadf_cluster</target>
  <class-name>weblogic.logging.exporter.Startup</class-name>
</startup-class>

WebLogic Server CLASSPATHの更新

  1. setDomainEnv.shファイルをポッドからローカル・フォルダにコピーします:

    $  kubectl cp wccns/wccinfra-adminserver:/u01/oracle/user_projects/domains/wccinfra/bin/setDomainEnv.sh $PWD/setDomainEnv.sh

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

  2. setDomainEnv.shを変更してサーバー・クラス・パスを更新し、ファイルの最後に次のコードを追加します:

    CLASSPATH=/u01/oracle/user_projects/domains/wccinfra/weblogic-logging-exporter.jar:/u01/oracle/user_projects/domains/wccinfra/snakeyaml-1.27.jar:${CLASSPATH}
export CLASSPATH

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

    $ kubectl cp setDomainEnv.sh wccns/wccinfra-adminserver:/u01/oracle/user_projects/domains/wccinfra/bin/setDomainEnv.sh

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

このステップでは、weblogic-logging-exporterの構成ファイルを作成します。

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

    サンプル:

    weblogicLoggingIndexName: wls
publishHost: elasticsearch.default.svc.cluster.local
publishPort: 9200
domainUID: wccinfra
weblogicLoggingExporterEnabled: true
weblogicLoggingExporterSeverity: Notice
weblogicLoggingExporterBulkSize: 1
weblogicLoggingExporterFilters:
- FilterExpression: NOT(MSGID = 'BEA-000449')

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

    $ kubectl cp ${WORKDIR}/logging-services/weblogic-logging-exporter/WebLogicLoggingExporter.yaml  wccns/wccinfra-adminserver:/u01/oracle/user_projects/domains/wccinfra/config/

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

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

サーバーを停止するには:
$ kubectl patch domain wccinfra -n wccns --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "NEVER" }]'
サーバーを起動するには:
$ kubectl patch domain wccinfra -n wccns --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/wccinfra/config/WebLogicLoggingExporter.yaml 
  
Config{weblogicLoggingIndexName='wls', publishHost='elasticsearch.default.svc.cluster.local', publishPort=9200, weblogicLoggingExporterSeverity='Notice', weblogicLoggingExporterBulkSize='1', enabled=true, weblogicLoggingExporterFilters=[
FilterConfig{expression='NOT(MSGID = 'BEA-000449')', servers=[]}], domainUID='wccinfra'} 
====================== WebLogic Logging Exporter is ebled 
================= publishHost in initialize: elasticsearch.default.svc.cluster.local 
================= publishPort in initialize: 9200 
================= url in executePutOrPostOnUrl: http://elasticsearch.default.svc.cluster.local:9200/wls

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

「Kibana」→「Management」で適切な索引パターンを作成します。サーバーが起動すると、Kibanaダッシュボードにログ・データが表示されます。

Fluentdを使用したElasticsearchへのログの公開

概要

このページでは、Fluentdを使用してログ情報をElasticsearchに送信するようにWebLogicドメインを構成する方法について説明します。次に、この仕組みの一般的なメカニズムを示します:

fluentd構成の作成

ドメインのネームスペースにfluentd-configという名前のConfigMapを作成します。ConfigMapには、解析ルールおよびElasticsearch構成が含まれます。次に、ConfigMapに定義されているいくつかの要素の説明を示します:

次に、fluentd構成のサンプルconfigmapを示します。

fluentd構成のサンプルconfigmap fluentd_configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    weblogic.domainUID: wccinfra
    weblogic.resourceVersion: domain-v2
  name: fluentd-config
  namespace: wccns
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']}"
    </match>

次のコマンドを使用して、ConfigMapを作成します

   $kubectl create -f fluentd_configmap.yaml

fluentd構成のマウント - WebLogicコンテナのボリュームとしてのConfigmap。

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

   $kubectl edit domain -n wccns

サンプルyamlコードの下に、Configmapをボリュームとして追加します。

  volumes:
- name: weblogic-domain-storage-volume
  persistentVolumeClaim:
    claimName: wccinfra-domain-pvc
- configMap:
    defaultMode: 420
    name: fluentd-config
  name: fluentd-config-volume

WebLogic Serverポッドへのfluentdコンテナの追加

fluentdコンテナyamlを、管理サーバーおよび管理対象サーバーのポッドでfluentdを実行するserverPod:セクションの下のドメインに追加します。

次のコンテナ定義に注意してください:

   $kubectl edit domain -n wccns

サンプルのfluentdコンテナyaml fluentd container:

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/wccinfra/$(SERVER_NAME).log
     - name: FLUENTD_CONF
       value: fluentd.conf
     - name: FLUENT_ELASTICSEARCH_SED_DISABLE
       value: "true"
     - name: ELASTICSEARCH_HOST
       value: elasticsearch.default.svc.cluster.local
     - name: ELASTICSEARCH_PORT
       value: "9200"
     - name: ELASTICSEARCH_USER
       value: elastic
     - name: ELASTICSEARCH_PASSWORD
       value: changeme
     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: /u01/oracle/user_projects/domains
       name: weblogic-domain-storage-volume

WebLogic Serverの再起動

サーバーを再起動するには、ドメインを編集し、serverStartPolicyをNEVERに変更してWebLogic Serverを停止します

   $kubectl edit domain -n wccns

すべてのサーバーが停止したら、ドメインを再度編集し、serverStartPolicyをIF_NEEDEDに設定してサーバーを再起動します。

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

「Kibana」→「Management」で索引パターン"wccinfra*"を作成します。サーバーが起動すると、Kibanaダッシュボードにログ・データが表示されます。

wcc-kibana-dashboard

ImagingおよびCaptureのドメインへの追加のマウントまたは共有領域の構成

外部アプリケーションが新しいファイルを書き込むことができるように、Kubernetesクラスタの外部から直接アクセスできるサーバー・ポッドにボリュームをマウントできます。

これは、特にファイル・インポート用のWebCenter ImagingおよびWebCenter Captureアプリケーションで使用できます。

Kubernetesは、ボリューム | Kubernetesに示された複数のタイプのボリュームをサポートしています。

この項では、さらにnfsボリュームを例として取り上げます。

ボリュームとしての"nfs"のマウント

ボリュームを使用するには、.spec.volumesでポッドに提供するボリュームを指定し、domain.yamlファイルの.spec.containers[*].volumeMountsでそれらのボリュームをコンテナにマウントする場所を宣言します。

domain.yamlを更新して次のサンプルに示すように変更を適用し、/u01/sharedirですべてのサーバー・ポッドにnfsサーバー(/sharedirの共有エクスポート・パスを持つ100.XXX.XXX.Xなど)をマウントします。

パス/u01/sharedirは、WebCenter ImagingおよびWebCenter Captureアプリケーションでファイル・インポート・パスとして構成でき、/sharedirに配置されたファイルはアプリケーションによって処理されます。

nfs-volume構成でのdomain.yamlのサンプル・エントリ

...
serverPod:
    # an (optional) list of environment variable to be set on the servers
    env:
    - name: JAVA_OPTIONS
      value: "-Dweblogic.StdoutDebugEnabled=false"
    - name: USER_MEM_ARGS
      value: "-Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx1024m "
    volumes:
    - name: weblogic-domain-storage-volume
      persistentVolumeClaim:
        claimName: wccinfra-domain-pvc
    - name: nfs-volume
      nfs:
        server: 100.XXX.XXX.XXX
        path: /sharedir
    volumeMounts:
    - mountPath: /u01/oracle/user_projects/domains
      name: weblogic-domain-storage-volume
    - mountPath: /u01/sharedir
      name: nfs-volume
...

パッチ適用およびアップグレード

既存のOracle WebCenter Contentイメージにパッチを適用するか、インフラストラクチャをアップグレードします(基礎となるKubernetesクラスタを新しいリリースにアップグレードしたり、WebLogic Kubernetes Operatorリリースをアップグレードするなど)。

Oracle WebCenter Content製品のDockerイメージへのパッチ適用

実行中のOracle WebCenter Content Kubernetes環境で、基礎となるOracle WebCenter Content製品イメージをアップグレードします。

次の手順では、実行中のOracle WebCenter Content Kubernetes環境で、Oracle WebCenter Content製品のDockerイメージの新しいリリースをアップグレードする方法について説明します。ドメインの管理対象サーバー・ポッドをアップグレードするには、ローリング・アップグレード方式が使用されます。

ノート: ローリング・アップグレード方式が使用されるため、ゼロ・ダウンタイムが予想されます。

前提条件

推奨事項: * WebLogic Image Toolの作成機能を使用して、Oracle WebCenter Content Dockerイメージにバンドル・パッチと複数の個別パッチを適用します。これは、イメージのサイズが最適化されるため、推奨されるアプローチです。* WebLogic Image Toolの更新機能を使用して、Oracle WebCenter Content Dockerイメージに単一の個別パッチを適用します。パッチ適用ツールによって導入された追加のイメージ・レイヤーが原因で、パッチ適用されたイメージ・サイズが大幅に増加する可能性があることに注意してください。

パッチ適用されたイメージの適用

  1. パッチ適用されたイメージを使用して、domain.yaml構成ファイルのimage:フィールドを更新します。

  2. 更新されたdomain.yaml構成ファイルを適用します:

    $ kubectl apply -f domain.yaml

    ノート: サーバー・ポッドは自動的に再起動されます(ローリング再起動)。

オペレータ・リリースのアップグレード

WebLogic Kubernetes Operatorリリースを新しいバージョンにアップグレードします。

これらの手順は、追加のバージョンがリリースされるときに、4.xリリースファミリ内でのオペレータのアップグレードに適用されます。

Kubernetesオペレータをアップグレードするには、helm upgradeコマンドを使用します。オペレータをアップグレードする場合、helm upgradeコマンドでは、新しいHelmチャートおよびイメージを指定する必要があります。例:

$ helm upgrade \
  --reuse-values \
  --set image=oracle/weblogic-kubernetes-operator:4.2.9 \
  --namespace weblogic-operator-namespace \
  --wait \
  weblogic-operator \
  kubernetes/charts/weblogic-operator

Kubernetesクラスタのアップグレード

実行中のOracle WebCenter Content Kubernetes環境で、基礎となるKubernetesクラスタ・バージョンをアップグレードします。

次の手順では、Oracle WebCenter Contentドメインがデプロイされているkubeadmを使用して作成されたKubernetesクラスタをアップグレードする方法について説明します。Kubernetesクラスタのノード(マスターおよびワーカー)をアップグレードするには、ローリング・アップグレード方式が使用されます。

警告: アップグレード・プロセスの一環としてノードをドレインする必要があるため、Kubernetesクラスタのアップグレード中に停止時間が発生することが予想されます。

前提条件

Kubernetesバージョンのアップグレード

Kubernetesでは、あるマイナー・バージョンから次のマイナー・バージョンへのアップグレード、または同じマイナーのパッチ・バージョン間でのアップグレードがサポートされます。たとえば、1.xから1.x+1にはアップグレードできますが、1.xから1.x+2にはアップグレードできません。Kubernetesバージョンをアップグレードするには、最初にKubernetesクラスタのすべてのマスター・ノードを順次アップグレードし、次に各ワーカー・ノードを順次アップグレードする必要があります。

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

この項では、Oracle WebCenter Contentドメインのデプロイに使用されるOracle WebCenter Content Dockerイメージを作成または更新する方法について説明します。Oracle WebCenter Content Dockerイメージは、WebLogic Image Toolを使用して作成できます。

My Oracle Support (MOS)へのアクセス権があり、パッチ(バンドルまたは個別)を含む新しいイメージをビルドする必要がある場合は、WebLogic Image Toolを使用して本番デプロイメント用のOracle WebCenter Contentイメージをビルドすることをお薦めします。

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

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

推奨事項: * createを使用して、*パッチなし*で、またはOracle WebCenter Contentバイナリ、バンドル・パッチおよび個別パッチを含めて新しいOracle WebCenter Content Dockerイメージを作成します。これは、イメージのサイズが最適化されるため、Oracle WebCenter Contentパッチにアクセスできる場合に推奨されるアプローチです。* updateを使用して、既存のOracle WebCenter Content Dockerイメージに単一の個別パッチを適用します。パッチ適用ツールによって導入された追加のイメージ・レイヤーが原因で、パッチ適用されたイメージ・サイズが大幅に増加する可能性があることに注意してください。

WebLogic Image Toolの設定

前提条件

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

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 Content Dockerイメージを作成するには、Oracle WebCenter Contentドメイン用の追加のコンテナ・スクリプトが必要です。

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

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

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

    $ mkdir -p imagetool-setup/docker-images/WebCenterContent/imagetool/14.1.2.0.0
$ cd imagetool-setup/docker-images/WebCenterContent/imagetool/14.1.2.0.0
$ cp -rf ${WORKDIR}/weblogic-kubernetes-operator/kubernetes/samples/scripts/imagetool-scripts/* .

イメージの作成

WebLogic Image Toolおよび必要なビルド・スクリプトの設定後、次のステップに従って、WebLogic Image Toolを使用して新しいOracle WebCenter Content Dockerイメージを作成します。

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

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

インストール・バイナリおよびパッチのサンプル・リスト: * JDK:
* jdk-17.0.9+10_linux-x64_bin.tar.gz

ノート: これはパッチのサンプル・リストです。Oracle WebCenter Contentイメージの適切なパッチ・リストを取得する必要があります。

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

コード・リポジトリの場所<imagetool-setup-location>/docker-images/OracleWebCenterContent/imagetool/14.1.2.0.0で使用可能な次のファイルは、イメージの作成に使用されます。* additionalBuildCmds.txt * buildArgs

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

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

    %DOCKER_REPO%/OracleWebCenterContent/imagetool/14.1.2.0.0/

    更新後:
    <imagetool-setup-location>/docker-images/OracleWebCenterContent/imagetool/14.1.2.0.0/

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

イメージの作成

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

    $ imagetool cache addInstaller --type jdk --version 17.0.9-10 --path <download location>/jdk-17.0.9+10_linux-x64_bin.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_generic.jar

$ imagetool cache addInstaller --type wcc --version 14.1.2.0.0 --path <download location>/fmw_14.1.2.0.0_wccontent_generic.jar

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

    キャッシュにパッチを追加するコマンド:

    $ imagetool cache addEntry --key p33578xyz_141200_Generic --path <download location>/p33578xyz_141200_Generic.zip

$ imagetool cache addEntry --key 28186abc_13.9.4.2.8 --path <download location>/p28186abc_139428_Generic-24497645.zip

  4. パッチ・リストをbuildArgsに更新します。

    buildArgsファイルのcreateコマンドに、--patchesフラグを使用してOracle WebCenter Contentパッチ・リストを追加し、--opatchBugNumberフラグを使用してOpatchパッチを追加します。前述のパッチ・リストのサンプル・オプションは、次のとおりです:

    --patches 33578xyz_14.1.2.0.0
--opatchBugNumber=28186abc_13.9.4.2.8

    製品のパッチ・リストおよびOpatchパッチを追加した後のbuildArgsファイルの例:

    create
--jdkVersion=17.0.9-10
--type WCC
--version=14.1.2.0.0
--tag=oracle/wccontent_create_1015:14.1.2.0.0
--pull
--chown oracle:root
--additionalBuildCommands <imagetool-setup-location>/docker-images/OracleWebCenterContent/imagetool/14.1.2.0.0/additionalBuildCmds.txt
--additionalBuildFiles <imagetool-setup-location>/docker-images/OracleWebCenterContent/dockerfiles/14.1.2.0.0/container-scripts
--patches 33578xyz_14.1.2.0.0
--opatchBugNumber=28186abc_13.9.4.2.8

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

  5. 次のコマンドを入力して、Oracle WebCenter Contentイメージを作成します:

    $ imagetool @<absolute path to `buildargs` file>"

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

########## BEGIN DOCKERFILE ##########
#
# Copyright (c) 2023, 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:8-slim as os_update
LABEL com.oracle.weblogic.imagetool.buildid="f46ab190-077e-4ed7-b747-7bb170fe592c"
USER root

RUN yum -y --downloaddir=/tmp/imagetool install gzip tar unzip libaio jq hostname  \
 && 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 root)" ]; then hash groupadd &> /dev/null && groupadd root || exit -1 ; fi \
 && if [ -z "$(getent passwd oracle)" ]; then hash useradd &> /dev/null && useradd -g root oracle || exit -1; fi \
 && mkdir -p /u01 \
 && chown oracle:root /u01 \
 && chmod 775 /u01

# Install Java
FROM os_update as jdk_build
LABEL com.oracle.weblogic.imagetool.buildid="f46ab190-077e-4ed7-b747-7bb170fe592c"

ENV JAVA_HOME=/u01/jdk

COPY --chown=oracle:root jdk-17.0.9-10-linux-x64.tar.gz /tmp/imagetool/

USER oracle


RUN tar xzf /tmp/imagetool/jdk-17.0.9-10-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="f46ab190-077e-4ed7-b747-7bb170fe592c"

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:root /u01/oracle/oraInventory \
 && chown oracle:root /u01/oracle

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

COPY --chown=oracle:root fmw_14.1.2.0.0_infrastructure_generic.jar fmw.rsp /tmp/imagetool/
COPY --chown=oracle:root fmw_14.1.2.0.0_wccontent.jar wcc.rsp /tmp/imagetool/
COPY --chown=oracle:root oraInst.loc /u01/oracle/



USER oracle


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





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="f46ab190-077e-4ed7-b747-7bb170fe592c"

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

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



USER oracle
WORKDIR /u01/oracle

#ENTRYPOINT /bin/bash



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

    USER root

    RUN mkdir -p $VOLUME_DIR && \
        mkdir -p /u01/oracle/container-scripts && \
        mkdir -p /u01/oracle/silent-install-files-tmp/config && \
        mkdir -p /u01/oracle/logs && \
        chown oracle:root -R /u01 $VOLUME_DIR && \
        chmod a+xr /u01
    COPY --chown=oracle:root files/container-scripts/ /u01/oracle/container-scripts/
    RUN chmod +xr $SCRIPT_FILE


    USER oracle

    EXPOSE $UCM_PORT $UCM_INTRADOC_PORT $IBR_INTRADOC_PORT $IBR_PORT $ADMIN_PORT
    WORKDIR ${ORACLE_HOME}

    CMD ["/u01/oracle/container-scripts/createDomainandStartAdmin.sh"]

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

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

      $ docker images | grep wcc

イメージの更新

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

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

    bash wrap $ cd <imagetool-setup> $ imagetool cache addEntry --key=33578xyz_14.1.2.0.0 --value <downloaded-patches-location>/p33578xyz_141200_Generic.zip [INFO ] Added entry 33578xyz_14.1.2.0.0=<downloaded-patches-location>/p33578xyz_141200_Generic.zip

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

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

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

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

    ##### 例

サンプルのupdateコマンド:

  # If you are using a pre-built Oracle WebCenter Content image, obtained from My Oracle Support, then please use this command:
  $ imagetool update --fromImage oracle/wccontent:14.1.2.0.0 --tag=oracle/wccontent_update_1015:14.1.2.0.0 --patches=33578xyz_14.1.2.0.0 --opatchBugNumber=28186abc_13.9.4.2.8

  # In case, you chose to build an Oracle WebCenter Content image, please use the command given below:
  $ imagetool update --chown oracle:root --fromImage oracle/wccontent:14.1.2.0.0  --tag=oracle/wccontent_update_1015:14.1.2.0.0 --patches=33578xyz_14.1.2.0.0 
    --opatchBugNumber=28186abc_13.9.4.2.8

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

      $ docker images | grep wcc

アンインストール

この項では、Oracle WebCenter Contentドメイン設定をクリーンアップするプロセスについて説明します。

すべての管理サーバーおよび管理対象サーバーのポッドの停止

最初に、ドメインに関連するすべてのポッドを停止します。これを行うには、ドメインの"serverStartPolicy"を"NEVER"にパッチ適用します。次に、これのサンプル・コマンドを示します。

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

例:

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

ドメインの削除

  1. Helmを使用してドメインのイングレス(Traefikイングレスなど)を削除します:

    $ helm uninstall wcc-domain-ingress -n sample-domain1-ns

    例:

    $ helm uninstall wccinfra-traefik -n wccns

  2. ${WORKDIR}/weblogic-kubernetes-operator/kubernetes/samples/scripts/delete-domainにあるサンプルのdelete-weblogic-domain-resources.shスクリプトを使用して、ドメイン・リソースを削除します:

    $ cd ${WORKDIR}/weblogic-kubernetes-operator/kubernetes/samples/scripts/delete-domain
$ ./delete-weblogic-domain-resources.sh -d sample-domain1

    例:

    $ cd ${WORKDIR}/weblogic-kubernetes-operator/kubernetes/samples/scripts/delete-domain
$ ./delete-weblogic-domain-resources.sh -d wccinfra

  3. kubectlを使用して、サーバー・ポッドおよびドメイン・リソースが削除されていることを確認します:

    $ kubectl get pods -n sample-domain1-ns
$ kubectl get domains -n sample-domain1-ns

    例:

    $ kubectl get pods -n wccns
$ kubectl get domains -n wccns

RCUスキーマの削除

[これらのステップ]({{< relref “/wccontent-domains/installguide/prepare-your-environment/#create-or-drop-schemas” >}})に従って、Oracle WebCenter Contentドメイン用に作成されたRCUスキーマを削除します。

ドメイン・ネームスペースの削除

  1. インストールされているイングレス・ロード・バランサ(Traefikなど)を構成して、ドメイン・ネームスペースでのイングレスの管理を停止します:

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

  2. WebLogic Kubernetes Operatorを構成して、ドメインの管理を停止します:

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

    例:

    $ cd ${WORKDIR}/weblogic-kubernetes-operator
$ helm upgrade weblogic-kubernetes-operator \
  kubernetes/charts/weblogic-operator \
  --namespace opns \
  --reuse-values \
  --set "domainNamespaces={}" \
  --wait

  3. ドメイン・ネームスペースを削除します:

    $ kubectl delete namespace sample-domain1-ns

    例:

    $ kubectl delete namespace wccns

WebLogic Kubernetes Operatorの削除

  1. WebLogic Kubernetes Operatorを削除します:

    $ helm uninstall sample-weblogic-operator -n sample-weblogic-operator-ns

    例:

    $ helm uninstall weblogic-kubernetes-operator -n opns

  2. WebLogic Kubernetes Operatorのネームスペースを削除します:

    $ kubectl delete namespace sample-weblogic-operator-ns

    例:

    $ kubectl delete namespace opns

ロード・バランサの削除

  1. インストールされているイングレス・ベースのロード・バランサ(Traefikなど)を削除します:

    $ helm uninstall traefik -n traefik

  2. Traefikネームスペースを削除します:

    $ kubectl delete namespace traefik

ドメイン・ホームの削除

create-domain.shスクリプトを使用して生成されたドメイン・ホームを削除するには、適切な権限に基づいて、ドメイン・ホーム永続ボリューム(PV)にアタッチされたストレージの内容を手動で削除します。

たとえば、host_pathタイプのドメインの永続ボリュームの場合:

$ rm -rf /scratch/k8s_dir/WCC

Oracle Cloud Infrastructure

WebLogic Kubernetes Operatorを使用したWebCenter Contentドメインの設定

これは、Oracle Cloud InfrastructureでWebLogic Kubernetes Operator管理のWebcenterContentドメインを実行するためのガイドです。

OKE環境の準備

内容

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

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

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

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

テナンシ内には、必要なネットワーク・リソース(VCN、サブネット、インターネット・ゲートウェイ、ルート表、セキュリティ・リスト)を含むコンパートメントが存在する必要があります。1.OCIコンソールに移動し、左上のメニューを使用して、「アイデンティティ」→「コンパートメント」オプションを選択します。2.「コンパートメントの作成」ボタンをクリックします。3.コンパートメント名(WCCStorageなど)と説明(OKEコンパートメント)を入力し、「コンパートメントの作成」ボタンをクリックします。

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

  1. コンソールで、ナビゲーション・メニューを開きます。「開発者サービス」に移動して、「Kubernetesクラスタ(OKE)」をクリックします。OKE-CLUSTER
  2. 作業する権限があるコンパートメントを選択します。ここでは、WCCStorageコンパートメントを使用します。
  3. 「クラスタ・リスト」ページで、コンパートメントを選択し、「クラスタの作成」をクリックします。OKE-CLUSTER
  4. 「クラスタの作成」ダイアログで、「クイック作成」を選択して「ワークフローの起動」をクリックします。OKE-CLUSTER
  5. 「クラスタの作成」ページで、環境に応じて(次に示すサンプル値のように)値を指定します
    • 名前: WCCOKEPHASE1
    • コンパートメント: WCCStorage
    • Kubernetesバージョン: v1.26.2
    • 可視性タイプの選択: プライベート
    • シェイプ: 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
  11. ワーカー・ノードのステータスを表示し、すべてのノード状態が「アクティブ」で、「Kubernetesのノード条件」が「準備完了」であることを確認します。「Kubernetesのノード条件」が「準備完了」になると、kubectlコマンドでワーカー・ノードがリストされます。OKE-CLUSTER
  12. クラスタにアクセスするには、クラスタWCCOKEPHASE1のページで「クラスタへのアクセス」をクリックします。OKE-CLUSTER
  13. 次に要塞ノードを作成して、クラスタにアクセスします。

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

内部リソースにアクセスするための要塞ノードを設定します。次のステップに従って、同じVCNに要塞ノードを作成し、ワーカー・ノードにSSH接続できるようにします。ここでは、CIDRブロック: 10.0.22.0/24を選択します。必要に応じて、別のブロックを選択できます。

  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 8.X
    • 可用性ドメイン: インスタンスの作成に制限がある任意のADを選択
    • 仮想クラウド・ネットワーク・コンパートメント: WCCStorage (つまり、OKEコンパートメント)
    • 仮想クラウド・ネットワークの選択: クイック・クラスタによって作成されたVCNを選択
    • サブネット・コンパートメント: WCCStorage (つまり、OKEコンパートメント)
    • サブネット: bastion-subnet (前に作成済)
    • 「パブリックIPアドレスの割当て」を選択
    • SSHキー: ステップ1で作成したid_rsa.pubの内容をコピー Bastion-Node Bastion-Node Bastion-Node

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

  11. 次のように要塞ホストにログインします

    ssh -i <your_ssh_bastion.key> opc@123.456.xxx.xxx

    OCI CLIの設定

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

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

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

  14. 後で設定後に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

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

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

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

  18. クラスタにアクセスするには、クラスタWCCOKEPHASE1のページで「クラスタへのアクセス」をクリックします Bastion-Node

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

    $ oci -v
$ mkdir -p $HOME/.kube

$ oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.phx.aaaaaaaaae4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrqgjtd 
--file $HOME/.kube/config --region us-phoenix-1 --token-version 2.0.0

$ export KUBECONFIG=$HOME/.kube/config

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

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

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

    $ kubectl get nodes
NAME          STATUS   ROLES   AGE   VERSION
10.0.10.197   Ready    node    14d   v1.26.2
10.0.10.206   Ready    node    14d   v1.26.2
10.0.10.50    Ready    node    14d   v1.26.2

  22. Oracle WebCenter Contentクラスタ設定に必要なアドオンをインストールします

    • helm v3.10.*のインストール

      $ wget wget https://get.helm.sh/helm-v3.10.3-linux-amd64.tar.gz
$ tar -zxvf helm-v3.10.3-linux-amd64.tar.gz
$ sudo mv linux-amd64/helm  /bin/helm
$ helm version
version.BuildInfo{Version:"v3.10.3", GitCommit:"835b7334cfe2e5e27870ab3ed4135f136eecc704", GitTreeState:"clean", GoVersion:"go1.18.9"}

    • gitのインストール

      sudo yum install git -y

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

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

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

OCIRの作成

OCIRへのイメージの公開

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

認証トークンの作成

OCIRからイメージをプッシュおよびプルするためのDockerパスワードとして使用される「認証トークン」を作成します。OCIコンソールにログインし、OCIコンソール・ページの右上隅のOCIユーザー・プロファイルのドロップダウンにある「ユーザー設定」に移動します。OCIR * 「ユーザーの詳細」ページで、ページの左下隅にある「認証トークン」リンクをクリックし、次に「トークンの生成」ボタンをクリックします。名前を入力し、「トークンの生成」をクリックします OCIR OCIR * トークンが生成されます OCIR * 生成されたトークンをコピーします。> ノート: これは1回のみ表示されます。将来の使用に備え、安全な場所にコピーする必要があります。

OCIRの使用

Docker CLIを使用したOCIRへのログイン(フェニックスの場合はphx.ocir.io、アッシュバーンの場合はiad.ocir.ioなど) 1. docker login phx.ocir.io 1.ユーザー名の入力を求められたら、Dockerユーザー名をOCIR RepoName/ociユーザー名として入力します(axcmmdmzqtqb/oracleidentitycloudservice/myemailid@oracle.comなど) 1.パスワードの入力を求められたら、生成された認証トークンを入力します 1.これで、WCC Dockerイメージをタグ付けして、OCIRにプッシュできます。サンプル・ステップは次のとおりです

$ docker login phx.ocir.io
$ username - axcmmdmzqtqb/oracleidentitycloudservice/myemailid@oracle.com
$ password - abCXYz942,vcde     (Token Generated for OCIR using user setting)

$ docker tag oracle/wccontent:14.1.2.0.0-<tag> phx.ocir.io/axcmmdmzqtqb/oracle/wccontent:14.1.2.0.0-<tag>

$ docker push phx.ocir.io/axcmmdmzqtqb/oracle/wccontent:14.1.2.0.0-<tag>

要塞ノードですべてのイメージに対してこれを行う必要があります。

OCIRイメージの検証

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

OCIR

WCCドメインの環境の準備

Kubernetes OKE環境でOracle WebCenter Contentドメインを作成するには、次のステップを実行します:

内容

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

  2. Oracle WebCenter Contentドメインのネームスペースの作成

  3. imagePullSecretsの作成

  4. OKEへのWebLogic Kubernetes Operatorのインストール

  5. Oracle WebCenter Contentドメインの環境の準備

    1. Oracle WebCenter Contentドメイン・ネームスペースを使用したWebLogic Kubernetes Operatorのアップグレード

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

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

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

    5. データベースのインストールおよび起動

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

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

  6. Oracle WebCenter Contentドメインの作成

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

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

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

    $ mkdir $HOME/wcc_4.2.9
$ cd $HOME/wcc_4.2.9

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

    $ git clone https://github.com/oracle/fmw-kubernetes.git
$ export WORKDIR=$HOME/wcc_4.2.9/fmw-kubernetes/OracleWebCenterContent/kubernetes

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

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

 $ kubectl create namespace wccns

imagePullSecretsの作成

KubernetesデプロイメントがOCIRからイメージを自動的にプルできるように、imagePullSecretsを(wccnsネームスペースに)作成します。

ノート: 次のようなサンプル・コマンドを使用して、環境に応じてimagePullSecretを作成します -

$ kubectl create secret docker-registry image-secret -n wccns --docker-server=phx.ocir.io  --docker-username=axxxxxxxxxxx/oracleidentitycloudservice/<your_user_name> --docker-password='vUv+xxxxxxxxxxx<KN7z'  --docker-email=me@oracle.com

パラメータ値は次のとおりです:

OCIリージョンはフェニックスphx.ocir.io、OCIテナンシ名はaxxxxxxxxxxx、ImagePullSecret名はimage-secret、ユーザー名と電子メール・アドレスはme@oracle.com、認証トークン・パスワードはvUv+xxxxxxxxxxx<KN7zです

OKEへのWebLogic Kubernetes Operatorのインストール

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

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

WebLogic Kubernetes Operatorのネームスペースおよびサービス・アカウントの作成
$ kubectl create namespace opns
$ kubectl create serviceaccount -n opns  op-sa
OKEへのWebLogic Kubernetes Operatorのインストール
$ cd ${WORKDIR} 
  
$ helm install weblogic-kubernetes-operator charts/weblogic-operator --namespace opns  --set image=phx.ocir.io/xxxxxxxxxxx/oracle/weblogic-kubernetes-operator:4.2.9 --set imagePullSecret=image-secret --set serviceAccount=op-sa --set "domainNamespaces={}" --set "javaLoggingLevel=FINE" --wait
WebLogic Kubernetes Operatorポッドの検証
$ kubectl get pods -n opns

NAME                                 READY   STATUS    RESTARTS   AGE
weblogic-operator-779965b66c-d8265   1/1     Running   0          11d

# Verify the Operator helm Charts
$ helm list -n opns

NAME                            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                          APP VERSION
weblogic-kubernetes-operator    opns            3               2022-02-24 06:50:29.810106777 +0000 UTC deployed        weblogic-operator-4.2.9        4.2.9

Oracle WebCenter Contentドメインの環境の準備

Oracle WebCenter Contentドメイン・ネームスペースを使用したWebLogic Kubernetes Operatorのアップグレード
 $ cd ${WORKDIR}
 $ helm upgrade --reuse-values --namespace opns --set "domainNamespaces={wccns}" --wait weblogic-kubernetes-operator charts/weblogic-operator
Oracle WebCenter Contentドメインの永続ストレージの作成

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

ここでは、ここで作成したNFSサーバーおよびマウント・パスを使用します。

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

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

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

シークレットは、kubectl get secretコマンドを使用して確認できます。

例:

$ kubectl get secret wccinfra-domain-credentials -o yaml -n wccns
apiVersion: v1
data:
password: d2VsY29tZTE=
username: d2VibG9naWM=
kind: Secret
metadata:
creationTimestamp: "2021-07-30T06:04:33Z"
labels:
  weblogic.domainName: wccinfra
  weblogic.domainUID: wccinfra
managedFields:
- apiVersion: v1
  fieldsType: FieldsV1
  fieldsV1:
    f:data:
      .: {}
      f:password: {}
      f:username: {}
    f:metadata:
      f:labels:
        .: {}
        f:weblogic.domainName: {}
        f:weblogic.domainUID: {}
    f:type: {}
  manager: kubectl
  operation: Update
  time: "2021-07-30T06:04:36Z"
name: wccinfra-domain-credentials
namespace: wccns
resourceVersion: "90770768"
selfLink: /api/v1/namespaces/wccns/secrets/wccinfra-domain-credentials
uid: 9c5dab09-15f3-4e1f-a40d-457904ddf96b
type: Opaque
RCU資格証明を使用したKubernetesシークレットの作成

データベース・スキーマの資格証明を含むKubernetesシークレットも作成する必要があります。ドメインを作成すると、このシークレットからRCU資格証明が取得されます。

付属のサンプル・スクリプトを使用して、シークレットを作成します:

$ cd ${WORKDIR}/create-rcu-credentials

$ ./create-rcu-credentials.sh -u weblogic -p welcome1 -a sys -q welcome1 -d wccinfra -n wccns -s wccinfra-rcu-credentials

パラメータ値は次のとおりです:

-u スキーマ所有者(通常ユーザー)のユーザー名、必須。
-p スキーマ所有者(通常ユーザー)のパスワード、必須。
-a SYSDBAユーザーのユーザー名、必須。
-q SYSDBAユーザーのパスワード、必須。
-d domainUID。例: wccinfra
-n ネームスペース。例: wccns
-s secretName。例: wccinfra-rcu-credentials

シークレットが想定どおりに作成されたことを確認するには、kubectl get secretコマンドを使用します。

例:

サンプル・シークレットの説明:

$ kubectl get secret wccinfra-rcu-credentials -o yaml -n wccns
  apiVersion: v1
data:
  password: d2VsY29tZTE=
  sys_password: d2VsY29tZTE=
  sys_username: c3lz
  username: d2VibG9naWM=
kind: Secret
metadata:
  creationTimestamp: "2020-09-16T08:23:04Z"
  labels:
    weblogic.domainName: wccinfra
    weblogic.domainUID: wccinfra
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:password: {}
        f:sys_password: {}
        f:sys_username: {}
        f:username: {}
      f:metadata:
        f:labels:
          .: {}
          f:weblogic.domainName: {}
          f:weblogic.domainUID: {}
      f:type: {}
    manager: kubectl
    operation: Update
    time: "2020-09-16T08:23:04Z"
  name: wccinfra-rcu-credentials
  namespace: wccns
  resourceVersion: "3277132"
  selfLink: /api/v1/namespaces/wccns/secrets/wccinfra-rcu-credentials
  uid: b75f4e13-84e6-40f5-84ba-0213d85bdf30
type: Opaque
データベースのインストールおよび起動

このステップは、スタンドアロン・データベースがまだ設定されておらず、ユーザーがコンテナでデータベースを使用する場合にのみ必要です。Oracle Database Dockerイメージは、非本番環境の用途でのみサポートされています。詳細は、My Oracle Supportノート: Oracle Support for Database Running on Docker (Doc ID 2216342.1)を参照してください。本番環境では、スタンドアロンDBを使用することをお薦めします。サンプルでは、コンテナにデータベースを作成するステップを示します。

コンテナにデータベースを作成する場合は、データを永続化するためにPVをアタッチすることも、PVをアタッチしないこともできます。この設定では、PVをアタッチせずにコンテナにデータベースを作成します。

$ cd ${WORKDIR}/create-oracle-db-service

$ ./start-db-service.sh -i phx.ocir.io/xxxxxxxxxxxx/oracle/database/enterprise:x.x.x.x -s image-secret -n wccns

サンプル出力:

$ ./start-db-service.sh -i phx.ocir.io/xxxxxxxxxxxx/oracle/database/enterprise:x.x.x.x -s image-secret -n wccns
Checking Status for NameSpace [wccns]
Skipping the NameSpace[wccns] Creation ...
NodePort[30011] ImagePullSecret[docker-store] Image[phx.ocir.io/xxxxxxxxxxxx/oracle/database/enterprise:x.x.x.x] NameSpace[wccns]
service/oracle-db created
deployment.apps/oracle-db created
[oracle-db-8598b475c5-cx5nk] already initialized ..
Checking Pod READY column for State [1/1]
NAME                         READY   STATUS    RESTARTS   AGE
oracle-db-8598b475c5-cx5nk   1/1     Running   0          20s
Service [oracle-db] found
NAME                         READY   STATUS    RESTARTS   AGE
oracle-db-8598b475c5-cx5nk   1/1     Running   0          25s
NAME        TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
oracle-db   LoadBalancer   10.96.74.187   <pending>     1521:30011/TCP   28s
[1/30] Retrying for Oracle Database Availability...
[2/30] Retrying for Oracle Database Availability...
[3/30] Retrying for Oracle Database Availability...
[4/30] Retrying for Oracle Database Availability...
[5/30] Retrying for Oracle Database Availability...
[6/30] Retrying for Oracle Database Availability...
[7/30] Retrying for Oracle Database Availability...
[8/30] Retrying for Oracle Database Availability...
[9/30] Retrying for Oracle Database Availability...
[10/30] Retrying for Oracle Database Availability...
[11/30] Retrying for Oracle Database Availability...
[12/30] Retrying for Oracle Database Availability...
[13/30] Retrying for Oracle Database Availability...
Done ! The database is ready for use .
Oracle DB Service is RUNNING with NodePort [30011]
Oracle DB Service URL [oracle-db.wccns.svc.cluster.local:1521/devpdb.k8s]

データベースが正常に作成されると、create-domain-inputs.yamlファイルのrcuDatabaseURLパラメータとしてデータベース接続文字列を使用できます。

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

コンテナを実行してrcu podを作成します

kubectl run rcu --generator=run-pod/v1 \
  --image phx.ocir.io/xxxxxxxxxxx/oracle/wccontent:x.x.x.x \
  --namespace wccns \
  --overrides='{ "apiVersion": "v1", "spec": { "imagePullSecrets": [{"name": "image-secret"}] } }'  \
  -- sleep infinity
   
# Check the status of rcu pod
kubectl get pods -n wccns
リポジトリ作成ユーティリティの実行によるデータベース・スキーマの設定
スキーマの作成または削除

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

例:

# Make sure rcu pod status is running before executing this 
kubectl exec -n wccns -ti rcu /bin/bash

# DB details 
export CONNECTION_STRING=your_db_host:1521/your_db_service
export RCUPREFIX=your_schema_prefix
echo -e welcome1"\n"welcome1> /tmp/pwd.txt
   
# Create schemas
/u01/oracle/oracle_common/bin/rcu -silent -createRepository -databaseType ORACLE -connectString $CONNECTION_STRING -dbUser sys -dbRole sysdba -useSamePasswordForAllSchemaUsers true -selectDependentsForComponents true -schemaPrefix $RCUPREFIX -component CONTENT -component MDS   -component STB -component OPSS  -component IAU -component IAU_APPEND -component IAU_VIEWER -component WLS  -tablespace USERS -tempTablespace TEMP -f < /tmp/pwd.txt

# Drop schemas
/u01/oracle/oracle_common/bin/rcu -silent -dropRepository -databaseType ORACLE -connectString $CONNECTION_STRING -dbUser sys -dbRole sysdba -selectDependentsForComponents true -schemaPrefix $RCUPREFIX -component CONTENT -component MDS  -component STB -component OPSS  -component IAU -component IAU_APPEND -component IAU_VIEWER -component WLS -f < /tmp/pwd.txt 

# Exit from the container
exit

ノート: 前述のスキーマの作成および削除コマンドで、IPMおよびCAPTUREアプリケーションが有効になっている場合は、それぞれ追加のコンポーネント(-component IPM -component CAPTURE)を渡します。

これでDockerイメージが用意され、RCUスキーマが作成されたため、ロード・バランサの設定後にドメインを作成する準備ができました。

ロード・バランサの設定

Oracle Cloud Infrastructure上のWebLogic Kubernetes Operator管理のOracle WebCenter Contentドメインは、TraefikやNGINXなどのイングレスベースのロード・バランサをサポートしています。

Traefik

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

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

内容

非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をインストールします:

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

サンプル出力:

NAME: traefik-operator
LAST DEPLOYED: Mon Jun  1 19:31:20 2020
NAMESPACE: traefik
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get Traefik load balancer IP or hostname:

  NOTE: It may take a few minutes for this to become available.

  You can watch the status by running:

      $ kubectl get svc traefik-operator --namespace traefik -w

  Once 'EXTERNAL-IP' is no longer '<pending>':

      $ kubectl describe svc traefik-operator --namespace traefik | grep Ingress | awk '{print $3}'

2. Configure DNS records corresponding to Kubernetes ingress resources to point to the load balancer IP or hostname found in step 1

Traefik 2.6.0のデプロイメント用のサンプルvalues.yaml:

image:
name: traefik
tag: 2.6.0
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
   expose: true
   # The exposed port for this service
   exposedPort: 9000
   # The port protocol (TCP/UDP)
   protocol: TCP
web:
   port: 8000
   # hostPort: 8000
   expose: true
   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
#    # hostPort: 8443
   expose: true
   exposedPort: 30443
   # The port protocol (TCP/UDP)
   protocol: TCP
   nodePort: 30443
additionalArguments:
  - "--log.level=INFO"

  1. Traefik (ロード・バランサ)サービスを検証します:

    traefik-operatorサービスのEXTERNAL-IPを書き留めてください。これは、WebLogic Server管理コンソールおよびWebCenter Content URLへのアクセスに使用するロード・バランサのパブリックIPアドレスです。

    $ kubectl get service -n traefik
NAME      TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)                                          AGE
traefik   LoadBalancer   10.96.8.30   123.456.xx.xx   9000:30734/TCP,30305:30305/TCP,30443:30443/TCP   6d23h

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

    $ TRAEFIK_PUBLIC_IP=`kubectl describe svc traefik --namespace traefik | grep Ingress | awk '{print $3}'`
$ echo $TRAEFIK_PUBLIC_IP
123.456.xx.xx

    helmチャートを確認します:

    $ helm list -n traefik
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
traefik traefik         2               2022-09-11 12:22:41.122310912 +0000 UTC deployed        traefik-10.24.3    2.8.5

    Traefikステータスを確認し、ポート番号を見つけます

     $ kubectl get all -n traefik

    サンプル出力:

    NAME                          READY   STATUS    RESTARTS   AGE
pod/traefik-f9cf58697-xjhpl   1/1     Running   0          7d


NAME              TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)                                          AGE
service/traefik   LoadBalancer   10.96.8.30   123.456.xx.xx   9000:30734/TCP,30305:30305/TCP,30443:30443/TCP   7d


NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/traefik   1/1     1            1           7d

NAME                                DESIRED   CURRENT   READY   AGE
replicaset.apps/traefik-f9cf58697   1         1         1       7d

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

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

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

サンプル出力:

    Release "traefik" has been upgraded. Happy Helming!
    NAME: traefik
    LAST DEPLOYED: Sun Jan 17 23:43:02 2021
    NAMESPACE: traefik
    STATUS: deployed
    REVISION: 2
    TEST SUITE: None

ドメインのイングレスの作成

サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します。ここでは、パスベースのルーティングがイングレスに使用されます。デフォルト構成のサンプル値は、${WORKDIR}/charts/ingress-per-domain/values.yamlファイルに示されています。デフォルトでは、typeはTRAEFIK、tlsはNon-SSLで、domainTypeはwccinfraです。これらの値をオーバーライドするには、コマンドラインを介して値を渡すか、構成のタイプ(非SSLまたはSSL)に基づいてサンプル・ファイルvalues.yamlでそれらを編集します。必要に応じて、イングレスYAMLファイルを更新して、アクセスが必要なドメイン・アプリケーションURLに基づいて(spec.rules.host.http.pathsセクションに)追加のパス・ルールを定義できます。Traefik (イングレスベース)ロード・バランサのテンプレートYAMLファイルは、${WORKDIR}/charts/ingress-per-domain/templates/traefik-ingress.yamlにあります

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

    $ export LB_HOSTNAME=<Traefik load balancer DNS name>

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

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

     $ cd ${WORKDIR}
 $ helm install wcc-traefik-ingress  \
     charts/ingress-per-domain \
     --set type=TRAEFIK \
     --namespace wccns \
     --values charts/ingress-per-domain/values.yaml \
     --set "traefik.hostname=$LB_HOSTNAME" \
     --set tls=NONSSL

    サンプル出力:

      NAME: wcc-traefik-ingress
  LAST DEPLOYED: Sun Jan 17 23:49:09 2021
  NAMESPACE: wccns
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None

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

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

     $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt \
 -subj "/CN=<Traefik load balancer DNS name>" \
 -extensions san -config \
 <(echo "[req]"; 
 echo distinguished_name=req; 
 echo "[san]"; 
 echo subjectAltName=IP:$TRAEFIK_PUBLIC_IP 
 )

#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=*" \
 -extensions san -config \
 <(echo "[req]"; 
 echo distinguished_name=req; 
 echo "[san]"; 
 echo subjectAltName=IP:$TRAEFIK_PUBLIC_IP 
 )

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

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

    $ kubectl -n wccns create secret tls domain1-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt

Traefikカスタム・リソースの作成

  1. Traefikミドルウェア・カスタム・リソースの作成

    SSL終端の場合、Traefikはカスタム・ヘッダーWL-Proxy-SSL:trueをWebLogic Serverエンドポイントに渡す必要があります。次のコマンドを使用して、ミドルウェアを作成します:

    $ cat <<EOF | kubectl apply -f -
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: wls-proxy-ssl
  namespace: wccns
spec:
  headers:
    customRequestHeaders:
       WL-Proxy-SSL: "true"
EOF

  2. 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: wccns
spec:
  defaultCertificate:
    secretName:  domain1-tls-cert   
EOF

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

  1. 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: wccns-wls-proxy-ssl@kubernetescrd

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

     $ cd ${WORKDIR}
 $ helm install wcc-traefik-ingress  \
     charts/ingress-per-domain \
     --set type=TRAEFIK \
     --namespace wccns \
     --values charts/ingress-per-domain/values.yaml \
     --set "traefik.hostname=$LB_HOSTNAME" \
     --set "traefik.hostnameorip=$TRAEFIK_PUBLIC_IP" \
     --set tls=SSL

    サンプル出力:

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

  2. 前述のデプロイ済イングレスによってサービスの詳細を取得します:

     $ kubectl describe  ingress wccinfra-traefik  -n wccns

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

     $ curl -v http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_PORT}/weblogic/ready
 * About to connect() to abc.com port 30305 (#0)
 *   Trying 100.111.156.246...
 * Connected to abc.com (100.111.156.246) port 30305 (#0)
 > GET /weblogic/ready HTTP/1.1
 > User-Agent: curl/7.29.0
 > Host: domain1.org:30305
 > Accept: */*
 >
 < HTTP/1.1 200 OK
 < Content-Length: 0
 < Date: Thu, 03 Dec 2020 13:16:19 GMT
 < Vary: Accept-Encoding
 <
 * Connection #0 to host abc.com left intact

エンドツーエンド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をインストールします:

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

サンプル出力:

    NAME: traefik
    LAST DEPLOYED: Sun Jan 17 23:30:20 2021
    NAMESPACE: traefik
    STATUS: deployed
    REVISION: 1
    TEST SUITE: None

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

     $ kubectl get all -n traefik

    サンプル出力:

    
   NAME                                    READY   STATUS    RESTARTS   AGE
   pod/traefik-operator-676fc64d9c-skppn   1/1     Running   0          78d

   NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
   service/traefik-operator             NodePort    10.109.223.59   <none>        443:30443/TCP,80:30305/TCP   78d
   service/traefik-operator-dashboard   ClusterIP   10.110.85.194   <none>        80/TCP                       78d

   NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/traefik-operator   1/1     1            1           78d

   NAME                                          DESIRED   CURRENT   READY   AGE
   replicaset.apps/traefik-operator-676fc64d9c   1         1         1       78d
   replicaset.apps/traefik-operator-cb78c9dc9    0         0         0       78d

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

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

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

サンプル出力:

      Release "traefik" has been upgraded. Happy Helming!
      NAME: traefik
      LAST DEPLOYED: Sun Jan 17 23:43:02 2021
      NAMESPACE: traefik
      STATUS: deployed
      REVISION: 2
      TEST SUITE: None

IngressRouteTCPの作成

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

    ノート: エンドツーエンドSSL構成のロード・バランサには、制限があります。複数のタイプのサーバー(異なる管理対象サーバーや管理サーバー)に同時にアクセスすることは、現在サポートされていません。一度に1つの管理対象サーバーにのみアクセスできます。

    traefik-tls.yamlで次を更新する必要があります:

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

    サンプルtraefik-tls.yaml:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRouteTCP
metadata:
  name: wcc-ucm-routetcp
  namespace: wccns
spec:
  entryPoints:
    - websecure
  routes:
  - match: HostSNI(`<Traefik load balancer DNS name>`)
    services:
    - name: wccinfra-cluster-ucm-cluster
      port: 16201
      weight: 3
      terminationDelay: 400
  tls:
    passthrough: true

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

  1. IngressRouteTCPを作成します:
cd ${WORKDIR}/charts/ingress-per-domain/tls

$ kubectl apply -f traefik-tls.yaml

Oracle WebCenter Contentドメインの作成

ロード・バランサが構成された状態で、ドメイン・アプリケーションURLアクセスを検証する前に、[Oracle WebCenter Contentドメインの作成]({{< relref “/wccontent-domains/oracle-cloud/create-wccontent-domains” >}})に記載された手順に従ってドメインを作成してください。

ドメイン・アプリケーションURLアクセスの検証

非SSLアクセスの検証

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

http://${TRAEFIK_PUBLIC_IP}:30305/weblogic/ready
http://${TRAEFIK_PUBLIC_IP}:30305/cs
http://${TRAEFIK_PUBLIC_IP}:30305/ibr
http://${TRAEFIK_PUBLIC_IP}:30305/imaging
http://${TRAEFIK_PUBLIC_IP}:30305/dc-console
http://${TRAEFIK_PUBLIC_IP}:30305/wcc

SSL終端およびエンドツーエンドSSLアクセスの検証

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

LOADBALANCER-SSLPORTは30443です

https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/cs
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/ibr
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/imaging
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/dc-console
https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER-SSLPORT}/wcc

Traefikのアンインストール

$ helm delete wcc-traefik-ingress -n wccns

$ helm delete traefik -n wccns

$ kubectl delete namespace traefik

NGINX

この項では、Oracle WebCenter Contentドメイン・クラスタをロード・バランシングするように、イングレス・ベースのNGINXロード・バランサをインストールおよび構成する方法について説明します。アプリケーションURLの非SSL、SSL終端およびエンドツーエンドSSLアクセス用にNGINXを構成できます。

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

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

内容

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

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

非SSLおよびSSL終端

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

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

    非SSLの場合、次のコマンドを使用します

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

    ロード・バランサでのSSL終端の場合、次のコマンドを使用します

     $ helm install nginx-ingress -n wccns \
        --set controller.service.type=LoadBalancer \
        --set controller.admissionWebhooks.enabled=false \
        --set controller.extraArgs.default-ssl-certificate="wccns/domain1-tls-cert" \
          ingress-nginx/ingress-nginx

    サンプル出力:

NAME: nginx-ingress
LAST DEPLOYED: Fri Jul 29 00:14:19 2022
NAMESPACE: wccns
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 wccns get services -o jsonpath="{.spec.ports[0].nodePort}" nginx-ingress-ingress-nginx-controller)
  export HTTPS_NODE_PORT=$(kubectl --namespace wccns get services -o jsonpath="{.spec.ports[1].nodePort}" nginx-ingress-ingress-nginx-controller)
  export NODE_IP=$(kubectl --namespace wccns 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/v1
  kind: Ingress
  metadata:
    name: example
    namespace: foo
  spec:
    ingressClassName: nginx
    rules:
      - host: www.example.com
        http:
          paths:
            - pathType: Prefix
              backend:
                service:
                  name: exampleService
                  port:
                    number: 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. デプロイされたイングレス・コントローラのステータスを確認します:

    nginx-controllerサービスのEXTERNAL-IPを書き留めてください。これは、WebLogic Server管理コンソールおよびWebCenter Content URLへのアクセスに使用するロード・バランサのパブリックIPアドレスです。> ノート: LoadBalancer IP(EXTERNAL-IP)が使用可能になるまで数分かかる場合があります。

    $ kubectl --namespace wccns get services | grep ingress-nginx-controller

    サンプル出力:

    NAME                                   TYPE         CLUSTER-IP   EXTERNAL-IP     PORT(S)   
nginx-ingress-ingress-nginx-controller LoadBalancer 10.96.180.215 144.24.xx.xx    80:31339/TCP,443:32278/TCP

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

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

$ echo $NGINX_PUBLIC_IP   
144.24.xx.xx

    helmチャートを確認します:

    $ helm list -A
NAME          NAMESPACE REVISION  UPDATED      STATUS      CHART                APP VERSION
nginx-ingress  wccns    1         2022-05-13  deployed   ingress-nginx-4.2.5   1.3.1

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

  1. サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します。ここでは、パスベースのルーティングがイングレスに使用されます。デフォルト構成のサンプル値は、${WORKDIR}/charts/ingress-per-domain/values.yamlファイルに示されています。デフォルトでは、typeはTRAEFIK、tlsはNon-SSLで、domainTypeはwccinfraです。これらの値をオーバーライドするには、コマンドラインを介して値を渡すか、サンプル・ファイルvalues.yamlでそれらを編集します。必要に応じて、イングレスYAMLファイルを更新して、アクセスが必要なドメイン・アプリケーションURLに基づいて(spec.rules.host.http.pathsセクションに)追加のパス・ルールを定義できます。${WORKDIR}/charts/ingress-per-domain/templates/nginx-ingress.yamlにあるNGINXロード・バランサのテンプレートYAMLファイルを更新します

    非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を指すように空のままにしてください。

     $ cd ${WORKDIR}
 $ helm install wccinfra-nginx-ingress charts/ingress-per-domain \
     --namespace wccns \
     --values charts/ingress-per-domain/values.yaml \
     --set "nginx.hostname=$LB_HOSTNAME" \
     --set type=NGINX \
     --set tls=NONSSL

    サンプル出力:

     NAME: wccinfra-nginx-ingress
 LAST DEPLOYED: Tue May 10 10:37:12 2022
 NAMESPACE: wccns
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None

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

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

     $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls1.key -out /tmp/tls1.crt \
 -subj "/CN=<NGINX load balancer DNS name>" \
 -extensions san -config \
 <(echo "[req]"; 
 echo distinguished_name=req; 
 echo "[san]"; 
 echo subjectAltName=IP:$NGINX_PUBLIC_IP 
 )

#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=*" \
 -extensions san -config \
 <(echo "[req]"; 
 echo distinguished_name=req; 
 echo "[san]"; 
 echo subjectAltName=IP:$NGINX_PUBLIC_IP 
 )

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

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

    $ kubectl -n wccns create secret tls domain1-tls-cert --key /tmp/tls1.key --cert /tmp/tls1.crt

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

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

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

    サンプル出力:

     NAME: wccinfra-nginx-ingress
 LAST DEPLOYED: Tue May 10 10:37:12 2022
 NAMESPACE: wccns
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None

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

      $ kubectl describe ingress wccinfra-nginx  -n wccns

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

Name:             wccinfra-nginx
Namespace:        wccns
Address:          144.24.xx.xx
Default backend:  default-http-backend:80 (<none>)
Rules:
  Host  Path  Backends
  ----  ----  --------
  *
        /em                      wccinfra-adminserver:7001 (10.244.2.117:7001)
        /wls-exporter            wccinfra-adminserver:7001 (10.244.2.117:7001)
        /cs                      wccinfra-cluster-ucm-cluster:16200 (10.244.2.118:16200,10.244.2.120:16200)
        /adfAuthentication       wccinfra-cluster-ucm-cluster:16200 (10.244.2.118:16200,10.244.2.120:16200)
        /_ocsh                   wccinfra-cluster-ucm-cluster:16200 (10.244.2.118:16200,10.244.2.120:16200)
        /_dav                    wccinfra-cluster-ucm-cluster:16200 (10.244.2.118:16200,10.244.2.120:16200)
        /idcws                   wccinfra-cluster-ucm-cluster:16200 (10.244.2.118:16200,10.244.2.120:16200)
        /idcnativews             wccinfra-cluster-ucm-cluster:16200 (10.244.2.118:16200,10.244.2.120:16200)
        /wsm-pm                  wccinfra-cluster-ucm-cluster:16200 (10.244.2.118:16200,10.244.2.120:16200)
        /ibr                     wccinfra-cluster-ibr-cluster:16250 (10.244.2.119:16250)
        /ibr/adfAuthentication   wccinfra-cluster-ibr-cluster:16250 (10.244.2.119:16250)
        /weblogic/ready          wccinfra-cluster-ucm-cluster:16200 (10.244.2.118:16200,10.244.2.120:16200)
Annotations:
  nginx.ingress.kubernetes.io/affinity-mode:  persistent
  kubernetes.io/ingress.class:                nginx
  nginx.ingress.kubernetes.io/affinity:       cookie
Events:
  Type    Reason  Age                  From                      Message
  ----    ------  ----                 ----                      -------
  Normal  Sync    8m3s (x2 over 8m5s)  nginx-ingress-controller  Scheduled for sync

エンドツーエンドSSL構成

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

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

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

    helm install nginx-ingress -n wccns \
--set controller.extraArgs.default-ssl-certificate=wccns/domain1-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: Mon Sep 19 11:08:16 2022
NAMESPACE: wccns
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The ingress-nginx controller has been installed.
It may take a few minutes for the LoadBalancer IP to be available.
You can watch the status by running 'kubectl --namespace wccns get services -o wide -w nginx-ingress-ingress-nginx-controller'
An example Ingress that makes use of the controller:
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: example
    namespace: foo
  spec:
    ingressClassName: nginx
    rules:
      - host: www.example.com
        http:
          paths:
            - pathType: Prefix
              backend:
                service:
                  name: exampleService
                  port:
                    number: 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 wccns get services | grep ingress-nginx-controller

    サンプル出力:

    NAME                                   TYPE         CLUSTER-IP   EXTERNAL-IP     PORT(S)   
nginx-ingress-ingress-nginx-controller LoadBalancer 10.96.180.215 144.24.xx.xx    80:31339/TCP,443:32278/TCP

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

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

$ echo $NGINX_PUBLIC_IP   
144.24.xx.xx

個々の管理対象サーバーにアクセスするためのtlsのデプロイ

  1. tlsをデプロイしてサービスに安全にアクセスします。ssl-passthroughで構成できるアプリケーションは1つのみです。サービスwccinfra-cluster-ucm-clusterおよびポート16201のNGINXのサンプルtlsファイルを次に示します。ポート16201で実行されているすべてのアプリケーションに、このイングレスを介して安全にアクセスできます。NGINXでは、注釈ssl-passthroughによる複数のパス/ルールがサポートされていないため、バックエンド・サービスごとに異なるイングレスを作成します。つまり、wccinfra-cluster-ucm-cluster、wccinfra-cluster-ibr-cluster、wccinfra-cluster-ipm-cluster、wccinfra-cluster-capture-cluster、wccinfra-cluster-wccadf-clusterおよびwccinfra-adminserverでは、異なるイングレスを作成する必要があります。

    ノート: エンドツーエンドSSL構成のロード・バランサには、制限があります。複数のタイプのサーバー(異なる管理対象サーバーや管理サーバー)に同時にアクセスすることは、現在サポートされていません。一度に1つの管理対象サーバーにのみアクセスできます。

    $ cd ${WORKDIR}/charts/ingress-per-domain/tls

    サンプルnginx-ucm-tls.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wcc-ucm-ingress
  namespace: wccns
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  tls:
  - hosts:
    - '$NGINX_PUBLIC_IP'
    secretName: domain1-tls-cert
  rules:
  - host: '<NGINX load balancer DNS name>'
    http:
      paths:
      - path:
        pathType: ImplementationSpecific
        backend:
          service:
            name: wccinfra-cluster-ucm-cluster
            port:
              number: 16201

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

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

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

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

    $ kubectl describe ingress wcc-ucm-ingress -n wccns

イングレスでサポートされているサービス:

Name:             wcc-ucm-ingress
Namespace:        wccns
Address:          10.102.97.237
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  domain1-tls-cert terminates domain1.org
Rules:
  Host                                         Path  Backends
  ----                                         ----  --------
  domain1.org
                                                  wccinfra-cluster-ucm-cluster:16201 (10.244.238.136:16201,10.244.253.132:16201)
Annotations:                                   kubernetes.io/ingress.class: nginx
                                               nginx.ingress.kubernetes.io/ssl-passthrough: true
Events:
  Type    Reason  Age                 From                      Message
  ----    ------  ----                ----                      -------
  Normal  Sync    62s (x2 over 106s)  nginx-ingress-controller  Scheduled for sync

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

  1. NGINXのssl-passthroughは、個々のエンドポイントではなくバッキング・サービスのclusterIPで動作するため、clusterIPを使用してWebLogic Kubernetes Operatorによって作成されたadminserver serviceを公開する必要があります。

    例:

    1. 管理サーバー・サービスの名前を取得します:
      $ kubectl get svc -n wccns | grep wccinfra-adminserver

    サンプル出力: bash wccinfra-adminserver ClusterIP None <none> 7001/TCP,7002/TCP 7

    1. 管理サーバー・サービスwccinfra-adminserverを公開し、新しいサービス名wccinfra-adminserver-nginx-sslを使用します:
     $ kubectl expose svc wccinfra-adminserver -n wccns --name=wccinfra-adminserver-nginx-ssl --port=7002
    1. 保護されたイングレスをデプロイします:

サンプルnginx-admin-tls.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wcc-admin-ingress
  namespace: wccns
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  tls:
  - hosts:
    - '$NGINX_PUBLIC_IP'
    secretName: domain1-tls-cert
  rules:
  - host: '<NGINX load balancer DNS name>'
    http:
      paths:
      - path:
        pathType: ImplementationSpecific
        backend:
          service:
            name: wccinfra-adminserver-nginx-ssl
            port:
              number: 7002

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

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

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

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

Oracle WebCenter Contentドメインの作成

ロード・バランサが構成された状態で、ドメイン・アプリケーションURLアクセスを検証する前に、[Oracle WebCenter Contentドメインの作成]({{< relref “/wccontent-domains/oracle-cloud/create-wccontent-domains” >}})に記載された手順に従ってドメインを作成してください。

ドメイン・アプリケーションURLアクセスの検証

非SSLアクセスの検証

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

  http://${LOADBALANCER-HOSTNAME}/weblogic/ready
  http://${LOADBALANCER-HOSTNAME}/em
  http://${LOADBALANCER-HOSTNAME}/cs
  http://${LOADBALANCER-HOSTNAME}/ibr
  http://${LOADBALANCER_HOSTNAME}/imaging
  http://${LOADBALANCER_HOSTNAME}/dc-console
  http://${LOADBALANCER_HOSTNAME}/wcc

SSL終端およびエンドツーエンドSSLアクセスの検証

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

  https://${LOADBALANCER-HOSTNAME}/weblogic/ready
  https://${LOADBALANCER-HOSTNAME}/em
  https://${LOADBALANCER-HOSTNAME}/cs
  https://${LOADBALANCER-HOSTNAME}/ibr
  https://${LOADBALANCER_HOSTNAME}/imaging
  https://${LOADBALANCER_HOSTNAME}/dc-console
  https://${LOADBALANCER_HOSTNAME}/wcc

NGINXのアンインストール

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

//Uninstall and delete the `ingress-nginx` deployment
$ helm delete wccinfra-nginx-ingress -n wccns

//Uninstall NGINX
$ helm delete nginx-ingress -n wccns

Oracle WebCenter Contentドメインの作成

内容

ドメイン作成スクリプトの実行

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

$ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/

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

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

managed-server-wrapperスクリプトの実行

ドメインYAMLを内部的に適用するoke-start-managed-server-wrapper.shスクリプトを実行します。このスクリプトは、管理対象サーバー・コンテナの初期構成も適用し、将来のコンテナ間通信のために管理対象サーバーを準備します。

$ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/

$ ./oke-start-managed-servers-wrapper.sh -o <path_to_output_directory> -l <load_balancer_external_ip> -p <load_balancer_port> -s <ssl_termination>

ノート: パラメータ-sの値は、ロード・バランサでSSL終端が使用されている場合にのみ指定する必要があります。許容される値は、trueまたはfalseです。このパラメータ値が指定されていない場合、スクリプトはロード・バランサでSSL終端が使用されていないと想定し、デフォルトでこの値はfalseとみなされます。

必要に応じてIPMおよびWCCADFアプリケーションの起動構成スクリプトを実行

IPMが有効になっている場合は、スクリプトconfigure-ipm-connection.shを実行して起動構成を実行します。

$ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/
$ ./configure-ipm-connection.sh -l <load_balancer_external_ip> -p <load_balancer_port> -s <ssl_or_ssl_termination>

ADFUIが有効になっている場合は、スクリプトconfigure-wccadf-domain.shを実行して起動構成を実行します。

$ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/
$ ./configure-wccadf-domain.sh -n <node_ip> -m <ucm_node_port>

変更がドメインに適用されるようにドメインにパッチを適用します。

#STOP
$ kubectl patch domain DOMAINUID -n NAMESPACE --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "NEVER" }]'

sleep 2m

#START
$ kubectl patch domain DOMAINUID -n NAMESPACE --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IF_NEEDED" }]'

結果の検証

ドメイン作成スクリプトは、ドメインが作成されたことを検証し、エラーが発生した場合は失敗をレポートします。ただし、スクリプトによって作成された様々なKubernetesオブジェクトに慣れるためだけであっても、ドメインを手動で検証することが望ましい場合があります。

デフォルト入力で生成されたYAMLファイル

生成されたdomain.yamlのサンプル・コンテンツ:

$ cat output/weblogic-domains/wccinfra/domain.yaml
# Copyright (c) 2017, 2021, Oracle and/or its affiliates.
# Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
#
# This is an example of how to define a Domain resource.
#
apiVersion: "weblogic.oracle/v8"
kind: Domain
metadata:
  name: wccinfra
  namespace: wccns
  labels:
    weblogic.domainUID: wccinfra
spec:
  # The WebLogic Domain Home
  domainHome: /u01/oracle/user_projects/domains/wccinfra
  maxClusterConcurrentStartup: 1

  # The domain home source type
  # Set to PersistentVolume for domain-in-pv, Image for domain-in-image, or FromModel for model-in-image
  domainHomeSourceType: PersistentVolume

  # The WebLogic Server image that the WebLogic Kubernetes Operator uses to start the domain
  image: "phx.ocir.io/xxxxxxxxxx/oracle/wccontent/oracle/wccontent:x.x.x.x"

  # imagePullPolicy defaults to "Always" if image version is :latest
  imagePullPolicy: "IfNotPresent"

  # Identify which Secret contains the credentials for pulling an image
  imagePullSecrets:
  - name: image-secret

  # Identify which Secret contains the WebLogic Admin credentials (note that there is an example of
  # how to create that Secret at the end of this file)
  webLogicCredentialsSecret:
    name: wccinfra-domain-credentials

  # Whether to include the server out file into the pod's stdout, default is true
  includeServerOutInPodLog: true

  # Whether to enable log home
  logHomeEnabled: true

  # Whether to write HTTP access log file to log home
  httpAccessLogInLogHome: true

  # The in-pod location for domain log, server logs, server out, introspector out, and Node Manager log files
  logHome: /u01/oracle/user_projects/domains/logs/wccinfra
  # An (optional) in-pod location for data storage of default and custom file stores.
  # If not specified or the value is either not set or empty (e.g. dataHome: "") then the
  # data storage directories are determined from the WebLogic domain home configuration.
  dataHome: ""


  # serverStartPolicy legal values are "NEVER", "IF_NEEDED", or "ADMIN_ONLY"
  # This determines which WebLogic Servers the WebLogic Kubernetes Operator will start up when it discovers this Domain
  # - "NEVER" will not start any server in the domain
  # - "ADMIN_ONLY" will start up only the administration server (no managed servers will be started)
  # - "IF_NEEDED" will start all non-clustered servers, including the administration server and clustered servers up to the replica count
  serverStartPolicy: "IF_NEEDED"

  serverPod:
    # an (optional) list of environment variable to be set on the servers
    env:
    - name: JAVA_OPTIONS
      value: "-Dweblogic.StdoutDebugEnabled=false"
    - name: USER_MEM_ARGS
      value: "-Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx1024m "
    volumes:
    - name: weblogic-domain-storage-volume
      persistentVolumeClaim:
        claimName: wccinfra-domain-pvc
    volumeMounts:
    - mountPath: /u01/oracle/user_projects/domains
      name: weblogic-domain-storage-volume

  # adminServer is used to configure the desired behavior for starting the administration server.
  adminServer:
    # serverStartState legal values are "RUNNING" or "ADMIN"
    # "RUNNING" means the listed server will be started up to "RUNNING" mode
    # "ADMIN" means the listed server will be start up to "ADMIN" mode
    serverStartState: "RUNNING"
    # adminService:
    #   channels:
    # The Admin Server's NodePort
    #    - channelName: default
    #      nodePort: 30701
    # Uncomment to export the T3Channel as a service
    #    - channelName: T3Channel

  # clusters is used to configure the desired behavior for starting member servers of a cluster.
  # If you use this entry, then the rules will be applied to ALL servers that are members of the named clusters.
  clusters:
  - clusterName: ibr_cluster
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 1
  # The number of managed servers to start for unlisted clusters
  # replicas: 1

  # Istio
  # configuration:
  #   istio:
  #     enabled:
  #     readinessPort:

  - clusterName: ucm_cluster
    clusterService:
         annotations:
            traefik.ingress.kubernetes.io/affinity: "true"
            traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
            traefik.ingress.kubernetes.io/session-cookie-name: JSESSIONID
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 3
  # The number of managed servers to start for unlisted clusters
  # replicas: 1
    - clusterName: ipm_cluster
    clusterService:
         annotations: 
            traefik.ingress.kubernetes.io/affinity: "true"
            traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
            traefik.ingress.kubernetes.io/session-cookie-name: JSESSIONID
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 3
  # The number of managed servers to start for unlisted clusters
  # replicas: 1
  - clusterName: capture_cluster
    clusterService:
         annotations: 
            traefik.ingress.kubernetes.io/affinity: "true"
            traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
            traefik.ingress.kubernetes.io/session-cookie-name: JSESSIONID
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 3
  # The number of managed servers to start for unlisted clusters
  # replicas: 1
  - clusterName: wccadf_cluster
    clusterService:
         annotations: 
            traefik.ingress.kubernetes.io/affinity: "true"
            traefik.ingress.kubernetes.io/service.sticky.cookie: "true"
            traefik.ingress.kubernetes.io/session-cookie-name: WCCSID
    serverService:
      precreateService: true
    serverStartState: "RUNNING"
    serverPod:
      # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
      # already members of the same cluster.
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: "weblogic.clusterName"
                      operator: In
                      values:
                        - $(CLUSTER_NAME)
                topologyKey: "kubernetes.io/hostname"
    replicas: 3
  # The number of managed servers to start for unlisted clusters
  # replicas: 1

ドメインの検証

ドメインが作成されたことを確認するには、次のコマンドを入力します:

$ kubectl describe domain DOMAINUID -n NAMESPACE

DOMAINUIDはdomainUIDに、NAMESPACEは実際のネームスペースに置き換えます。

サンプル・ドメインの説明:

[opc@bastionhost domain-home-on-pv]$ kubectl describe domain wccinfra -n wccns
Name:         wccinfra
Namespace:    wccns
Labels:       weblogic.domainUID=wccinfra
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"weblogic.oracle/v8","kind":"Domain","metadata":{"annotations":{},"labels":{"weblogic.domainUID":"wccinfra"},"name":"wccinfr...
API Version:  weblogic.oracle/v8
Kind:         Domain
Metadata:
  Creation Timestamp:  2021-08-24T12:26:19Z
  Generation:          33
  Managed Fields:
    API Version:  weblogic.oracle/v8
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:kubectl.kubernetes.io/last-applied-configuration:
        f:labels:
          .:
          f:weblogic.domainUID:
    Manager:      kubectl
    Operation:    Update
    Time:         2021-09-30T10:56:07Z
    API Version:  weblogic.oracle/v8
    Fields Type:  FieldsV1
    fieldsV1:
      f:status:
        .:
        f:clusters:
        f:conditions:
        f:introspectJobFailureCount:
        f:servers:
        f:startTime:
    Manager:         Kubernetes Java Client
    Operation:       Update
    Time:            2021-10-04T20:06:17Z
  Resource Version:  115422662
  Self Link:         /apis/weblogic.oracle/v8/namespaces/wccns/domains/wccinfra
  UID:               e283c968-b80b-404b-aa1e-711080d7cc38
Spec:
  Admin Server:
    Server Start State:  RUNNING
  Clusters:
    Cluster Name:  ibr_cluster
    Replicas:      1
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:  true
    Server Start State:   RUNNING
    Cluster Name:         ucm_cluster
    Cluster Service:
      Annotations:
        traefik.ingress.kubernetes.io/affinity:               true
        traefik.ingress.kubernetes.io/service.sticky.cookie:  true
        traefik.ingress.kubernetes.io/session-cookie-name:    JSESSIONID
    Replicas:                                                 3
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:        true
    Server Start State:         RUNNING
        Cluster Name:         ipm_cluster
    Cluster Service:
      Annotations:
        traefik.ingress.kubernetes.io/affinity:               true
        traefik.ingress.kubernetes.io/service.sticky.cookie:  true
        traefik.ingress.kubernetes.io/session-cookie-name:    JSESSIONID
    Replicas:                                                 3
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:  true
    Server Start State:   RUNNING
    Cluster Name:         capture_cluster
    Cluster Service:
      Annotations:
        traefik.ingress.kubernetes.io/affinity:               true
        traefik.ingress.kubernetes.io/service.sticky.cookie:  true
        traefik.ingress.kubernetes.io/session-cookie-name:    JSESSIONID
    Replicas:                                                 3
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:  true
    Server Start State:   RUNNING
    Cluster Name:         wccadf_cluster
    Cluster Service:
      Annotations:
        traefik.ingress.kubernetes.io/affinity:               true
        traefik.ingress.kubernetes.io/service.sticky.cookie:  true
        traefik.ingress.kubernetes.io/session-cookie-name:    WCCSID
    Replicas:                                                 3
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Service:
      Precreate Service:  true
    Server Start State:   RUNNING
  Data Home:
  Domain Home:                  /u01/oracle/user_projects/domains/wccinfra
  Domain Home Source Type:      PersistentVolume
  Http Access Log In Log Home:  true
  Image:                        phx.ocir.io/xxxxxxxxxx/oracle/wccontent:x.x.x.x
  Image Pull Policy:            IfNotPresent
  Image Pull Secrets:
    Name:                          image-secret
  Include Server Out In Pod Log:   true
  Log Home:                        /u01/oracle/user_projects/domains/logs/wccinfra
  Log Home Enabled:                true
  Max Cluster Concurrent Startup:  1
  Server Pod:
    Env:
      Name:   JAVA_OPTIONS
      Value:  -Dweblogic.StdoutDebugEnabled=false
      Name:   USER_MEM_ARGS
      Value:  -Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx1024m
    Volume Mounts:
      Mount Path:  /u01/oracle/user_projects/domains
      Name:        weblogic-domain-storage-volume
    Volumes:
      Name:  weblogic-domain-storage-volume
      Persistent Volume Claim:
        Claim Name:     wccinfra-domain-pvc
  Server Start Policy:  IF_NEEDED
  Web Logic Credentials Secret:
    Name:  wccinfra-domain-credentials
Status:
  Clusters:
    Cluster Name:      ibr_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    1
    Replicas:          1
    Replicas Goal:     1
    Cluster Name:      ucm_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    3
    Replicas:          3
    Replicas Goal:     3
    Cluster Name:      ipm_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    3
    Replicas:          3
    Replicas Goal:     3
    Cluster Name:      capture_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    3
    Replicas:          3
    Replicas Goal:     3
    Cluster Name:      wccadf_cluster
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    3
    Replicas:          3
    Replicas Goal:     3

  Conditions:
    Last Transition Time:        2021-09-30T11:04:35.889547Z
    Reason:                      ServersReady
    Status:                      True
    Type:                        Available
  Introspect Job Failure Count:  0
  Servers:
    Desired State:  RUNNING
    Health:
      Activation Time:  2021-09-30T10:58:38.381000Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      10.0.10.135
    Server Name:    adminserver
    State:          RUNNING
    Cluster Name:   ibr_cluster
    Desired State:  RUNNING
    Health:
      Activation Time:  2021-09-30T11:01:09.987000Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      10.0.10.135
    Server Name:    ibr_server1
    State:          RUNNING
    Cluster Name:   ibr_cluster
    Desired State:  SHUTDOWN
    Server Name:    ibr_server2
    Cluster Name:   ibr_cluster
    Desired State:  SHUTDOWN
    Server Name:    ibr_server3
    Cluster Name:   ibr_cluster
    Desired State:  SHUTDOWN
    Server Name:    ibr_server4
    Cluster Name:   ibr_cluster
    Desired State:  SHUTDOWN
    Server Name:    ibr_server5
    Cluster Name:   ucm_cluster
    Desired State:  RUNNING
    Health:
      Activation Time:  2021-09-30T11:00:36.369000Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      10.0.10.142
    Server Name:    ucm-server1
    State:          RUNNING
    Cluster Name:   ucm_cluster
    Desired State:  RUNNING
    Health:
      Activation Time:  2021-09-30T11:02:35.448000Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      10.0.10.135
    Server Name:    ucm-server2
    State:          RUNNING
    Cluster Name:   ucm_cluster
    Desired State:  RUNNING
    Health:
      Activation Time:  2021-09-30T11:04:32.314000Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      10.0.10.142
    Server Name:    ucm-server3
    State:          RUNNING
    Cluster Name:   ucm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ucm-server4
    Cluster Name:   ucm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ucm-server5
    Cluster Name:   ipm_cluster
    Desired State:  RUNNING
    Health:
      Activation Time:  2021-09-30T11:04:32.314000Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    ipm_server1
    State:          RUNNING
    Cluster Name:   ipm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ipm_server2
    Cluster Name:   ipm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ipm_server3
    Cluster Name:   ipm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ipm_server4
    Cluster Name:   ipm_cluster
    Desired State:  SHUTDOWN
    Server Name:    ipm_server5
    Cluster Name:   capture_cluster
    Desired State:  RUNNING
    Health:         
      Activation Time:  2021-09-30T11:04:32.314000Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime 
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    capture_server1
    State:          RUNNING
    Cluster Name:   capture_cluster
    Desired State:  SHUTDOWN
    Server Name:    capture_server2
    Cluster Name:   capture_cluster
    Desired State:  SHUTDOWN
    Server Name:    capture_server3
    Cluster Name:   capture_cluster
    Desired State:  SHUTDOWN
    Server Name:    capture_server4
    Cluster Name:   capture_cluster
    Desired State:  SHUTDOWN
    Server Name:    capture_server5
    Cluster Name:   wccadf_cluster
    Desired State:  RUNNING
    Health:         
      Activation Time:  2021-09-30T11:04:32.314000Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime 
        Symptoms:
    Node Name:      MyNodeName
    Server Name:    wccadf_server1
    State:          RUNNING
    Cluster Name:   wccadf_cluster
    Desired State:  SHUTDOWN
    Server Name:    wccadf_server2
    Cluster Name:   wccadf_cluster
    Desired State:  SHUTDOWN
    Server Name:    wccadf_server3
    Cluster Name:   wccadf_cluster
    Desired State:  SHUTDOWN
    Server Name:    wccadf_server4
    Cluster Name:   wccadf_cluster
    Desired State:  SHUTDOWN
    Server Name:    wccadf_server5

  Start Time:       2021-08-24T12:26:20.033714Z
Events:             <none>

出力のStatusセクションに、使用可能なサーバーおよびクラスタがリストされます。このコマンドがスクリプトの終了後すぐに発行された場合、まだ使用可能なサーバーがないか、管理サーバーのみで管理対象サーバーがない可能性があることに注意してください。WebLogic Kubernetes Operatorは、最初に管理サーバーを起動し、その準備が完了するまで待機してから管理対象サーバーを起動します。

ポッドの検証

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

$ kubectl get pods -n NAMESPACE

次に、このコマンドの出力例を示します。ucmおよびibrクラスタの管理サーバーと管理対象サーバーが実行されていることを確認できます。

$ kubectl get pod -n wccns
NAME                                                READY   STATUS      RESTARTS   AGE
rcu                                                 1/1     Running     0          54d
wccinfra-adminserver                                1/1     Running     0          18d
wccinfra-create-fmw-infra-sample-domain-job-xqnn4   0/1     Completed   0          54d
wccinfra-ibr-server1                                1/1     Running     0          18d
wccinfra-ucm-server1                                1/1     Running     0          18d
wccinfra-ucm-server2                                1/1     Running     0          18d
wccinfra-ucm-server3                                1/1     Running     0          18d
wccinfra-ipm-server1                                1/1     Running     0          18d
wccinfra-ipm-server2                                1/1     Running     0          18d
wccinfra-ipm-server3                                1/1     Running     0          18d
wccinfra-capture-server1                            1/1     Running     0          18d
wccinfra-capture-server2                            1/1     Running     0          18d
wccinfra-capture-server3                            1/1     Running     0          18d
wccinfra-wccadf-server1                             1/1     Running     0          18d
wccinfra-wccadf-server2                             1/1     Running     0          18d
wccinfra-wccadf-server3                             1/1     Running     0          18d

サービスの検証

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

$ kubectl get services -n NAMESPACE

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

サービスのサンプル・リスト:

$ kubectl get services -n wccns
NAME                               TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)          AGE
oracle-db                          LoadBalancer   10.96.4.194     141.148.xxx.xxx   1521:30011/TCP   15d
wccinfra-adminserver               ClusterIP      None            <none>            7001/TCP         43h
wccinfra-capture-server1           ClusterIP      None            <none>            16400/TCP        43h
wccinfra-capture-server2           ClusterIP      None            <none>            16400/TCP        43h
wccinfra-capture-server3           ClusterIP      None            <none>            16400/TCP        43h
wccinfra-capture-server4           ClusterIP      10.96.162.97    <none>            16400/TCP        43h
wccinfra-capture-server5           ClusterIP      10.96.86.213    <none>            16400/TCP        43h
wccinfra-cluster-capture-cluster   ClusterIP      10.96.107.96    <none>            16400/TCP        2d13h
wccinfra-cluster-ibr-cluster       ClusterIP      10.96.123.229   <none>            16250/TCP        2d13h
wccinfra-cluster-ipm-cluster       ClusterIP      10.96.130.117   <none>            16000/TCP        2d13h
wccinfra-cluster-ucm-cluster       ClusterIP      10.96.24.88     <none>            16200/TCP        119s
wccinfra-cluster-wccadf-cluster    ClusterIP      10.96.11.113    <none>            16225/TCP        2d13h
wccinfra-ibr-server1               ClusterIP      None            <none>            16250/TCP        43h
wccinfra-ibr-server2               ClusterIP      10.96.57.47     <none>            16250/TCP        43h
wccinfra-ibr-server3               ClusterIP      10.96.75.252    <none>            16250/TCP        43h
wccinfra-ibr-server4               ClusterIP      10.96.120.224   <none>            16250/TCP        43h
wccinfra-ibr-server5               ClusterIP      10.96.34.58     <none>            16250/TCP        43h
wccinfra-ipm-server1               ClusterIP      None            <none>            16000/TCP        43h
wccinfra-ipm-server2               ClusterIP      None            <none>            16000/TCP        43h
wccinfra-ipm-server3               ClusterIP      None            <none>            16000/TCP        43h
wccinfra-ipm-server4               ClusterIP      10.96.44.8      <none>            16000/TCP        43h
wccinfra-ipm-server5               ClusterIP      10.96.77.81     <none>            16000/TCP        43h
wccinfra-ucm-server1               ClusterIP      None            <none>            16200/TCP        43h
wccinfra-ucm-server2               ClusterIP      None            <none>            16200/TCP        43h
wccinfra-ucm-server3               ClusterIP      None            <none>            16200/TCP        43h
wccinfra-ucm-server4               ClusterIP      10.96.132.1     <none>            16200/TCP        43h
wccinfra-ucm-server5               ClusterIP      10.96.199.161   <none>            16200/TCP        43h
wccinfra-wccadf-server1            ClusterIP      None            <none>            16225/TCP        43h
wccinfra-wccadf-server2            ClusterIP      None            <none>            16225/TCP        43h
wccinfra-wccadf-server3            ClusterIP      None            <none>            16225/TCP        43h
wccinfra-wccadf-server4            ClusterIP      10.96.156.42    <none>            16225/TCP        43h
wccinfra-wccadf-server5            ClusterIP      10.96.194.175   <none>            16225/TCP        43h

IBR intradocポートのサービスの公開

  1. ibr管理対象サーバー・ポッドをホストするノードのIPアドレスを取得します。このサンプルでは、wccinfra-ibr-server1ポッドを実行しているノードにIP '10.0.10.xx'があります

    $ kubectl get pods -n wccns -o wide

#output
NAME                                                READY   STATUS      RESTARTS   AGE     IP             NODE          NOMINATED NODE   READINESS GATES
wccinfra-adminserver                                1/1     Running     0          4h50m   10.244.0.150   10.0.10.xxx   <none>           <none>
wccinfra-create-fmw-infra-sample-domain-job-zbsxr   0/1     Completed   0          7d22h   10.244.1.25    10.0.10.xx    <none>           <none>
wccinfra-ibr-server1                                1/1     Running     0          4h48m   10.244.1.38    10.0.10.xx   <none>           <none>
wccinfra-ucm-server1                                1/1     Running     0          4h48m   10.244.1.39    10.0.10.xx    <none>           <none>
wccinfra-ucm-server2                                1/1     Running     0          4h46m   10.244.0.151   10.0.10.xxx   <none>           <none>
wccinfra-ucm-server3                                1/1     Running     0          4h44m   10.244.1.40    10.0.10.xx    <none>           <none>

  2. IBR intradocポートをNodePortとして公開します > ノート: 範囲からNodePort値を選択します(デフォルト: 30000-32767)。このサンプルでは、nodePort値を30555として選択しました

    $ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/

kubectl expose  service/wccinfra-cluster-ibr-cluster --name wccinfra-cluster-ibr-cluster-ext --port=5555 --type=NodePort -n wccns --dry-run=true -o yaml > wccinfra-cluster-ibr-cluster-ext.yaml

sed -i -e '/targetPort:*/a\ \ \ \ nodePort: 30555' wccinfra-cluster-ibr-cluster-ext.yaml

kubectl -n wccns apply -f wccinfra-cluster-ibr-cluster-ext.yaml

  3. ibrサービス名'wccinfra-cluster-ibr-cluster-ext'を検証します

    $ kubectl get svc -n wccns
NAME                            TYPE      CLUSTER-IP    EXTERNAL-IP PORT(S)
wccinfra-cluster-ibr-cluster-ext NodePort 10.109.247.52 <none>     5555:30555/TCP

  4. 次の詳細を指定して送信プロバイダを作成し、サーバーを再起動します。

    NodePort値(前述のサンプルでは30555)をServer Portとして指定してください。

    Server Host Name:  <your-ibr-managed-server-node-ip>

Server Port: 30555

    oke-wcc-provider-ucm-ibr

UCM intradocポートのサービスの公開

  1. ucm管理対象サーバー・ポッドをホストするノードのIPアドレスを取得します。このサンプルでは、wccinfra-ucm-server1ポッドを実行しているノードにIP '10.0.10.xx'があります

    $ kubectl get pods -n wccns -o wide

#output
NAME                                                READY   STATUS      RESTARTS   AGE     IP             NODE          NOMINATED NODE   READINESS GATES
wccinfra-adminserver                                1/1     Running     0          4h50m   10.244.0.150   10.0.10.xxx   <none>           <none>
wccinfra-create-fmw-infra-sample-domain-job-zbsxr   0/1     Completed   0          7d22h   10.244.1.25    10.0.10.xx    <none>           <none>
wccinfra-ibr-server1                                1/1     Running     0          4h48m   10.244.1.38    10.0.10.xx   <none>           <none>
wccinfra-ucm-server1                                1/1     Running     0          4h48m   10.244.1.39    10.0.10.xx    <none>           <none>
wccinfra-ucm-server2                                1/1     Running     0          4h46m   10.244.0.151   10.0.10.xxx   <none>           <none>
wccinfra-ucm-server3                                1/1     Running     0          4h44m   10.244.1.40    10.0.10.xx    <none>           <none>

  2. UCM intradocポートをNodePortとして公開します > ノート: 範囲からNodePort値を選択します(デフォルト: 30000-32767)。このサンプルでは、nodePort値を30444として選択しました

    $ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/

$ kubectl expose  service/wccinfra-cluster-ucm-cluster --name wccinfra-cluster-ucm-cluster-ext --port=4444 --type=NodePort -n wccns --dry-run=true -o yaml > wccinfra-cluster-ucm-cluster-ext.yaml

$ sed -i -e '/targetPort:*/a\ \ \ \ nodePort: 30444' wccinfra-cluster-ucm-cluster-ext.yaml

$ kubectl -n wccns apply -f wccinfra-cluster-ucm-cluster-ext.yaml

  3. ucmサービス名'wccinfra-cluster-ucm-cluster-ext'を検証します

    $ kubectl get svc -n wccns
NAME                            TYPE      CLUSTER-IP    EXTERNAL-IP PORT(S)
wccinfra-cluster-ucm-cluster-ext NodePort 10.109.247.52 <none>     4444:30444/TCP

Oracle Identity Cloud Service (IDCS)用のOracle WebCenter Contentの構成

内容

概要

OKEでのOracle Identity Cloud Service (IDCS)用のWebCenter Contentの構成。構成情報は次の項で説明します。

SSL.hostnameVerifierプロパティの更新

SSL.hostnameVerifierプロパティを更新するには、次を実行します(これは、IDCSプロバイダがIDCSにアクセスするために必要です)。

  1. ドメイン内のすべてのサーバー(管理サーバーおよびすべての管理対象WebLogicサーバーを含む)を停止します。

  2. SSL.hostnameVerifierプロパティを更新します:

    ファイル//bin/setDomainEnv.shを編集します: pvの場所のファイル・システムに移動し、ファイルsetDomainEnv.shを変更します(サンプル: /WCCFS/wccinfra/bin/setDomainEnv.sh)

    または

    別の方法として、ファイル<DOMAIN_HOME>/<domain_name>/bin/setUserOverrides.shを作成または変更します。IDCSオーセンティケータにSSL.hostnameVerifierプロパティを追加します(サンプル: /WCCFS/wccinfra/bin/setUserOverrides.sh)

     EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dweblogic.security.SSL.hostnameVerifier=weblogic.security.utils.SSLWLSWildcardHostnameVerifier"

 export EXTRA_JAVA_PROPERTIES

  3. 管理サーバーおよびすべての管理対象WebLogicサーバーを起動します。

IDCSセキュリティ・プロバイダの構成

  1. IDCS管理コンソールにログインします。

  2. 信頼できるアプリケーションを作成します。機密アプリケーションの追加ウィザードで次のようにします:

    1. クライアント名と説明を入力します(オプション)。
    2. 「このアプリケーションをクライアントとして今すぐ構成します」オプションを選択します。このアプリケーションを構成するには、「構成」タブで「クライアント構成」を展開します。
    3. 「許可される権限付与タイプ」で、「クライアント資格証明」フィールド(チェック・ボックス)を選択します。
    4. 「Identity Cloud Service管理APIへのクライアント・アクセス権を付与します」セクションで、「追加」をクリックして、APPロール(アプリケーション・ロール)を追加します。「アイデンティティ・ドメイン管理者」ロールを追加できます。
    5. ページのデフォルト設定のままにして、「終了」をクリックします。
    6. クライアントIDおよびクライアント・シークレットを記録/コピーします。これは、IDCSプロバイダを作成する場合に必要です。
    7. アプリケーションをアクティブ化します。

Oracle Identity Cloud Integratorプロバイダの構成

Oracle Identity Cloud Integratorプロバイダを構成するには:

  1. WebLogic Server管理コンソールにログインします。
  2. 「ドメイン構造」ペインで「セキュリティ・レルム」を選択します。
  3. 「セキュリティ・レルムのサマリー」ページで、レルムの名前(myrealmなど)を選択します。「myrealm」をクリックします。「myrealmの設定」ページが表示されます。
  4. 「レルム名の設定」ページで、「プロバイダ」→「認証」を選択します。新しい認証プロバイダを作成するには、認証プロバイダの表で「新規」をクリックします。
  5. 「新しい認証プロバイダの作成」ページで、認証プロバイダの名前(IDCSIntegratorなど)を入力し、ドロップダウン・リストから認証プロバイダの「OracleIdentityCloudIntegrator」タイプを選択して、「OK」をクリックします。
  6. 「認証プロバイダ」表で、新しく作成したOracle Identity Cloud Integratorの「IDCSIntegrator」リンクをクリックします。
  7. 「IDCSIntegratorの設定」ページの「制御フラグ」フィールドで、ドロップダウン・リストから「十分」オプションを選択し、「保存」をクリックします。
  8. 「プロバイダ固有」ページに移動して、セキュリティ・プロバイダの追加属性を構成します。次のフィールドに値を入力し、「保存」をクリックします:
    • ホスト
    • ポート443(デフォルト)
    • 「SSLの有効化」を選択
    • テナント
    • クライアントID
    • クライアント・シークレット。
      > ノート: IDCS URLがidcs-abcde.identity.example.comの場合、IDCSホストはidentity.example.com、テナント名はidcs-abcdeになります。ページのその他のセクションではデフォルト設定を維持します。
  9. 「セキュリティ・レルム」、「myrealm」、「プロバイダ」の順に選択します。「認証プロバイダ」表で「並替え」をクリックします。
  10. 「認証プロバイダの並替え」ページで、「IDCSIntegrator」を一番上に移動して、「OK」をクリックします。
  11. 「認証プロバイダ」表で、「DefaultAuthenticator」リンクをクリックします。「DefaultAuthenticatorの設定」ページの「制御フラグ」フィールドで、ドロップダウン・リストから「十分」オプションを選択します。「保存」をクリックします。
  12. すべての変更がアクティブになります。管理サーバーを再起動します。

IDCSとWebLogicの間の信頼の設定

IDCSとWebLogicの間に信頼を設定するには 1.証明書をKSSストアにインポートします。* これを管理サーバー・ノードから実行します。* IDCS証明書を取得します: ```bash echo -n | openssl s_client -showcerts -servername -connect :443|sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > /tmp/idcs_cert_chain.crt

 #sample
 echo -n | openssl s_client -showcerts -servername xyz.identity.oraclecloud.com -connect idcs-xyz.identity.oraclecloud.com:443|sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/idcs_cert_chain.crt

 #copy the certificate inside the admin_pod
 kubectl cp /tmp/idcs_cert_chain.crt wccns/xyz-adminserver:/u01/idcs_cert_chain.crt
 ```
  1. 管理サーバーおよび管理対象サーバーを再起動します

IDCS管理コンソールでのWebCenter Contentの管理ユーザーの作成

管理対象サーバーがSAML用に構成されると、ドメイン管理ユーザー(通常はweblogicユーザー)は管理対象サーバーにログインできなくなるため、IDCSで管理ユーザーを作成することが重要です。

IDCSでWebCenter Content JaxWS接続用のWebLogic管理ユーザーを作成するには:

  1. 「グループ」タブに移動し、IDCSで「管理者」ロールと「sysmanager」ロールを作成します。
  2. 「ユーザー」タブに移動し、wls管理ユーザー(weblogicなど)を作成して、それを「管理者」グループと「sysmanager」グループに割り当てます。
  3. すべての管理対象サーバーを再起動します。

グループ・メンバーシップ、ロールおよびアカウントの管理

これには、IDCSにアクセスするためにOPSSおよびlibOVDを変更する必要があります。ユーザー認可にIDCSを使用する場合、次のステップが必要です。ユーザー認証のみにIDCSを使用する場合は、これらのステップを実行しないでください。次のステップに進む前に、すべてのサーバー(管理を含む)が停止していることを確認してください: > ノート: WebLogic Server管理コンソールを使用してすべてのサーバーを停止します。ポッドを起動/停止する場合は、kubectl patch domainコマンドが推奨される方法であることに注意してください。同じ操作にWebLogic Server管理コンソールなどを使用することは避けてください。

  1. 次のスクリプトを実行します。

    #exec the Administration server
kubectl exec -n wccns -it wccinfra-adminserver -- /bin/bash

#Run the wlst.sh
cd /u01/oracle/oracle_common/common/bin/
./wlst.sh

    ノート: WebLogic管理サーバーに接続する必要はありません。

  2. ドメインを読み取ります:

    readDomain(<DOMAIN_HOME>)

#sample
wls:/offline> readDomain('/u01/oracle/user_projects/domains/wccinfra')

  3. テンプレートを追加します:

    addTemplate(<MIDDLEWARE_HOME>/oracle_common/common/templates/wls/oracle.opss_scim_template.jar")

#sample
wls:/offline/wccinfra>addTemplate('/u01/oracle/oracle_common/common/templates/wls/oracle.opss_scim_template.jar')

    ノート: このステップで警告がスローされる場合がありますが、無視してかまいません。addTemplateは非推奨です。addTemplateのかわりにselectTemplateを使用し、その後にloadTemplatesを使用してください。

  4. ドメインを更新します:

    updateDomain()

#sample
wls:/offline/wccinfra> updateDomain()

  5. ドメインを閉じます:

    closeDomain()

#sample
wls:/offline/wccinfra> closeDomain()

  6. 管理サーバー・コンテナを終了します:

    exit

  7. サーバー(管理および管理対象)を起動します。

ユーザー・ログアウトのためのWebCenterコンテンツの構成

「ログアウト」リンクが選択されている場合、SAMLによって再認証されます。「ログアウト」リンクを選択できるようにするには:

  1. WebCenter Content Serverに管理者としてログインします。「管理」、「管理サーバー」、「一般構成」の順に選択します。

  2. 「追加の構成変数」ペインで、次のパラメータを追加します:

    EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dweblogic.security.SSL.hostnameVerifier=weblogic.security.utils.SSLWLSWildcardHostnameVerifier"

  3. 「保存」をクリックします。

  4. 管理サーバーおよび管理対象サーバーを再起動します。

ImagingおよびCaptureのドメインへの追加のマウントまたは共有領域の構成

外部アプリケーションが新しいファイルを書き込むことができるように、Kubernetesクラスタの外部から直接アクセスできるサーバー・ポッドにボリュームをマウントできます。

これは、特にファイル・インポート用のWebCenter ImagingおよびWebCenter Captureアプリケーションで使用できます。

Kubernetesは、ボリューム | Kubernetesに示された複数のタイプのボリュームをサポートしています。

この項では、さらにnfsボリュームを例として取り上げます。

ボリュームとしての"nfs"のマウント

ファイル・システムの準備に関する項の説明に従ってNFSファイル・システムを作成します。または、既存のNFSサーバーを使用することもできます。

ボリュームを使用するには、.spec.volumesでポッドに提供するボリュームを指定し、domain.yamlファイルの.spec.containers[*].volumeMountsでそれらのボリュームをコンテナにマウントする場所を宣言します。

domain.yamlを更新して次のサンプルに示すように変更を適用し、/u01/sharedirですべてのサーバー・ポッドにnfsサーバー(/sharedirの共有エクスポート・パスを持つ100.XXX.XXX.Xなど)をマウントします。

パス/u01/sharedirは、WebCenter ImagingおよびWebCenter Captureアプリケーションでファイル・インポート・パスとして構成でき、/sharedirに配置されたファイルはアプリケーションによって処理されます。

nfs-volume構成でのdomain.yamlのサンプル・エントリ

...
serverPod:
    # an (optional) list of environment variable to be set on the servers
    env:
    - name: JAVA_OPTIONS
      value: "-Dweblogic.StdoutDebugEnabled=false"
    - name: USER_MEM_ARGS
      value: "-Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx1024m "
    volumes:
    - name: weblogic-domain-storage-volume
      persistentVolumeClaim:
        claimName: wccinfra-domain-pvc
    - name: nfs-volume
      nfs:
        server: 100.XXX.XXX.XXX
        path: /sharedir
    volumeMounts:
    - mountPath: /u01/oracle/user_projects/domains
      name: weblogic-domain-storage-volume
    - mountPath: /u01/sharedir
      name: nfs-volume
...

Oracle Cloud InfrastructureにデプロイされたコンテナでのOracle Webcenter Contentネイティブ・アプリケーションの起動

この項では、OCIにデプロイされたコンテナ化された管理対象サーバーから、ユーザー・インタフェースでOracle WebCenter Contentネイティブ・バイナリを使用するために必要なステップについて説明します。

Oracle WebCenter Contentネイティブ・バイナリのヘッドフル・ユーザー・インタフェースの起動に関する問題

Oracle WebCenter Content (UCM)は、製品コンテナ・イメージの一部として提供されるヘッドフルUIを備えたネイティブ・バイナリのセットを提供します。WebCenter Contentコンテナ・イメージは、デフォルトでOracle slim linuxイメージで作成されます。このイメージには、UIが起動されるヘッドフル・アプリケーションをサポートするために事前インストールされるパッケージの一部が付属していません。UCMには、UIサポートにJAVA AWTを使用するこのような多くのネイティブ・バイナリが用意されています。現在のOracle WebCenter Contentコンテナ・イメージでは、ネイティブ・アプリケーションの実行に失敗するため、UIを起動できません。

次の各項では、一連の手順を提供して、ユーザーがUIを備えたUCMネイティブ・アプリケーションを実行できるようにする解決策について説明します。

これらの手順は2つの部分に分かれています -

  1. 既存のコンテナ・イメージを更新するステップ
  2. VNCセッションを使用してネイティブ・アプリケーションを起動するステップ

WebLogic Image Toolを使用して初期設定のOracle WebCenter Contentコンテナ・イメージを更新するステップ

この項では、WebLogic Image Toolを使用してOSパッケージでイメージを更新する方法について説明します。WebLogic Image Toolの設定については、ここを参照してください。#### 追加のビルド・コマンド

必要なOSパッケージをイメージにインストールするには、WebLogic Image Toolで使用可能な追加のビルド・コマンド・オプションでyumコマンドを使用します。次に示すサンプルのadditionalBuildCmds.txtファイルを使用して、必要なLinuxパッケージ(libXext.x86_64、libXrender.x86_64およびlibXtst.x86_64)をインストールします。

[final-build-commands]
USER root
RUN yum -y --downloaddir=/tmp/imagetool install libXext libXrender libXtst  \
        && yum -y --downloaddir=/tmp/imagetool clean all \
    && rm -rf /var/cache/yum/* \
    && rm -rf /tmp/imagetool
USER oracle

ノート: ユーザーをoracleに変更することが重要です。そうしないと、コンテナ実行中のユーザーはrootになります。#### ビルド引数

イメージの更新に必要な引数は、ファイルとしてWebLogic Image Toolに渡すことができます。

'update' is the sub command to Image Tool for updating an existing docker image.
'--fromImage' option provides the existing docker image that has to be updated.
'--tag' option should be provided with the new tag for the updated image.
'--additionalBuildCommands' option should be provided with the above created additional build commands file.
'--chown oracle:root' option should be provided to update file permissions.

次に、イメージの更新に使用するサンプルのビルド引数(buildArgs)ファイルを示します。

  update
  --fromImage <existing_WCContent_image_without_dependent_packages>
  --tag <name_of_updated_WCContent_image_to_be_built>
  --additionalBuildCommands ./additionalBuildCmds.txt
  --chown oracle:root

Oracle WebCenter Contentコンテナ・イメージの更新

ここで、前述のビルド引数ファイルを使用して、WebLogic Image Toolを実行し、初期設定のイメージを更新します -

$ imagetool @buildArgs

WebLogic Image Toolには、イメージを更新するための複数のオプションが用意されています。更新オプションの詳細は、このドキュメントを参照してください。

イメージを更新しても、追加のビルド・コマンドで変更されないかぎり、ソース・イメージの'CMD'は変更されません。

$ docker inspect -f '{{.Config.Cmd}}' <name_of_updated_Wccontent_image>
[/u01/oracle/container-scripts/createDomainandStartAdmin.sh]

VNCセッションを使用してOracle WebCenter Contentネイティブ・アプリケーションを起動するステップ

更新されたイメージが正常にビルドされ、必要なすべてのノードで使用可能になったら、次を実行します:

  1. 更新されたイメージ名でdomain.yamlファイルを更新し、domain.yamlファイルを適用します。
$ kubectl apply -f domain.yaml
  1. 変更されたdomain.yamlを適用すると、ポッドが再起動され、必要なパッケージで更新されたイメージで実行が開始されます。
$ kubectl get pods -n <namespace_being_used_for_wccontent_domain>

  1. UCMサーバー・ポッドがデプロイされている1つのワーカー・ノードにVNCサーバーをインストールします。

  2. ワーカー・ノードでvncserver systemctlデーモンを起動した後、要塞ホストからプライベート・サブネット・インスタンス(ワーカー・ノード)に次のコマンドを実行します。

# The default VNC port is 5900, but that number is incremented according to the configured display number. Thus, display 1 corresponds to 5901, display 2 to 5902, and so on.
$ ssh -i <Workernode_private.key> -L 590<display_number>:localhost:590<display_number> -p 22 -L 590<display number>:localhost:590<display number> -N -f <user>@<Workernode_privateIPAddress>

# Sample command 
$ ssh -i <Workernode_private.key> -L 5901:localhost:5901 -p 22 -L 5901:localhost:5901 -N -f opc@10.0.10.xx
  1. 個人クライアントから、前述のセッションを開いた状態で次のコマンドを実行します。
# Use any Linux emulator (like, Windows Power Shell for Windows) to run the following command
$ ssh -i <Bastionnode_private.key> -L 590<display_number>:localhost:590<display_number> -p 22 -L 590<display_number>:localhost:590<display_number> -N -f <user>@<BastionHost_publicIPAddress>

#  Sample command
$ ssh -i <Bastionnode_private.key> -L 5901:localhost:5901 -p 22 -L 5901:localhost:5901 -N -f opc@129.xxx.249.xxx

  1. 個人クライアントでVNCクライアント・ソフトウェアを開き、localhost:590<display_number>を使用してワーカー・ノードのVNCサーバーに接続します。

  2. ワーカー・ノードにVNCセッションが接続されたら、ターミナルを開きます -

$ xhost +
  1. 要塞ホストのターミナルから次のコマンドを実行します –
# Get into the pod's (for example, wccinfra-ucm-server1) shell:
$ kubectl exec -n wccns -it wccinfra-ucm-server1 -- /bin/bash

# Traverse to the Native Binaries' location
$ cd /u01/oracle/user_projects/domains/wccinfra/ucm/cs/bin

# Set DISPLAY variable within the container
$ export DISPLAY=<Workernode_privateIPAddress, where VNC session was created>:<dispay_number>
# Sample command 
$ export DISPLAY=10.0.10.xx:1

# Launch any native UCM application, from within the container, like this:
$ ./SystemProperties
  1. アプリケーションにUIがある場合は、個人クライアントから接続されたVNCセッションですぐに起動されます。

付録

この項では、KubernetesでのOracle WebCenter Contentドメイン・デプロイメントに関連するその他のタスクについて説明します。

ドメイン・リソースのサイズ設定

KubernetesクラスタでのOracle WebCenter Contentドメイン設定のリソース・サイズ設定情報について説明します。

Oracle WebCenter Contentクラスタのサイズ設定に関する推奨事項

Oracle WebCenter Content 通常の使用状況 中程度の使用状況 高水準の使用状況
管理サーバー CPUコア数: 1、メモリー: 4GB CPUコア数: 1、メモリー: 4GB CPUコア数: 1、メモリー: 4GB
管理対象サーバー サーバー数: 2、CPUコア数: 2、メモリー: 16GB サーバー数: 2、CPUコア数: 4、メモリー: 16GB サーバー数: 3、CPUコア数: 6、メモリー: 16-32GB
PVストレージ 最小250GB 最小250GB 最小500GB

セキュリティの強化

DockerおよびKubernetesクラスタの強化に関するリソースを確認します。

Kubernetesクラスタの保護には、APIサーバー、etcd、ノード、コンテナ・イメージ、コンテナ・ランタイムおよびクラスタ・ネットワークの保護など、複数の面での強化が含まれます。多層防御の原則、最小特権の原則を適用し、攻撃面を最小限に抑えます。Kube-Benchなどのセキュリティ・ツールを使用して、クラスタのセキュリティ状態を確認します。Kubernetesは急速に進化しているため、Kubernetesクラスタの保護に関する最新情報は、Kubernetesセキュリティの概要を参照してください。また、デプロイされたDockerコンテナがDockerセキュリティのガイダンスに従っていることも確認してください。

この項では、DockerおよびKubernetesを安全に構成する方法に関するリファレンスを提供します。

リファレンス

  1. Dockerの強化
  2. Kubernetesの強化
  3. DockerおよびKubernetesで実行されるOracle WebLogic Serverのセキュリティ・ベスト・プラクティス

オンプレミスでのクイック・スタート・デプロイメント

このクイック・スタートを使用して、WebLogic Kubernetes OperatorでKubernetesクラスタ(オンプレミス環境)にOracle WebCenter Contentドメイン・デプロイメントを作成します。この段階的な手順は、デモンストレーションのみを目的としており、本番では使用できないことに注意してください。これらの手順は、ユーザーがKubernetesをすでによく理解していることを前提としています。詳細な手順が必要な場合は、「インストール・ガイド」を参照してください。

ハードウェア要件

WebLogic Kubernetes OperatorでOracle WebCenter Contentドメインをデプロイおよび実行するためにサポートされているLinuxカーネルは、Oracle Linux 8およびRed Hat Enterprise Linux 8です。詳細は、前提条件を参照してください。

この演習で、単一ノードのKubernetesクラスタを作成し、それぞれ1つのUCMおよびIBRクラスタを持つOracle WebCenter Contentドメインをデプロイするための最小ハードウェア要件は、次のとおりです。

ハードウェア サイズ
RAM 32GB
ディスク領域 250GB+
CPUコア 6

KubernetesクラスタでのOracle WebCenter Contentドメイン設定のリソース・サイズ設定情報は、ここを参照してください。

オンプレミス環境でのOracle WebCenter Contentの設定

このトピックのステップを実行して、単一インスタンスのオンプレミスKubernetesクラスタを作成し、Oracle WebCenter Content ServerおよびOracle WebCenter Inbound Refinery ServerをデプロイするOracle WebCenter Contentドメインを作成します。

1. Kubernetesクラスタ用の仮想マシンの準備

説明目的のため、これらの手順はOracle Linux 8用です。Linuxの異なるフレーバを使用している場合は、それに応じてステップを調整する必要があります。

ノート: これらのステップは、特に指定がないかぎり、rootユーザーで実行する必要があります。コマンドにYOUR_USERIDが見つかった場合は、常に実際のuseridに置き換える必要があります。

1.1 前提条件

  1. DockerおよびKubernetesファイルが格納されるディレクトリを選択します。Dockerディレクトリは、すべてのイメージおよびコンテナを含むDockerファイル・システムに使用されるため、多くの空き領域(100GB超)を持つディスク上に存在する必要があります。Kubernetesディレクトリは、/var/lib/kubeletファイル・システムおよび永続ボリューム・ストレージに使用されます。

    $ export docker_dir=/u01/docker
$ export kubelet_dir=/u01/kubelet
$ mkdir -p $docker_dir $kubelet_dir
$ ln -s $kubelet_dir /var/lib/kubelet

  2. ホストでIPv4転送が有効になっていることを確認します。

    ノート: eth0は、コンピュート・リソースのイーサネット・インタフェース名に置き換えます(異なる場合)。

    $ /sbin/sysctl -a 2>&1|grep -s 'net.ipv4.conf.docker0.forwarding'
$ /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.docker0.forwarding = 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.docker0.forwarding=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

    再起動後も設定を保持するには: /usr/lib/sysctl.d/、/run/sysctl.d/および/etc/sysctl.d/にあるファイルで、前述の値を1に更新します

  3. 転送用のiptablesルールを確認します。

    Kubernetesは、iptablesを使用して多くのネットワーキングおよびポート転送ルールを処理します。標準のDockerインストールでは、転送を妨げるファイアウォール・ルールが作成されることがあります。

    転送トラフィックを受け入れる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 ")"

  4. firewalldを無効化および停止します:

    $ systemctl disable firewalld
$ systemctl stop firewalld

1.2 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/OL8/olcne18/x86_64

### Installing cri-o
$ dnf install -y cri-o

    ノート: 別のバージョンのCRI-Oをインストールするか、別のオペレーティング・システムにインストールするには、CRI-Oのインストール手順を参照してください。

  3. 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

  4. 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

  5. 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

  2. SELinuxを許可モードに設定します(実質的に無効化します):

    $ export PATH=/sbin:$PATH
$ setenforce 0
$ sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

  3. プロキシをエクスポートし、kubeadm、kubeletおよびkubectlをインストールします:

    ### 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/docker.sock,$ip_addr
$ export no_proxy=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/docker.sock,$ip_addr
$ 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 kubernetes 1.26.2-0
$ VERSION=1.26.2-0
$ yum install -y kubelet-$VERSION kubeadm-$VERSION kubectl-$VERSION --disableexcludes=kubernetes

### enable kubelet service so that it auto-restart on reboot
$ systemctl enable --now kubelet

  4. トラフィック・ルーティングの問題を回避するために、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

  5. スワップ・チェックを無効化します:

    $ 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

  6. crioを使用してイメージをプルします:

    $ kubeadm config images pull --cri-socket unix:///var/run/crio/crio.sock

1.4 Helmの設定

  1. Helm v3.10.xをインストールします

    1. https://github.com/helm/helm/releasesからHelmをダウンロードします。Helm v3.5.4をダウンロードする例:

      $ wget https://get.helm.sh/helm-v3.10.3-linux-amd64.tar.gz

    2. tar.gzを解凍します:

      $ tar -zxvf helm-v3.10.3-linux-amd64.tar.gz

    3. 解凍したディレクトリでHelmバイナリを検索し、目的の宛先に移動します:

      $ mv linux-amd64/helm /usr/bin/helm

  2. helm versionを実行して、インストールを確認します:

    $ helm version
  version.BuildInfo{Version:"v3.10.3", GitCommit:"835b7334cfe2e5e27870ab3ed4135f136eecc704", GitTreeState:"clean", GoVersion:"go1.18.9"}

2. 単一インスタンスのKubernetesクラスタの設定

ノート: * これらのステップは、特に指定がないかぎり、rootユーザーで実行する必要があります。* 別のCIDRブロック(つまり、kubeadm initコマンドの--pod-network-cidr=に対して10.244.0.0/16以外)を使用する場合は、NO_PROXYおよびno_proxyも適切な値で更新します。* 同様に、デプロイする前に必ず新しい値でkube-flannel.yamlを更新してください。* 次を適切な値に置き換えます: * ADD-YOUR-INTERNAL-NO-PROXY-LIST * REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT

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    master   8m26s   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-amd64-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/master-

これで終了です。Kubernetesクラスタ環境は、Oracle WebCenter Contentドメインをデプロイする準備が完了しました。

Kubernetesクラスタ設定に関する追加のリファレンスは、Kubernetesクラスタを設定するためのドキュメントを確認してください。

3. スクリプトおよびイメージの取得

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

これらのステップに従って、Oracle WebCenter Contentドメインのデプロイに必要なソース・コード・リポジトリを設定します。

3.2 依存イメージの取得およびローカル・レジストリへの追加

これらのステップに従って、Oracle WebCenter Contentドメインのデプロイに必要な依存Dockerイメージをプルします。

3.3 Oracle WebCenter Content Dockerイメージの取得およびローカル・レジストリへの追加

これらのステップに従って、Oracle WebCenter Contentイメージを取得します。

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

4.1 WebLogic Kubernetes Operatorの準備。

  1. WebLogic Kubernetes Operatorのネームスペースopnsを作成します:

    $ kubectl create namespace opns

  2. オペレータのネームスペースにWebLogic Kubernetes Operatorのサービス・アカウントop-saを作成します:

    $ kubectl create serviceaccount -n opns op-sa

4.2 WebLogic Kubernetes Operatorのインストール

Helmを使用して、WebLogic Kubernetes Operatorをインストールし、クローニングしたディレクトリから起動します:

$ cd ${WORKDIR}
$ helm install weblogic-kubernetes-operator charts/weblogic-operator \
--namespace opns \
--set image=oracle/weblogic-kubernetes-operator:4.2.9 \
--set serviceAccount=op-sa \
--set "domainNamespaces={}" \
--wait

4.3 WebLogic Kubernetes Operatorの検証

  1. それぞれのネームスペースのポッドをリストして、WebLogic Kubernetes Operatorのポッドが実行されていることを確認します。WebLogic Kubernetes Operator用のものが表示されます:

    $ kubectl get pods -n opns

  2. オペレータ・ポッドのログを表示して、WebLogic Kubernetes Operatorが稼働していることを確認します:

    $ kubectl logs -n opns -c weblogic-operator deployments/weblogic-operator

WebLogic Kubernetes Operator v4.2.9がインストールされました。ロード・バランサおよびOracle WebCenter Contentドメインの設定に進みます。

5. Traefik (イングレスベース)ロード・バランサのインストール

WebLogic Kubernetes Operatorは、ロード・バランサとしてTraefik、NGINXおよびApacheをサポートしています。サンプルはドキュメントに記載されています。

このクイック・スタートでは、Traefikイングレス・コントローラをインストールして、Oracle WebCenter Contentドメインのロード・バランシングを提供する方法を示します。

  1. Traefikのネームスペースを作成します:

    $ kubectl create namespace traefik

  2. サード・パーティ・サービス用のHelmを設定します:

    $ helm repo add traefik https://containous.github.io/traefik-helm-chart

  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 Contentドメインの作成および構成

6.1 Oracle WebCenter Contentドメインの準備

  1. Oracle WebCenter Contentドメインをホストできるネームスペースを作成します:

    $ kubectl create namespace wccns

  2. Helmを使用して、このネームスペースでOracle WebCenter Contentドメインを管理するようにWebLogic Kubernetes Operatorを構成します:

    $ cd ${WORKDIR}
$ helm upgrade weblogic-kubernetes-operator charts/weblogic-operator \
   --reuse-values \
   --namespace opns \
   --set "domainNamespaces={wccns}" \
   --wait

  3. Kubernetesシークレットを作成します。

    1. ドメインと同じKubernetesネームスペースで、ドメインのKubernetesシークレットを作成します。この例では、ユーザー名はweblogic、パスワードはwelcome1、ネームスペースはwccnsです:

        $ cd ${WORKDIR}/create-weblogic-domain-credentials
  $ ./create-weblogic-credentials.sh \
     -u weblogic \
     -p welcome1 \
     -n wccns    \
     -d wccinfra \
     -s wccinfra-domain-credentials

    2. ドメインと同じKubernetesネームスペースで、RCUのKubernetesシークレットを作成します:

    • スキーマ・ユーザー: WCC1
    • スキーマ・パスワード: Oradoc_db1
    • DB sysユーザー・パスワード: Oradoc_db1
    • ドメイン名: wccinfra
    • ドメイン・ネームスペース: wccns
    • シークレット名: wccinfra-rcu-credentials
      $ cd ${WORKDIR}/create-rcu-credentials
  $ ./create-rcu-credentials.sh \
         -u WCC1 \
         -p Oradoc_db1 \
         -a sys \
         -q Oradoc_db1 \
         -d wccinfra \
         -n wccns \
         -s wccinfra-rcu-credentials

  4. Kubernetes永続ボリュームおよび永続ボリューム要求を作成します。

    1. Oracle WebCenter Contentドメイン・ホーム・ディレクトリを作成します。uid:gidが1000:0のユーザーがホスト・システムにすでに存在するかどうかを確認します:
    $ sudo getent passwd 1000

    このコマンドでユーザー名(最初のフィールド)が返される場合は、次のuseraddコマンドをスキップできます。そうでない場合は、useraddを使用してoracleユーザーを作成します:

    $ sudo useradd -u 1000 -g 0 oracle

    Oracle WebCenter Contentドメイン・ホームに使用するディレクトリを作成します:

    $ sudo mkdir /scratch/k8s_dir
$ sudo chown -R 1000:0 /scratch/k8s_dir
    1. 次の値でcreate-pv-pvc-inputs.yamlを更新します:
    • baseName: domain
    • domainUID: wccinfra
    • namespace: wccns
    • weblogicDomainStoragePath: /scratch/k8s_dir

    変更が必要な場合は、確認して更新します。

    $ cd ${WORKDIR}/create-weblogic-domain-pv-pvc
$ vim create-pv-pvc-inputs.yaml
    1. create-pv-pvc.shスクリプトを実行して、PVおよびPVC構成ファイルを作成します:
    $ ./create-pv-pvc.sh -i create-pv-pvc-inputs.yaml -o output
    1. 前のステップで作成した構成ファイルを使用して、PVおよびPVCを作成します:
    $ kubectl create -f  output/pv-pvcs/wccinfra-domain-pv.yaml
$ kubectl create -f  output/pv-pvcs/wccinfra-domain-pvc.yaml

  5. データベースを構成し、Oracle WebCenter Contentドメインのスキーマを作成します。

    データベース・アクセスの構成ステップおよびRCUの実行ステップに従って、データベース接続を設定し、Oracle WebCenter Contentドメインをデプロイするために必要な製品スキーマを構成します。

これで、環境はOracle WebCenter Contentドメインの作成を開始する準備ができました。

6.2 Oracle WebCenter Contentドメインの作成

  1. Oracle WebCenter Contentドメイン・デプロイメントのサンプル・スクリプトは、${WORKDIR}/create-wcc-domain/domain-home-on-pvにあります。create-domain-inputs.yaml (またはそのコピー)を編集して、ドメインの詳細を指定する必要があります。

  2. create-domain.shスクリプトを実行して、ドメインを作成します:

    $ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv/
$ ./create-domain.sh -i create-domain-inputs.yaml -o output

  3. Kubernetesドメイン・オブジェクトを作成します:

    create-domain.shが成功すると、output/weblogic-domains/wccinfra/domain.yamlが生成され、これを使用してKubernetesリソース・ドメインを作成し、ドメインおよびサーバーを起動できます:

    $ cd ${WORKDIR}/create-wcc-domain/domain-home-on-pv
$ kubectl create -f output/weblogic-domains/wccinfra/domain.yaml

  4. wccinfraという名前のKubernetesドメイン・オブジェクトが作成されていることを確認します:

    $ kubectl get domain -n wccns
NAME       AGE
wccinfra   3m18s

  5. ドメインを作成すると、イントロスペクト・ポッドが作成されます。これにより、ドメイン・ホームが検査され、wccinfra-adminserverポッドが起動されます。wccinfra-adminserverポッドが正常に起動すると、管理対象サーバー・ポッドが並行して起動されます。wccnsネームスペースで、ドメイン作成のステータスを確認します:

    $ kubectl get pods -n wccns

  6. Oracle WebCenter Contentドメイン・サーバーのポッドおよびサービスが作成され、Ready状態であることを確認します:

    $ kubectl get all -n wccns

6.3 Oracle WebCenter Contentドメイン・サービスにアクセスするためのTraefikの構成

  1. Oracle WebCenter Contentドメイン・ネームスペース(wccns)で作成されたイングレスを管理するようにTraefikを構成します:

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

  2. サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します:

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

  3. ドメインごとに作成されたイングレスの詳細を確認します:

    $ kubectl describe ingress wccinfra-traefik -n wccns

6.4 Oracle WebCenter ContentドメインURLにアクセスできることの確認

  1. 現在の環境のLOADBALANCER_HOSTNAMEを取得します:

    export LOADBALANCER_HOSTNAME=$(hostname -f)

  2. Oracle WebCenter Contentドメインでは、次のURLが使用可能です:

    資格証明: ユーザー名: weblogic パスワード: welcome1

    http://${LOADBALANCER_HOSTNAME}:30305/em
http://${LOADBALANCER_HOSTNAME}:30305/cs
http://${LOADBALANCER_HOSTNAME}:30305/ibr
http://${LOADBALANCER_HOSTNAME}:30305/imaging
http://${LOADBALANCER_HOSTNAME}:30305/dc-console
http://${LOADBALANCER_HOSTNAME}:30305/wcc