23 エンタープライズ・デプロイメントの共通の構成および管理タスク
構成タスクには、サイジング情報の確認やバックアップとリカバリの実行など、すべてのエンタープライズ・デプロイメントに共通するいくつかの手順が含まれます。エンタープライズ・デプロイメントへのパッチ適用およびコンポーネントのクロス・ワイヤリングは、その他の共通タスクです。
この章の内容は次のとおりです。
- すべてのエンタープライズ・デプロイメントの構成および管理タスク
Oracle Fusion Middlewareエンタープライズ・デプロイメントに適用されるこれらの共通の構成タスクを完了します。これらのタスクには、デプロイメントのサイジング要件の確認、Webサービス用のJDBC永続ストアの使用、およびデプロイメントのバックアップの取得が含まれます。 - コンポーネントの起動と停止
様々なコンポーネント(WebLogicコンポーネント、ドメイン全体、WebLogicクラスタなど)は、デプロイ後に起動および停止できます。 - エンタープライズ・デプロイメントへのパッチ適用
パッチがリリースされるたびに、バンドル・パッチでOracle Identity Governance Kubernetesクラスタを更新する必要があります。 - バックアップおよびリストア操作の実行
クラスタに問題がある場合でも使用できるように、バックアップをKubernetesクラスタの外部に保持します。 - Kubernetesワーカー・ノードでのメンテナンスの実行
メンテナンス/パッチ適用のためにKubernetesワーカー・ノードを停止する必要がある場合、または単にリフレッシュする必要がある場合は、まずそのワーカー・ノードで実行中のKubernetesサービスを正常に移動する必要があります。 - サーバー・ポッドの有効性プローブの調整
有効性プローブは、デフォルトでは、45秒ごとに有効性をチェックするよう構成されています。停止している場合は、この構成が原因で、使用できなくなっているバックエンドのポッドにリクエストがルーティングされることがあります。 - クロス・コンポーネント・ワイヤリングについての考慮事項
クロス・コンポーネント・ワイヤリング(CCW)を利用すると、FMWコンポーネントは、特定のAPIを使用することによってWLSドメインで使用可能なサービスの一部をパブリッシュし、それにバインドすることができます。
すべてのエンタープライズ・デプロイメントの構成および管理タスク
Oracle Fusion Middlewareエンタープライズ・デプロイメントに適用されるこれらの共通の構成タスクを完了します。これらのタスクには、デプロイメントのサイジング要件の確認、Webサービス用のJDBC永続ストアの使用、およびデプロイメントのバックアップの取得が含まれます。
コアDNS割当て
ノート:
このステップは、corednsを使用するすべてのKubernetesシステムに適用されます。
corednsポッドをコントロール・プレーンに配置し(可能な場合)、別の2つのポッドをワーカー・ノードに配置します。corednsフットプリントは低くなっています。 VIRT RES SHR S %CPU %MEM TIME+ COMMAND
146268 41684 29088 S 0.3 0.1 25:44.04 coredns
MB required (default settings) = (Pods + Services) / 1000 + 54$ kubectl label nodes K8ControlPlane1 area=dnsarea
$ kubectl label nodes K8ControlPlane2 area=dnsarea
$ kubectl label nodes K8ControlPlane3 area=dnsarea
$ kubectl label nodes k8worker1 area=dnsarea
$ kubectl label nodes k8worker2 area=dnsarea
$ kubectl label nodes k8worker3 area=dnsareacorednsデプロイメントを更新します。
ノート:
トポロジ分散制約は、Kubernetes v1.18で開始されるベータ版です。最初に、kube-apiサーバーおよびkube-schedulerで機能ゲートを有効にします。次に、ワーカーおよびコントロール・プレーン・ノードにポッドが適切に分散されるように、corednsデプロイメントを変更します。
corednsトポロジ分散構成の詳細は次のとおりです:
次に、corednsデプロイメントのyamlファイルのサンプルを示します:
$ kubectl get deployment coredns -n kube-system -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "7"
creationTimestamp: "2021-01-15T13:15:05Z"
generation: 8
labels:
area: dnsarea
k8s-app: kube-dns
managedFields:
- apiVersion: apps/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:k8s-app: {}
f:spec:
f:progressDeadlineSeconds: {}
f:revisionHistoryLimit: {}
f:selector:
f:matchLabels:
.: {}
f:k8s-app: {}
f:strategy:
f:rollingUpdate:
.: {}
f:maxSurge: {}
f:maxUnavailable: {}
f:type: {}
f:template:
f:metadata:
f:labels:
.: {}
f:k8s-app: {}
f:spec:
f:containers:
k:{"name":"coredns"}:
.: {}
f:args: {}
f:image: {}
f:imagePullPolicy: {}
f:livenessProbe:
.: {}
f:failureThreshold: {}
f:httpGet:
.: {}
f:path: {}
f:port: {}
f:scheme: {}
f:initialDelaySeconds: {}
f:periodSeconds: {}
f:successThreshold: {}
f:timeoutSeconds: {}
f:name: {}
f:ports:
.: {}
k:{"containerPort":53,"protocol":"TCP"}:
.: {}
f:containerPort: {}
f:name: {}
f:protocol: {}
k:{"containerPort":53,"protocol":"UDP"}:
.: {}
f:containerPort: {}
f:name: {}
f:protocol: {}
k:{"containerPort":9153,"protocol":"TCP"}:
.: {}
f:containerPort: {}
f:name: {}
f:protocol: {}
f:readinessProbe:
.: {}
f:failureThreshold: {}
f:httpGet:
.: {}
f:path: {}
f:port: {}
f:scheme: {}
f:periodSeconds: {}
f:successThreshold: {}
f:timeoutSeconds: {}
f:resources:
.: {}
f:limits:
.: {}
f:memory: {}
f:requests:
.: {}
f:cpu: {}
f:memory: {}
f:securityContext:
.: {}
f:allowPrivilegeEscalation: {}
f:capabilities:
.: {}
f:add: {}
f:drop: {}
f:readOnlyRootFilesystem: {}
f:terminationMessagePath: {}
f:terminationMessagePolicy: {}
f:volumeMounts:
.: {}
k:{"mountPath":"/etc/coredns"}:
.: {}
f:mountPath: {}
f:name: {}
f:readOnly: {}
f:dnsPolicy: {}
f:nodeSelector:
.: {}
f:kubernetes.io/os: {}
f:priorityClassName: {}
f:restartPolicy: {}
f:schedulerName: {}
f:securityContext: {}
f:serviceAccount: {}
f:serviceAccountName: {}
f:terminationGracePeriodSeconds: {}
f:tolerations: {}
f:volumes:
.: {}
k:{"name":"config-volume"}:
.: {}
f:configMap:
.: {}
f:defaultMode: {}
f:items: {}
f:name: {}
f:name: {}
manager: kubeadm
operation: Update
time: "2021-01-15T13:15:05Z"
- apiVersion: apps/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
f:area: {}
f:spec:
f:replicas: {}
f:template:
f:metadata:
f:annotations:
.: {}
f:kubectl.kubernetes.io/restartedAt: {}
f:labels:
f:foo: {}
f:spec:
f:topologySpreadConstraints:
.: {}
k:{"topologyKey":"area","whenUnsatisfiable":"DoNotSchedule"}:
.: {}
f:labelSelector:
.: {}
f:matchLabels:
.: {}
f:foo: {}
f:maxSkew: {}
f:topologyKey: {}
f:whenUnsatisfiable: {}
manager: kubectl
operation: Update
time: "2021-01-28T16:00:21Z"
- apiVersion: apps/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.: {}
f:deployment.kubernetes.io/revision: {}
f:status:
f:availableReplicas: {}
f:conditions:
.: {}
k:{"type":"Available"}:
.: {}
f:lastTransitionTime: {}
f:lastUpdateTime: {}
f:message: {}
f:reason: {}
f:status: {}
f:type: {}
k:{"type":"Progressing"}:
.: {}
f:lastTransitionTime: {}
f:lastUpdateTime: {}
f:message: {}
f:reason: {}
f:status: {}
f:type: {}
f:observedGeneration: {}
f:readyReplicas: {}
f:replicas: {}
f:updatedReplicas: {}
manager: kube-controller-manager
operation: Update
time: "2021-01-28T16:00:39Z"
name: coredns
namespace: kube-system
resourceVersion: "2520507"
selfLink: /apis/apps/v1/namespaces/kube-system/deployments/coredns
uid: 79d24e61-98f4-434f-b682-132625b04c49
spec:
progressDeadlineSeconds: 600
replicas: 4
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: kube-dns
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
annotations:
kubectl.kubernetes.io/restartedAt: "2021-01-28T15:29:48Z"
creationTimestamp: null
labels:
foo: bar
k8s-app: kube-dns
spec:
containers:
- args:
- -conf
- /etc/coredns/Corefile
image: k8s.gcr.io/coredns:1.6.7
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 5
httpGet:
path: /health
port: 8080
scheme: HTTP
initialDelaySeconds: 60
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
name: coredns
ports:
- containerPort: 53
name: dns
protocol: UDP
- containerPort: 53
name: dns-tcp
protocol: TCP
- containerPort: 9153
name: metrics
protocol: TCP
readinessProbe:
failureThreshold: 3
httpGet:
path: /ready
port: 8181
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
resources:
limits:
memory: 170Mi
requests:
cpu: 100m
memory: 70Mi
securityContext:
allowPrivilegeEscalation: false
capabilities:
add:
- NET_BIND_SERVICE
drop:
- all
readOnlyRootFilesystem: true
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /etc/coredns
name: config-volume
readOnly: true
dnsPolicy: Default
nodeSelector:
kubernetes.io/os: linux
priorityClassName: system-cluster-critical
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: coredns
serviceAccountName: coredns
terminationGracePeriodSeconds: 30
tolerations:
- key: CriticalAddonsOnly
operator: Exists
- effect: NoSchedule
key: node-role.kubernetes.io/master
topologySpreadConstraints:
- labelSelector:
matchLabels:
foo: bar
maxSkew: 1
topologyKey: area
whenUnsatisfiable: DoNotSchedule
volumes:
- configMap:
defaultMode: 420
items:
- key: Corefile
path: Corefile
name: coredns
name: config-volume
status:
availableReplicas: 4
conditions:
- lastTransitionTime: "2021-01-21T19:08:12Z"
lastUpdateTime: "2021-01-21T19:08:12Z"
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: "True"
type: Available
- lastTransitionTime: "2021-01-28T15:29:48Z"
lastUpdateTime: "2021-01-28T16:00:39Z"
message: ReplicaSet "coredns-84b49c57fd" has successfully progressed.
reason: NewReplicaSetAvailable
status: "True"
type: Progressing
observedGeneration: 8
readyReplicas: 4
replicas: 4
updatedReplicas: 4
labels:
foo: bar
k8s-app: kube-dns
topologySpreadConstraints:
- labelSelector:
matchLabels:
foo: bar
maxSkew: 1
topologyKey: area
whenUnsatisfiable: DoNotSchedule
これにより、マスター・ノードとワーカー・ノード間での均等配分が保証されます。したがって、コントロール・プレーンがリストアされると、ワーカー・ポッドは問題なく続行され、その逆も同様になります。
coredns分散のサンプル:kubectl get pods -A -o wide | grep coredns
kube-system coredns-84b49c57fd-4fz4g 1/1 Running 0 166m 10.244.1.20 K8ControlPlane2 <none> <none>
kube-system coredns-84b49c57fd-5mrkw 1/1 Running 0 165m 10.244.4.76 K8Worker2 <none> <none>
kube-system coredns-84b49c57fd-5zm88 1/1 Running 0 165m 10.244.2.17 K8ControlPlane3 <none> <none>
kube-system coredns-84b49c57fd-nqlwb 1/1 Running 0 166m 10.244.4.75 K8Worker2 <none> <none>
WLSSchemaDataSourceの適切なサイズ変更および構成の確認
WLSSchemaDataSourceは、JMS JDBCストア、JTA JDBCストアおよびリース・サービスのFMWコンポーネントで使用するために予約されている共通のデータ・ソースです。WLSSchemaDataSourceは、クリティカルなWLSインフラストラクチャ・サービスで競合を回避し、デッドロックに備えるために使用されます。
WLSSchemaDataSourceの接続使用量を削減するには、JMS JDBCおよびTLOG JDBCストア接続キャッシュ・ポリシーを、各接続キャッシュ・ポリシー設定を使用して「デフォルト」から「最小」に変更します。バックエンド・データベース・システム内の接続数を削減する必要がある場合、キャッシュ・ポリシーを「最小」に設定することをお薦めします。キャッシュ・ポリシー「なし」を使用するとパフォーマンスが低下する可能性があるため、このポリシーは使用しないでください。JDBCストアで使用される接続についての詳細な推奨事項については、『WebLogic永続ストアの管理』で、JDBCストア接続キャッシュ・ポリシーの構成に関する項を参照してください。
WLSSchemaDataSource接続プールのデフォルト・サイズは75です(GridLinkデータ・ソースの場合はサイズが2倍になります)。FMWの各クラスタのサイズと、移行に構成する候補に応じて、このサイズは高い値にチューニングすることができます。たとえば、ストア当たりのワーカー・スレッドがデフォルト値である一般的なSOA EDGデプロイメントを考えてみます。25個を超えるJDBCストアまたはTLOG-in-DBインスタンス(あるいはその両方)が同じWebLogicサーバーにフェイルオーバーでき、「接続キャッシュ・ポリシー」が「デフォルト」から「最小」に変更されていない場合は、接続の競合問題が発生する可能性があります。このような場合は、デフォルトのWLSSchemaDataSourceプール・サイズ(最大容量)を増やす必要があります(各JMSストアは、最小で2つの接続を使用し、リースとJTAが追加されてもプールの競合が発生します)。
WebサービスのJDBC永続ストアについて
デフォルトでは、Webサービスの永続性にはWebLogic Serverデフォルト永続ストアが使用されます。このストアはWebサービスに対して高パフォーマンスの記憶域ソリューションを提供します。
-
信頼できるメッセージング
-
接続
-
セキュア通信
-
メッセージ・バッファリング
デフォルト・ストアではなく、JDBC永続ストアをWebLogic ServerのWebサービスで使用することもできます。Webサービスの永続性の詳細は、Webサービスの永続性の管理を参照してください。
自動スケーリングの有効化
Kubernetesでは、ポッドが自動スケーリングされます。実行中のポッドが2つあり、リソースがメモリーなどのしきい値を超えると、新しいポッドが自動的に起動されます。
たとえば、使用可能なメモリーの75%に達すると、別のワーカー・ノードで新しいポッドが起動されます。
自動スケーリングを行うには、まず自動スケーリングするポッド・タイプごとにリソース要件を定義する必要があります。詳細は、関連する製品のインストールと構成の章を参照してください。
Kubernetesメトリック・サーバーのデプロイ
- このサーバーをデプロイするには、次のコマンドを実行します:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml - 次のコマンドを使用して、メトリック・サーバーが実行中であることを確認します:
kubectl get pods -n kube-system
親トピック: 自動スケーリングの有効化
Kubernetes HorizontalPodAutoscalerリソースのデプロイ
次の例では、メモリーおよびCPU使用率に基づいて、WebLogicクラスタを自動的にスケーリングする方法を示しています。
OAMクラスタをoamnsネームスペースで実行している場合は、次のコマンドを使用して、クラスタ・リソース(accessdomain-oam-cluster)をターゲットにしたHorizontalPodAutoscaler (HPA)リソースを作成すると、Oracle WebLogic Serverインスタンスが、最小2つのクラスタ・メンバーから5つのクラスタ・メンバーに自動スケーリングされます。スケール・アップまたはスケール・ダウンは、平均CPU使用率が常に70%を超えている場合に行われます。
親トピック: 自動スケーリングの有効化
エンタープライズ・デプロイメントのバックアップとリカバリの実行
Oracle Identity and Access Managementエンタープライズ・デプロイメントに必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。
ノート:
この項で示す静的なランタイム・アーティファクトの一部は、Network Attached Storage (NAS)からホストされています。可能な場合は、これらのボリュームをアプリケーション・サーバーではなく直接NASファイラからバックアップおよびリカバリします。
Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。
表23-1は、一般的なOracle Identity and Access Managementエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。
表23-1 Oracle Identity and Access Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト
| タイプ | ホスト | 層 |
|---|---|---|
|
データベースOracleホーム |
DBHOST1およびDBHOST2 |
データ層 |
|
Oracle Fusion Middleware Oracleホーム |
WEBHOST1およびWEBHOST2 |
Web層 |
|
Oracle Fusion Middleware Oracleホーム |
OIMHOST1およびOIMHOST2 (またはNASファイラ) |
アプリケーション層 |
|
インストール関連ファイル |
WEBHOST1、WEHOST2および共有記憶域 |
該当なし |
表23-2は、一般的なOracle Identity and Access Managementエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。
表23-2 Oracle Identity and Access Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト
| タイプ | ホスト | 層 |
|---|---|---|
|
管理サーバーのドメイン・ホーム(ASERVER_HOME) |
OIMHOST1 (またはNASファイラ) |
アプリケーション層 |
|
アプリケーション・ホーム(APPLICATION_HOME) |
OIMHOST1 (またはNASファイラ) |
アプリケーション層 |
|
Oracle RACデータベース |
DBHOST1およびDBHOST2 |
データ層 |
|
スクリプトとカスタマイズ |
ホスト単位 |
アプリケーション層 |
|
デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME) |
OIMHOST1 (またはNASファイラ) |
アプリケーション層 |
|
OHS構成ディレクトリ |
WEBHOST1およびWEBHOST2 |
Web層 |
コンポーネントの起動と停止
様々なコンポーネント(WebLogicコンポーネント、ドメイン全体、WebLogicクラスタなど)は、デプロイ後に起動および停止できます。
次の手順を使用して、様々なコンポーネントを起動および停止します:
Oracle Unified Directoryの起動と停止
Oracle Unified Directory (OUD)は、helmコマンドを使用して停止および起動されます。
helm upgrade -n <OUDNS> --set replicaCount=0 <OUD_PREFIX> /home/opc/workdir/OUD/samples/kubernetes/helm/oud-ds-rs --reuse-valueshelm upgrade -n oudns --set replicaCount=0 edg /workdir/OUD/samples/kubernetes/helm/oud-ds-rs --reuse-valueshelm upgrade -n <OUDNS> --set replicaCount=<NO_SERVERS> <OUD_PREFIX> /home/opc/workdir/OUD/samples/kubernetes/helm/oud-ds-rs --reuse-valueshelm upgrade -n oudns --set replicaCount=2 edg /workdir/OUD/samples/kubernetes/helm/oud-ds-rs --reuse-values親トピック: コンポーネントの起動と停止
OAMおよびOIGの起動と停止
WebLogicクラスタを使用してWebLogicコンポーネントを起動および停止することはできません。次の手順を使用する必要があります:
ノート:
操作を開始および停止するサンプル・スクリプトに付属しているシェル・スクリプトがあります。これらのスクリプトは、ダウンロード・ディレクトリにあります。fmw-kubernetes/<PRODUCT>/kubernetes/domain-lifecycle/ドメイン全体の起動と停止
startDomain.sh -d <DOMAIN_NAME> -n <NAMESPACE>stopDomain.sh -d <DOMAIN_NAME> -n <NAMESPACE> 親トピック: OAMおよびOIGの起動と停止
WebLogicクラスタの起動と停止
startCluster.sh -d <DOMAIN_NAME> -n <NAMESPACE> -c <CLUSTER_NAME>stopCluster.sh -d <DOMAIN_NAME> -n <NAMESPACE> -c <CLUSTER_NAME>./rollCluster.sh -d <DOMAIN_NAME> -n <NAMESPACE> -c <CLUSTER_NAME>親トピック: OAMおよびOIGの起動と停止
管理対象サーバーおよび管理サーバーの起動と停止
startServer.sh -d <DOMAIN_NAME> -n <NAMESPACE> -s <SERVER_NAME> -k <REPLICAS>stopServer.sh -d <DOMAIN_NAME> -n <NAMESPACE> -s <SERVER_NAME> -k <REPLICAS>restartServer.sh d <DOMAIN_NAME> -n <NAMESPACE> -s <SERVER_NAME>親トピック: OAMおよびOIGの起動と停止
エンタープライズ・デプロイメントへのパッチ適用
パッチがリリースされるたびに、バンドル・パッチでOracle Identity Governance Kubernetesクラスタを更新する必要があります。
Helmベースのデプロイメントへのバンドル・パッチの適用
helm upgrade --reuse-values --set image.tag=<NEW_IMAGE> --namespace <NAMESPACE> --wait <DEPLOYMENT> <CHART>たとえば:
helm upgrade \
--reuse-values \
--set image.tag=3.3.0 \
--namespace opns \
--wait \
weblogic-operator \
/workdir/samples/charts/weblogic-operator/helm upgrade --reuse-values --set image.tag=12.2.1.4.0-8-ol7-211013.1053 --namespace oudns edg ../workdir/OUD/samples/kubernetes/helm/oud-ds-rsこのコマンドは、完全なイメージ名ではなくタグを更新します。
ノート:
これらのコマンドは、ポッドを自動的に再起動しません。次のコマンドを使用して、ポッドをローリング方式で再起動できます:kubectl get pod <podname> -n <namespace> -o yaml | kubectl replace --force -f -次に進む前に、必ず各ポッドを再起動してください。
kubectl describe pod <podname> -n <namespace>親トピック: エンタープライズ・デプロイメントへのパッチ適用
WebLogicドメインへのバンドル・パッチの適用
kubectl edit domainコマンドを実行します。kubectl patch domainコマンドを実行します。
kubectl patch domainコマンドの使用
kubectl patch domainコマンドでドメインを更新するには、次を実行します:$ kubectl patch domain <domain> -n <namespace> --type merge -p '{"spec":{"image":"newimage:tag"}}'$ kubectl patch domain governancedomain -n oigns --type merge -p '{"spec":{"image":"oracle/oig:12.2.1.4.0-8-ol7-210525.2125"}}'domain.weblogic.oracle/oimcluster patched親トピック: WebLogicドメインへのバンドル・パッチの適用
Oracle Identity Governanceへのパッチ適用
- 指定されたネームスペースにヘルパー・ポッドが存在するかどうかを確認します。存在する場合は、ヘルパー・ポッドが削除されます。
- 新しいイメージにより、新しいヘルパー・ポッドが表示されます。
- ドメイン定義のyamlファイルで
NEVERに設定されたserverStartPolicyにより、管理サーバー、SOAサーバーおよびOIMサーバーが停止されます。 - すべてのサーバーの停止を待機します(デフォルトのタイムアウトは2000秒です)。
- ジョブ構成マップからの資格証明を含むDBプロパティのイントロスペクションが行われます。
- ヘルパー・ポッドからDBスキーマの変更が行われます。
serverStartPolicyがIF_NEEDEDに、イメージが新しいイメージ・タグに設定され、管理サーバー、SOAサーバーおよびOIMサーバーが起動されます。- すべてのサーバーの準備が整うまで待機します(デフォルトのタイムアウトは2000秒です)。
ターゲット・ポッドのカウントに達する前に構成可能なタイムアウトに達した場合、スクリプトは、ドメイン構成に応じて、ゼロ以外で終了します。また、DBスキーマおよびドメインのパッチ適用中に障害が発生した場合も、ゼロ以外で終了します。
ノート:
スクリプトの実行により、OIGデプロイメントおよびデータベース・スキーマへのパッチ適用中に停止時間が発生します。パッチ適用前の前提条件
- ドメインの管理に関するドキュメントを確認すること。
- クラスタ内に実行中のOIGデプロイメントがあること。
- 実行中のデータベースがあること。
パッチ・ドメイン・スクリプトの実行
パッチ・ドメイン・スクリプトを実行するには、スクリプトに必要な入力内容を指定します。
$ cd $WORKDIR/samples/domain-lifecycle
$ ./patch_oig_domain.sh -h
$ ./patch_oig_domain.sh -i <target_image_tag> -n <OIGNS>$ cd /workdir/OIG/samples/domain-lifecycle
$ ./patch_oig_domain.sh -h
$ ./patch_oig_domain.sh -i 12.2.1.4.0-8-ol7-210721.0748 -n oigns[INFO] Found domain name: governancedomain [INFO] Image Registry: container-registry.oracle.com/middleware/oig_cpu [INFO] Domain governancedomain is currently running with image: container-registry.oracle.com/middleware/oig_cpu:12.2.1.4-jdk8-ol7-220120.1359 current no of pods under governancedomain are 3 [INFO] The pod helper already exists in namespace oigns. [INFO] Deleting pod helper pod "helper" deleted [INFO] Fetched Image Pull Secret: orclcred [INFO] Creating new helper pod with image: container-registry.oracle.com/middleware/oig_cpu:12.2.1.4-jdk8-ol7-220223.2107 pod/helper created Checking helper Running [INFO] Stopping Admin, SOA and OIM servers in domain governancedomain. This may take some time, monitor log /scratch/oig_post_patch/log/oim_patch_log-2022-09-06_09-43-15/stop_servers.log for details [INFO] All servers are now stopped successfully. Proceeding with DB Schema changes [INFO] Patching OIM schemas... [INFO] DB schema update successful. Check log /scratch/oig_post_patch/log/oim_patch_log-2022-09-06_09-43-15/patch_oim_wls.log for details [INFO] Starting Admin, SOA and OIM servers with new image container-registry.oracle.com/middleware/oig_cpu:12.2.1.4-jdk8-ol7-220223.2107 [INFO] Waiting for weblogic pods to be ready..This may take several minutes, do not close the window. Check log /scratch/oig_post_patch/log/oim_patch_log-2022-09-06_09-43-15/monitor_weblogic_pods.log for progress [SUCCESS] All servers under governancedomain are now in ready state with new image: container-registry.oracle.com/middleware/oig_cpu:12.2.1.4-jdk8-ol7-220223.2107
デフォルトでは、ログは$WORKDIR/samples/domain-lifecycleにあります。スクリプトにカスタム・ログの場所を指定することもできます。
パッチ・ドメイン・スクリプトの作成に失敗した場合は、「ドメインへのパッチ適用の失敗」を参照してください。
Oracle Identity Role Intelligenceへのパッチ適用
- 新しいイメージを使用して、Oracle Identity Role Intelligence (OIRI) CLIを再起動します。
- 新しいイメージを使用して、Data Ingester CLIを再起動します。
- 新しいCLIを使用して、OIRIデプロイメントを新しいイメージにアップグレードします。
次のステップを開始する前に、コンテナ・レジストリに最新のコンテナ・イメージがあること、または各ワーカー・ノードでローカルに使用可能であることを確認してください。
- 次のコマンドでCLIを削除します:
kubectl delete -f oiri-cli.yaml oiri-cli.yamlファイルを編集し、イメージの値が新しいイメージ・タグになるように変更します。kubectl delete -f oiri-cli.yaml- 次のコマンドでCLIを再作成します:
kubectl create -f oiri-cli.yaml次のコマンドを使用すると、作成したCLIを確認できます:kubectl get pods -n <OIRINS>
- 次のコマンドでDING CLIを削除します:
kubectl delete -f ding-cli.yaml dingi-cli.yamlを編集し、イメージの値が新しいイメージ・タグになるように変更します。- 次のコマンドでDING CLIを再作成します:
kubectl create -f ding-cli.yaml次のコマンドを使用すると、作成したCLIを確認できます:kubectl get pods -n <DINGNS>
kubectl exec -n <OIRINS> -ti oiri-cli
/updateValuesYaml.sh \
--oiriapiimage oiri:<NEW_IMAGE_VER> \
--oiriuiimage oiri-ui:<NEW_IMAGE_VER> \
--dingimage oiri-ding:<NEW_IMAGE_VER>./updateConfig.sh \
--dingimage oiri-ding:<NEW_IMAGE_VER>helm upgrade oiri /helm/oiri -f /app/k8s/values.yaml -n <OIRINS>親トピック: エンタープライズ・デプロイメントへのパッチ適用
Oracle Advanced Authenticationへのパッチ適用
Oracle Advanced Authenticationにパッチを適用するには、次のステップを実行します:
親トピック: エンタープライズ・デプロイメントへのパッチ適用
個別パッチの適用
個別パッチを適用する必要がある場合は、それらのパッチが適用された独自のイメージを作成する必要があります。この項では、WebLogic Image Toolを使用してOIGイメージをビルドする手順について説明します。
- OIGイメージのビルドの前提条件
- WebLogic Image Toolのダウンロードと設定
- パッケージ/インストーラおよびパッチのダウンロード
- 必要なビルド・ファイルのダウンロード
- イメージの作成
- サンプルDockerfileの生成
親トピック: エンタープライズ・デプロイメントへのパッチ適用
OIGイメージのビルドの前提条件
WebLogic Image Toolを使用してOIGイメージをビルドする前に、次の前提条件が必要です:
- Docker 18.03.1以降の動作可能なインストール。
- Bashバージョン4.0以上(コマンドの完全な機能を有効にするため)。
- JAVA_HOME環境変数をJDKの場所に設定。たとえば、
/u01/oracle/products/jdkです。
親トピック: 個別パッチの適用
WebLogic Image Toolのダウンロードと設定
リリース・ページから最新バージョンのWebLogic Image Toolをダウンロードして、次のステップを実行します:
親トピック: 個別パッチの適用
パッケージ/インストーラおよびパッチのダウンロード
必要なインストーラをOracle Software Delivery Cloudからダウンロードし、任意のディレクトリに保存します。例: <work directory>/stage:
- Oracle IdentityおよびAccess Management 12.2.1.4.0
- Oracle Fusion Middleware 12c Infrastructure 12.2.1.4.0
- Oracle SOA Suite 12.2.1.4.0
- Oracle Service Bus 12.2.1.4.0
- Oracle JDK
親トピック: 個別パッチの適用
イメージの作成
imagetool/binディレクトリに移動し、次のコマンドを実行します。次の例では、適切なファイルが存在するディレクトリを<work directory>/stageに置き換えます。
親トピック: 個別パッチの適用
サンプルDockerfileの生成
imagetoolで作成されたサンプルdockerfileを確認するには、--dryRunオプションを指定してimagetoolコマンドを使用します:
./imagetool.sh @<work directory/build/buildArgs --dryRun親トピック: 個別パッチの適用
バックアップおよびリストア操作の実行
クラスタに問題がある場合でも使用できるように、バックアップをKubernetesクラスタの外部に保持します。
Kubernetesデプロイメントは、次の4つの部分で構成されます:
Kubernetesオブジェクト
Kubernetesオブジェクトをバックアップおよびリストアする最も簡単な方法は、Kubernetesスナップショット・ツールを使用することです。このツールは、すべてのKubernetesオブジェクトを一連のファイルとしてネームスペースにアンロードし、必要に応じて別のクラスタにロードできます。
Kubernetesスナップショット・ツールを使用する手順は、「Kubernetesオブジェクトのバック・アップとリストア」を参照してください。
親トピック: バックアップおよびリストア操作の実行
コンテナ・イメージ
コンテナ・イメージがコンテナ・レジストリに格納されている場合、使用するクラスタは、必要なイメージに簡単にアクセスして使用できます。ただし、イメージを新しいKubernetesワーカー・ノードにリストアする場合は、必要なKubernetesイメージがそのワーカー・ノードで使用可能であることを確認してください。
親トピック: バックアップおよびリストア操作の実行
永続ボリューム
永続ボリュームは基本的にディスク上のディレクトリであり、通常はNFSストレージに格納されます。永続ボリュームのバックアップを取得するには、まず、ストレージにアクセスできるホストにディレクトリをマウントしてから、優先バックアップ・ツールを使用してバックアップします。ハードウェア・スナップショット、tar、rsyncの使用など、データのバックアップにはいくつかの方法があります。使用することを選択したバックアップ・ツールの使用方法については、関連するドキュメントを参照してください。
親トピック: バックアップおよびリストア操作の実行
データベース
Oracleデータベースは、データ保護(「バックアップ/リストア・ジョブの作成」を参照)であるか、ディスク、テープまたはバックアップ・アプライアンスに対して実行されるデータベース・バックアップのいずれかになります。Oracleでは、データベース・バックアップにRMANを使用することをお薦めします。RMANコマンドの詳細は、Oracle Databaseリリース21cのドキュメント『バックアップおよびリカバリ・リファレンス』を参照してください。
親トピック: バックアップおよびリストア操作の実行
Kubernetesワーカー・ノードでのメンテナンスの実行
メンテナンス/パッチ適用のためにKubernetesワーカー・ノードを停止する必要がある場合、または単にリフレッシュする必要がある場合は、まずそのワーカー・ノードで実行中のKubernetesサービスを正常に移動する必要があります。
kubectl drain <node name>kubectl uncordon <node name>ドレインの詳細は、Safely Drain a Nodeを参照してください。
サーバー・ポッドの有効性プローブの調整
プローブをより頻繁に実行するよう構成するには、ドメインを編集して、serverPods.livenessProbeの値を次のように変更します:
livenessProbe:
failureThreshold: 1
initialDelaySeconds: 30
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 3domain.yamlファイルには次のようなエントリがあります: - clusterName: oam_cluster
serverPod:
livenessProbe:
failureThreshold: 1
initialDelaySeconds: 30
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 3クロス・コンポーネント・ワイヤリングについての考慮事項
クロス・コンポーネント・ワイヤリング(CCW)を利用すると、FMWコンポーネントは、特定のAPIを使用することによってWLSドメインで使用可能なサービスの一部をパブリッシュし、それにバインドすることができます。
CCWがワイヤリング情報のバインドを実行するのは、構成ウィザードのセッション中のみ、またはWLSドメイン管理者によって手動で強制実行されたときだけです。クラスタにWeblogic Serverを追加するとき(静的または動的クラスタでのスケール・アウトおよびスケール・アップ操作で)、新しいサーバーはサービスを公開しますが、そのサービスを使用するクライアントのすべてが自動的に更新されて、新しいサービス・プロバイダにバインドされるわけではありません。CCW表にすでにバインドされている既存のサーバーは、クラスタに新しいメンバーが追加されたことを自動的に認識しないため、更新は実行されません。これは、ESSおよびWSMPMがSOAにサービスを提供する場合と同じです(両者はサービスをサービス表に動的に公開しますが、SOAサーバーはバインドが再び強制されないかぎり、これらの更新を認識しません)。
ノート:
-
『Oracle Fusion Middlewareの管理』の連携するコンポーネントのワイヤリング。
-
『Oracle HTTP Serverの管理』の、Oracle HTTP用にオラクルが開発したモジュールに関する項
WSMPMおよびESS用のクロス・コンポーネント・ワイヤリング
クロス・コンポーネント・ワイヤリングのt3情報は、JNDI呼出しURLで使用されるサーバーのリスト取得する際に、WSMPMとESSによって使用されます。
CCWのt3情報は、動的更新が欠落していてもその影響を制限します。呼出しが完了すると、JNDI URLを使用してRMIスタブとクラスタのメンバーのリストが取得されます。JNDI URLが、サーバーのリスト全体を含んでいる必要はありません。RMIスタブには常にクラスタ内のすべてのサーバーのリストが含まれており、それら全体でのリクエストのロード・バランスに使用されます。そのため、バインドなしに、クラスタに追加されたサーバーが(バインドURLに存在していなくても)使用されます。唯一の欠点は、クラスタの拡張または縮小時にシステムを動作させ続けるために、最初のCCWバインドで指定される元のサーバーのうち少なくとも1つが稼働している必要があるという点です。この問題を回避するために、メンバーの静的リストを使用するかわりにサービス表でクラスタ名構文を使用できます。
cluster:t3://cluster_name
cluster:t3://cluster_nameを使用すると、CCW呼出しによって常にクラスタ内のすべてのメンバーのリストがフェッチされるため、初期サーバーに依存することなく、そのとき存在するすべてのメンバーが対象になります。
親トピック: クロス・コンポーネント・ワイヤリングについての考慮事項
WSMPMでのcluster_name構文の使用
この手順では、WSMPMでt3構文を使用することにより、WSMPMクラスタでサーバーを追加または削除する場合にCCW情報を再更新することを不要にします。
CCW t3情報は、デフォルトでクラスタ構文を使用するように構成されています。クラスタ構文が使用されていることを確認し、必要があれば編集するだけです。
- 管理者のアカウントを使用してFusion Middleware Controlにサインインします。たとえば、
weblogic_iamです。 - 「WebLogicドメイン」ドロップダウン・メニューから、「クロス・コンポーネント・ワイヤリング」-「サービス表」を選択します。
- 「OWSMポリシー・マネージャ」のurn:oracle:fmw.owsm-pm:t3行を選択します。
- クラスタ構文が使用されていることを確認します。そうでない場合、「編集」をクリックして、クラスタ名構文を使用してt3およびt3sの値を更新します。
- 「OK」をクリックします。
- 「WebLogicドメイン」ドロップダウン・メニューから、「クロス・コンポーネント・ワイヤリング」-「コンポーネント」を選択します。
- 「OWSMエージェント」を選択します。
- 「クライアント構成」セクションで、owsm-pm-connection-t3行を選択して「バインド」をクリックします。
- 「OK」をクリックします。
ノート:
ワイヤリング表は、クラスタのスケール・アウトまたはスケール・アップのたびに更新されますが、手動の再バインドを使用しないかぎり、クラスタ構文を置き換えはしません。したがって、クラスタのライフサイクルのあらゆる更新(追加、削除)の影響を受けません。
親トピック: クロス・コンポーネント・ワイヤリングについての考慮事項