This sample demonstrates deploying a Model in Image domain home source type. Unlike Domain in PV and Domain in Image, Model in Image eliminates the need to pre-create your WebLogic domain home prior to deploying your Domain YAML file. Instead, Model in Image uses a WebLogic Deploy Tooling (WDT) model to specify your WebLogic configuration.
WDT models are a convenient and simple alternative to WebLogic Scripting Tool (WLST) configuration scripts and templates. They compactly define a WebLogic domain using YAML files and support including application archives in a ZIP file. The WDT model format is described in the open source, WebLogic Deploy Tooling GitHub project, and the required directory structure for a WDT archive is specifically discussed here.
There are three types of domains supported by Model in Image: a standard
WLS domain, an Oracle Fusion Middleware Infrastructure Java Required Files (
JRF) domain, and a
RestrictedJRF domain. This sample demonstrates the
JRF domain path through the sample includes additional steps required for JRF: deploying an infrastructure database, initializing the database using the Repository Creation Utility (RCU) tool, referencing the infrastructure database from the WebLogic configuration, setting an Oracle Platform Security Services (OPSS) wallet password, and exporting/importing an OPSS wallet file.
JRF domains may be used by Oracle products that layer on top of WebLogic Server, such as SOA and OSB. Similarly,
RestrictedJRF domains may be used by Oracle layered products, such as Oracle Communications products.
This sample demonstrates four Model in Image use cases:
Initial: An initial WebLogic domain with the following characteristics:
v1of an exploded Java EE web application
weblogic.domainUIDlabel set to
Update 1: Demonstrates updating the initial domain by dynamically adding a data source using a model ConfigMap.
spec.model.configMapreferencing the ConfigMap
Update 2: Demonstrates deploying a second domain (similar to the Update 1 use case domain).
envvariable that sets a new domain name
Update 3: Demonstrates deploying an updated image with an updated application to the Update 1 use case domain.
model-in-image:WLS-v2, similar to
myapp-v2directory path instead of
The sample contains the following files and directories:
||JRF and WLS Domain YAML files.|
||Source code location for WebLogic Deploy Tooling application ZIP archives.|
||Staging for each model image’s WDT YAML files, WDT properties, and WDT archive ZIP files. The directories in
||Staging files for a model ConfigMap that configures a data source.|
||Utility script for watching the pods in a domain reach their expected
||Utility script for updating a running domain
||Utility script for exporting or importing a JRF domain OPSS wallet file.|
If you run the sample from a machine that is remote to one or more of your Kubernetes cluster worker nodes, then you need to ensure that the images you create can be accessed from any node in the cluster.
For example, if you have permission to put the image in a Docker repository that the cluster can also access, then:
docker tagthe image with a target image name (including the registry host name, port, repository name, and the tag, if needed).
docker pushthe tagged image to the target repository.
image:value to match the Docker tag for the image in the repository.
docker secretto the same namespace that the Domain will use, and modify the Domain YAML file’s
imagePullSecrets:to reference this secret.
Alternatively, if you have access to the local Docker image cache on each worker node in the cluster, then you can use a Docker command to save the image to a file, copy the image file to each worker node, and use a
docker command to load the image file into the node’s image cache.
For more information, see the Cannot pull image FAQ.
For references to the relevant user documentation, see: