Kubernetes上のOracle WebCenter Sites

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

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

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

現在の本番リリース

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

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

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

WebCenter Sitesドメインの制限事項

このリリースでの制限は、こちらを参照してください。

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

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

追加資料

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

リリース・ノート

Kubernetes上のOracle WebCenter Sitesの最新の変更および既知の問題を確認します。

最近の変更

日付 バージョン 後方非互換性の導入 変更
2024年12月10日 24.4.3 いいえ Oracle WebLogic Kubernetes Operatorバージョン4.2.9で認定されているOracle WebCenter Sites 14.1.2.0.0ドメイン・デプロイメントをサポートします。このリリースのOracle WebCenter Sites 14.1.2.0.0コンテナ・イメージは、container-registry.oracle.comからダウンロードできます。

既知の問題

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

インストール・ガイド

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

要件および制限事項

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

内容

概要

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

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

システム要件

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

制限事項

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

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

WebCenter Sites 通常の使用状況 中程度の使用状況 高い使用状況
管理サーバー 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

環境の準備

必要なシークレットの作成、永続ボリュームとボリューム・クレームの作成、データベースの作成、データベース・スキーマの作成など、Oracle WebCenter Sitesドメインの作成を準備します。

内容

このドキュメントでは、Kubernetesクラスタの設定、およびデータベースを含むWebLogicオペレータの設定を含む環境を設定するステップについて説明します。

概要

Kubernetesクラスタの設定

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

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

Oracle WebCenter Sitesイメージの構築

「イメージの作成または更新」に従って、Oracle WebCenter Sites 14.1.2.0.0イメージを構築します。

Oracle WebCenter Sitesイメージの取得

最新のバンドル・パッチおよび必要な個別パッチを含むOracle WebCenter Sitesイメージは、Oracleによって事前に構築されており、Oracle WebCenter Sites 14.1.2.0.0、最新パッチ・セット更新(PSU)、およびクリティカル・パッチ・アップデート(CPU)プログラムでリリースされたその他の修正が含まれています。これは、本番デプロイメントでサポートされている唯一のイメージです。次のいずれかの方法を使用して、Oracle WebCenter Sitesイメージを取得します:

  1. Oracle Container Registryからダウンロード:

    • Oracle Container Registryにログインし、「ミドルウェア」 > webcentersites/webcentersites_cpuに移動して、ライセンス契約にまだ同意していない場合は同意する必要があります。

    • PodmanまたはDockerクライアントからOracle Container Registry (container-registry.oracle.com)にログインします:

      $ podman login container-registry.oracle.com

    • イメージをプルします:

      たとえば:

      $ podman pull container-registry.oracle.com/middleware/webcentersites:14.1.2.0.0

      またはタグを使用してイメージをプルします:

      $ podman pull container-registry.oracle.com/middleware/webcentersites:14.1.2.0.0-<Tag>

  2. My Oracle Supportからダウンロード:

    • My Oracle Support (MOS)からWebCenter Sitesイメージをダウンロードします。

    • ダウンロードしたパッチzipファイルを解凍します。

    • podman loadコマンドを使用してイメージ・アーカイブをロードします。

      たとえば:

      $ podman load < wcsites-141200.tar.gz
  Loaded image: oracle/wcsites:14.1.2.0.0

My Oracle Supportから取得したイメージに含まれない任意の追加のパッチでOracle WebCenter Sites Dockerイメージを構築して使用する場合は、「イメージの作成または更新」のトピックのステップに従ってイメージを作成します。

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

他の依存イメージのプル

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

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

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

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

次に、これらのDockerイメージをプルし、再度タグ付けします:

podman 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イメージ:

$ podman pull container-registry.oracle.com/middleware/weblogic-kubernetes-operator:4.2.9
$ podman tag container-registry.oracle.com/middleware/weblogic-kubernetes-operator:4.2.9 oracle/weblogic-kubernetes-operator:4.2.9
  1. 前述の構築およびプルされたイメージをすべてクラスタ内のすべてのノードにコピーするか、クラスタがアクセスできるDockerレジストリに追加します。

ノート: 開発マシンでKubernetesを実行していない場合は、レジストリでDockerイメージをKubernetesクラスタに表示できるようにする必要があります。次のように、DockerおよびKubernetesを実行しているマシンにイメージをアップロードします:

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

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

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

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

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

    $ mkdir $HOME/wcs_1412
$ cd $HOME/wcs_1412

  2. WebCenter Sites Kubernetesデプロイメント・スクリプトをこのリポジトリからダウンロードします。

    $ git clone https://github.com/oracle/fmw-kubernetes.git

このドキュメントで説明するように、$HOME/wcs_1412/fmw-kubernetes/OracleWebCenterSites/kubernetesのデプロイメント・スクリプトを使用して、WebCenter Sitesドメインを設定できるようになりました。

これは、必要なすべてのスクリプトを実行するためのホーム・ディレクトリになります。

$ cd $HOME/wcs_1412/fmw-kubernetes/OracleWebCenterSites/kubernetes
$ export WORKDIR=$HOME/wcs_1412/fmw-kubernetes/OracleWebCenterSites/kubernetes

失効したリソースのクリア

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

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

  2. WebLogicカスタム・リソース定義が見つかった場合は、次のコマンドを実行して削除します: bash $ kubectl delete crd domains.weblogic.oracle customresourcedefinition.apiextensions.k8s.io "domains.weblogic.oracle" deleted

WebLogic Kubernetes Operatorのインストール

  1. WebLogic Kubernetes Operatorのネームスペースを作成します:

        $ kubectl create namespace operator-ns
    namespace/operator-ns created

    ノート: この演習では、"operator-ns" (任意の名前)というネームスペースを作成します。

    次のメソッドも使用できます。

    • domainUID/domainnameとしてwcsitesinfra
    • ドメイン・ネームスペースとしてwcsites-ns
    • オペレータ・ネームスペースとしてoperator-ns
    • traefikネームスペースとしてtraefik

  2. オペレータのネームスペースにWebLogic Kubernetes Operatorのサービス・アカウントを作成します:

    $ kubectl create serviceaccount -n operator-ns operator-sa
serviceaccount/operator-sa created

  3. Weblogic Kubernetes Operatorリポジトリの追加

    $ helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update

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

  5. helmを使用して、ダウンロードしたリポジトリからWebLogic Kubernetes Operatorをインストールして起動します:

    Helmでweblogic-operatorをインストールします

    $ helm install weblogic-kubernetes-operator weblogic-operator/weblogic-operator  --version 4.2.9 --namespace operator-ns  --set serviceAccount=operator-sa --set "javaLoggingLevel=FINE" --wait

NAME: weblogic-kubernetes-operator
LAST DEPLOYED: Tue May 19 04:04:32 2024
NAMESPACE: operator-ns
STATUS: deployed
REVISION: 1
TEST SUITE: None

  6. オペレータのポッドが実行中であることを確認するには、オペレータのネームスペースにポッドをリストします。WebLogic Kubernetes Operatorの1つが表示されます:

    $ kubectl get pods -n operator-ns
NAME                                         READY   STATUS    RESTARTS   AGE
weblogic-operator-66d44b89fb-d9tqf           2/2     Running   0          5m39s
weblogic-operator-webhook-798bbcbfcc-z82rl   2/2     Running   0          5m39s

  7. そして、次のサンプル・ログ・スニペットに示すように、オペレータ・ポッドのログを表示して確認します:

    $ kubectl logs -n operator-ns -c weblogic-operator deployments/weblogic-operator

Launching Oracle WebLogic Server Kubernetes Operator...
VM settings:
    Max. Heap Size (Estimated): 21.59G
    Using VM: Java HotSpot(TM) 64-Bit Server VM

{"timestamp":"2024-10-07T12:30:40.520682507Z","thread":1,"fiber":"","namespace":"","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.helpers.HealthCheckHelper","method":"createAndValidateKubernetesVersion","timeInMillis":1728304240520,"message":"Kubernetes version is: v1.27.8","exception":"","code":"","headers":{},"body":""}
{"timestamp":"2024-10-07T12:30:40.779242046Z","thread":1,"fiber":"","namespace":"","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.OperatorMain$MainDelegateImpl","method":"logStartup","timeInMillis":1728304240779,"message":"Oracle WebLogic Kubernetes Operator, version: 4.2.9, implementation: 7394a56ef6ac3231a766455d8d199095f6e69fbb.7394a56, build time: 2024-09-11T17:18:22+0000","exception":"","code":"","headers":{},"body":""}
{"timestamp":"2024-10-07T12:30:40.78423637Z","thread":1,"fiber":"","namespace":"","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.OperatorMain$MainDelegateImpl","method":"lambda$logStartup$0","timeInMillis":1728304240784,"message":"The following optional operator features are enabled: []","exception":"","code":"","headers":{},"body":""}
{"timestamp":"2024-10-07T12:30:40.794745506Z","thread":1,"fiber":"","namespace":"","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.OperatorMain$MainDelegateImpl","method":"logStartup","timeInMillis":1728304240794,"message":"Operator namespace is: operator-ns","exception":"","code":"","headers":{},"body":""}
{"timestamp":"2024-10-07T12:30:40.796536215Z","thread":1,"fiber":"","namespace":"","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.OperatorMain$MainDelegateImpl","method":"logStartup","timeInMillis":1728304240796,"message":"Operator service account is: operator-sa","exception":"","code":"","headers":{},"body":""}
{"timestamp":"2024-10-07T12:30:42.294724178Z","thread":57,"fiber":"fiber-1-child-2 NOT_COMPLETE","namespace":"wcsites-ns1","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.helpers.EventHelper$CreateEventStep$CreateEventResponseStep","method":"onSuccess","timeInMillis":1728304242294,"message":"Start managing namespace wcsites-ns1","exception":"","code":"","headers":{},"body":""}
{"timestamp":"2024-10-07T12:30:42.296199191Z","thread":58,"fiber":"fiber-1-child-1 NOT_COMPLETE","namespace":"wcsites-ns","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.helpers.EventHelper$CreateEventStep$CreateEventResponseStep","method":"onSuccess","timeInMillis":1728304242296,"message":"Start managing namespace wcsites-ns","exception":"","code":"","headers":{},"body":""}
{"timestamp":"2024-10-07T12:30:44.482491307Z","thread":125,"fiber":"fiber-1 NOT_COMPLETE","namespace":"","domainUID":"","level":"INFO","class":"oracle.kubernetes.operator.OperatorMain","method":"logStartingLivenessMessage","timeInMillis":1728304244482,"message":"Starting operator liveness Thread","exception":"","code":"","headers":{},"body":""}

NFS (ネットワーク・ファイル・システム)サーバーの構成

NFSサーバーを構成するには、nfs-utilsパッケージをできればマスター・ノードにインストールします:

$ sudo yum install nfs-utils

nfs-serverサービスを開始し、システムの再起動後にサービスが開始するように構成します:

$ sudo systemctl start nfs-server
$ sudo systemctl enable nfs-server

NFS共有としてエクスポートするディレクトリを作成します。たとえば、/scratch/K8SVolume:

$ sudo mkdir -p /scratch/K8SVolume
$ sudo chown -R 1000:0 /scratch/K8SVolume

NFSサーバーのホスト名またはIPアドレス

ノート: 以降の項でPV/PVCを作成するときに使用されるNFSサーバーおよびNFS共有パスのホスト名またはIPアドレス。

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

  1. デフォルト・ネームスペースを使用する場合を除き、1つ以上のドメインをホストできるKubernetesネームスペースを作成します:

    $ kubectl create namespace wcsites-ns
namespace/wcsites-ns created
$ kubectl label namespace wcsites-ns weblogic-operator=enabled

  2. Kubernetesシークレットの作成:

    1. create-weblogic-credentialsスクリプトを使用して、ドメインのユーザー名とパスワードを含むKubernetesシークレットをドメインと同じKubernetesネームスペースに作成します:

    出力: ```bash $ sh kubernetes/create-weblogic-domain-credentials/create-weblogic-credentials.sh
    -u weblogic -p Welcome1 -n wcsites-ns
    -d wcsitesinfra -s wcsitesinfra-domain-credentials

    secret/wcsitesinfra-domain-credentials created secret/wcsitesinfra-domain-credentials labeled The secret wcsitesinfra-domain-credentials has been successfully created in the wcsites-ns namespace. ```説明:

    * weblogic                         is the weblogic username
* Welcome1                         is the weblogic password
* wcsitesinfra                     is the domain name
* wcsites-ns                       is the domain namespace
* wcsitesinfra-domain-credentials  is the secret name

    ノート: 次のように資格証明を調査できます: bash $ kubectl get secret wcsitesinfra-domain-credentials -o yaml -n wcsites-ns

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

    出力:

    $ sh kubernetes/create-rcu-credentials/create-rcu-credentials.sh \
    -u WCS1 -p Oradoc_db1 -a sys -q Oradoc_db1 -n wcsites-ns \
    -d wcsitesinfra -s wcsitesinfra-rcu-credentials

secret/wcsitesinfra-rcu-credentials created
secret/wcsitesinfra-rcu-credentials labeled
The secret wcsitesinfra-rcu-credentials has been successfully created in the wcsites-ns namespace.

    説明:

    * WCS1                             is the schema user
* Oradoc_db1                       is the schema password
* Oradoc_db1                       is the database SYS users password
* wcsitesinfra                     is the domain name
* wcsites-ns                       is the domain namespace
* wcsitesinfra-rcu-credentials     is the secret name

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

    $ kubectl get secret wcsitesinfra-rcu-credentials -o yaml -n wcsites-ns

  3. Kubernetes PVおよびPVC (永続ボリュームおよび永続ボリューム・クレーム)を作成します:

    1. kubernetes/create-wcsites-domain/utils/create-wcsites-pv-pvc-inputs.yamlを更新します。

    トークン%NFS_SERVER%を、「NFSサーバーの構成」の項で作成したNFSサーバーのホスト名/IPに置き換えます。

    NFSサーバーで、次に示すようにフォルダを作成し、権限を付与します。

    $ sudo rm -rf /scratch/K8SVolume/WCSites && sudo mkdir -p /scratch/K8SVolume/WCSites && sudo chown 1000:0 /scratch/K8SVolume/WCSites

    weblogicDomainStoragePathパラメータを/scratch/K8SVolume/WCSitesで更新します。

    1. create-pv-pvc.shスクリプトを実行して、PVおよびPVC構成ファイルを作成します:
    $ sh kubernetes/create-weblogic-domain-pv-pvc/create-pv-pvc.sh \
    -i kubernetes/create-wcsites-domain/utils/create-wcsites-pv-pvc-inputs.yaml \
    -o kubernetes/create-wcsites-domain/output

Input parameters being used
export version="create-weblogic-sample-domain-pv-pvc-inputs-v1"
export baseName="domain"
export domainUID="wcsitesinfra"
export namespace="wcsites-ns"
export weblogicDomainStorageType="NFS"
export weblogicDomainStorageNFSServer="%NFS_SERVER%"
export weblogicDomainStoragePath="/scratch/K8SVolume/WCSites"
export weblogicDomainStorageReclaimPolicy="Retain"
export weblogicDomainStorageSize="10Gi"

Generating kubernetes/create-wcsites-domain/output/pv-pvcs/wcsitesinfra-domain-pv.yaml
Generating kubernetes/create-wcsites-domain/output/pv-pvcs/wcsitesinfra-domain-pvc.yaml
The following files were generated:
kubernetes/create-wcsites-domain/output/pv-pvcs/wcsitesinfra-domain-pv.yaml
kubernetes/create-wcsites-domain/output/pv-pvcs/wcsitesinfra-domain-pvc.yaml

Completed
    1. PVおよびPVCを作成するには、kubectl createを出力構成ファイルとともに使用します:

    出力:

    $ kubectl create -f kubernetes/create-wcsites-domain/output/pv-pvcs/wcsitesinfra-domain-pv.yaml \
    -f kubernetes/create-wcsites-domain/output/pv-pvcs/wcsitesinfra-domain-pvc.yaml

persistentvolume/wcsitesinfra-domain-pv created
persistentvolumeclaim/wcsitesinfra-domain-pvc created

    ノート: PVおよびPVの詳細を次のように検証できます:

    $ kubectl describe pv wcsitesinfra-domain-pv -n wcsites-ns
    $ kubectl describe pvc wcsitesinfra-domain-pvc -n wcsites-ns

  4. 必要に応じて、Kubernetesクラスタ内のノードに、特定のノード上のサーバーのターゲット・スケジューリングのラベルを付けます:

    kubectl label node <node-name> name=abc

    ノート: ここで、<node-name>はkubectl get nodesコマンドのNAMEフィールドに表示されるノードです。abcは、定義するラベルです。ラベルはキーと値のペアであり、意味のあるものにできます。nodeSelectorにも同じものを使用する必要があります。スケジューリングでは、ラベルに基づいてこれらのノードを選択できます。

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

Oracle WebCenter Sitesドメインには、必要なスキーマがインストールされたデータベースが必要です。リポジトリ作成ユーティリティ(RCU)を使用すると、これらのスキーマを作成できます。ドメインを作成する前にデータベースを設定する必要があります。KubernetesでOracle WebCenter Sitesを実行することで追加される要件はありません。同じ既存の要件が適用されます。

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

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

Oracle WebCenter Sitesドメインの作成

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

内容

スクリプトの概要

このドキュメントでは、サンプル・スクリプトを使用して、既存のKubernetes永続ボリューム(PV)および永続ボリューム・クレーム(PVC)でWebCenter Sitesドメイン・ホームを作成する方法について詳しく説明します。また、スクリプトはドメインYAMLファイルを生成します。これを使用して、対応するドメインのKubernetesアーティファクトを起動できます。

前提条件

WebCenter Sitesドメイン作成入力ファイルの準備

必要に応じて、次に示すようにcreate-domain-inputs.yamlを編集することで、ドメイン作成入力をカスタマイズできます:

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

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

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

構成パラメータ

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

