新しいプロジェクトごとに最初の停止点はProject Settingsです。 このセクションでは、次のことをディシジョンし、プロジェクトの入力を行います:
WindowsまたはLinuxでWKT UIアプリケーションを実行する場合、アプリケーションはユーザーからその環境を継承します。 たとえば、アプリケーションで使用されるPATHにディレクトリを追加することは、PATH環境変数を変更し、アプリケーションを再起動するだけです。 macOSでは、事態は少し複雑になります。
アプリケーションをmacOSで実行する場合、アプリケーションは環境ではなくlaunchdというデーモン・プロセスの環境を継承します。 デフォルトでは、launchd環境にはPATH上のいくつかのコア・ディレクトリ(つまり、/usr/bin, /bin, /usr/sbinおよび/sbin)のみが含まれます。 たとえば、これらのロケーションのいずれかにツールが見つからない場合、クラウド・プロバイダのコマンドライン・ツールのいずれかへのアクセスが必要なkubectl呼出しが失敗します。 管理ユーザーがlaunchdがこの問題に対処するために使用する環境を変更することは可能ですが、WKT UIアプリケーションでは、クラウド・プロバイダのコマンドライン・ツールがインストールされているディレクトリを、アプリケーションがdocker, podman, kubectlの起動に使用するPATHおよびhelmに明示的に追加するためのExtra Path Directory表が提供されます。 また、Extra Environment Variable Name/Extra Environment Variable Value表を使用して、必要に応じて追加の環境変数を定義します。 この追加の環境構成は、Docker/Podman、kubectlおよびHelmの起動時に「のみ」、使用されることに注意してください。 このセクションは、macOSでアプリケーションを実行する場合にのみ表示されます。
WKT UIアプリケーションは、プロジェクトの資格証明を安全に格納することも、保存することもできません。 次の3つの選択肢があります:
Store in Native OS Credential Storeを選択した場合、Windows資格証明マネージャ、macOSキー・チェーンまたはLinux libsecretライブラリの資格証明ストアを使用します。 これらの資格証明ストアは、ほとんどのユーザーがすでに理解している資格証明を格納するための既知のセキュアなメカニズムを提供します。 このスキームの唯一の下位は、資格証明がローカル・マシンにのみ格納されることです。 プロジェクトを他のユーザーと共有しようとしたユーザーは、ローカル・マシンの資格証明ストアに保存できるように、他のユーザーが資格証明を再入力する必要があります。
WKT UIアプリケーションでは、WebLogic Serverドメイン構成に応じて、12つ以上の資格証明の格納が必要になる場合があります。 WKT UIによる資格証明ストアからの資格証明のロードへの初回アクセス時に、OSは、各資格証明へのアプリケーション・アクセスを許可するかどうかをプロンプトし、資格証明ごとに1回確認します。 これは迷惑になる可能性がありますが、一部のプラットフォーム(macOSなど)では、常にWKT UIアプリケーションによる資格証明へのアクセスを許可するようにOSに指示するオプションがあります。
資格証明を格納するもう1つの選択肢であるStore Encrypted in Project Fileは、資格証明をWKTプロジェクト・ファイルにインラインに格納できるようにするパスフレーズ・ベースの暗号化を使用します。 使用されるアルゴリズムと手法は、現在の業界標準および推奨事項に従います。ただし、このプロジェクトはオープン・ソースであるため、興味のある方は詳細を参照できます。 この方法では、パスフレーズ自体は格納されないため、WKT Projectファイルを使用できるほかのユーザーとパスフレーズを共有する必要があります。
クリエイティブなユーザーは、パスフレーズ・ベースの暗号化を使用して、ネイティブOS資格証明ストアに通常格納されている資格証明を別のマシンに移動できることに気付く場合があります。 これを行うステップは、次のとおりです:
最終的な選択であるNot Storedは、資格証明をまったく格納しません。 これは実行可能なオプションですが、資格証明を必要とするアクションを実行する必要がある場合は常に、プロジェクト内のすべての資格証明の値を再入力する必要があります。
新しいWKTプロジェクトを開始する際、最初に考慮すべき事項の1つは、ドメインを配置する場所です。 ドメインは、コンテナ、イメージまたは永続ボリュームに配置できます。 選択した場合、UIのほとんどのセクションで様々なフィールドが公開および非表示になります。 次に、3つのロケーションの意味について説明します:
Created in the container from the model in the image - ドメインの最新の最も一般的なロケーションはコンテナにあります。 これは"Model in Image"と呼ばれますが、基礎となるWKTツールでは"From Model"とも呼ばれます。 この場合、モデル関連ファイルのセットがイメージに追加されます。 WebLogic Kubernetes Operatorドメイン・オブジェクトがデプロイされると、インスペクタ・プロセスが実行され、実行中のコンテナ内にWebLogic Serverドメインがオンザフライで作成されます。 このプロセスは起動時に少量のオーバーヘッドを加えますが、イメージの保守も容易になります。 たとえば、最新のPatch Set Updates (PSU)をピック・アップするために定期的に更新される共通のWebLogic Serverイメージを持つことができます。 次に、そのイメージを使用して、最新バージョンのWebLogic Deploy Toolingおよびドメイン・モデル・ファイルを上位のレイヤーとして追加します。
Created as part of the image - この選択によって、ドメインがイメージに格納されます。 これは"Domain in Image"と呼ばれますが、WebLogic Kubernetes Operator構成では"イメージ"とも呼ばれます。 このオプションを使用すると、ドメインは(WebLogic Deploy Toolingを使用して)WebLogic Image Toolによってモデルから作成され、イメージにベイク処理されます。 これにより、起動時にわずかなオーバーヘッドが節約されますが、新しいWebLogic Serverイメージが作成されるたびにドメインを再作成する必要があるため、メンテナンスのコストが高くなります。
Externally created in a Kubernetes persistent volume - この選択は、ドメインをKubernetes永続ボリュームに格納します。これは"Domain in PV"と呼ばれます。 これは、ドメインがディスク上に作成され、必要に応じて使用および保守されるドメインを保守する従来の方法に近いものです。 使用しているFusion Middleware製品によっては、Kubernetesでドメインを実行するためにサポートされている唯一の選択肢になる場合があります。 WKT UIアプリケーションは、現在、永続ボリューム、必要な永続ボリューム要求またはドメインの作成に役立つことはありません。 これらのものが存在すると、アプリケーションを使用して、永続ボリュームに格納されている新しいドメインをデプロイできます。
ターゲット・タイプは、使用する予定のKubernetes環境の種類をアプリケーションに指示します。 現在、WebLogic Kubernetes OperatorおよびVerrazzanoは2つの選択肢のみです。 アプリケーションでは、ターゲット・タイプを使用して次のことを行います:
たとえば、KubernetesページはWebLogic Kubernetes Operatorターゲット・タイプに関連するため、Verrazzanoターゲット・タイプが選択されるとそれらのページとその関連アクションは非表示になります。かわりに、Verrazzanoページが表示されます。
アプリケーションは、WebLogic Deploy ToolingおよびWebLogic Image Toolの起動時にこれらのディレクトリを使用します。他の目的では使用しません。 これらのディレクトリを選択するときは、JAVA_HOMEおよびORACLE_HOME (またはMW_HOME)環境変数を設定するのと同じディレクトリを選択してください。 これらは通常、最上位のインストール・ディレクトリです。
新しいイメージをビルドし、イメージを検査し、イメージ・リポジトリと対話するには、WKT UIアプリケーションはイメージビルドツールを使用します。これはデフォルトでdockerに設定されます。 イメージビルドツールは、「前提条件」の説明に従ってローカルにインストールする必要があります。 dockerは現在最も人気のあるツールですが、多くのベンダー(Oracle、IBM RedHat、Googleなど)がデフォルトでpodmanを使用するように移行しています。