The first stop for every new project is Project Settings. In this section, you make decisions and provide
input for the project on:
When running the WKT UI application on Windows or Linux, the application inherits its environment from the user. For example, adding a directory to the PATH used by the application is just a matter of changing your PATH environment variable and restarting the application. On macOS, things are a bit more complicated.
When running the application on macOS, the application inherits the environment of a daemon process called launchd instead
of your environment. By default, the launchd environment contains only a few core directories on the PATH
(that is, /usr/bin, /bin, /usr/sbin, and /sbin). This will, for example, cause kubectl invocations requiring
access to one of the cloud providers' command-line tooling to fail if the tool is not found in one of those locations.
While it is possible for an administrative user to change the environment that launchd uses to address this issue, the
WKT UI application provides the Extra Path Directory table to explicitly add the directory where the cloud providers'
command-line tooling is installed, to the PATH that the application uses to invoke docker, podman, kubectl, and
helm. Also, use the Extra Environment Variable Name/Extra Environment Variable Value table to define extra
environment variables as needed. Note that this extra environment configuration is used only when invoking
Docker/Podman, kubectl, and Helm. This section is visible only when running the application on macOS.
The WKT UI application can securely store credentials for your project or not store them at all. The three choices are:
If you choose Store in Native OS Credential Store, then you will be using the Windows Credential Manager, the macOS Keychain,
or the Linux libsecret library’s credential store. These credential stores offer a well-known, secure mechanism for
storing credentials that most users already understand. The only downside to this scheme is that the credentials are
stored only on the local machine. Anyone trying to share their project with others users will have to have the other users
re-enter the credentials so that they get saved to their local machine’s credential store.
The WKT UI application can require storing a dozen or more credentials, depending on your WebLogic Server domain configuration. Upon first access by the WKT UI to load credentials from the credential store, the OS will prompt whether you want to allow the application access to each credential, prompting you once for each credential. This can get annoying, but on some platforms (for example, macOS), you have the option of telling the OS to always allow access to the credential by the WKT UI application.
The other choice to store credentials, Store Encrypted in Project File, uses a passphrase-based encryption built into the application that allows
the credentials to be stored inline in the WKT Project file. The algorithms and techniques used follow the current
industry standards and recommendations; however, because this project is open source, you can look at the details,
if you are interested. The only downside to this approach is that, because the passphrase itself is
never stored, you must share the passphrase with any other users that should be able to use the WKT Project file.
A creative person might realize that they can use the passphrase-based encryption to move credentials normally stored in the native OS credential store to another machine. The steps to accomplish this would be:
The final choice, Not Stored, is to not store the credentials at all. While this is a viable option, it also means that whenever you
need to run any of the actions that require credentials, you will need to re-enter the value of every credential in the
project.
When getting started with a new WKT Project, one of the first things to consider is where you want the domain to reside. Domains can reside in a container, in an image, or in a persistent volume. Your choice will expose and hide different fields across most sections of the UI. The following describe the implications of the three locations:
Created in the container from the model in the image - The newest and most popular location for a domain is in the container. This is known as “Model in Image” but also
referred to as a “From Model” in the underlying WKT tooling. In this case, the set of model-related files are added to
the image. When the WebLogic Kubernetes Operator domain object is deployed, its inspector process runs and creates the
WebLogic Server domain inside a running container on-the-fly. While this process adds a small amount of overhead at
startup, it also makes it easier to maintain the image. For example, you can have a common WebLogic Server image that
is updated periodically to pick up the latest Patch Set Updates (PSUs). Then, you use that image to add the
most recent version of the WebLogic Deploy Tooling and your domain model files as a layer on top.
Created as part of the image - This selection stores the domain in the image. This is known as “Domain in Image” but also is referred to as “Image”
in the WebLogic Kubernetes Operator configuration. Using this option, the domain is created from the model by the
WebLogic Image Tool (using the WebLogic Deploy Tooling) and baked into the image. While this saves a little overhead
at startup, it is more expensive to maintain due to the need to recreate the domain every time a new WebLogic
Server image is created.
Externally created in a Kubernetes persistent volume - This selection stores the domain in a Kubernetes persistent volume; this is known as “Domain in PV”.
This closely approximates the traditional way of maintaining a domain where the domain is created on disk and then
used and maintained for as long as necessary. Depending on which Fusion Middleware products you are using, this may be
your only supported choice for running the domain in Kubernetes. The WKT UI application currently doesn’t do anything to help
you create the persistent volume, the necessary persistent volume claim, or the domain. After those things exist, the
application will allow you to use them to deploy new domains stored in a persistent volume.
The target type tells the application what sort of Kubernetes environment that you plan to use. Currently, WebLogic Kubernetes Operator and Verrazzano are the only two choices. The application uses the target type to:
For example, the Kubernetes pages are relevant to the WebLogic Kubernetes Operator target type, so those pages
and their associated actions are hidden when the Verrazzano target type is selected; instead, the Verrazzano
pages are displayed.
The application uses these directories when invoking the WebLogic Deploy Tooling and WebLogic Image Tool; it does not
use them for any other purpose. When selecting these directories, make sure to select the same directory you would use
to set the JAVA_HOME and ORACLE_HOME (or MW_HOME) environment variables. These are generally the top-level
installation directories.
To build new images, inspect images, and interact with image repositories, the WKT UI application uses an image build
tool, which defaults to docker. The image build tool must be installed locally, as mentioned in the Prerequisites.
While docker is currently the most popular tool, many vendors (for example, Oracle, IBM RedHat, Google) are moving to
use podman by default.