パラメータ 定義 デフォルト
adminPort Kubernetesクラスタ内の管理サーバーのポート番号。 7001
adminServerName 管理サーバーの名前。 AdminServer
clusterName ドメイン用に生成するWebLogicクラスタ・インスタンスの名前。デフォルトでは、WebCenter Sitesドメインのクラスタ名はwcsites-clusterです。 wcsites-cluster
configuredManagedServerCount ドメインの管理対象サーバー・インスタンスの数。 3
createDomainFilesDir ホスト・マシン上のディレクトリで、createDomainScriptNameプロパティで指定されたスクリプトを含む、WebLogicドメインの作成に必要なすべてのファイルを検索します。デフォルトでは、このディレクトリは相対パスwlstに設定され、作成スクリプトはwlstディレクトリの組込みWLSTオフライン・スクリプトを使用してWebLogicドメインを作成します。絶対パスも、ファイル・システム内の任意のディレクトリを指すようにサポートされています。組込みスクリプトは、指定したディレクトリにあるかぎり、ユーザーが指定したスクリプトまたはモデル・ファイルに置き換えできます。このディレクトリ内のファイルは、Kubernetes構成マップに配置され、Kubernetesポッドがスクリプトおよびサポート・ファイルを使用してドメイン・ホームを作成できるように、createDomainScriptsMountPathにマウントされます。 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 Sitesドメインのホーム・ディレクトリ。This field cannot be modified. /u01/oracle/user_projects/domains/wcsitesinfra
domainPVMountPath ドメイン永続ボリュームのマウント・パス。This field cannot be modified. /u01/oracle/user_projects/domains
domainUID この特定のドメインの識別に使用される一意のID。生成されたWebLogicドメインの名前およびKubernetesドメイン・リソースの名前として使用されます。このIDは、Kubernetesクラスタ内のすべてのドメインにわたって一意である必要があります。このIDには、Kubernetesサービス名で有効ではない文字を含めることはできません。 wcsitesinfra
exposeAdminNodePort 管理サーバーがKubernetesクラスタの外部に公開されているかどうかを示すブール。 false
exposeAdminT3Channel T3管理チャネルがKubernetesクラスタの外部に公開されているかどうかを示すブール。 false
image WebCenter Sites Dockerイメージ。オペレータには、WebCenter Sitesリリース14.1.2.0.0が必要です。イメージの取得または作成方法の詳細は、「WebCenter Sites Dockerイメージ」を参照してください。 oracle/wcsites:14.1.2.0.0
imagePullPolicy WebLogic Dockerイメージ・プル・ポリシー。有効な値は、IfNotPresent、AlwaysまたはNeverです IfNotPresent
imagePullSecretName Docker StoreにアクセスしてWebLogic Server DockerイメージをプルするためのKubernetesシークレットの名前。このパラメータを指定すると、シークレットの存在が検証されます。
includeServerOutInPodLog ポッドの標準出力にserver.outを含めるかどうかを示すブール。 true
initialManagedServerReplicas ドメインの最初に起動する管理対象サーバーの数。 1
javaOptions 管理サーバーおよび管理対象サーバーを起動するためのJavaオプション。Javaオプションには、WebLogicドメイン情報を取得するための次の事前定義された1つ以上の変数への参照を含めることができます: $(DOMAIN_NAME)、$(DOMAIN_HOME)、$(ADMIN_NAME)、$(ADMIN_PORT)および$(SERVER_NAME)。 -Dweblogic.StdoutDebugEnabled=false
logHome ドメイン・ログ、サーバー・ログ、サーバー・アウトおよびノード・マネージャのログ・ファイルのポッド内の場所。This field cannot be modified. /u01/oracle/user_projects/logs/wcsitesinfra
managedServerNameBase 管理対象サーバー名の生成に使用されるベース文字列。 wcsites_server
managedServerPort 各管理対象サーバーのポート番号。 7103
namespace ドメインを作成するKubernetesネームスペース。 wcsites-ns
persistentVolumeClaimName ドメイン・ホームをホストするために作成された永続ボリューム・クレームの名前。指定しない場合、値はdomainUIDから<domainUID>-weblogic-sample-pvcとして導出されます。 wcsitesinfra-domain-pvc
productionModeEnabled ドメインで本番モードが有効かどうかを示すブール。 true
serverStartPolicy 起動するWebLogic Serverインスタンスを決定します。有効な値は、Never、IfNeeded、AdminOnlyです。 IfNeeded
t3ChannelPort NetworkAccessPointのT3チャネルのポート。 30012
t3PublicAddress T3チャネルのパブリック・アドレス。これは、Kubernetesクラスタのパブリック・アドレスに設定する必要があります。これは通常、ロード・バランサ・アドレスです。 指定しない場合、スクリプトはKubernetesクラスタのIPアドレスに設定しようとします。
weblogicCredentialsSecretName 管理サーバーのユーザー名とパスワードのKubernetesシークレットの名前。指定しない場合、値はdomainUIDから<domainUID>-weblogic-credentialsとして導出されます。 wcsites-domain-credentials
weblogicImagePullSecretName WebLogic Serverイメージのプルに使用されるDocker StoreのKubernetesシークレットの名前。
serverPodCpuRequest、serverPodMemoryRequest、serverPodCpuCLimit、serverPodMemoryLimit 許容されるコンピュート・リソースの最大量および各サーバー・ポッドに必要なコンピュート・リソースの最小量。詳細は、Managing Compute Resources for ContainersにあるKubernetesのドキュメントを参照してください。 リソース・リクエストおよびリソース制限が指定されていません。詳細は、「WebCenter Sitesクラスタのサイズ設定に関する推奨事項」を参照してください。
rcuSchemaPrefix データベースで使用するスキーマ接頭辞。たとえば、WCS1。RCUスキーマとドメインの一致を簡略化するために、これをdomainUIDと同じにできます。 WCS1
rcuDatabaseURL データベースURL。 oracle-db.wcsitesdb-ns.svc.cluster.local:1521/devpdb.k8s
rcuCredentialsSecret 指定するロードバランサ・ホスト名。 wcsites-rcu-credentials
loadBalancerHostName K8S環境外でアクセス可能な最後のURLのホスト名。 abc.def.com
loadBalancerPortNumber K8S環境外でアクセス可能な最後のURLのポート。 30305
loadBalancerProtocol K8S環境外でアクセス可能な最後のURLのプロトコル。 http
loadBalancerType 使用されるロードバランサ名。例: Traefikまたは“” traefik
unicastPort アプリケーションが使用するユニキャスト・ポートの開始範囲。 50000
sitesSamples デフォルトでサンプル・サイトなしでインストールするサイト。それ以外の場合はtrue。 false
adminAdministrationPort 管理サーバーの管理ポート番号。 9002
adminServerSSLPort 管理サーバーのSSLポート番号。 7002
sslEnabled trueを選択してSSLを有効にします。secureEnabledがtrueに設定されている場合、sslEnabledはデフォルトでtrueに設定されます。 false
managedServerSSLPort 各WCS管理対象サーバーのSSLポート番号。 7104
managedServerAdministrationPort 管理対象サーバーの管理ポート番号。 9111
secureEnabled ドメインでセキュアが有効かどうかを示すブール。この値は、14.1.2.0.0でのみ意味を持ちます。この値は、開発モード(つまり、productionModeEnabledがfalseの場合)では意味がありません。 false

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

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

WebCenter Sitesドメインの作成

  1. create-domain.shスクリプトの構文の理解:

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

    このスクリプトは次の機能を実行します:

    • このドメイン用に生成されたKubernetes YAMLファイルのディレクトリ(まだ存在しない場合)を作成します。パス名は/<path to output-directory>/weblogic-domains/<domainUID>です。ディレクトリがすでに存在する場合は、このスクリプトを使用する前にその内容を削除します。

    • ユーティリティWebCenter Sitesコンテナを起動し、オフラインWLSTスクリプトを実行して共有ストレージにドメインを作成するKubernetesジョブを作成します。

    • ジョブが終了するまで実行して待機します。

    • 前述で作成したディレクトリにKubernetesドメインYAMLファイルdomain.yamlを作成します。このYAMLファイルは、kubectl create -fまたはkubectl apply -fコマンドを使用してKubernetesリソースを作成するために使用できます:

      $ kubectl apply -f ../<path to output-directory>/weblogic-domains/<domainUID>/domain.yaml

    • 作成スクリプトによって作成されたドメイン・ホームをクリーン・アップするための便利なユーティリティ・スクリプトdelete-domain-job.yamlを作成します。

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

    bash-4.2$ rm -rf kubernetes/create-wcsites-domain/output/weblogic-domains

bash-4.2$ sh kubernetes/create-wcsites-domain/domain-home-on-pv/create-domain.sh \
    -i kubernetes/create-wcsites-domain/domain-home-on-pv/create-domain-inputs.yaml \
    -o kubernetes/create-wcsites-domain/output

Input parameters being used
export version="create-weblogic-sample-domain-inputs-v1"
export sslEnabled="false"
export adminPort="7001"
export adminServerSSLPort="7002"
export adminAdministrationPort="9002"
export adminServerName="adminserver"
export domainUID="wcsitesinfra"
export domainHome="/u01/oracle/user_projects/domains/$domainUID"
export serverStartPolicy="IfNeeded"
export clusterName="wcsites-cluster"
export configuredManagedServerCount="3"
export initialManagedServerReplicas="1"
export managedServerNameBase="wcsites-server"
export managedServerPort="7103"
export managedServerSSLPort="7104"
export managedServerAdministrationPort="9111"
export image="oracle/wcsites:14.1.2.0.0"
export imagePullPolicy="IfNotPresent"
export productionModeEnabled="true"
export secureEnabled="false"
export weblogicCredentialsSecretName="wcsitesinfra-domain-credentials"
export includeServerOutInPodLog="true"
export logHome="/u01/oracle/user_projects/logs/$domainUID"
export t3ChannelPort="30012"
export exposeAdminT3Channel="false"
export adminNodePort="30701"
export exposeAdminNodePort="false"
export namespace="wcsites-ns"
javaOptions=-Dweblogic.StdoutDebugEnabled=false
export persistentVolumeClaimName="wcsitesinfra-domain-pvc"
export domainPVMountPath="/u01/oracle/user_projects"
export createDomainScriptsMountPath="/u01/weblogic"
export createDomainScriptName="create-domain-job.sh"
export createDomainFilesDir="wlst"
export serverPodMemoryRequest="4G"
export serverPodCpuRequest="2000m"
export serverPodMemoryLimit="4G"
export serverPodCpuLimit="2000m"
export rcuSchemaPrefix="wcsk8s1"
export rcuDatabaseURL="shivaoke-3.subnet1bom1.devcec02bom.oraclevcn.com:1521/orcl.subnet1bom1.devcec02bom.oraclevcn.com"
export rcuCredentialsSecret="wcsitesinfra-rcu-credentials"
export loadBalancerHostName="cjuyal-1.subnet1bom1.devcec02bom.oraclevcn.com"
export loadBalancerPortNumber="30305"
export loadBalancerProtocol="http"
export loadBalancerType="traefik"
export unicastPort="50000"
export sitesSamples="false"

validateWlsDomainName called with wcsitesinfra
createFiles - valuesInputFile is create-wcsites-domain/domain-home-on-pv/create-domain-inputs.yaml
createDomainScriptName is create-domain-job.sh
Generating create-wcsites-domain/output//weblogic-domains/wcsitesinfra/create-domain-job.yaml
Generating create-wcsites-domain/output//weblogic-domains/wcsitesinfra/delete-domain-job.yaml
Generating create-wcsites-domain/output//weblogic-domains/wcsitesinfra/domain.yaml
Checking to see if the secret wcsitesinfra-domain-credentials exists in namespace wcsites-ns
configmap "wcsitesinfra-create-fmw-infra-sample-domain-job-cm" deleted
configmap/wcsitesinfra-create-fmw-infra-sample-domain-job-cm created
Checking the configmap wcsitesinfra-create-fmw-infra-sample-domain-job-cm was created
configmap/wcsitesinfra-create-fmw-infra-sample-domain-job-cm labeled
Checking if object type job with name wcsitesinfra-create-fmw-infra-sample-domain-job exists
No resources found in wcsites-ns namespace.
$loadBalancerType is NOT empty
Creating the domain by creating the job create-wcsites-domain/output//weblogic-domains/wcsitesinfra/create-domain-job.yaml
job.batch/wcsitesinfra-create-fmw-infra-sample-domain-job created
Waiting for the job to complete...
status on iteration 1 of 20
pod wcsitesinfra-create-fmw-infra-sample-domain-job-6x8cg status is Running
status on iteration 2 of 20
pod wcsitesinfra-create-fmw-infra-sample-domain-job-6x8cg status is Running
status on iteration 3 of 20
pod wcsitesinfra-create-fmw-infra-sample-domain-job-6x8cg status is Running
status on iteration 4 of 20
pod wcsitesinfra-create-fmw-infra-sample-domain-job-6x8cg status is Completed

Domain wcsitesinfra was created and will be started by the WebLogic Kubernetes Operator

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

Completed

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

    $ kubectl get pods -n wcsites-ns |grep wcsitesinfra-create

wcsitesinfra-create-fmw-infra-sample-domain-job-6x8cg   0/1     Completed   0          6m48s
    $ kubectl get pods -n wcsites-ns | grep wcsitesinfra-create | awk '{print $1}' | xargs kubectl -n wcsites-ns logs -f

    サンプル出力:

    The domain will be created using the script /u01/weblogic/createSitesDomain.sh
Install Automation -> Starting automation script
    [mkdir] Created dir: /u01/wcs-wls-docker-install/work
     [echo] [10/7/24, 12:48 PM] Work Directory=/u01/wcs-wls-docker-install/work
     [echo] [10/7/24, 12:48 PM] DB URL: jdbc:oracle:thin:@
     [echo] [10/7/24, 12:48 PM] Info -> The script.db.connectstring has been set.
     [echo] [10/7/24, 12:48 PM] Info.setDBConnectStringPropertey -> setting shivaoke-3.subnet1bom1.devcec02bom.oraclevcn.com:1521/orcl.subnet1bom1.devcec02bom.oraclevcn.com
     [echo] [10/7/24, 12:48 PM] Validation -> Checking if full path to JAVA executable is correctly specified
     [exec] java version "17.0.12" 2024-07-16 LTS
     [exec] Java(TM) SE Runtime Environment (build 17.0.12+8-LTS-286)
     [exec] Java HotSpot(TM) 64-Bit Server VM (build 17.0.12+8-LTS-286, mixed mode, sharing)
     [echo] [10/7/24, 12:48 PM] Validation -> Checking database connection
     [echo] [10/7/24, 12:48 PM] dbUrl-----------------: jdbc:oracle:thin:@shivaoke-3.subnet1bom1.devcec02bom.oraclevcn.com:1521/orcl.subnet1bom1.devcec02bom.oraclevcn.com
     [echo] [10/7/24, 12:48 PM] Database Connection --> Success!
     [echo] [10/7/24, 12:48 PM] 1st phase: WebCenter Sites installation started...
     [copy] Copying 1 file to /u01/wcs-wls-docker-install/work
     [copy] Copying /u01/wcs-wls-docker-install/rcu.rsp to /u01/wcs-wls-docker-install/work/rcu.rsp
     [echo] [10/7/24, 12:48 PM] 1st phase: WebCenter Sites installation completed
     [echo] [10/7/24, 12:48 PM] 2nd phase: WebCenter Sites RCU configuration started...
     [echo] [10/7/24, 12:48 PM] Installation -> Repository Creation Utility - creates schema
     [echo] [10/7/24, 12:48 PM] connectString-----------------: shivaoke-3.subnet1bom1.devcec02bom.oraclevcn.com:1521/orcl.subnet1bom1.devcec02bom.oraclevcn.com
  [replace] Replaced 1 occurrences in 1 files.
  [replace] Replaced 1 occurrences in 1 files.
  [replace] Replaced 1 occurrences in 1 files.
  [replace] Replaced 1 occurrences in 1 files.
  [replace] Replaced 1 occurrences in 1 files.
     [echo] [10/7/24, 12:48 PM] Create schema using command: /u01/oracle/oracle_common/bin/rcu -silent -responseFile /u01/wcs-wls-docker-install/work/rcu.rsp -f < /u01/wcs-wls-docker-install/work/rcuPasswords10710756107204523639.txt >/u01/wcs-wls-docker-install/work/rcu_output.log
     [echo] [10/7/24, 12:48 PM] RCU Create Schema -> Please wait ... may take several minutes
     [echo] [10/7/24, 12:49 PM]
     [echo]     RCU Logfile: /u01/wcs-wls-docker-install/work/rcu/RCU2024-10-07_12-48_1569219683/logs/rcu.log
     [echo] Processing command line ....
     [echo] Repository Creation Utility - Checking Prerequisites
     [echo] Checking Global Prerequisites
     [echo] Repository Creation Utility - Checking Prerequisites
     [echo] Checking Component Prerequisites
     [echo] Repository Creation Utility - Creating Tablespaces
     [echo] Validating and Creating Tablespaces
     [echo] Create tablespaces in the repository database
     [echo] Repository Creation Utility - Create
     [echo] Repository Create in progress.
     [echo]         Percent Complete: 16
     [echo] Executing pre create operations
     [echo]         Percent Complete: 33
     [echo]         Percent Complete: 33
     [echo]         Percent Complete: 35
     [echo]         Percent Complete: 37
     [echo]         Percent Complete: 39
     [echo]         Percent Complete: 39
     [echo]         Percent Complete: 39
     [echo] Creating Common Infrastructure Services(STB)
     [echo]         Percent Complete: 48
     [echo]         Percent Complete: 48
     [echo]         Percent Complete: 58
     [echo]         Percent Complete: 58
     [echo]         Percent Complete: 58
     [echo] Creating Audit Services Append(IAU_APPEND)
     [echo]         Percent Complete: 66
     [echo]         Percent Complete: 66
     [echo]         Percent Complete: 76
     [echo]         Percent Complete: 76
     [echo]         Percent Complete: 76
     [echo] Creating Audit Services Viewer(IAU_VIEWER)
     [echo]         Percent Complete: 84
     [echo]         Percent Complete: 84
     [echo]         Percent Complete: 84
     [echo]         Percent Complete: 85
     [echo]         Percent Complete: 85
     [echo]         Percent Complete: 85
     [echo]         Percent Complete: 86
     [echo]         Percent Complete: 86
     [echo]         Percent Complete: 86
     [echo]         Percent Complete: 87
     [echo]         Percent Complete: 88
     [echo]         Percent Complete: 88
     [echo]         Percent Complete: 88
     [echo] Creating Weblogic Services(WLS)
     [echo]         Percent Complete: 93
     [echo]         Percent Complete: 93
     [echo]         Percent Complete: 97
     [echo]         Percent Complete: 97
     [echo]         Percent Complete: 100
     [echo] Creating Audit Services(IAU)
     [echo] Creating Oracle Platform Security Services(OPSS)
     [echo] Creating WebCenter Sites(WCSITES)
     [echo] Executing post create operations
     [echo] Repository Creation Utility: Create - Completion Summary
     [echo] Database details:
     [echo] -----------------------------
     [echo] Host Name                                    : shivaoke-3.subnet1bom1.devcec02bom.oraclevcn.com
     [echo] Port                                         : 1521
     [echo] Service Name                                 : ORCL.SUBNET1BOM1.DEVCEC02BOM.ORACLEVCN.COM
     [echo] Connected As                                 : sys
     [echo] Prefix for (prefixable) Schema Owners        : WCSK8S1
     [echo] RCU Logfile                                  : /u01/wcs-wls-docker-install/work/rcu/RCU2024-10-07_12-48_1569219683/logs/rcu.log
     [echo] Component schemas created:
     [echo] -----------------------------
     [echo] Component                                    Status         Logfile
     [echo] Common Infrastructure Services               Success        /u01/wcs-wls-docker-install/work/rcu/RCU2024-10-07_12-48_1569219683/logs/stb.log
     [echo] Oracle Platform Security Services            Success        /u01/wcs-wls-docker-install/work/rcu/RCU2024-10-07_12-48_1569219683/logs/opss.log
     [echo] WebCenter Sites                              Success        /u01/wcs-wls-docker-install/work/rcu/RCU2024-10-07_12-48_1569219683/logs/wcsites.log
     [echo] Audit Services                               Success        /u01/wcs-wls-docker-install/work/rcu/RCU2024-10-07_12-48_1569219683/logs/iau.log
     [echo] Audit Services Append                        Success        /u01/wcs-wls-docker-install/work/rcu/RCU2024-10-07_12-48_1569219683/logs/iau_append.log
     [echo] Audit Services Viewer                        Success        /u01/wcs-wls-docker-install/work/rcu/RCU2024-10-07_12-48_1569219683/logs/iau_viewer.log
     [echo] WebLogic Services                            Success        /u01/wcs-wls-docker-install/work/rcu/RCU2024-10-07_12-48_1569219683/logs/wls.log
     [echo] Repository Creation Utility - Create : Operation Completed
     [echo] [10/7/24, 12:49 PM] Successfully created schemas
     [echo] [10/7/24, 12:49 PM] 2nd phase: WebCenter Sites RCU configuration completed successfully.
     [echo] [10/7/24, 12:49 PM] Oracle WebCenter Sites Installation complete. You can connect to the WebCenter Sites instance at http://10.244.1.228:7002/sites/

