機械翻訳について

アプローチの選択

様々なアプローチを使用する場合について説明し、話し合いましょう。 まず、次のような質問をすることから始めます:

  • 構成のオーバーライドまたはModel in Image ConfigMapで目的の変更を行うことはできますか。

    ドメイン・ホームのソース・タイプがDomain on PVまたはDomain in Imageの場合、オペレータはドメイン内のサーバーを起動する前に多数の「構成オーバーライド」をポッドにインジェクトできます。

    ドメイン・ホームのソース・タイプがModel in Imageの場合、ドメイン内のサーバーを起動する前に、任意のタイプの更新に対して、またはほとんどのタイプの更新に対してドメインが実行されている場合でも、「モデル更新のインジェクト」を実行できます。 Model in Imageランタイム・モデルの更新は、実行中のWebLogic Serversの「再起動」 (ローリング)によって伝播されます。

    変更のよい例は、データ・ソースの設定を変更することです。 たとえば、本番環境では、開発/テスト環境よりも大きな接続プールが必要になる場合があります。 別の資格証明を使用することもできます。 サービス名などの変更が必要な場合があります。 これらすべての更新は、Domain on PVおよびDomain in Imageの構成オーバーライド、およびModel in Imageのモデル更新を使用して実行できます。 これらはKubernetes ConfigMapに配置されます。つまり、イメージの外部にあるため、イメージを再ビルドする必要はありません。 すべての変更がこのカテゴリに収まる場合は、Domain on PVおよびDomain in Imageの構成オーバーライドのみを使用し、Model in Imageのモデル更新を使用する方がよいでしょう。

  • アプリケーションのデプロイや更新、構成オーバーライドでサポートされていない方法でのリソース構成の変更、Model in Imageモデルの更新など、WebLogic構成のみを変更しますか。

    変更がこのカテゴリに該当し、“domain-in-image”アプローチとイメージ・レイヤー化モデルを使用している場合は、イメージの最上位レイヤーのみを更新する必要があります。 これは、下位レイヤーに変更を加えるよりも比較的簡単です。 変更を含む新しいレイヤーを作成することも、既存の最上位レイヤーを新しいレイヤーで再ビルド/置換することもできます。 どちらのアプローチを選択するかは、主に同じドメイン暗号化キーを保持する必要があるかどうかによって異なります。

  • ローリング再起動を実行できる必要がありますか。

    たとえば、アプリケーションの可用性を維持するために、Domain in Imageでローリング再起動を実行する必要がある場合は、新しいドメイン・レイヤーに同じドメイン暗号化キーがあることを確認する必要があります。 新しいメンバーに異なる暗号化キーがある場合、ドメインのローリング再起動は実行できません。

    Model in ImageまたはDomain on PVでローリング再起動を実行する必要がある場合、ドメイン暗号化キーは問題になりません。 Model in Imageでは、キーは最初のWebLogic Serverポッドが開始される前に、実行時にオペレータによって生成されます。 Domain on PVでは、キーはドメインの初回起動時に一度生成され、PV内のドメイン・ホームに残ります。

  • WebLogic、JDKまたはLinuxへのパッチ適用など、下位レイヤーで何かを変更する必要がありますか。

    下位レイヤーで更新を行う必要がある場合は、そのレイヤーとその上位のすべてのレイヤーを再ビルドする必要があります。 つまり、ドメイン・レイヤーを再ビルドする必要があります。 Domain in Imageの場合、同じドメイン暗号化キーを保持する必要があるかどうかを判断する必要があります。

次の図は、「イメージ内ドメイン」の場合のディシジョン・ツリーで、これらの懸念事項をまとめたものです:

「イメージ内のドメイン」アプローチのディシジョン・モデル

domain-on-PVまたはmodel-in-image方式を使用している場合は、ドメインとイメージが効果的に分離されるため、これらの懸念の多くがモットになります。 イメージ内の更新がドメインに影響する可能性があります。たとえば、JDKを更新した場合、新しいJDKパスを反映するようにドメイン・スクリプトの一部を更新する必要がある場合があります。

ただし、このシナリオでは、環境は従来の(non-Kubernetes)環境で使用されていた可能性が高いため、そのpre-Kubernetes環境から使用したすべてのプラクティスも、わずかな変更のみで、ここでも直接適用できます。 たとえば、WebLogicパッチを適用するには、新しいイメージを作成する必要があります。