この項では、KubernetesでWebLogic Serverを実行するためのコンテナ・イメージの展開および変更を管理するための推奨手法について説明します。 使用可能なアプローチとテクニックはいくつかあり、使用する方法の選択は特定の要件によって大きく異なります。 まず「問題のあるスペース」を確認し、次にさまざまなアプローチを選択するための考慮事項について説明します。 CI/CDを実装するためのいくつかのアプローチについて詳しく説明し、例へのリンクを示します。
Kubernetesでは、イメージが不変であり、イメージに状態が含まれておらず、ポッド/コンテナを破棄して新しいバージョンのイメージを使用する新しいものに置き換えるのと同じくらい簡単に更新できることを前提としています。 これらの前提はマイクロサービス・アプリケーションでは非常に効果的に機能しますが、従来のワークロードでは、必要な動作を得るために追加の考え方と追加の作業を行う必要があります。
CI/CDは、標準仮定が必ずしも適切ではない領域です。 マイクロサービス・アーキテクチャでは、通常、依存関係を最小限に抑え、依存関係をすべて備えたイメージを最初からビルドします。 また、通常は、すべての構成をイメージの外部に保持します。たとえば、Kubernetes構成マップやシークレット、およびイメージの外部のすべての状態に保持します。 これにより、実行中のポッドを新しいイメージで簡単に更新できます。
WebLogicイメージがどのように異なるかを考えてみましょう。 もちろん、オペレーティング・システムには基本レイヤーがあります。ここでは、それがOracle Linux "slim"であると仮定します。 その後、JDKが必要になり、これは別のレイヤーでよく使用されます。 多くのユーザーは、たとえば「サーバーJREイメージ」のように、Dockerストアから正式にサポートされているJDKイメージを使用します。 その上に、WebLogic Serverバイナリ(Oracle Home)が必要です。 その上に、いくつかのパッチまたは更新がインストールされている場合があります。 その後、ドメイン(つまり構成)が必要になります。
リース表、メッセージ・ストア、トランザクション・ストアなど、どこかに存続する必要があるドメインに関連するその他の情報もあります。 これらは、組込みデータベース・サーバーHAを利用するためにデータベースに保持することをお薦めします。また、最短距離を除くすべてのサイトの障害時リカバリでは、データの統合およびレプリケートに常に単一のデータベース・サーバー(DataGuard)を使用する必要があります。
これらのコンポーネントの構成方法には、次の3つの一般的なアプローチがあります:
これらのアプローチはすべて完全に有効であり(完全にサポートされている)、様々な長所と短所があります。 「これらのアプローチの相対的な利点を次に示します」をリストしました。
これらのアプローチの主な違いの1つは、保有するイメージの数と、そのビルドおよび維持方法です - イメージCI/CDプロセス。 ここでは、短いデターを取り、イメージ・レイヤーについて説明します。
コンテナ・イメージ・レイヤー・リングとその重要性について学習します。
コンテナ・イメージ・レイヤー化がCI/CDプロセスに影響する理由について説明します。
アプローチの選択方法。
ドメイン・レイヤーを変更する方法。
ドメインのコピー方法。
CI/CDパイプラインのビルドに使用できるツール。