Sites RCU Phase completed successfull!!!

Sites Installation completed in 47 seconds.
---------------------------------------------------------

The domain will be created using the script /u01/weblogic/create-domain-script.sh
wlst.sh -skipWLSModuleScanning /u01/weblogic/createSitesDomain.py -oh /u01/oracle -jh /u01/jdk -parent /u01/oracle/user_projects/domains/wcsitesinfra/.. -name wcsitesinfra -user weblogic -password Welcome1 -rcuDb shivaoke-3.subnet1bom1.devcec02bom.oraclevcn.com:1521/orcl.subnet1bom1.devcec02bom.oraclevcn.com -rcuPrefix wcsk8s1 -rcuSchemaPwd Welcome1 -adminListenPort 7001 -adminName adminserver -managedNameBase wcsites-server -managedServerPort 7103 -prodMode true -secureMode false -managedServerCount 3 -clusterName wcsites-cluster -exposeAdminT3Channel false -t3ChannelPublicAddress 100.69.176.148 -t3ChannelPort 30012 -sslEnabled false -adminServerSSLPort 7002 -managedServerSSLPort 7104 -domainType wcsites -adminAdministrationPort 9002 -managedServerAdministrationPort 9111 -machineName wcsites_machine

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

Creating Admin Server...
Creating cluster...
Creating Node Managers...
managed server name is wcsites-server1
managed server name is wcsites-server2
managed server name is wcsites-server3
['wcsites-server1', 'wcsites-server2', 'wcsites-server3']
Will create Base domain at /u01/oracle/user_projects/domains/wcsitesinfra
Writing base domain...
Base domain created at /u01/oracle/user_projects/domains/wcsitesinfra
Extending domain at /u01/oracle/user_projects/domains/wcsitesinfra
Database  shivaoke-3.subnet1bom1.devcec02bom.oraclevcn.com:1521/orcl.subnet1bom1.devcec02bom.oraclevcn.com
ExposeAdminT3Channel false with 100.69.176.148:30012
Applying JRF templates...
Extension Templates added
Applying WCSITES templates...
Extension Templates added
INFO: deleting wcsites_server1
INFO: deleted wcsites_server1
Configuring the Service Table DataSource...
fmwDb...jdbc:oracle:thin:@shivaoke-3.subnet1bom1.devcec02bom.oraclevcn.com:1521/orcl.subnet1bom1.devcec02bom.oraclevcn.com
Set user...wcsk8s1_OPSS
Set user...wcsk8s1_IAU_APPEND
Set user...wcsk8s1_IAU_VIEWER
Set user...wcsk8s1_STB
Set user...wcsk8s1_WCSITES
Getting Database Defaults...
Targeting Server Groups...
Targeting Server Groups...
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcsites-server1
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcsites-server2
Set CoherenceClusterSystemResource to defaultCoherenceCluster for server:wcsites-server3
Targeting Cluster ...
Set CoherenceClusterSystemResource to defaultCoherenceCluster for cluster:wcsites-cluster
Set WLS clusters as target of defaultCoherenceCluster:[wcsites-cluster]
Preparing to update domain...
Oct 07, 2024 12:50:27 PM oracle.security.jps.az.internal.runtime.policy.AbstractPolicyImpl initializeReadStore
INFO: Property for read store in parallel: oracle.security.jps.az.runtime.readstore.threads = null
Domain updated successfully
Copying /u01/weblogic/server-config-update.sh to PV /u01/oracle/user_projects/domains/wcsitesinfra
Copying /u01/weblogic/unicast.py to PV /u01/oracle/user_projects/domains/wcsitesinfra
replacing tokens in /u01/oracle/user_projects/domains/wcsitesinfra/server-config-update.sh
Successfully Completed

WebCenter Sitesドメインの初期化

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

```bash
$ kubectl apply -f kubernetes/create-wcsites-domain/output/weblogic-domains/wcsitesinfra/domain.yaml
domain.weblogic.oracle/wcsitesinfra created
cluster.weblogic.oracle/wcsitesinfra-wcsites-cluster created
```

WebCenter Sitesドメインの検証

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

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

-bash-4.2$ kubectl get pods -n wcsites-ns -w
NAME                                                    READY   STATUS      RESTARTS   AGE
wcsitesinfra-create-fmw-infra-sample-domain-job-6x8cg   0/1     Completed   0          12m
wcsitesinfra-introspector-s56gz                         1/1     Running     0          20s
wcsitesinfra-introspector-s56gz                         0/1     Completed   0          51s
wcsitesinfra-introspector-s56gz                         0/1     Completed   0          53s
wcsitesinfra-introspector-s56gz                         0/1     Terminating   0          54s
wcsitesinfra-adminserver                                0/1     Pending       0          0s
wcsitesinfra-adminserver                                0/1     Pending       0          0s
wcsitesinfra-adminserver                                0/1     Init:0/1      0          0s
wcsitesinfra-adminserver                                0/1     Init:0/1      0          2s
wcsitesinfra-adminserver                                0/1     PodInitializing   0          12s
wcsitesinfra-adminserver                                0/1     Running           0          13s
wcsitesinfra-adminserver                                0/1     Running           1 (0s ago)   87s
wcsitesinfra-adminserver                                1/1     Running           1 (3m4s ago)   4m31s
wcsitesinfra-wcsites-server1                            0/1     Pending           0              0s
wcsitesinfra-wcsites-server1                            0/1     Pending           0              0s
wcsitesinfra-wcsites-server1                            0/1     Init:0/1          0              0s
wcsitesinfra-wcsites-server1                            0/1     Init:0/1          0              1s
wcsitesinfra-wcsites-server1                            0/1     PodInitializing   0              12s
wcsitesinfra-wcsites-server1                            0/1     Running           0              13s
wcsitesinfra-wcsites-server1                            0/1     Running           1 (1s ago)     87s
wcsitesinfra-wcsites-server1                            1/1     Running           1 (4m19s ago)   5m45s
-bash-4.2$ kubectl get all -n wcsites-ns
NAME                                                        READY   STATUS      RESTARTS        AGE
pod/wcsitesinfra-adminserver                                1/1     Running     1 (11m ago)     13m
pod/wcsitesinfra-create-fmw-infra-sample-domain-job-6x8cg   0/1     Completed   0               25m
pod/wcsitesinfra-wcsites-server1                            1/1     Running     1 (7m10s ago)   8m36s

NAME                                           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
service/wcsitesinfra-adminserver               ClusterIP   None          <none>        7001/TCP   13m
service/wcsitesinfra-cluster-wcsites-cluster   ClusterIP   10.96.46.39   <none>        7103/TCP   8m36s
service/wcsitesinfra-wcsites-server1           ClusterIP   None          <none>        7103/TCP   8m36s

NAME                                                        COMPLETIONS   DURATION   AGE
job.batch/wcsitesinfra-create-fmw-infra-sample-domain-job   1/1           2m2s       25m

NAME                                  AGE
domain.weblogic.oracle/wcsitesinfra   14m

NAME                                                   AGE
cluster.weblogic.oracle/wcsitesinfra-wcsites-cluster   14m

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

$ kubectl logs -f wcsitesinfra-adminserver -n wcsites-ns
$ kubectl exec -it wcsitesinfra-adminserver  -n wcsites-ns -- /bin/bash
$ kubectl logs -f wcsitesinfra-wcsites-server1 -n wcsites-ns
$ kubectl exec -it wcsitesinfra-wcsites-server1  -n wcsites-ns -- /bin/bash
ポッドの検証

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

$ kubectl get pods -n NAMESPACE

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

-bash-4.2$ kubectl get pods -n wcsites-ns
NAME                                                    READY   STATUS      RESTARTS        AGE
wcsitesinfra-adminserver                                1/1     Running     1 (12m ago)     13m
wcsitesinfra-create-fmw-infra-sample-domain-job-6x8cg   0/1     Completed   0               26m
wcsitesinfra-wcsites-server1                            1/1     Running     1 (7m50s ago)   9m16s
サービスの検証

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

$ kubectl get services -n NAMESPACE

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

-bash-4.2$ kubectl get services -n wcsites-ns
NAME                                                    READY   STATUS      RESTARTS   AGE
wcsitesinfra-adminserver                                1/1     Running     0          7m38s
wcsitesinfra-create-fmw-infra-sample-domain-job-6l7zh   0/1     Completed   0          23m
wcsitesinfra-wcsites-server1                            1/1     Running     0          5m50s

WebCenter Sitesサービスの公開

次に、すべてのWebCenter Sites管理対象サーバーに必要なサービスを公開するためのデフォルト値を示します。いずれかの値が変更された場合はリセットします。

kubernetes/create-wcsites-domain/utils/wcs-services.yamlの詳細:

次のコマンドを実行してサービスを公開します: (ドメインが3台を超える管理対象サーバー用に構成されている場合は、追加のサーバー用にサービスyamlを追加します。)

$ kubectl apply -f kubernetes/create-wcsites-domain/utils/wcs-services.yaml
service/wcsitesinfra-wcsites-server1-np created
service/wcsitesinfra-wcsites-server1-svc created
service/wcsitesinfra-wcsites-server2-svc created
service/wcsitesinfra-wcsites-server3-svc created

作成されたサービスを検証するには、このコマンドの出力例を次に示します:

-bash-4.2$ kubectl get services -n wcsites-ns
NAME                                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                                               AGE
wcsitesinfra-adminserver               ClusterIP   None            <none>        7001/TCP                                                                                              14m
wcsitesinfra-cluster-wcsites-cluster   ClusterIP   10.96.46.39     <none>        7103/TCP                                                                                              10m
wcsitesinfra-wcsites-server1           ClusterIP   None            <none>        7103/TCP                                                                                              10m
wcsitesinfra-wcsites-server1-np        NodePort    10.96.201.245   <none>        7103:30966/TCP                                                                                        18s
wcsitesinfra-wcsites-server1-svc       ClusterIP   None            <none>        50000/TCP,50001/TCP,50002/TCP,50003/TCP,50004/TCP,50005/TCP,50006/TCP,50007/TCP,50008/TCP,50009/TCP   18s
wcsitesinfra-wcsites-server2-svc       ClusterIP   None            <none>        50000/TCP,50001/TCP,50002/TCP,50003/TCP,50004/TCP,50005/TCP,50006/TCP,50007/TCP,50008/TCP,50009/TCP   18s
wcsitesinfra-wcsites-server3-svc       ClusterIP   None            <none>        50000/TCP,50001/TCP,50002/TCP,50003/TCP,50004/TCP,50005/TCP,50006/TCP,50007/TCP,50008/TCP,50009/TCP   18s

イングレス・コントローラまたはWebサーバーを使用したロード・バランス

Kubernetesクラスタで実行されているWebLogicドメインのロード・バランサ・プロバイダを選択できます。サポートされている各ロード・バランサの現在の機能および設定手順の詳細は、WebLogic Kubernetes Operatorロード・バランサのサンプルを参照してください。

K8SでWebCenter Sitesドメインを設定するためのロードバランサの設定方法の詳細は、次を参照してください:

Traefikの場合、K8SでのWebCenter SitesドメインのロードバランサTraefikの設定を参照してください

Nginxの場合、K8SでのWebCenter SitesドメインのロードバランサNginxの設定を参照してください

Apache webtierの場合、K8SでのWebCenter SitesドメインのロードバランサApache Webtierの設定を参照してください

WebCenter Sitesの構成

  1. URL http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-PORT}/sites/sitesconfigsetupを押してWebCenter Sitesを構成します

    インストール時に、インストールするサンプル・サイトを選択し、必要なパスワードを入力します。sites-configの場所は変更しないでください。場所を変更すると、インストールは失敗します。

  2. 構成が完了した後、ドメインを編集し、管理対象サーバーを再起動します。

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

    $ kubectl patch cluster wcsitesinfra-wcsites-cluster -n wcsites-ns --type=merge -p '{"spec":{"replicas":0}}'

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

    $ kubectl patch cluster wcsitesinfra-wcsites-cluster -n wcsites-ns --type=merge -p '{"spec":{"replicas":3}}'

  3. 管理対象サーバー・ポッドが強制終了されるまで待機してから再起動します。次のコマンドを使用してモニターします:

    -bash-4.2$ kubectl get pods -n wcsites-ns -w
NAME                                                    READY   STATUS      RESTARTS   AGE
wcsitesinfra-adminserver                                1/1     Running     0          111m
wcsitesinfra-create-fmw-infra-sample-domain-job-6x8cg   0/1     Completed   0          126m
wcsitesinfra-wcsites-server1                            1/1     Running     0          3m7s
wcsitesinfra-wcsites-server2                            1/1     Running     0          3m7s
wcsitesinfra-wcsites-server3                            1/1     Running     0          3m7s

WebCenter Sitesプロパティ管理の設定

Traefikロード・バランサの場合: プロパティ管理ツールを使用し、cookieserver.validnamesプロパティを値JSESSIONID,stickyで更新します。

Nginxロード・バランサの場合: プロパティ管理ツールを使用し、cookieserver.validnamesプロパティを値JSESSIONID,stickyidで更新します。

WebCenter Sitesでの公開設定

公開先の構成中に、次のコマンドを実行して確認できるターゲット・クラスタのNodePort portを使用します:

(この例の公開では、ポート30155を使用する必要があります。)

    -bash-4.2$ kubectl get service/wcsitesinfra-wcsites-server1-np -n wcsites-ns
    NAME                              TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
    wcsitesinfra-wcsites-server1-np   NodePort   10.96.201.245    <none>        7103:30966/TCP   18m

カスタマイズ

顧客固有のカスタマイズ(extend.sites.webapp-lib.war)は、ドメイン・マウント・パス内のsite-homeディレクトリに配置する必要があります。

管理ガイド

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

ロード・バランサの設定

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

Traefik

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

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

  1. Traefik (イングレスベース)ロード・バランサのインストール
  2. ドメインのイングレスの作成
  3. アプリケーションURLアクセスの検証
  4. Traefikイングレスのアンインストール
  5. Traefikのアンインストール

Traefik (イングレスベース)ロード・バランサのインストール

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

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

    サンプル出力:

     "traefik" has been added to your repositories

  2. Traefikのインストール:

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

    {{%expand “サンプル出力を表示するにはここをクリックしてください。” %}}

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

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

    image:
name: traefik
pullPolicy: IfNotPresent
ingressRoute:
dashboard:
   enabled: true
   # Additional ingressRoute annotations (e.g. for kubernetes.io/ingress.class)
   annotations: {}
   # Additional ingressRoute labels (e.g. for filtering IngressRoute by custom labels)
   labels: {}
providers:
kubernetesCRD:
   enabled: true
kubernetesIngress:
   enabled: true
   # IP used for Kubernetes Ingress endpoints
ports:
traefik:
   port: 9000
   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

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

    $ kubectl get all -n traefik
NAME                           READY   STATUS    RESTARTS   AGE
pod/traefik-5fc4947cf9-fbl9r   1/1     Running   5          7d17h

