This sample demonstrates deploying a Domain on PV domain home source type with Domain creation images. The Domain on PV sample uses a WebLogic Deploy Tooling (WDT) model to specify your initial WebLogic configuration.
WDT models are a convenient and simple alternative to WebLogic Scripting Tool (WLST) configuration scripts. They compactly define a WebLogic domain using model files, variable properties files, and application archive files. 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.
For more information, see the Domain on PV user documentation.
Domain on PV is supported on two types of domains: a standard Oracle WebLogic Server (WLS) domain and an Oracle Fusion Middleware Infrastructure, Java Required Files (JRF) domain. This sample demonstrates both WLS and JRF domain types.
The JRF domain path through the sample includes additional steps required for JRF: deploying an infrastructure database, referencing the infrastructure database from the WebLogic configuration, setting an Oracle Platform Security Services (OPSS) wallet password, and exporting or 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.
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 domain creation image’s WDT YAML files, WDT properties, and WDT archive ZIP files. The directories in
||Utility script for exporting or importing a JRF domain OPSS wallet file.|
||Utility script that optionally waits for the pods in a domain to reach their expected
||Utility script to examine or clean up the contents of shared directories on the persistent volume.|
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 container registry 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.
spec.configuration.initializeDomainOnPV.domain.domainCreationImages[*].imagevalue to match the image 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 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: