This feature is supported only in 3.0.0-rc1.
Model in Image is an alternative to the operator’s Domain in Image and Domain in PV domain types. See Choose a domain home source type for a comparison of operator domain types.
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 resource.
This feature is supported for standard WLS domains, Restricted JRF domains, and JRF domains.
WDT models are a convenient and simple alternative to WebLogic 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 Tool GitHub project.
For JRF domains, Model in Image provides additional support for initializing the infrastructure database for a domain, when a domain is started for the first time, supplying an database password, and obtaining an database wallet for re-use in subsequent restarts of the same domain. See Prerequisites for JRF domain types.
When you deploy a Model in Image domain resource:
DOMAIN_UID-weblogic-domain-introspect-cmand puts the packaged domain home in it.
Model updates can be applied at runtime by changing the image, secrets, or WDT model ConfigMap after initial deployment. If the image name changes, or the domain resource
restartVersion changes, then this will cause the introspector job to rerun and generate a new domain home, and subsequently the changed domain home will be propagated to the domain’s WebLogic pods using a rolling upgrade (each pod restarting one at a time). See Runtime updates.
To understand how Model in Image works with CI/CD, see CI/CD considerations.
Regardless of the domain home source type, we recommend that you always keep state outside the Docker image. This includes JDBC stores for leasing tables, JMS and transaction stores, EJB timers, JMS queues, and so on. This ensures that data will not be lost when a container is destroyed.
We recommend that state be kept in a database to take advantage of built-in database server high availability features, and the fact that disaster recovery of sites across all but the shortest distances, almost always requires using a single database server to consolidate and replicate data (DataGuard).