NAME              TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
service/traefik   NodePort   10.100.195.70   <pending>     80:30305/TCP,443:30443/TCP   7d17h

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

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/traefik-5fc4947cf9   1         1         1       7d17h

  4. HTTPホストtraefik.example.comを使用して、URL http://<MASTERNODE-HOSTNAME>:30305からTraefikダッシュボードにアクセスします。

    $ curl -H "host: <MASTERNODE-HOSTNAME>" http://<MASTERNODE-HOSTNAME>:30305/dashboard/

    ノート: <MASTERNODE-HOSTNAME>の完全修飾ノード名を指定してください

  5. Traefikを構成して、このネームスペースで作成されたイングレスを管理します。traefikはTraefikネームスペース、wcsites-nsはドメインのネームスペースです:

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

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

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

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

  1. Oracle WebCenter Sitesドメイン・アプリケーションURLにアクセスするための適切なLOADBALANCER_HOSTNAMEを選択します。

    $ export LOADBALANCER_HOSTNAME=<LOADBALANCER_HOSTNAME>

    たとえば、マスター・ノード端末からコマンドを実行する場合、マスター・ホスト名はLOADBALANCER_HOSTNAMEです:

    $ export LOADBALANCER_HOSTNAME=$(hostname -f)

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

     $ cd ${WORKDIR}
 $ helm install wcsitesinfra-ingress  \
     charts/ingress-per-domain \
     --namespace wcsites-ns \
     --values charts/ingress-per-domain/values.yaml \
     --set "traefik.hostname=${LOADBALANCER_HOSTNAME}"

    サンプル出力:

      NAME: wcsitesinfra-ingress
  LAST DEPLOYED: Mon Jul 20 11:44:13 2024
  NAMESPACE: wcsites-ns
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None

  3. Oracle WebCenter Sitesアプリケーションへのセキュアなアクセス(SSL終端およびE2ESSL)の場合は、証明書を作成し、Kubernetesシークレットを生成します:

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

  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: wcsites-ns
spec:
  defaultCertificate:
    secretName:  wcs-tls-cert   
EOF

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

     $ cd ${WORKDIR}
 $ helm install wcsitesinfra-ingress  \
     charts/ingress-per-domain \
     --namespace wcsites-ns \
     --values charts/ingress-per-domain/values.yaml \
     --set "traefik.hostname=${LOADBALANCER_HOSTNAME}" \
     --set sslType=SSL

    サンプル出力:

      NAME: wcsitesinfra-ingress
  LAST DEPLOYED: Mon Jul 20 11:44:13 2020
  NAMESPACE: wcsites-ns
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None

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

    ノート: E2ESSL構成を使用するには、sslEnabledがtrueに設定されたOracle WebCenter Sitesドメインを作成しておく必要があります。詳細は、「Oracle WebCenter Sitesドメインの作成」を参照してください。

     $ cd ${WORKDIR}
 $ helm install wcsitesinfra-ingress  \
     charts/ingress-per-domain \
     --namespace wcsites-ns \
     --values charts/ingress-per-domain/values.yaml \
     --set sslType=E2ESSL

    サンプル出力:

     NAME: wcsitesinfra-ingress
 LAST DEPLOYED: Fri Apr  9 09:47:27 2021
 NAMESPACE: wcsites-ns
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None

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

     $ kubectl describe ingress wcsitesinfra-traefik -n wcsites-ns
 Name:             wcsitesinfra-traefik
 Labels:           app.kubernetes.io/managed-by=Helm
                   weblogic.resourceVersion=domain-v2
 Namespace:        wcsites-ns
 Address:
 Ingress Class:    <none>
 Default backend:  <default>
 Rules:
   Host                                            Path  Backends
   ----                                            ----  --------
   www.example.com
                                                   /console        wcsitesinfra-adminserver:7001 (10.244.3.138:7001)
                                                   /em             wcsitesinfra-adminserver:7001 (10.244.3.138:7001)
                                                   /wls-exporter   wcsitesinfra-adminserver:7001 (10.244.3.138:7001)
                                                   /weblogic       wcsitesinfra-adminserver:7001 (10.244.3.138:7001)
                                                   /sbconsole      wcsitesinfra-adminserver:7001 (10.244.3.138:7001)
                                                   /management     wcsitesinfra-adminserver:7001 (10.244.3.138:7001)
                                                   /testconsole    wcsitesinfra-adminserver:7001 (10.244.3.138:7001)
                                                   /sites          wcsitesinfra-cluster-wcsites-cluster:7103 (10.244.1.230:7103)
                                                   /cas            wcsitesinfra-cluster-wcsites-cluster:7103 (10.244.1.230:7103)
                                                   /wls-exporter   wcsitesinfra-cluster-wcsites-cluster:7103 (10.244.1.230:7103)
 Annotations:                                      kubernetes.io/ingress.class: traefik
                                                   meta.helm.sh/release-name: wcsitesinfra-ingress
                                                   meta.helm.sh/release-namespace: wcsites-ns
                                                   traefik.ingress.kubernetes.io/router.middlewares: wcsites-ns-custom-header@kubernetescrd
 Events:                                           <none>

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

     $ kubectl describe ingress wcsitesinfra-traefik -n wcsites-ns

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

     $ kubectl describe IngressRouteTCP wcsitesinfra-traefik -n wcsites-ns

  10. ロード・バランサが新しいイングレスを認識し、ドメイン・サーバー・ポッドへのルーティングに成功したことを確認するには、次のように、HTTP 200ステータス・コードを返すWebLogic ReadyAppフレームワークのURLにリクエストを送信できます: bash $ curl -v http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_PORT}/weblogic/ready * Trying 149.87.129.203... > GET http://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_PORT}/weblogic/ready HTTP/1.1 > User-Agent: curl/7.29.0 > Accept: */* > Proxy-Connection: Keep-Alive > host: ${LOADBALANCER_HOSTNAME} > < HTTP/1.1 200 OK < Date: Sat, 14 Mar 2020 08:35:03 GMT < Vary: Accept-Encoding < Content-Length: 0 < Proxy-Connection: Keep-Alive < * Connection #0 to host localhost left intact

アプリケーションURLアクセスの検証

NONSSL構成の場合

Traefikロードバランサを設定した後、ドメイン・アプリケーションがロードバランサ・ポート30305を介してアクセス可能であることを確認します。ロード・バランサ(Traefik port 30305)を介して、WebCenter Sitesドメイン・タイプのドメインを設定するために次のURLを使用できます:

    http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-PORT}/weblogic/ready
    http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-PORT}/console
    http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-PORT}/em
    http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-PORT}/sites/version.jsp
SSL構成の場合

Traefik (イングレスベース)ロード・バランサを設定した後、ドメイン・アプリケーションがHTTPSアクセスのSSLロード・バランサ・ポート30443を介してアクセス可能であることを確認します。タイプがwcsのOracle WebCenter SitesドメインのサンプルURLは次のとおりです:

    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/weblogic/ready
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/console
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/em
    https://${LOADBALANCER_HOSTNAME}:${LOADBALANCER_SSLPORT}/sites/version.jsp
E2ESSL構成の場合

Traefik (イングレスベース)ロード・バランサを設定した後、ドメイン・アプリケーションがHTTPSアクセスのSSLロード・バランサ・ポート30443を介してアクセス可能であることを確認します。

タイプがwcsのOracle WebCenter SitesドメインのサンプルURLは次のとおりです:

  https://admin.domain.org:${LOADBALANCER_SSLPORT}/weblogic/ready
  https://admin.domain.org:${LOADBALANCER_SSLPORT}/console
  https://admin.domain.org:${LOADBALANCER_SSLPORT}/em
  https://wcsites.domain.org:${LOADBALANCER_SSLPORT}/sites/version.jsp

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

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

$ helm delete wcsitesinfra-ingress -n wcsites-ns

Traefikのアンインストール

$ helm delete traefik -n traefik

NGINX

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

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

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

  1. 非SSLおよびSSL終端構成用のNGINXロード・バランサのインストール
  2. SSLアクセス用のシークレットの生成
  3. エンドツーエンドSSL構成用のNGINXロード・バランサのインストール
  4. イングレスを管理するためのNGINXの構成
  5. ドメイン・アプリケーションURLアクセスの検証
  6. NGINXイングレスのアンインストール
  7. NGINXのアンインストール

リポジトリ情報を取得するには、次の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 wcsites-ns \
 --set controller.service.type=NodePort \
 --set controller.admissionWebhooks.enabled=false \ 
 --set controller.service.nodePorts.http=30305 \
 ingress-nginx/ingress-nginx

SSLアクセス用のシークレットの生成

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

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

    ノート: CNの値は、このイングレスをデプロイするホストであり、シークレット名は<domainUID>-tls-certである必要があります。

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

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

     $ helm install nginx-ingress -n wcsites-ns \
       --set controller.extraArgs.default-ssl-certificate=wcsites-ns/wcs-tls-cert \
       --set controller.service.type=NodePort \
       --set controller.admissionWebhooks.enabled=false \
       --set controller.extraArgs.enable-ssl-passthrough=true  \
        ingress-nginx/ingress-nginx

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

    $ kubectl --namespace wcsites-ns get services | grep ingress-nginx-controller

    サンプル出力:

     nginx-ingress-ingress-nginx-controller   NodePort    10.106.186.235   <none>        80:30305/TCP,443:30443/TCP   19m

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

  1. Oracle WebCenter Sitesドメイン・アプリケーションURLにアクセスするための適切なLOADBALANCER_HOSTNAMEを選択します。

    $ export LOADBALANCER_HOSTNAME=<LOADBALANCER_HOSTNAME>

    たとえば、マスター・ノード端末からコマンドを実行する場合、マスター・ホスト名はLOADBALANCER_HOSTNAMEです:

    $ export LOADBALANCER_HOSTNAME=$(hostname -f)

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

     $ cd ${WORKDIR}
 $ helm install wcsitesinfra-ingress  charts/ingress-per-domain \
     --namespace wcsites-ns \
     --values charts/ingress-per-domain/values.yaml \
     --set "nginx.hostname=${LOADBALANCER_HOSTNAME}" \
     --set type=NGINX

    サンプル出力:

    NAME: wcsitesinfra-ingress
LAST DEPLOYED: Fri Jul 24 09:34:03 2020
NAMESPACE: wcsites-ns
STATUS: deployed
REVISION: 1
TEST SUITE: None

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

     $ cd ${WORKDIR}
 $ helm install wcsitesinfra-ingress  charts/ingress-per-domain \
     --namespace wcsites-ns \
     --values charts/ingress-per-domain/values.yaml \
     --set "nginx.hostname=${LOADBALANCER_HOSTNAME}" \
     --set type=NGINX --set sslType=SSL

    サンプル出力:

     NAME: wcsitesinfra-ingress
 LAST DEPLOYED: Fri Jul 24 09:34:03 2020
 NAMESPACE: wcsites-ns
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None

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

    ノート: E2ESSL構成を使用するには、sslEnabledがtrueに設定されたOracle WebCenter Sitesドメインを作成しておく必要があります。「Oracle WebCenter Sitesドメインの作成」を参照してください。

     $ cd ${WORKDIR}
 $ helm install wcsitesinfra-ingress  charts/ingress-per-domain \
     --namespace wcsites-ns \
     --values charts/ingress-per-domain/values.yaml \
     --set type=NGINX --set sslType=E2ESSL

    サンプル出力:

     NAME: wcsitesinfra-ingress
 LAST DEPLOYED: Fri Jul 24 09:34:03 2020
 NAMESPACE: wcsites-ns
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None

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

NONSSL構成
SSL構成
E2ESSL構成

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

wcsitesinfra-ingressデプロイメントをアンインストールおよび削除します:

$ helm uninstall wcsitesinfra-ingress -n wcsites-ns

NGINXのアンインストール

$ helm uninstall nginx-ingress -n wcsites-ns

Apache Webtier

この項では、Oracle WebCenter Sitesドメイン・クラスタをロード・バランシングするためのApache Webtierのインストールおよび構成方法について説明します。アプリケーションURLの非SSLおよびSSL終端アクセスに対してApache Webtierを構成できます。

これらのステップに従い、Apache WebtierをKubernetesクラスタ内のOracle WebCenter Sitesドメインのロード・バランサとして設定します:

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

Apache Webtierイメージの構築

Apache Webtier Dockerイメージを構築するには、サンプルを参照してください。

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

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

    wcsドメインの構成ファイルcustom_mod_wl_apache.confのサンプル・コンテンツ

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

 <IfModule mod_weblogic.c>
 WebLogicHost ${WEBLOGIC_HOST}
 WebLogicPort 7001
 </IfModule>

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

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

 <Location /wls-exporter>
 SetHandler weblogic-handler
 WebLogicHost wcsitesinfra-adminserver
 WebLogicPort 7001
 </Location>

 <Location /weblogic>
 SetHandler weblogic-handler
 WebLogicHost wcsitesinfra-adminserver
 WebLogicPort 7001
 </Location>

 # Directive for all application deployed on weblogic cluster with a prepath defined by LOCATION variable
 # For example, if the LOCAITON is set to '/weblogic', all applications deployed on the cluster can be accessed via 
 # http://myhost:myport/weblogic/application_end_url
 # where 'myhost' is the IP of the machine that runs the Apache webtier, and 
 #       'myport' is the port that the Apache webtier is publicly exposed to.
 # Note that LOCATION cannot be set to '/' unless this is the only Location module configured.
 <Location /sites>
 WLSRequest On
 WebLogicCluster wcsitesinfra-cluster-wcsites-cluster:7103
 PathTrim /weblogic1
 </Location>

 <Location /cas>
 WLSRequest On
 WebLogicCluster wcsitesinfra-cluster-wcsites-cluster:7103
 PathTrim /weblogic1
 </Location>

 <Location /wls-exporter>
 WLSRequest On
 WebLogicCluster wcsitesinfra-cluster-wcsites-cluster:7103
 PathTrim /weblogic1
 </Location>

  2. custom_mod_wl_apache.confの格納に使用できるPVおよびPVC (PV-claim-name)を作成します。PVまたはPVCの作成については、サンプルを参照してください。

証明書と秘密キーの準備

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

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

    ノート: WEBLOGIC_HOSTを、Apache Webtierをインストールするホスト名に置き換えます。

    証明書生成の出力

     $ls
 certgen.sh  custom_mod_wl_apache.conf  custom_mod_wl_apache.conf_orig  input.yaml  README.md
 $ sh certgen.sh
 Generating certs for WEBLOGIC_HOST
 Generating a 2048 bit RSA private key
 ........................+++
 .......................................................................+++
 unable to write 'random state'
 writing new private key to 'apache-sample.key'
 -----
 $ ls
 certgen.sh                 custom_mod_wl_apache.conf_orig                             WEBLOGIC_HOST.info
 config.txt                 input.yaml                                                 WEBLOGIC_HOST.key
 custom_mod_wl_apache.conf  WEBLOGIC_HOST.crt  README.md

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

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

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

    入力パラメータ・ファイルcharts/apache-samples/custom-sample/input.yamlを更新します。

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

     $ cat apache-samples/custom-sample/input.yaml
 # Use this to provide your own Apache webtier configuration as needed; simply define this
 # Persistence Volume which contains your own custom_mod_wl_apache.conf file.
 persistentVolumeClaimName: <pv-claim-name>

 # The VirtualHostName of the Apache HTTP server. It is used to enable custom SSL configuration.
 virtualHostName: <WEBLOGIC_HOST>

 # The customer-supplied certificate to use for Apache webtier SSL configuration.
 # The value must be a string containing a base64 encoded certificate. Run following command to get it.
 # base64 -i ${SSL_CERT_FILE} | tr -d '\n'
 customCert: <cert_data>

 # The customer-supplied private key to use for Apache webtier SSL configuration.
 # The value must be a string containing a base64 encoded key. Run following command to get it.
 # base64 -i ${SSL_KEY_FILE} | tr -d '\n'
 customKey: <key_data>

Apache Webtier Helmチャートのインストール

  1. 指定した入力パラメータを使用して、Apache Webtier Helmチャートをドメイン・ネームスペース(たとえば、wcsites-ns)にインストールします:

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

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

     $ kubectl get all -n wcsites-ns | grep apache

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

    pod/apache-webtier-apache-webtier-65f69dc6bc-zg5pj   1/1     Running     0          22h
service/apache-webtier-apache-webtier   NodePort       10.108.29.98     <none>        80:30305/TCP,4433:30443/TCP   22h
deployment.apps/apache-webtier-apache-webtier   1/1     1            1           22h
replicaset.apps/apache-webtier-apache-webtier-65f69dc6bc   1         1         1       22h

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

Apache Webtierロード・バランサの実行後、ロード・バランサ・ポート30305/30443を介してドメイン・アプリケーションにアクセス可能であることを確認します。タイプがwcsのドメインのアプリケーションURLは次のとおりです:

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

NONSSL構成
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/weblogic/ready
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/console
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/em
 http://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-Non-SSLPORT}/sites/version.jsp
SSL構成
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/weblogic/ready
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/console
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/em
https://${LOADBALANCER-HOSTNAME}:${LOADBALANCER-SSLPORT}/sites/version.jsp

Apache Webtierのアンインストール

$ helm delete apache-webtier -n wcsites-ns

ドメインのモニターおよびログの公開

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

Oracle WebCenter Sitesドメインを設定した後、次のことができます:

PrometheusおよびGrafanaを使用してOracle WebCenter Sitesインスタンスをモニター

WebLogic Monitoring Exporterを使用すると、実行中のOracle WebCenter Sitesインスタンスからランタイム情報をスクレイピングし、PrometheusおよびGrafanaを使用してモニターできます。

前提条件

このドキュメントでは、Prometheus OperatorがKubernetesクラスタにデプロイされていることを前提としています。まだデプロイされていない場合は、次のステップに従ってPrometheusオペレータをデプロイします。

kube-prometheusプロジェクトのクローン作成

$ git clone https://github.com/coreos/kube-prometheus.git

ノードのラベル付け

Kube-Prometheusでは、すべてのエクスポータ・ノードにkubernetes.io/os=linuxのラベルを付ける必要があります。ノードにラベルが付いていない場合は、次のコマンドを使用してラベル付けする必要があります:

$ kubectl label nodes --all kubernetes.io/os=linux

PrometheusおよびGrafanaリソースの作成

kube-prometheusディレクトリに変更し、次のコマンドを実行してネームスペースおよびCRDを作成します:

ノート: 各コマンドが処理されるまで1分間待機します。

$ cd kube-prometheus

$ kubectl create -f manifests/setup
$ until kubectl get servicemonitors --all-namespaces ; do date; sleep 1; echo ""; done
$ kubectl create -f manifests/

外部アクセスの提供

