ドメイン・レイヤーの変更
ドメイン・レイヤーを変更する必要があり、同じドメイン暗号化キーを保持する必要がある場合は、以前と同じ方法で実装することもできます。 それでは、これらについて詳しく説明します。
最初のオプションは、各変更を前の状態への差分として実装することです。 これは概念的に、不変オブジェクト(Java文字列など)の実装方法、つまりユニットとしてドメイン構成に適用される「copy on write」アプローチに似ています。 これは実装が簡単であるという利点がありますが、ビルドが以前の良好なビルドに依存するという欠点があり、これは一般的なCI/CDプラクティスとは若干異なります。 また、不良ビルド、つまりシーケンス内の「穴」で何をするかを確認する必要があります。
かわりに、順序を開始する前にドメインの初期状態を取得することもできます。 実際には、これは、アプリケーションやリソースが含まれていない非常に単純なドメインを作成し、サーバーを起動する前に保存することを意味する場合があります。 この最初のドメイン(t=0と呼びます)は、各変更のビルドに使用されます。 そのため、各状態はt=0に加えて、その時点までのすべての変更から構築されます。
別の方法として、各ビルドはt=0で始まり、ベース・イメージとして拡張されます。 これにより、各中間状態を維持する必要がなくなります。また、中間レイヤーに"lost" ("whited out"はイメージ・レイヤー用語)領域がないため、ドメインから何かを削除しても利点があります。 ただし、これらのレイヤーは比較的小さい傾向があるため、大きな問題ではない可能性があります。
このアプローチはおそらく改善されています。 WebLogicへのパッチ適用時やJDKの更新時など、下位レイヤーを更新する場合には興味深いことがあります。 これが発生した場合は、図に示すように、別のベース・イメージをv2 t-0として作成する必要があります。 この新しいチェーンのすべての変更は、この新しいベース・イメージに基づいています。 そのため、最初のシリーズ(v1 t=0からt=3)からドメインを取得し、それを2番目のシリーズ(v2)に「コピー」する方法の問題が解決されません。