このドキュメントでは、WebLogic ServerインスタンスがKubernetes環境でいつ再起動されるかについて説明します。
WebLogicまたはKubernetes環境構成を変更した場合、ドメインまたはクラスタ内のすべてのサーバーを再起動する必要がある状況が数多くあります(WebLogic Serverパッチの適用時やアプリケーションのアップグレード時など)。
オペレータの最も重要なジョブの1つは、対応するKubernetesポッドを作成および削除してWebLogic Serverインスタンスを起動および停止することです。 ポッドを廃止するように変更する必要がある場合があるため、ポッドを削除して再作成する必要があります。 変更に応じて、多くの場合、ドメインまたはクラスタのサービスを停止せずにポッドを徐々に再作成でき(ローリング再起動など)、場合によっては、すべてのポッドを削除してから停止時間の一環として再作成する必要があります(完全再起動など)。
オペレータは、次のタイプのサーバー再起動をサポートしています:
ローリング再起動 - エンド・ユーザーへのサービスが中断されないように、ドメインまたはクラスタ内のすべてのサーバーの調整および制御された停止。
オペレータが開始 - ここで、WebLogic Kubernetes Operatorは一部のタイプの変更を検出でき、ドメインまたはクラスタ内のポッドのローリング再起動を自動的に開始します。
手動で開始 - オペレータがKubernetes環境でOracle WebLogic Serverの特定の変更を検出できないため、ローリング再起動を手動で開始する必要がある場合に必要です。
ドメイン全体の再起動 - ドメイン内の管理サーバーとすべての管理対象サーバーが停止され、エンド・ユーザーに対するサービスの可用性に影響を与えてから再起動されます。 ローリング再起動とは異なり、オペレータは完全なドメイン再起動を検出して開始することはできません。常に手動で開始する必要があります。
オペレータを使用してサーバーを再起動する方法の詳細は、「サーバーの起動、停止および再起動」を参照してください。
このドキュメントでは、多くの一般的なシナリオでサーバーを正しく再起動するために必要なアクションについて説明します:
image、volumes、envなど)のフィールドの変更WebLogicドメイン構成の変更では、ドメイン・ホームのロケーションおよび構成変更のタイプに応じて、ローリングまたは完全なドメイン再起動が必要になる場合があります。
Domain in Image 「ドメイン・ホーム・ソース・タイプ」は、WebLogic Kubernetes Operatorバージョン4.0では非推奨です。 Oracleでは、必要に応じてDomain on PVまたはModel in Imageを選択することをお薦めします。
Domain in Imageの場合、ローリング再起動を実行できるのは、現在のイメージと新しいイメージの間でWebLogic構成の変更が両方とも動的で、互換性のある暗号化キーを使用してイメージを作成する「CI/CDガイドラインに準拠」がある場合のみです。
そうでない場合は、互換性のある暗号化キーを持たない新しいイメージまたは動的でない構成変更を使用するには、ドメインを完全に再起動する必要があります。
現在実行中のドメインと互換性のない構成変更を提供するイメージでは、ローリング再起動ではなく、ドメインimageフィールドを変更する前に完全な停止が必要です。 ローリング再起動をサポートする変更については、「サポートされる更新」および「サポートされない更新」を参照してください。
新しい名前で新しいイメージを作成し、ローリング再起動を回避する場合は、「ドメインのイメージ・フィールド変更時のローリング再起動の回避」を参照してください。
同じ名前で新しいイメージを作成する場合は、新しいイメージでポッドを実行するために、ドメイン全体の再起動またはローリング再起動を手動で開始する必要があります。 完全再起動を開始するには、「ドメイン全体の再起動」を参照してください。 ローリング再起動を開始するには、ドメインrestartVersionフィールドの値を変更します。 「サーバーの再起動」および「ローリング再起動」を参照してください。
実行中のドメインの更新されたモデルまたはシークレットを指定する場合は、「ランタイムの更新」を参照してください。
Domain on PVの場合、必要な再起動のタイプは、WebLogicドメイン構成の変更の性質によって異なります:
stuck thread timer intervalプロパティを変更する場合に適用できます。 「ドメイン内のすべてのサーバーの再起動」を参照してください。 WebLogicドメイン構成の変更に対応するオペレータのライフ・サイクルに関する前述の説明は、バージョン3.0.0以降に適用されます。 オペレータ・バージョン3.0.0より前は、管理コンソールまたはWLSTを使用してWebLogicドメイン構成を変更できましたが、オペレータは、ドメインの完全な停止および再起動後にのみ、これらの変更を検出して対応していました。
オペレータ・バージョンの3.0.0以降、ドメイン構成オーバーライドに対する多くの変更は、動的に適用することも、ローリング再起動の一部として適用することもできます。 以前は、構成を変更した場合、完全なドメイン停止および再起動が必要でした。 構成オーバーライドの変更には、次のものがあります:
configuration.overridesConfigMapを変更configuration.secretsを変更configuration.overridesConfigMapで参照されるConfigMapの内容の変更configuration.secretsによって参照されるシークレットへのコンテンツの変更前にリストされたフィールドまたは関連リソースのコンテンツに対する変更は、自動的に処理されません。 かわりに、これらのフィールドは「オペレータ・イントロスペクションの開始」の場合にのみ処理されます。 オペレータは、選択した戦略に応じて、新しい構成オーバーライドを動的に適用するか、WebLogic Serverインスタンスの再起動時にのみオーバーライドを適用します。
実行中のWebLogic Serverインスタンスに配布された構成オーバーライドへの変更は、対応するWebLogic構成のMBean属性が「動的」である場合にのみ有効になります。 たとえば、データソースの「passwordEncrypted」属性は動的ですが、「URL」属性は動的ではありません。
ドメインのKubernetesシークレットに含まれるWebLogic Server資格証明(ユーザー名とパスワード)を変更するには、「ドメインの完全再起動」が必要です。 Kubernetesのシークレットを直接更新することも、新しいシークレットを作成してドメインYAMLファイルのwebLogicCredentialsSecretフィールドで参照することもできます。
image、volumes、envなど、WebLogic Serverインスタンスのポッド生成に影響するドメインYAMLファイルのフィールドを変更すると、オペレータがドメインのローリング再起動を開始します。 完全なリストは、「サーバーを再起動させるフィールド」を参照してください。
これらのフィールドは、kubectlコマンドライン・ツールのeditおよびpatchコマンドまたはKubernetes REST APIを使用して変更できます。
たとえば、kubectlコマンドライン・ツールを使用してドメインYAMLファイルを直接編集するには、次のようにします:
$ kubectl edit domain <domain name> -n <domain namespace>
editコマンドを使用すると、テキスト・エディタが開き、その場でドメインを編集できます。
通常は、ドメインYAMLファイルを直接編集することをお薦めします。それ以外の場合は、ドメインをスケーリングし、元のdomain.yamlファイルのみを編集して再適用すると、古いレプリカ数に戻ることができます。
Oracleには、パッチ・セット更新、セキュリティ・パッチ更新、個別パッチなど、WebLogic Server用の様々なタイプのパッチが用意されています。 パッチにローリング互換性があるかどうか、または手動によるフル・ドメインの再起動が必要かどうかについては、READMEファイルなどのパッチのドキュメントを参照してください。
WebLogic Serverパッチは、domain home in imageまたはdomain home on PVのいずれかに適用できます。
ローリング互換パッチの場合:
imageプロパティを新しいイメージ名で更新すると、オペレータはローリング再起動を開始します。ローリング互換性のないパッチの場合:
imageプロパティを新しいイメージ名で更新する場合は、「ドメインのイメージ・フィールド変更時のローリング再起動の回避」のステップに従ってローリング再起動を回避する必要があります。「継続的インテグレーション/継続的デリバリ」 (CI/CD)プロセスを使用したデプロイ済アプリケーションの頻繁な更新は、非常に一般的なユースケースです。 更新されたアプリケーションを適用するプロセスは、domain home in imageとmodel in imageではdomain home on PVの場合とは異なります。 ローリング互換アプリケーション更新では、一部のサーバーで古いバージョンが実行され、一部のサーバーでローリング再起動プロセス中に新しいバージョンのアプリケーションが実行されます。 一方、ロール互換性のないアプリケーション更新では、ドメイン内のすべてのサーバーを停止して再起動する必要があります。
アプリケーションの更新にローリング互換性がある場合:
imageプロパティを新しいイメージ名で更新すると、オペレータはローリング再起動を開始します。アプリケーションの更新にローリング互換性がない場合:
imageプロパティを新しいイメージ名で更新する場合は、「ドメインのイメージ・フィールド変更時のローリング再起動の回避」のステップに従ってローリング再起動を回避する必要があります。WebLogic Serverドメインへのパッチ適用またはアプリケーションのデプロイメント・ファイルの更新のみが必要な場合は、次のステップに従って新しいローリング互換イメージを作成します:
a. 新しいイメージに別の名前を選択します。
b. Domain in Imageの場合、元のドメイン・ホームを新しいイメージに保持することが重要です。
ベースとして同じドメイン・ホーム・イン・イメージ・イメージを使用して、イメージ・ビルド中に更新されたアプリケーション・デプロイメント・ファイルまたはWebLogic Serverパッチをイメージにコピーする(DockerfileのCOPYコマンド)ことで、新しいイメージを作成します。
ここで重要なのは、WLSTまたはWDTを再実行して新しいドメイン・ホームを作成しないようにすることです(同じ構成になります)。 新しいドメインを作成すると、ドメイン暗号化シークレットが変更され、ローリング再起動はできなくなります。
c. 新しいイメージを新しい名前でコンテナ・レジストリにデプロイします。
d 新しいイメージ名を指定して、ドメインYAMLファイルのimageフィールドを更新します。
例えば:
```yaml
domain:
spec:
image: ghcr.io/oracle/weblogic-updated:4.2.8
```
e. オペレータは、ドメイン内のすべてのサーバーに対してローリング再起動を開始し、更新されたイメージを適用します。
ローリング互換性のない新しいイメージを作成し、イメージ名を変更した場合は、次のようになります:
serverStartPolicyをNeverに設定して、ドメインを停止(すべてのサーバーポッドを停止)します。 「すべてのサーバーの停止」を参照してください。
imageプロパティを新しいイメージ名で更新します。
serverStartPolicyをIfNeededに設定して、ドメインを起動します(すべてのサーバーポッドを起動します)。
変更の順序の検討:
同時にドメインに複数の変更を加える必要がある場合は、サーバーが途中で再起動したり、再起動する必要がないように、変更の順序に注意してください。 たとえば、レディネス・プローブのチューニング・パラメータとJavaオプション(どちらもローリング互換性がある)を変更する場合は、両方の値を変更してドメインYAMLファイルを一度更新し、オペレータ・ローリングによってサーバーが一度再起動されるようにする必要があります。 または、レディネス・プローブのチューニング・パラメータ(ローリング互換)を変更し、ドメインのカスタマイズ(完全な再起動が必要)を変更する場合は、まず完全な停止を実行してから、サーバーを再起動する必要があります。
または、変更のセットにローリング互換性がないことがわかっている場合は、次の方法でローリング再起動を回避する必要があります:
serverStartPolicyをNeverに設定して、ドメインを停止(すべてのサーバーポッドを停止)します。 「すべてのサーバーの停止」を参照してください。
Kubernetes環境でOracle WebLogic Serverにすべての変更を加えます。
serverStartPolicyをIfNeededに設定して、ドメインを起動します(すべてのサーバー・ポッドを起動します)。
「ドメインの知識を必要とする変更」。
サーバーの再起動が必要な変更が必要になる場合がありますが、その変更はドメイン構成、イメージ、またはオペレータにドメインを登録するKubernetesリソースには反映されません。 たとえば、サーバーが外部データベースから情報をキャッシュしており、データベースの内容を変更したとします。
このような場合は、手動で再起動を開始する必要があります。
「管理対象Coherenceサーバーの安全な停止」。
ドメインがCoherenceクラスタを使用するように構成されている場合は、Kubernetesの正常なタイムアウト値を増やす必要があります。 サーバーを停止する場合、Coherenceでは、別のサーバーを安全に停止するために、パーティションをリカバリしてクラスタをリバランスする時間が必要です。 Kubernetesの正常終了機能を使用すると、オペレータは、Coherence HAStatusのMBean属性でサーバーを安全に停止できることが示されるまで自動的に待機します。 ただし、正常終了タイムアウトの期限が切れると、ポッドは削除されます。 したがって、Coherenceが安全になる前にサーバーが停止しないように、ドメインYAML timeoutSecondsを十分な大きさの値に設定することが重要です。 さらに、オペレータがCoherence MBeanにアクセスできない場合、ドメインtimeoutSecondsが期限切れになるまでサーバーは停止しません。 キャッシュ・データ損失の可能性を最小限に抑えるには、timeoutSeconds値を大きい数値(15分など)に増やす必要があります。