Grafana、PrometheusおよびAlertmanagerに外部アクセスを提供するには、次のコマンドを実行します:

$ kubectl patch svc grafana -n monitoring --type=json -p '[{"op": "replace", "path": "/spec/type", "value": "NodePort" },{"op": "replace", "path": "/spec/ports/0/nodePort", "value": 32100 }]'
$ kubectl patch svc prometheus-k8s -n monitoring --type=json -p '[{"op": "replace", "path": "/spec/type", "value": "NodePort" },{"op": "replace", "path": "/spec/ports/0/nodePort", "value": 32101 }]'
$ kubectl patch svc alertmanager-main -n monitoring --type=json -p '[{"op": "replace", "path": "/spec/type", "value": "NodePort" },{"op": "replace", "path": "/spec/ports/0/nodePort", "value": 32102 }]'

ノート:

WebLogic Monitoring Exporterの設定

WebLogic Serverメトリックを収集し、WebCenter SitesドメインをモニターするWebLogic Monitoring Exporterを設定します。

WebLogic Monitoring Exporterデプロイメント・パッケージの生成

リスニング・ポートは管理サーバーと管理対象サーバーで異なるため、2つのパッケージが必要です。管理サーバー(wls-exporter-as.war)に1つのバイナリ、および管理対象クラスタ(wls-exporter-ms.war)に1つのバイナリが必要です。必要なプロキシを設定し、スクリプトgetX.X.X.shを実行して2つのバイナリを生成します:

$ cd kubernetes/create-wcsites-domain/utils/weblogic-monitoring-exporter

$ sh get1.1.0.sh

出力:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   607    0   607    0     0    357      0 --:--:--  0:00:01 --:--:--   357
100 2016k  100 2016k    0     0   398k      0  0:00:05  0:00:05 --:--:--  797k
-------------------wls-exporter-ms start-------------------
created /tmp/ci-GNysQzP1kv
Copying completed
/tmp/ci-GNysQzP1kv /kubernetes/create-wcsites-domain/utils/weblogic-monitoring-exporter
in temp dir
  adding: WEB-INF/weblogic.xml (deflated 66%)
  adding: config.yml (deflated 63%)
wls-exporter-ms.war is ready
-------------------wls-exporter-ms end-------------------
-------------------wls-exporter-as start-------------------
Copying completed
in temp dir
  adding: WEB-INF/weblogic.xml (deflated 66%)
  adding: config.yml (deflated 52%)
wls-exporter-as.war is ready
-------------------wls-exporter-as end-------------------
zip completed
kubernetes/3.3.0/create-wcsites-domain/utils/weblogic-monitoring-exporter

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

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

$ kubectl cp wls-exporter-as.war wcsites-ns/wcsitesinfra-adminserver:/u01/oracle/user_projects/domains/wcsitesinfra/

$ kubectl cp wls-exporter-ms.war wcsites-ns/wcsitesinfra-adminserver:/u01/oracle/user_projects/domains/wcsitesinfra/

WebLogic Monitoring Exporterのデプロイ

次のステップに従って、WebLogic Serverインスタンスにパッケージをデプロイします:

  1. 管理サーバーおよび管理対象サーバーで、Oracle Enterprise Managerを使用してWebLogic Monitoring Exporter (wls-exporter-ms.war)を個別にデプロイします。

    Wme-Deploy

  2. エクスポータWARをデプロイするサーバーを選択します:

    Wme-Deploy-Target-Server

  3. アプリケーション名を設定します。管理サーバーと管理対象サーバーに別々にデプロイされている場合、アプリケーション名は異なる必要があります。両方のデプロイメントのコンテキスト・ルートがwls-exporterであることを確認します:

    ![Wme-Deploy-Contextroot](images/wme-deploy-contextroot.png ” Wme-Deploy-Contextroot”)

  4. アプリケーションのインストールおよび起動をクリックします。

  5. 次に、WebLogic Monitoring Exporterアプリケーション(wls-exporter-ms.war)をデプロイします。

  6. 変更をアクティブ化してアプリケーションを起動します。アプリケーションが起動され、ポートが公開されている場合は、このURL: http://<server:port>/wls-exporterを使用してWebLogic Monitoring Exporterコンソールにアクセスできます。

    Wme-Test-Url

  7. wls-exporter-as.warについても同じステップを繰り返します。

Prometheusオペレータの構成

Prometheusを使用すると、WebLogic Monitoring Exporterからメトリックを収集できます。Prometheusオペレータは、サービス検出を使用してターゲットを識別します。WebLogic Monitoring Exporterのエンド・ポイントをターゲットとして検出するには、サービスを指すサービス・モニターを作成する必要があります。

次のサンプル・サービス・モニター・デプロイメントYAML構成ファイルを参照してください

kubernetes/create-wcsites-domain/utils/weblogic-monitoring-exporter/wls-exporter.yaml。

wls-exporterの場合はServiceMonitor:

apiVersion: v1
kind: Secret
metadata:
  name: basic-auth
  namespace: monitoring
data:
  password: V2VsY29tZTE= # Welcome1 i.e.'WebLogic password'
  user: d2VibG9naWM= # weblogic  i.e. 'WebLogic username'
type: Opaque
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: wls-exporter-wcsitesinfra
  namespace: monitoring
  labels:
    k8s-app: wls-exporter
spec:
  namespaceSelector:
    matchNames:
    - wcsites-ns
  selector:
    matchLabels:
      weblogic.domainName: wcsitesinfra
  endpoints:
  - basicAuth:
      password:
        name: basic-auth
        key: password
      username:
        name: basic-auth
        key: user
    port: default
    relabelings:
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
    interval: 10s
    honorLabels: true
    path: /wls-exporter/metrics

wls-exporterからのメトリックのエクスポートにはbasicAuthが必要であるため、base64でエンコードされたユーザー名とパスワードを使用してKubernetes Secretが作成されます。このSecretは、ServiceMonitorデプロイメントで使用されます。

ユーザー名とパスワードに対してbase64でエンコードされた文字列を生成する場合は、エンコードされた文字列に改行文字が追加されているかどうかを確認します。この行の文字が原因で認証に失敗します。改行の文字列を回避するには、次の例を使用します:

$ echo -n "Welcome1" | base64
V2VsY29tZTE=

前述のwls-exporterのデプロイメントYAML構成では、weblogic.domainName: wcsitesinfraがspec.selector.matchLabelsのラベルとして使用されるため、サービス・モニターのすべてのサービスが選択されます。このラベルを使用しない場合は、サーバー名がspec.selector.matchLabelsの一致ラベルとして使用されている場合、サーバーごとに個別のサービス・モニターを作成する必要があります。これを行うと、Prometheusではデフォルトでwls-exporterで提供されているラベルを無視するため、構成のラベルを変更する必要があります。

デフォルトでは、Prometheusではターゲットによって提供されるすべてのラベルを格納しません。サービス・モニター・デプロイメントYAML構成では、weblogic-monitoring-exporterによって提供される特定のラベル(Grafanaダッシュボードで必要)がPrometheusに格納されるように、構成のラベル変更(spec.endpoints.relabelings)を指定する必要があります。構成YAMLファイルから次のセクションを削除しないでください:

relabelings:
  - action: labelmap
    regex: __meta_kubernetes_service_label_(.+)

WebLogicドメイン・ネームスペースにRoleBindingおよびRoleを追加

RoleBindingは、PrometheusがWebLogic Monitoring Exporterによって提供されるエンドポイントにアクセスするために必要です。KubernetesクラスタでWebLogic Serverポッドが実行されているネームスペースにRoleBindingを追加する必要があります。Prometheusオペレータ・デプロイメント・マニフェストでkube-prometheus/manifests/prometheus-roleBindingSpecificNamespaces.yamlファイルを編集し、次の例と同じようにネームスペース(wcsites-ns)にRoleBindingを追加します:

- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: prometheus-k8s
    namespace: wcsites-ns
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: prometheus-k8s
  subjects:
  - kind: ServiceAccount
    name: prometheus-k8s
    namespace: monitoring

同様に、KubernetesクラスタでWebLogic Serverポッドが実行されているネームスペースにRoleを追加します。Prometheusオペレータ・デプロイメント・マニフェストでkube-prometheus/manifests/prometheus-roleSpecificNamespaces.yamlを編集し、次の例と同じようにネームスペース(wcsites-ns)にRoleを追加します:

- apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    name: prometheus-k8s
    namespace: wcsites-ns
  rules:
  - apiGroups:
    - ""
    resources:
    - services
    - endpoints
    - pods
    verbs:
    - get
    - list
    - watch

次に、クラスタで有効にするため、RoleBindingおよびRoleにprometheus-roleBindingSpecificNamespaces.yamlおよびprometheus-roleSpecificNamespaces.yamlを適用します。

$ kubectl apply -f kube-prometheus/manifests/prometheus-roleBindingSpecificNamespaces.yaml

$ kubectl apply -f kube-prometheus/manifests/prometheus-roleSpecificNamespaces.yaml

サービス・モニターのデプロイ

サービス・モニターをデプロイするには、前述のwls-exporter.yamlデプロイメントYAMLを使用して、次のコマンドを実行します:

$ kubectl create -f kubernetes/create-wcsites-domain/utils/weblogic-monitoring-exporter/wls-exporter.yaml

Prometheusでのサービスの検出の有効化

サービス・モニターのデプロイメント後、Prometheusではwls-exporterおよびエクスポートのメトリックを検出できます。

Prometheusダッシュボードには、http://mycompany.com:32101/からアクセスできます。

Wme-Service-Discovery

Grafanaダッシュボードのデプロイ

ドメイン・メトリックを表示するには、WebLogic Monitoring Exporterで提供されているGrafanaダッシュボードをデプロイします。

Grafanaダッシュボードには、http://mycompany.com:32100/からアクセスできます。

  1. admin/adminでGrafanaダッシュボードにログインします。

  2. 「Settings」に移動し、「DataSources」、「Add Data Source」の順に選択します。

    HTTP URL: Prometheus URL http://mycompany.com:32101/

    認証: Basic認証の有効化

    Basic認証の詳細: ステップ「Prometheusオペレータの構成」で提供されるWebLogic資格証明

    Wme-GP-Add-Datasource

  3. ここからweblogic_dashboard.jsonファイルをダウンロードします。

  4. 「Add」、「Import」の順にクリックします。変更したJSONを「Paste JSON」ブロックに貼り付けてからロードします。

    Wme-GP-Import-Json

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

    Wme-GP-WLS-Dashboard

ログのElasticsearch統合

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

1. ElasticsearchをWebLogic Kubernetes Operatorに統合

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

Elasticsearch統合を有効にするには、WebLogic Kubernetes Operatorをデプロイする前にファイルkubernetes/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.6.0"                                                                                         
                                                                                                                        
# 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 Sitesログの公開

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

Logstash構成ファイルのサンプルは、kubernetes/create-wcsites-domain/utils/logstash/logstash.confにあります

$ vi kubernetes/create-wcsites-domain/utils/logstash/logstash.conf
input {
  file {
    path => "/u01/oracle/user_projects/logs/wcsitesinfra/adminserver.log"
    start_position => beginning
  }
  file {
    path => "/u01/oracle/user_projects/logs/wcsitesinfra/wcsites-server*.log"
    start_position => beginning
  }
  file {
    path => "/u01/oracle/user_projects/logs/wcsitesinfra/adminserver.out"
    start_position => beginning
  }
  file {
    path => "/u01/oracle/user_projects/logs/wcsitesinfra/wcsites-server*.out"
    start_position => beginning
  }
 file {
    path => "/u01/oracle/user_projects/domains/wcsitesinfra/servers/**/logs/sites.log"
    start_position => beginning
  }
 file {
    path => "/u01/oracle/user_projects/domains/wcsitesinfra/servers/**/logs/cas.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"]
  }
}

ここで、**はwcsitesinfraの下にあるすべてのサーバーからのすべてのsites.logおよびcas.logがLogstashにプッシュされることを意味します。

$ kubectl cp kubernetes/create-wcsites-domain/utils/logstash/logstash.conf wcsites-ns/wcsitesinfra-adminserver:/u01/oracle/user_projects/logs/logstash.conf

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

$ kubectl get pv -n wcsites-ns
NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                               STORAGECLASS                       REASON   AGE
wcsitesinfra-domain-pv   10Gi       RWX            Retain           Bound    wcsites-ns/wcsitesinfra-domain-pvc   wcsitesinfra-domain-storage-class            5d21h

Logstashデプロイメントのサンプルは、Logstashポッドのkubernetes/create-wcsites-domain/utils/logstash/logstash.yamlにあります。ドメイン・ホームのマウントされた永続ボリュームは、LogstashポッドへのWebLogic Serverログへのアクセスを提供します。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: logstash-wls
  namespace: wcsites-ns
spec:
  template: # create pods using pod definition in this template
    metadata:
      labels:
        k8s-app: logstash-wls
    spec:
      volumes:
      - name: weblogic-domain-storage-volume
        persistentVolumeClaim:
          claimName: wcsitesinfra-domain-pvc
      - name: shared-logs
        emptyDir: {}
      containers:
      - name: logstash
        image: logstash:6.6.0
        command: ["/bin/sh"]
        args: ["/usr/share/logstash/bin/logstash", "-f", "/u01/oracle/user_projects/logs/logstash.conf"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /u01/oracle/user_projects
          name: weblogic-domain-storage-volume
        - name: shared-logs
          mountPath: /shared-logs
        ports:
        - containerPort: 5044
          name: logstash

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

$ kubectl create -f kubernetes/create-wcsites-domain/utils/logstash/logstash.yaml

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

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

$ kubectl create -f kubernetes/elasticsearch-and-kibana/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.100.11.154   <none>        9200/TCP,9300/TCP   4m32s
kibana          NodePort    10.97.205.0     <none>        5601:31884/TCP      4m32s
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP             71d

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

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

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

WLS-Kibana-Dashboard

Elasticsearchへのログの公開

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

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

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

前提条件

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

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

事前組込みバイナリは、WebLogic Logging Exporterの「リリース」ページで使用できます。

ダウンロード:

これらの識別子は、このドキュメントのサンプル・コマンドで使用されます。

* `wcsites-ns`: WebCenter Sites domain namespace
* `wcsitesinfra`: `domainUID`
* `wcsitesinfra-adminserver`: Administration Server pod name

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

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

$ kubectl cp <file-to-copy> <namespace>/<Administration-Server-pod>:<domainhome>

$ kubectl cp snakeyaml-1.25.jar wcsites-ns/wcsitesinfra-adminserver:/u01/oracle/user_projects/domains/wcsitesinfra/

$ kubectl cp weblogic-logging-exporter-1.0.0.jar wcsites-ns/wcsitesinfra-adminserver:/u01/oracle/user_projects/domains/wcsitesinfra/

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

  1. WebLogicリモート・コンソールにログインし、左側のナビゲーション・ペインで「ツリーの編集」をクリックし、「環境」を展開して、「起動クラス」をクリックします。

  2. 「新規」をクリックして、新しい起動クラスを追加します。説明的な名前を選択できますが、クラス名はweblogic.logging.exporter.Startupである必要があります。

    WLE-Startup-Shutdown-Class

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

    WLE-Startup-Shutdown-Class-Targets

  4. /u01/oracle/user_projects/domains/wcsitesinfra/config/config.xmlファイルで、この更新は次の例のようになります:

        $ kubectl exec -it wcsitesinfra-adminserver -n wcsites-ns cat /u01/oracle/user_projects/domains/wcsitesinfra/config/config.xml
    <startup-class>
  <name>weblogic-logging-exporter</name>
  <target>AdminServer,wcsites_cluster</target>
  <class-name>weblogic.logging.exporter.Startup</class-name>
</startup-class>

WebLogic Server CLASSPATHの更新

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

    $  kubectl cp wcsites-ns/wcsitesinfra-adminserver:/u01/oracle/user_projects/domains/wcsitesinfra/bin/setDomainEnv.sh $PWD/setDomainEnv.sh
tar: Removing leading `/' from member names

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

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

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

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

    $ kubectl cp setDomainEnv.sh wcsites-ns/wcsitesinfra-adminserver:/u01/oracle/user_projects/domains/wcsitesinfra/bin/setDomainEnv.sh

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

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

    例:

    weblogicLoggingIndexName: wls
publishHost: elasticsearch.default.svc.cluster.local
publishPort: 9200
domainUID: wcsitesinfra
weblogicLoggingExporterEnabled: true
weblogicLoggingExporterSeverity: TRACE
weblogicLoggingExporterBulkSize: 1

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

    $ kubectl cp kubernetes/create-wcsites-domain/utils/weblogic-logging-exporter/WebLogicLoggingExporter.yaml wcsites-ns/wcsitesinfra-adminserver:/u01/oracle/user_projects/domains/wcsitesinfra/config/

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

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

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

$ kubectl patch domain wcsitesinfra -n wcsites-ns --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "Never" }]'

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

$ kubectl patch domain wcsitesinfra -n wcsites-ns --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IfNeeded" }]'

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

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

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

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

WLE-Kibana-Dashboard

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

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

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

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

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

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

前提条件

upgrade-domain-inputs.yamlの準備

kubernetes/create-wcsites-domain/domain-home-on-pv/upgrade/upgrade-domain-inputs.yamlを変更します。次にデフォルト値を示します。

# Name of the Admin Server
adminServerName: adminserver

# Unique ID identifying a domain.
# This ID must not contain an underscope ("_"), and must be lowercase and unique across all domains in a Kubernetes cluster.
domainUID: wcsitesinfra


# Number of managed servers to generate for the domain
configuredManagedServerCount: 3

#Number of managed servers running at the time of upgrade
managedServerRunning: 3

# Base string used to generate managed server names
managedServerNameBase: wcsites-server


# Oracle WebCenter Sites Docker image.
# Refer to build Oracle WebCenter Sites Docker image https://github.com/oracle/docker-images/tree/master/OracleWebCenterSites
# for details on how to obtain or create the image.
# tag image to a new tag for example: oracle/wcsites:14.1.2.0.0-XXXXXX
image: oracle/wcsites:14.1.2.0.0-XXXXXX

# Image pull policy
# Legal values are "IfNotPresent", "Always", or "Never"
imagePullPolicy: IfNotPresent

# Name of the domain namespace
namespace: wcsites-ns

アップグレード・スクリプトの実行

変更したupgrade-domain-inputs.yamlファイルを使用してアップグレード・スクリプトを実行し、スクリプトが終了するまで待機します。

$ sh kubernetes/create-wcsites-domain/domain-home-on-pv/upgrade/upgrade.sh -i upgrade-domain-inputs.yaml

増分的にロール・アウトされるポッドをモニターします。

$ kubectl get pods -n wcsites-ns -w

WebCenter Sitesパッチの構成

URL http://LOADBALANCER − HOSTNAME:{LOADBALANCER-PORT}/sites/sitespatchsetupを押してWebCenter Sitesパッチを構成します

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

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

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

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

  helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts
      --force-update
  
  helm upgrade \
  --reuse-values \
  --set version=4.2.9 \
  --namespace operator-ns \
  --wait \
  weblogic-kubernetes-operator \
  charts/weblogic-operator

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

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

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

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

前提条件

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

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

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

Oracle WebCenter Sitesドメインのデプロイに使用されるOracle WebCenter Sites Dockerイメージを作成または更新します。Oracle WebCenter Sites Dockerイメージは、WebLogic Image ToolまたはDockerfileのアプローチを使用して作成できます。

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

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

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

推奨事項:

WebLogic Image Toolの設定

WebLogic Image Toolの前提条件

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

WebLogic Image Toolの設定

WebLogic Image Toolを設定するには:

  1. 作業ディレクトリを作成して変更します。このステップでは、このディレクトリはimagetool-setup. bash $ 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 Sites Dockerイメージを作成するには、Oracle WebCenter Sitesドメイン用の追加のコンテナ・スクリプトが必要です。

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

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

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

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

イメージの作成

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

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

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

インストール・バイナリおよびパッチのサンプル・リスト: * JDK:
* jdk-21.0.3_linux-x64.tar.gzまたはjdk-17.0.12_linux-x64.tar.gz

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

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

コード・リポジトリの場所${WORKDIR}/imagetool-scriptsで使用可能な次のファイルは、イメージの作成に使用されます。

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

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

    %DOCKER_REPO%/OracleWebCenterSites/imagetool/14.1.2.0.0/

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

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

イメージの作成

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

    $ imagetool cache addInstaller --type jdk --version 17.0.12 --path <download location>/jdk-17.0.12_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 wcs --version 14.1.2.0.0 --path <download location>/fmw_14.1.2.0.0_wcsites_generic.jar

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

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

    $ imagetool cache addEntry --key <KEY-VALUE> --value <download location>/<PATCH-FILE-NAME>

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

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

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

    imagetool create 
--jdkVersion=17.0.12 
--type WCS 
--version=14.1.2.0.0 
--tag=oracle/wcsites:14.1.2.0.0 
--chown oracle:root 
--installerResponseFile <imagetool-setup-location>/OracleFMWInfrastructure/dockerfiles/14.1.2.0.0/install.file,<imagetool-setup-location>/OracleWebCenterSites/dockerfiles/14.1.2.0.0/wcs.file --additionalBuildCommands <imagetool-setup-location>/OracleWebCenterSites/imagetool/14.1.2.0.0/additionalBuildCmds.txt 
--additionalBuildFiles <imagetool-setup-location>/OracleWebCenterSites/dockerfiles/14.1.2.0.0/sites-container-scripts,<imagetool-setup-location>/OracleWebCenterSites/dockerfiles/14.1.2.0.0/wcs-wls-docker-install

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

  5. wcs-wls-docker-installインストーラjarの作成

    cd <imagetool-setup-location>/OracleWebCenterSites/dockerfiles/14.1.2.0.0/wcs-wls-docker-install
docker run --rm -u root -v ${PWD}:/wcs-wls-docker-install groovy:4.0.4-jdk17 /wcs-wls-docker-install/packagejar.sh

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

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

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

    ########## BEGIN DOCKERFILE ##########
#
# 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
#
#
FROM oraclelinux:7-slim as OS_UPDATE
LABEL com.oracle.weblogic.imagetool.buildid="3b37c045-11c6-4eb8-b69c-f42256c1e082"
USER root

RUN yum -y --downloaddir= install gzip tar unzip libaio \
 && yum -y --downloaddir= clean all \
 && rm -rf /var/cache/yum/* \
 && rm -rf 

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

# Install Java
FROM OS_UPDATE as JDK_BUILD
LABEL com.oracle.weblogic.imagetool.buildid="3b37c045-11c6-4eb8-b69c-f42256c1e082"

ENV JAVA_HOME=/u01/jdk

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

USER oracle


RUN tar xzf /tmp/imagetool/jdk-8u291-linux-x64.tar.gz -C /u01 \
 && mv /u01/jdk* /u01/jdk \
 && rm -rf /tmp/imagetool


# Install Middleware
FROM OS_UPDATE as WLS_BUILD
LABEL com.oracle.weblogic.imagetool.buildid="3b37c045-11c6-4eb8-b69c-f42256c1e082"

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.jar install.file /tmp/imagetool/
COPY --chown=oracle:root fmw_14.1.2.0.0_wcsites.jar wcs.file /tmp/imagetool/
COPY --chown=oracle:root oraInst.loc /u01/oracle/

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

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

USER oracle


RUN  \
 /u01/jdk/bin/java -Xmx1024m -jar /tmp/imagetool/fmw_14.1.2.0.0_infrastructure.jar -silent ORACLE_HOME=/u01/oracle \
    -responseFile /tmp/imagetool/install.file -invPtrLoc /u01/oracle/oraInst.loc -ignoreSysPrereqs -force -novalidation
RUN  \
 /u01/jdk/bin/java -Xmx1024m -jar /tmp/imagetool/fmw_14.1.2.0.0_wcsites.jar -silent ORACLE_HOME=/u01/oracle \
    -responseFile /tmp/imagetool/wcs.file -invPtrLoc /u01/oracle/oraInst.loc -ignoreSysPrereqs -force -novalidation

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

RUN /u01/oracle/OPatch/opatch napply -silent -oh /u01/oracle -phBaseDir /tmp/imagetool/patches \
 && /u01/oracle/OPatch/opatch util cleanup -silent -oh /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 \
    LC_ALL=${DEFAULT_LOCALE:-en_US.UTF-8} \
    PATH=${PATH}:/u01/jdk/bin:/u01/oracle/oracle_common/common/bin:/u01/oracle/wlserver/common/bin:/u01/oracle

LABEL com.oracle.weblogic.imagetool.buildid="3b37c045-11c6-4eb8-b69c-f42256c1e082"

    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


    USER root

    COPY --chown=oracle:root files/sites-container-scripts/overrides/oui/ /u01/oracle/wcsites/common/templates/wls/

    USER oracle

    RUN cd /u01/oracle/wcsites/common/templates/wls && \
        $JAVA_HOME/bin/jar uvf oracle.wcsites.base.template.jar startup-plan.xml file-definition.xml && \
        rm /u01/oracle/wcsites/common/templates/wls/startup-plan.xml && \
        rm /u01/oracle/wcsites/common/templates/wls/file-definition.xml

    #
    # Install the required packages
    # -----------------------------
    USER root
    ENV SITES_CONTAINER_SCRIPTS=/u01/oracle/sites-container-scripts \
        SITES_INSTALLER_PKG=wcs-wls-docker-install \
        DOMAIN_ROOT="${DOMAIN_ROOT:-/u01/oracle/user_projects/domains}" \
        ADMIN_PORT=7001 \
        WCSITES_PORT=7002 \
        ADMIN_SSL_PORT=9001 \
        WCSITES_SSL_PORT=9002 \
        PATH=$PATH:/u01/oracle/sites-container-scripts

    RUN yum install -y hostname && \
        rm -rf /var/cache/yum

    RUN mkdir -p ${SITES_CONTAINER_SCRIPTS} && \
        mkdir -p /u01/wcs-wls-docker-install 
    COPY --chown=oracle:root  files/sites-container-scripts/ ${SITES_CONTAINER_SCRIPTS}/
    COPY --chown=oracle:root  files/wcs-wls-docker-install/ /u01/wcs-wls-docker-install/

    RUN chown oracle:root -R /u01/oracle/sites-container-scripts && \
        chown oracle:root -R /u01/wcs-wls-docker-install && \
        chmod a+xr /u01/oracle/sites-container-scripts/* && \
        chmod a+xr /u01/wcs-wls-docker-install/*.sh

    # Expose all Ports
    # -------------------------------------------------------------
    EXPOSE $ADMIN_PORT $ADMIN_SSL_PORT $WCSITES_PORT $WCSITES_SSL_PORT

    USER oracle
    WORKDIR ${ORACLE_HOME}
    # Define default command to start.
    # -------------------------------------------------------------
    CMD ["/u01/oracle/sites-container-scripts/createOrStartSitesDomain.sh"]



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

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

      $ Docker images | grep wcsites

イメージの更新

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

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

    $  cd <imagetool-setup>
$ imagetool cache addEntry --key 35188131_14.1.2.0.0 --value < %path-to-downloaded-pathes%/patches/p35188131_141200_Generic.zip
[INFO] Added entry 35188131_14.1.2.0.0=< %path-to-downloaded-pathes%/patches/p35188131_122140_Generic.zip

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

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

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

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

    例

    updateコマンドの例:

        $ imagetool update --fromImage oracle/wcsites:14.1.2.0.0 --chown oracle:root --tag=oracle/wcsites:14.1.2.0.0-35188131 --patches=35188131_14.1.2.0.0 --opatchBugNumber=28186730_13.9.4.2.12

    [INFO   ] Image Tool build ID: 7c268a9a-723f-424e-a06e-cb615c783e6d
    [INFO   ] Temporary directory used for docker build context: %path-to-temp-directory%/tmpBuild/wlsimgbuilder_temp8555048225669509
    [INFO   ] Using patch 28186730_13.9.4.2.8 from cache: %path-to-downloaded-pathes%/patches/p28186730_139428_Generic.zip
    [INFO   ] OPatch will not be updated, fromImage has version 13.9.4.2.4, available version is 13.9.4.2.4
    [WARNING] skipping patch conflict check, no support credentials provided
    [WARNING] No credentials provided, skipping validation of patches
    [INFO   ] Using patch 31548912_14.1.2.0.0 from cache:  %path-to-downloaded-pathes%/patches/p31548912_122140_Generic.zip
    [INFO   ] docker cmd = docker build --no-cache --force-rm --tag oracle/wcsites:14.1.2.0.0-21.1.1 --build-arg http_proxy=http://www-proxy-your-company.com:80 --build-arg https_proxy=http://www-proxy-your-company.com:80 --build-arg no_proxy=localhost,127.0.0.0/8,/var/run/docker.sock %path-to-temp-directory%/tmpBuild/wlsimgbuilder_temp8555048225669509
    Sending build context to Docker daemon  212.7MB

    Step 1/7 : FROM oracle/wcsites:14.1.2.0.0-21.1.1 as FINAL_BUILD
    ---> 480f1a31c02b
    Step 2/7 : USER root
    ---> Running in 9d5a81ad5bde
    Removing intermediate container 9d5a81ad5bde
    ---> 71b50b0b34dc
    Step 3/7 : ENV OPATCH_NO_FUSER=true
    ---> Running in c361884e8a71
    Removing intermediate container c361884e8a71
    ---> 2951de256951
    Step 4/7 : LABEL com.oracle.weblogic.imagetool.buildid="7c268a9a-723f-424e-a06e-cb615c783e6d"
    ---> Running in e2f485ac9039
    Removing intermediate container e2f485ac9039
    ---> 970f6552ef9a
    Step 5/7 : USER oracle
    ---> Running in e3c85228af4b
    Removing intermediate container e3c85228af4b
    ---> 4401fdb4ebbe
    Step 6/7 : COPY --chown=oracle:root patches/* /tmp/imagetool/patches/
    ---> 978a48e1cc95
    Step 7/7 : RUN /u01/oracle/OPatch/opatch napply -silent -oh /u01/oracle -phBaseDir /tmp/imagetool/patches     && /u01/oracle/OPatch/opatch util cleanup -silent -oh /u01/oracle     && rm -rf /tmp/imagetool
    ---> Running in 5039320b2f10
    Oracle Interim Patch Installer version 13.9.4.2.4
    Copyright (c) 2020, Oracle Corporation.  All rights reserved.


    Oracle Home       : /u01/oracle
    Central Inventory : /u01/oracle/oraInventory
     from           : /u01/oracle/oraInst.loc
    OPatch version    : 13.9.4.2.4
    OUI version       : 13.9.4.0.0
    Log file location : /u01/oracle/cfgtoollogs/opatch/opatch2020-08-04_05-15-38AM_1.log


    OPatch detects the Middleware Home as "/u01/oracle"

    Verifying environment and performing prerequisite checks...
    OPatch continues with these patches:   31548912  

    Do you want to proceed? [y|n]
    Y (auto-answered by -silent)
    User Responded with: Y
    All checks passed.

    Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
    (Oracle Home = '/u01/oracle')


    Is the local system ready for patching? [y|n]
    Y (auto-answered by -silent)
    User Responded with: Y
    Backing up files...
    Applying interim patch '31548912' to OH '/u01/oracle'
    ApplySession: Optional component(s) [ oracle.wcsites.wccintegration, 14.1.2.0.0 ] , [ oracle.wcsites.wccintegration, 14.1.2.0.0 ]  not present in the Oracle Home or a higher version is found.

    Patching component oracle.wcsites, 14.1.2.0.0...

    Patching component oracle.wcsites, 14.1.2.0.0...

    Patching component oracle.wcsites.visitorservices, 14.1.2.0.0...

    Patching component oracle.wcsites.visitorservices, 14.1.2.0.0...

    Patching component oracle.wcsites.examples, 14.1.2.0.0...

    Patching component oracle.wcsites.examples, 14.1.2.0.0...

    Patching component oracle.wcsites.developer.tools, 14.1.2.0.0...

    Patching component oracle.wcsites.developer.tools, 14.1.2.0.0...

    Patching component oracle.wcsites.satelliteserver, 14.1.2.0.0...

    Patching component oracle.wcsites.satelliteserver, 14.1.2.0.0...

    Patching component oracle.wcsites.sitecapture, 14.1.2.0.0...

    Patching component oracle.wcsites.sitecapture, 14.1.2.0.0...
    Patch 31548912 successfully applied.
    Log file location: /u01/oracle/cfgtoollogs/opatch/opatch2020-08-04_05-15-38AM_1.log

    OPatch succeeded.
    Oracle Interim Patch Installer version 13.9.4.2.4
    Copyright (c) 2020, Oracle Corporation.  All rights reserved.


    Oracle Home       : /u01/oracle
    Central Inventory : /u01/oracle/oraInventory
     from           : /u01/oracle/oraInst.loc
    OPatch version    : 13.9.4.2.4
    OUI version       : 13.9.4.0.0
    Log file location : /u01/oracle/cfgtoollogs/opatch/opatch2020-08-04_05-16-11AM_1.log


    OPatch detects the Middleware Home as "/u01/oracle"

    Invoking utility "cleanup"
    OPatch will clean up 'restore.sh,make.txt' files and 'scratch,backup' directories.
    You will be still able to rollback patches after this cleanup.
    Do you want to proceed? [y|n]
    Y (auto-answered by -silent)
    User Responded with: Y

    Backup area for restore has been cleaned up. For a complete list of files/directories
    deleted, Please refer log file.

    OPatch succeeded.
    Removing intermediate container 5039320b2f10
    ---> 1be958e1e859
    Successfully built 1be958e1e859
    Successfully tagged oracle/wcsites:14.1.2.0.0-21.1.1-29710661
    [INFO   ] Build successful. Build time=73s. Image tag=oracle/wcsites:14.1.2.0.0-21.1.1-29710661



The example Dockerfile generated by the WebLogic Image Tool with the `–-dryRun` option:


    $ imagetool update --fromImage oracle/wcsites:14.1.2.0.0 --chown oracle:root --tag=oracle/wcsites:14.1.2.0.0-35188131 --patches=35188131_14.1.2.0.0 --opatchBugNumber=28186730_13.9.4.2.12 --dryRun

    [INFO   ] Image Tool build ID: a2fca032-7807-4bfb-b5a4-0ed90a710a56
    [INFO   ] Temporary directory used for docker build context: %path-to-temp-directory%/tmpBuild/wlsimgbuilder_temp4743247141639108603
    [INFO   ] Using patch 28186730_13.9.4.2.8 from cache: %path-to-downloaded-pathes%/patches
    /p28186730_139428_Generic.zip
    [INFO   ] OPatch will not be updated, fromImage has version 13.9.4.2.8, available version is 13.9.4.2.8
    [WARNING] skipping patch conflict check, no support credentials provided
    [WARNING] No credentials provided, skipping validation of patches
    [INFO   ] Using patch 29710661_14.1.2.0.0 from cache:  %path-to-downloaded-pathes%/patches
    /p29710661_122140_Generic.zip
    [INFO   ] docker cmd = docker build --no-cache --force-rm --tag oracle/wcsites:14.1.2.0.0 --build-arg http_proxy=http://www-proxy-your-company.com:80 --build-arg https_proxy=http://www-proxy-your-company.com:80 --build-arg no_proxy=localhost,127.0.0.0/8,/var/run/docker.sock %path-to-temp-directory%/tmpBuild/wlsimgbuilder_temp4743247141639108603
    ########## BEGIN DOCKERFILE ##########
    #
    # Copyright (c) 2019, 2020, Oracle and/or its affiliates.
    #
    # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
    #
    #

    FROM oracle/wcsites:14.1.2.0.0 as FINAL_BUILD
    USER root

    ENV OPATCH_NO_FUSER=true


    LABEL com.oracle.weblogic.imagetool.buildid="a2fca032-7807-4bfb-b5a4-0ed90a710a56"

    USER oracle


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

        RUN /u01/oracle/OPatch/opatch napply -silent -oh /u01/oracle -phBaseDir /tmp/imagetool/patches \
        && /u01/oracle/OPatch/opatch util cleanup -silent -oh /u01/oracle \
        && rm -rf /tmp/imagetool




    ########## END DOCKERFILE ##########
    [INFO   ] Dry run complete.  No image created.

  3. Docker imagesコマンドを使用して構築したイメージを確認します:

      $ Docker images | grep wcsites
  oracle/wcsites   14.1.2.0.0-35188131   2ef2a67a685b        About a minute ago   3.74GB

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

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

事前構築済のOracle Fusion Middleware Infrastructureイメージcontainer-registry.oracle.com/middleware/fmw-infrastructure:14.1.2.0.0は、container-registry.oracle.comにあります。このイメージをプルおよび名前変更して、Oracle WebCenter Sitesイメージを構築することをお薦めします。

  $ docker pull <path-to-container-registry>/fmw-infrastructure:14.1.2.0.0
  $ docker tag <path-to-container-registry>/fmw-infrastructure:14.1.2.0.0  oracle/fmw-infrastructure:14.1.2.0.0

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

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

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

  2. oracle/fmw-infrastructure:14.1.2.0.0イメージを構築します:

     $ cd docker-images/OracleFMWInfrastructure/dockerfiles
 $ sh buildDockerImage.sh -v 14.1.2.0.0 -s

    これにより、oracle/fmw-infrastructure:14.1.2.0.0という名前のイメージが生成されます。

  3. Oracle Technology Networkまたはe-deliveryからOracle WebCenter Sitesインストーラをダウンロードします。

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

  4. パッチを使用してOracle WebCenter Sitesイメージを構築するには、パッチのzipファイル(たとえば、p35188131_141200_Generic.zip)をダウンロードして、必要なバージョンのpatches/フォルダにドロップする必要があります。たとえば、14.1.2.0.0の場合、フォルダは14.1.2.0.0/patchesです。

  5. 提供されているスクリプトを実行して、Oracle WebCenter Sitesイメージを作成します:

    $ cd docker-images/OracleWebCenterSites/dockerfiles
$ ./buildDockerImage.sh -v 14.1.2.0.0 -s

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

アンインストール

Oracle WebCenter Sitesドメインの設定をクリーン・アップします。

Oracle WebCenter Sitesドメインの設定をクリーン・アップする方法を学習します。

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

ドメイン内のすべてのサーバー・ポッドを停止します。これは、ドメイン"serverStartPolicy"に"Never"のパッチを適用することで実行できます。同様のサンプル・コマンドを示します。

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

たとえば:

$ kubectl patch domain wcsitesinfra -n wcsites-ns --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "Never" }]'

公開されたサービスの削除

```bash
$ kubectl delete -f create-wcsites-domain/utils/wcs-services.yaml
```

ドメインの削除

  1. Helmを使用してドメインのイングレス(たとえば、Traefikイングレス)を削除します:

    $ helm uninstall wcsites-domain-ingress -n wcsites-namespace

    たとえば:

    $ helm uninstall wcsitesinfra-ingress -n wsites-ns

  2. ドメイン・ジョブの削除(これによりRCUスキーマが削除されます)

    $ kubectl apply -f kubernetes/create-wcsites-domain/output/weblogic-domains/wcsitesinfra/delete-domain-job.yaml

    ジョブが終了したかどうかを確認します。

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

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

    たとえば:

    $ cd ${WORKDIR}/delete-domain
$ ./delete-weblogic-domain-resources.sh -d wcsites-ns

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

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

    たとえば:

    $ kubectl get pods -n wcsites-ns
$ kubectl get domains -n wcsites-ns
$ kubectl get clusters -n wcsites-ns

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

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

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

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

    $ kubectl delete namespace sample-domain1-ns

    たとえば:

    $ kubectl delete namespace wcsites-ns

オペレータの削除

  1. オペレータの削除:

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

    たとえば:

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

  2. オペレータのネームスペースの削除:

    $ kubectl delete namespace sample-weblogic-operator-ns

    たとえば:

    $ kubectl delete namespace operator-ns

ロード・バランサの削除

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

    $ helm uninstall traefik-operator -n traefik

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

    $ kubectl delete namespace traefik

ドメイン・ホームの削除

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

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

$ rm -rf /scratch/K8SVolume/WCSites/*

Oracle Cloud Infrastructure

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

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

OKE環境の準備

OKEでのWebLogic Kubernetes Operatorが管理するWebCenter Sitesドメインの実行

概要

概要

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

Generating public/private rsa key pair.
Your identification has been saved in <path>/id_rsa.
Your public key has been saved in <path>/id_rsa.pub.
The key fingerprint is:
SHA256:xCi1gf1QFafbRwOM3WjUTgqEInwi6UklbuxbBeMzA6M demokey
The key's randomart image is:
+---[RSA 2048]----+
|  +++oo..++*++   |
| ++==+==. oo=.+  |
|Eo+o*+++o .o +o  |
| oo  * ..  o.... |
|  . .   S . . .  |
|   o         .   |
|  .              |
|                 |
|                 |
+----[SHA256]-----+

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

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

コンパートメント

仮想クラウド・ネットワークの作成

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

要塞ノードの作成

内部リソースにアクセスするための要塞ノードを設定します。

kubeconfigをダウンロードしてOKEクラスタにアクセスするためのOCI CLIの設定

$ bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"
$ 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 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.xxxxx5n3a
Enter a tenancy OCID: ocid1.tenancy.xxxxxxmffq
Enter a region (e.g. ap-mumbai-1, ap-seoul-1, ap-sydney-1, ap-tokyo-1, ca-toronto-1, eu-frankfurt-1, eu-zurich-1, sa-saopaulo-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 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: 30:b9:a6:80:6e:b7:bb:7d:f9:79:6b:84:48:30:03:16
Config written to /home/opc/.oci/config
 
 
    If you haven't already uploaded your 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

Kubeconfigへのアクセスの設定(OKEクラスタ)

Dockerのインストール
#install docker-engine
sudo yum -y install docker-engine
#Enable and start docker service
sudo systemctl enable docker
sudo systemctl start docker
#Add opc to docker group
sudo /sbin/usermod -a -G docker opc
$ docker version
Client: Docker Engine - Community
 Version:           19.03.1-ol
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        ead9442
 Built:             Wed Sep 11 06:40:28 2019
 OS/Arch:           linux/amd64
 Experimental:      false
 
Server: Docker Engine - Community
 Engine:
  Version:          19.03.1-ol
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       ead9442
  Built:            Wed Sep 11 06:38:43 2019
  OS/Arch:          linux/amd64
  Experimental:     false
  Default Registry: docker.io
 containerd:
  Version:          v1.2.0-rc.0-108-gc444666
  GitCommit:        c4446665cb9c30056f4998ed953e6d4ff22c7c39
 runc:
  Version:          spec: 1.0.1-dev
  GitCommit:
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
### Create the drop-in file /etc/systemd/system/docker.service.d/http-proxy.conf that contains proxy details:    
cat <<EOF > /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://<your-company-domain>:80"
Environment="HTTPS_PROXY=http://<your-company-domain>:80"
Environment="NO_PROXY=localhost,127.0.0.0/8,.<no-proxy-domain>,/var/run/docker.sock"
EOF
$ sudo systemctl daemon-reload  
$ sudo systemctl restart docker
$ docker info|grep -i proxy
Kubernetesパッケージのインストール
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kube*
EOF
export PATH=/sbin:$PATH
setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
VERSION=1.27.6-0
sudo yum install -y kubelet-$VERSION kubeadm-$VERSION kubectl-$VERSION --disableexcludes=kubernetes
### enable kubelet service so that it auto-restart on reboot
sudo systemctl enable --now kubelet
cat <<EOF >  /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sysctl --system
### run as a root user   
### Update --fail-swap-on=false into /etc/sysconfig/kubelet
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
Kubeconfigにアクセスするための要塞ノードの設定
$ oci -v
$ mkdir -p $HOME/.kube
$ oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.phx.xxxxxx --file $HOME/.kube/config --region us-phoenix-1 --token-version 2.0.0
$ export KUBECONFIG=$HOME/.kube/config
$ kubectl get nodes
NAME        STATUS   ROLES   AGE    VERSION
10.0.10.2   Ready    node    111m   v1.27.6
10.0.10.3   Ready    node    111m   v1.27.6
10.0.10.4   Ready    node    111m   v1.27.6

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

ファイルシステムの設定

OCIRの作成

Dockerイメージを管理するためのOCIRを設定します。

要塞ホストの準備

OKEでのWebLogic Kubernetes Operatorが管理するOracle WebCenter Sitesドメインの実行

ステップ1: パブリック・セキュリティ・リストの作成

要塞ノードのOKEクラスタと同じVCNにパブリック・セキュリティ・リスト(bastion_public_sec_list)を作成します*イングレス・ルール: (10.0.22.0/24は要塞サブネットに使用される予定のCIDRです)要塞*エグレス: 要塞

ステップ2: プライベート・セキュリティ・リストの作成

ワーカー・ノード・サブネットに追加されるOKEクラスタと同じVCNにプライベート・セキュリティ・リスト(bastion_private_sec_list)を作成します。*イングレス・ルール: (10.0.22.0/24は要塞サブネットに使用される予定のCIDR)要塞*エグレス・ルール: 要塞

ステップ3: ルート表の作成

要塞サブネットに使用される次の詳細を含むルート表(oke-bastion-routetables)を作成します要塞

ステップ4: 要塞サブネットの作成

次を使用した要塞サブネットを作成します。CIDRブロック: 10.0.22.0/24、ルート表: oke-bastion-routetables (ステップ3で作成)、セキュリティ・リスト: bastion_public_sec_list (ステップ1で作成)およびDHCPオプション: デフォルト使用可能要塞

ステップ5: 要塞アクセス用のワーカー・サブネットへのプライベート・セキュリティの追加

ステップ2で作成したプライベート・セキュリティ・リスト(bastion_private_sec_list)をワーカー・サブネットに追加して、要塞ノードをワーカー・ノードにssh接続できるようにします要塞

ステップ6: 要塞ノードの作成

サブネットが“bastion-subnet”の要塞ノードを作成し(ステップ4で作成)、プライベート・セキュリティ・リスト(bastion_private_sec_list)を追加して(ステップ2でワーカー・サブネットに作成)、要塞ノードをワーカー・ノードにSSH接続できるようにします*インスタンスの更新名、オペレーティング・システム・イメージの選択、可用性ドメインおよびインスタンス・タイプ要塞*クラスタが作成されるコンパートメント、VCNおよびサブネット・コンパートメントを選択します。ステップ4で作成したリージョナル要塞サブネットを選択します。「パブリックIPアドレスの割当て」をクリックしてください。要塞*要塞が作成されると次のように表示されます要塞

ステップ7: 要塞ホストからのワーカー・ノードへのアクセス

  1. 要塞ノードにログインします
scp -i id_rsa id_rsa opc@<bastion-host-address>:/home/opc
ssh -i id_rsa opc@<bastion-host-address>
  1. id_rsaのコピーを要塞ノードに配置してワーカー・ノードにアクセスします
ssh -i id_rsa opc@10.0.1.5

詳細は次を参照してください: https://docs.cloud.oracle.com/en-us/iaas/Content/Resources/Assets/whitepapers/bastion-hosts.pdf

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

OKEでのWebLogic Kubernetes Operatorが管理するOracle WebCenter Sitesドメインの実行

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

ノート: OKEで作成されたVCNにファイルシステムおよびセキュリティ・リストを作成していることを確認してください*OCIコンソールにログインし、ファイル・ストレージに移動して「ファイル・システム」をクリックしますファイルシステム*「ファイル・システムの作成」をクリックしますファイルシステム*デフォルト値でファイル・システムおよびマウント・ターゲットを作成できます。ただし、ファイル・システムおよびマウント・ターゲットの名前を変更する場合は、次のステップに従います。ファイルシステムノート: マウント・ターゲットの仮想クラウド・ネットワークが、インスタンスが作成され、このファイル・システムにアクセスするネットワークを参照していることを確認してください。*ファイル・システム名を"WCSFileSystem"に編集および変更しますファイルシステム*マウント・ターゲット名をWCSMountTargetに編集および変更して、選択した仮想クラウド・ネットワークが“WCSVCN”で、すべてのインスタンスが作成される仮想クラウド・ネットワークであることを確認します。パブリック・サブネットを選択します。「作成」をクリックしますファイルシステム*ファイル・システムが作成されると、次のページに移動します。“WCSFileSystem”リンクをクリックします。ファイルシステム*「マウント・コマンド」をクリックすると、このファイル・システムをインスタンスにマウントする方法の詳細が表示されます。ファイルシステム*「マウント・コマンド」ポップアップには、インスタンスからマウント・ターゲットにアクセスするためにセキュリティ・リストで構成する必要がある内容の詳細が表示されます。インスタンスで実行する必要があるマウント・コマンドを書き留めますファイルシステム*マウント・コマンドのポップアップに示されているように、次のイングレス・ルールを使用してセキュリティ・リスト"fss_security list"を作成します。ファイルシステム*マウント・コマンドのポップアップに示されているように、次のようにエグレス・ルールを作成します。ファイルシステム*次に示すように、作成されたセキュリティ・リスト"fss_security list"を各サブネットに追加してください: それ以外の場合、作成されたセキュリティ・リスト・ルールはインスタンスに適用されません。ファイルシステム ファイルシステム ファイルシステム*作成されたセキュリティ・リスト"fss_security list"がサブネットに追加されたら、インスタンスにログインし、ファイル・システムを要塞ノードにマウントします

#login as root
sudo su
 
#Install NFS Utils
yum install nfs-utils
 
#Create directory where you want the mount the file system
mkdir -p /mnt/WCSFileSystem
 
#Give proper permissions so that all users can access the share volume
chmod 777 /mnt/WCSFileSystem
 
# Alternatively you can use: "mount 10.0.0.7:/WCSFileSystem /mnt/WCSFileSystem". To persist on reboot add into /etc/fstab
echo "10.0.0.7:/WCSFileSystem /mnt/WCSFileSystem nfs nfsvers=3 0 0" >> /etc/fstab
 
mount -a
 
cd /mnt/WCSFileSystem
[root@wcsbastioninstance WCSFileSystem]# df -h .
Filesystem               Size  Used Avail Use% Mounted on
10.0.0.7:/WCSFileSystem  8.0E     0  8.0E   0% /mnt/WCSFileSystem
[root@wcsbastioninstance WCSFileSystem]#

OCIRの作成

OKEでのWebLogic Kubernetes Operatorが管理するOracle WebCenter Sitesドメインの実行

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

認証トークンの作成

OCIRログインからコンソールにイメージをプッシュ/プルするためのDockerパスワードとして使用される認証トークンを作成し、上部のナビゲーションのOCIユーザー名の下にあるドロップダウンの「ユーザー設定」に移動しますOCIR*「ユーザーの詳細」ページで、左側のナビゲーションで「認証トークン」を選択し、「トークンの生成」ボタンをクリックします: 名前を入力し、「トークンの生成」をクリックしますOCIR OCIR*トークンが生成されますOCIR*生成されたトークンをコピーします。ノート: これは一度のみ表示され、さらに使用するためには安全な場所にコピーする必要があります。ノート: これは一度のみ表示され、さらに使用するためには安全な場所にコピーする必要があります。

OCIR名の取得

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

OCIRの使用

Docker CLIを使用してOCIRにログインします(phoenixの場合: phx.ocir.io、ashburnの場合: iad.ocir.ioなど) a. docker login phx.ocir.io b.ユーザー名の入力を求められたら、OCIRリポジトリ名/ociユーザー名(axcmmdmzqtqb/oracleidentitycloudservice/myemailid@oracle.comなど)としてdockerユーザー名を入力します c. パスワードの入力を求められたら、生成された認証トークン、つまりp[3k;pYePDSTD:-(LlASを入力します

イメージにタグ付けしてOCIRにプッシュできます。

$ docker login phx.ocir.io
$ username - axcmmdmzqtqb/oracleidentitycloudservice/myemailid@oracle.com
$ password - p[3k;pYePDSTD:-(LlAS     (Token Generated for OCIR using user setting)

これは、すべてのイメージの要塞ノードで実行する必要があります。

よくある質問

この項では、KubernetesへのOracle WebCenter Sitesドメイン・デプロイメントの既知の問題について説明します。また、よくある質問に対する回答も示します。

Oracle WebCenter Sitesコンポジット・アプリケーションの外部URLアクセスの構成

Oracle WebCenter Sitesコンポジット・アプリケーションがインターネット経由で外部URLにアクセスする場合(クラスタがhttpプロキシ・サーバーの背後にある場合)、管理サーバーおよび管理対象サーバー・ポッドに対して次のプロキシ・パラメータを構成する必要があります。

-Dhttp.proxyHost=www-your-proxy.com  
-Dhttp.proxyPort=proxy-port  
-Dhttps.proxyHost=www-your-proxy.com  
-Dhttps.proxyPort=proxy-port  
-Dhttp.nonProxyHosts="localhost|wcsitesinfra-adminserver|wcsitesinfra-wcsites-server1|*.svc.cluster.local|*.your.domain.com|/var/run/docker.sock"

これを行うには、domain.yaml構成ファイルを編集し、プロキシ・パラメータをspec.serverPod.env.JAVA_OPTIONS環境変数値に追加します。

たとえば:

  serverPod:
    env:
    - name: JAVA_OPTIONS
      value: -Dweblogic.StdoutDebugEnabled=false -Dweblogic.ssl.Enabled=true -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dhttp.proxyHost=www-your-proxy.com -Dhttp.proxyPort=proxy-port -Dhttps.proxyHost=www-your-proxy.com -Dhttps.proxyPort=proxy-port -Dhttp.nonProxyHosts="localhost|wcsitesinfra-adminserver|wcsitesinfra-wcsites-server1|*.svc.cluster.local|*.your.domain.com|/var/run/docker.sock"
    - name: USER_MEM_ARGS
      value: '-Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx1024m '
    volumeMounts:

ノート: -Dhttp.nonProxyHostsパラメータには、管理サーバーおよび各管理対象サーバーのポッド名が必要です。例: wcsitesinfra-adminserver、wcsitesinfra-wcsites-server1など。

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

 $ kubectl apply -f domain.yaml

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

Oracle WebLogic Server Kubernetes OperatorのFAQ

一般的なOracle WebLogic Server Kubernetes Operatorの使用に関するよくある質問を参照してください。

付録

この項では、KubernetesでのOracle WebCenter Sitesドメイン・デプロイメントに関連するその他のタスクについて説明します。

ドメイン・リソースのサイズ設定

Kubernetesクラスタに設定されたOracle WebCenter Sitesドメインのリソースのサイズ設定について説明します。

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

Oracle WebCenter Sites 通常の使用状況 中程度の使用状況 高い使用状況
管理サーバー 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のセキュリティ・ベスト・プラクティス

オンプレミスのクイック・スタート・デプロイメント

このクイック・スタートを使用して、Oracle WebLogic Server Kubernetes OperatorでKubernetesクラスタ(オンプレミス環境)にOracle WebCenter Sitesドメイン・デプロイメントを作成します。このウォークスルーはデモンストレーションのみを目的としており、本番で使用するものではないことに注意してください。これらの手順は、Kubernetesをすでに理解していることを前提としています。詳細な手順が必要な場合は、「インストール・ガイド」を参照してください。

ハードウェア要件

オペレータを使用してOracle WebCenter Sitesドメインをデプロイおよび実行するためにサポートされているLinuxカーネルは、Oracle Linux 8およびRed Hat Enterprise Linux 8です。詳細は、「前提条件」を参照してください。

この演習で単一ノードのKubernetesクラスタを作成して、コンテナとして実行されているOracle WebCenter SitesおよびOracle Databaseの1つの管理対象サーバーでwcsitesinfraドメイン・タイプをデプロイするための、最小ハードウェア要件です

ハードウェア サイズ
RAM 32GB
ディスク領域 250GB+
CPUコア 6

Kubernetesクラスタで設定されたOracle WebCenter Sitesドメインのリソースのサイズ設定については、ここを参照してください。

オンプレミス環境でのOracle WebCenter Sitesの設定

このトピックのステップを実行して、単一インスタンスのオンプレミスKubernetesクラスタを作成し、Oracle WebCenter Sitesのwcsitesinfraドメイン・タイプを作成します。

1. Kubernetesクラスタ用の仮想マシンの準備

説明のため、これらの手順はOracle Linux 8用です。Linuxの異なるフレーバを使用している場合は、それに応じてステップを調整する必要があります。

ノート: これらのステップは、特に指定しないかぎり、rootユーザーで実行する必要があります。コマンドにYOUR_USERIDが表示されるたびに、実際のuseridに置き換える必要があります。

1.1 前提条件

  1. DockerおよびKubernetesファイルが格納されるディレクトリを選択します。Dockerディレクトリは、すべてのイメージおよびコンテナを含むDockerファイル・システムに使用されるため、多くの空き領域(100GBを超える)を持つディスク上に存在する必要があります。Kubernetesディレクトリは、/var/lib/kubeletファイル・システムおよび永続ボリューム・ストレージに使用されます。

    $ 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.eth0.forwarding'
$ /sbin/sysctl -a 2>&1|grep -s 'net.ipv4.conf.lo.forwarding'
$ /sbin/sysctl -a 2>&1|grep -s 'net.ipv4.ip_nonlocal_bind'

    例: すべてが1に設定されていることを確認します

    $ net.ipv4.conf.eth0.forwarding = 1
$ net.ipv4.conf.lo.forwarding = 1
$ net.ipv4.ip_nonlocal_bind = 1

    解決策: 次のコマンドを使用して、すべての値をすぐに1に設定します:

    $ /sbin/sysctl net.ipv4.conf.eth0.forwarding=1
$ /sbin/sysctl net.ipv4.conf.lo.forwarding=1
$ /sbin/sysctl net.ipv4.ip_nonlocal_bind=1

    再起動後の設定を保持するには: /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のインストール:

    dnf config-managerにOLCNE (Oracle Cloud Native Environment)リポジトリを追加します。これにより、dnfはCRI-Oインストールに必要な追加パッケージをインストールできます。

    Oracle Linux 8の場合:

    $ dnf config-manager --add-repo https://yum.oracle.com/repo/OracleLinux/OL8/olcne18/x86_64

    Oracle Linux 9の場合:

    $ dnf config-manager --add-repo https://yum.oracle.com/repo/OracleLinux/OL9/olcne18/x86_64

    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で実行する必要があります。

    ユーザー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/crio/crio.sock,$ip_addr,.svc
$ export no_proxy=localhost,127.0.0.0/8,ADD-YOUR-INTERNAL-NO-PROXY-LIST,/var/run/crio/crio.sock,$ip_addr,.svc
$ export http_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
$ export https_proxy=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
$ export HTTPS_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT
$ export HTTP_PROXY=http://REPLACE-WITH-YOUR-COMPANY-PROXY-HOST:PORT

### Install the kubernetes components and enable the kubelet service so that it automatically restarts on reboot
$ dnf install -y kubeadm kubelet kubectl
$ systemctl enable --now kubelet

  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
net.ipv4.ip_forward = 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.3+をインストールします。

    1. https://github.com/helm/helm/releasesからHelmをダウンロードします。Helm v3.10.3をダウンロードする例:

      $ 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クラスタの設定

ノート :

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を設定します。

    ノート: 今後は、YOUR_USERID:YOUR_GROUPを使用して、rootではなく、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

    ノート: このステップでは、ポッド・ネットワーク・アドオンがまだインストールされていないため、ノードは準備完了状態ではありません。次のステップの後、ノードのステータスは準備完了と表示されます。

  8. ポッド・ネットワーク・アドオン(flannel)をインストールして、ポッドが相互に通信できるようにします。

    ノート: 10.244.0.0/16とは異なるcidrブロックを使用している場合は、クラスタにデプロイする前に、正しいcidrアドレスでkube-flannel.ymlをダウンロードして更新します:

    $ 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. マスター・ノードが準備完了ステータスであることを検証します:

    $ 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 Sitesドメインをデプロイする準備ができています。

Kubernetesクラスタを設定するには、公式のドキュメントを参照してください。

3. スクリプトおよびイメージの取得

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

これらのステップに従って、Oracle WebCenter Sitesドメインのデプロイに必要なソース・コード・リポジトリを設定します。

3.2 必要なDockerイメージを取得し、ローカル・レジストリに追加

  1. Oracle Container RegistryからOracle WebLogic Operatorイメージを取得します:

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

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

    イメージを取得するには、Oracle Container Registryにログインします:

    $ podman login container-registry.oracle.com
    1. オペレータ・イメージをプルします:
    $ podman pull container-registry.oracle.com/middleware/weblogic-kubernetes-operator:4.2.9
$ podman tag container-registry.oracle.com/middleware/weblogic-kubernetes-operator:4.2.9 oracle/weblogic-kubernetes-operator:4.2.9

  2. Oracle Container RegistryからWebCenter Sitesイメージをプル、または「イメージの作成または更新」に従って、Oracle WebCenter Sites 14.1.2.0.0イメージを構築します。事前構築済のOracle WebCenter Sitesイメージ14.1.2.0.0インストール・イメージをプルします:

    $ podman pull container-registry.oracle.com/middleware/webcentersites:14.1.2.0.0

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

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

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

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

    $ mkdir $HOME/wcs_1412
$ cd $HOME/wcs_1412

  2. WebCenter Sites Kubernetesデプロイメント・スクリプトをこのリポジトリからダウンロードし、WebLogic Operatorサンプルの場所にコピーします。

    $ git clone https://github.com/oracle/fmw-kubernetes.git
$ export WORKDIR=$HOME/wcs_1412/fmw-kubernetes/OracleWebCenterSites/kubernetes

    このドキュメントで説明するように、$HOME/wcs_1412/fmw-kubernetes/OracleWebCenterSites/kubernetesのデプロイメント・スクリプトを使用して、WebCenter Sitesドメインを設定できるようになりました。

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

4.1 WebLogic Kubernetes Operatorの準備。

  1. Oracle WebCenter Sites OperatorコードのオペレータWORKDIRにネームスペースoperator-nsを作成します:

    $ kubectl create namespace operator-ns

  2. オペレータのネームスペースにオペレータのサービス・アカウントoperator-saを作成します:

    $ kubectl create serviceaccount -n operator-ns operator-sa
4.2 WebLogic Kubernetes Operatorのインストール

Helmを使用して、クローニングしたディレクトリからオペレータをインストールして起動します:

$ cd ${WORKDIR}
$ helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update
$ helm install weblogic-kubernetes-operator weblogic-operator/weblogic-operator  --version 4.2.9 --namespace operator-ns  --set serviceAccount=operator-sa --set "javaLoggingLevel=FINE" --wait

 NAME: weblogic-kubernetes-operator
 LAST DEPLOYED: Tue May 19 04:04:32 2024
 NAMESPACE: operator-ns
 STATUS: deployed
 REVISION: 1
 TEST SUITE: None
4.3 WebLogic Kubernetes Operatorの検証

  1. オペレータのネームスペースにポッドをリストして、オペレータのポッドが実行中であることを検証します。オペレータの1つが表示されます:

    $ kubectl get pods -n operator-ns

  2. オペレータ・ポッドのログを表示して、オペレータが稼働していることを検証します:

    $ kubectl logs -n operator-ns -c weblogic-operator deployments/weblogic-operator

WebLogic Kubernetes Operator v4.2.9がインストールされています。ロード・バランサおよびOracle WebCenter Sitesドメインの設定を続行します。

5.Traefik (イングレスベース)ロード・バランサのインストール

Oracle WebLogic Server Kubernetes Operatorは、Traefik、Nginx、Apache Webtierの3つのロード・バランサをサポートしています。サンプルはドキュメントに記載されています。

このクイック・スタートでは、Traefikイングレス・コントローラをインストールして、Oracle WebCenter Sitesドメインのロード・バランシングを提供する方法を示します。

  1. Traefikのネームスペースを作成します:

    $ kubectl create namespace traefik

  2. サード・パーティ・サービス用のHelmを設定します:

    $ helm repo add traefik https://helm.traefik.io/traefik --force-update

  3. 提供されているサンプル値を使用して、Traefikオペレータをtraefikネームスペースにインストールします:

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

6. Oracle WebCenter Sitesドメインの作成および構成

6.1 Oracle WebCenter Sitesドメインの準備

  1. Oracle WebCenter Sitesドメインをホストできるネームスペースを作成します:

    $ kubectl create namespace wcsites-ns
$ kubectl label namespace wcsites-ns weblogic-operator=enabled

  2. Kubernetesシークレットを作成します。

    1. ドメインと同じKubernetesネームスペースにドメインのKubernetesシークレットを作成します。この例では、ユーザー名はweblogic、パスワードはWelcome1、ネームスペースはwcsites-nsです:

      $ cd ${WORKDIR}/create-weblogic-domain-credentials
$ ./create-weblogic-credentials.sh \
     -u weblogic \
     -p Welcome1 \
     -n wcsites-ns    \
     -d wcsitesinfra \
     -s wcsitesinfra-domain-credentials

    2. ドメインと同じKubernetesネームスペースにRCUのKubernetesシークレットを作成します:

    • スキーマ・ユーザー: WCS1
    • スキーマ・パスワード: Oradoc_db1
    • DB sysユーザー・パスワード: Oradoc_db1
    • ドメイン名: wcsitesinfra
    • ドメイン・ネームスペース: wcsites-ns
    • シークレット名: wcsitesinfra-rcu-credentials
    $ cd ${WORKDIR}/create-rcu-credentials
$ ./create-rcu-credentials.sh \
       -u WCS1 \
       -p Oradoc_db1 \
       -a sys \
       -q Oradoc_db1 \
       -d wcsitesinfra \
       -n wcsites-ns \
       -s wcsitesinfra-rcu-credentials

  3. Kubernetes永続性ボリュームおよび永続性ボリューム・クレームを作成します。

    1. Oracle WebCenter Sitesドメイン・ホーム・ディレクトリを作成します。uid:gidが1000:0のホスト・システムにユーザーがすでに存在するかどうかを確認します。

      $ sudo getent passwd 1000

      このコマンドがユーザー名(最初のフィールド)を返す場合は、次のuseraddコマンドをスキップできます。そうでない場合は、useraddを使用してoracleユーザーを作成します:

      $ sudo useradd -u 1000 -g 0 oracle

      Oracle WebCenter Sitesドメイン・ホームに使用するディレクトリを作成します:

      $ sudo mkdir /scratch/K8SVolume/WCSites
$ sudo chown -R 1000:0 /scratch/K8SVolume/WCSites

    2. create-wcsites-domain/utils/create-wcsites-pv-pvc-inputs.yamlを次の値で更新します:

    • baseName: domain
    • domainUID: wcsitesinfra
    • ネームスペース: wcsites-ns
    • weblogicDomainStoragePath: /scratch/K8SVolume/WCSites
    $ cd ${WORKDIR}/
$ cp create-wcsites-domain/utils/create-pv-pvc-inputs.yaml create-wcsites-domain/utils/create-pv-pvc-inputs.yaml.orig
$ sed -i -e "s:baseName\: weblogic-sample:baseName\: domain:g" create-pv-pvc-inputs.yaml
$ sed -i -e "s:domainUID\::domainUID\: wcsitesinfra:g" create-pv-pvc-inputs.yaml
$ sed -i -e "s:namespace\: default:namespace\: wcsites-ns:g" create-pv-pvc-inputs.yaml
$ sed -i -e "s:#weblogicDomainStoragePath\: /scratch/K8SVolume/WCSites:weblogicDomainStoragePath\: /scratch/K8SVolume/WCSites:g" create-pv-pvc-inputs.yaml
    1. create-pv-pvc.shスクリプトを実行して、PVおよびPVC構成ファイルを作成します:
    $ sh create-weblogic-domain-pv-pvc/create-pv-pvc.sh \
  -i create-wcsites-domain/utils/create-wcsites-pv-pvc-inputs.yaml \
  -o create-wcsites-domain/output
    1. 前のステップで作成した構成ファイルを使用してPVおよびPVCを作成します:
    $ kubectl create -f create-wcsites-domain/output/pv-pvcs/wcsitesinfra-domain-pv.yaml
$ kubectl create -f create-wcsites-domain/output/pv-pvcs/wcsitesinfra-domain-pvc.yaml

  4. Oracle WebCenter Sitesドメインのデータベースをインストールして構成します。

    このステップは、スタンドアロン・データベースがまだ設定されておらず、コンテナでデータベースを使用する場合にのみ必要です。

    ノート: Oracle Database Dockerイメージは、本番以外の用途でのみサポートされています。詳細は、My Oracle Supportノート: Oracle Support for Database Running on Docker(ドキュメントID 2216342.1)を参照してください。本番環境では、スタンドアロン・データベースを使用することをお薦めします。この例では、コンテナにデータベースを作成するステップを示します。

Oracle WebCenter Sitesドメインの作成を開始する環境の準備が整いました。

6.2 Oracle WebCenter Sitesドメインの作成

  1. Oracle WebCenter Sitesドメイン・デプロイメントのサンプル・スクリプトは、<weblogic-kubernetes-operator-project>/kubernetes/create-wcsites-domainにあります。create-domain-inputs.yaml (またはそのコピー)を編集して、ドメインの詳細を指定する必要があります。

  2. create-domain.shスクリプトを実行して、ドメインを作成します:

    $ cd ${WORKDIR}/
$ sh create-wcsites-domain/domain-home-on-pv/create-domain.sh \
    -i create-wcsites-domain/domain-home-on-pv/create-domain-inputs.yaml \
    -o create-wcsites-domain/output

  3. Kubernetesドメイン・オブジェクトを作成します:

    create-domain.shが成功すると、ドメインおよびサーバーを起動するKubernetesリソース・ドメインの作成に使用できるoutput/weblogic-domains/wcsitesinfra/domain.yamlが生成されます:

    $ cd ${WORKDIR}/
$ kubectl create -f create-wcsites-domain/output/weblogic-domains/wcsitesinfra/domain.yaml

  4. wcsitesinfraという名前のKubernetesドメイン・オブジェクトが作成されていることを検証します:

    $ kubectl get domain -n wcsites-ns
NAME           AGE
wcsitesinfra   3m18s

  5. ドメインを作成すると、イントロスペクト・ポッドが作成されます。これにより、ドメイン・ホームが検査され、wcsitesinfra-adminserverポッドが起動されます。wcsitesinfra-adminserverポッドが正常に起動すると、管理対象サーバー・ポッドがパラレルで起動されます。wcsites-nsネームスペースで、ドメイン作成のステータスを確認します:

    $ kubectl get pods -n wcsites-ns -w

  6. Oracle WebCenter Sitesドメイン・サーバー・ポッドおよびサービスが作成され、準備完了状態になっていることを確認します:

    $ kubectl get all -n wcsites-ns
6.3 WebCenter Sites公開サービスの作成

kubernetes/create-wcsites-domain/utils/wcs-services.yamlの詳細:

次のコマンドを実行してサービスを公開します: (ドメインが3台を超える管理対象サーバー用に構成されている場合は、追加のサーバー用にサービスyamlを追加します。)

$ kubectl apply -f kubernetes/create-wcsites-domain/utils/wcs-services.yaml
service/wcsitesinfra-wcsites-server1-np created
service/wcsitesinfra-wcsites-server1-svc created
service/wcsitesinfra-wcsites-server2-svc created
service/wcsitesinfra-wcsites-server3-svc created
6.4 Oracle WebCenter Sitesドメイン・サービスでアクセスするためのTraefikの構成

  1. Oracle WebCenter Sitesドメイン・ネームスペース(wcsites-ns)で作成されたイングレスを管理するようにTraefikを構成します:

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

  2. サンプルのHelmチャートを使用して、ドメイン・ネームスペースにドメインのイングレスを作成します:

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

  3. ドメインごとに作成されたイングレスの詳細を検証します:

    $ kubectl describe ingress wcsitesinfra-ingress -n wcsites-ns
6.5 Oracle WebCenter SitesドメインURLにアクセスできることの検証

  1. 環境のLOADBALANCER_HOSTNAMEを取得します:

    export LOADBALANCER_HOSTNAME=$(hostname -f)

  2. ドメイン・タイプwcsitesinfraのOracle WebCenter Sitesドメインでは、次のURLを使用できます:

    資格証明: ユーザー名: weblogic パスワード: Welcome1

    http://${LOADBALANCER_HOSTNAME}:30305/console
http://${LOADBALANCER_HOSTNAME}:30305/em
http://${LOADBALANCER_HOSTNAME}:30305/sites