Model in image
Contents
Introduction
This sample demonstrates deploying a Model in Image domain home source type with Auxiliary images . 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. 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 .
Furthermore, the Model in Image auxiliary image option lets you supply your WDT models files, WDT variable files, and WDT archives files in a small separate image separate from your WebLogic image.
For more information, see the Model in Image user guide. For a comparison of Model in Image to other domain home source types, see Choose a domain home source type .
Use cases
This sample demonstrates five Model in Image use cases:
-
Initial : An initial WebLogic domain with the following characteristics:
- Auxiliary image
wdt-domain-image:WLS-v1with:- A directory where the WebLogic Deploy Tooling software is installed (also known as WDT Home).
- A WDT archive with version
v1of an exploded Java EE web application - A WDT model with:
- A WebLogic Administration Server
- A WebLogic cluster
- A reference to the web application
- A WebLogic image with a WebLogic and Java installation.
- Kubernetes Secrets:
- WebLogic credentials
- Required WDT runtime password
- A Domain with:
metadata.nameandweblogic.domainUIDlabel set tosample-domain1spec.domainHomeSourceType: FromModelspec.imageset to a WebLogic image with a WebLogic and Java installation.- References to the secrets
- Auxiliary image
-
Update 1 : Demonstrates updating the initial domain by dynamically adding a data source using a model ConfigMap and then restarting (rolling) the domain to propagate the change. Updates:
- Kubernetes Secrets:
- Same as Initial use case, plus secrets for data source credentials and URL
- Kubernetes ConfigMap with:
- A WDT model for a data source targeted to the cluster
- Domain, same as Initial use case, plus:
spec.model.configMapreferencing the ConfigMap- References to data source secrets
- Kubernetes Secrets:
-
Update 2 : Demonstrates deploying a second domain (similar to the Update 1 use case domain). Updates:
- Kubernetes Secrets and ConfigMap:
- Similar to the Update 1 use case, except names and labels are decorated with a new domain UID
- A Domain, similar to Update 1 use case, except:
- Its
metadata.nameandweblogic.domainUidlabel becomesample-domain2instead ofsample-domain1 - Its secret/ConfigMap references are decorated with
sample-domain2instead ofsample-domain1 - Has a changed
envvariable that sets a new domain name
- Its
- Kubernetes Secrets and ConfigMap:
-
Update 3 : Demonstrates deploying an updated auxiliary image with an updated application to the Update 1 use case domain and then restarting (rolling) its domain to propagate the change. Updates:
- Auxiliary image
wdt-domain-image:WLS-v2, similar towdt-domain-image:WLS-v1image with:- An updated web application
v2at themyapp-v2directory path instead ofmyapp-v1 - An updated model that points to the new web application path
- An updated web application
- Domain:
- Same as the Update 1 use case, except
spec.imageiswdt-domain-image:WLS-v2
- Same as the Update 1 use case, except
- Auxiliary image
-
Update 4 : Demonstrates dynamically updating the running Update 1 or Update 3 WebLogic domain configuration without requiring a domain restart (roll). Updates:
- Kubernetes ConfigMap with:
- A WDT model for Work Manager minimum and maximum threads constraints, plus the same data source as the Update 1 use case
- Kubernetes Secrets:
- Same as the Update 1 and Update 3 use case, except:
- An updated data source secret with a new password and an increased maximum pool capacity
- A Domain, same as Update 1 or Update 3 use case, plus:
spec.configuration.model.onlineUpdateset toenabled: true
- Kubernetes ConfigMap with:
Sample directory structure
The sample contains the following files and directories:
| Location | Description |
|---|---|
kubernetes/samples/scripts/create-weblogic-domain/model-in-image/domain-resources |
Domain YAML files. |
kubernetes/samples/scripts/create-weblogic-domain/wdt-artifacts/archives |
Source code location for WebLogic Deploy Tooling application ZIP archives. |
kubernetes/samples/scripts/create-weblogic-domain/wdt-artifacts/wdt-model-files |
Staging for each model image’s WDT YAML files, WDT properties, and WDT archive ZIP files. The directories in model images are named for their respective images. |
kubernetes/samples/scripts/create-weblogic-domain/model-in-image/model-configmaps/datasource |
Staging files for a model ConfigMap that configures a data source. |
kubernetes/samples/scripts/create-weblogic-domain/model-in-image/model-configmaps/workmanager |
Staging files for a model ConfigMap that configures the Work Manager threads constraints. |
kubernetes/samples/scripts/create-weblogic-domain/ingresses |
Ingress resources. |
kubernetes/samples/scripts/create-weblogic-domain/model-in-image/utils/patch-introspect-version.sh |
Utility script for updating a running domain spec.introspectVersion field (which causes it to ’re-instrospect’ and ‘roll’ only if non-dynamic attributes are updated). |
kubernetes/samples/scripts/create-weblogic-domain/model-in-image/utils/patch-restart-version.sh |
Utility script for updating a running domain spec.restartVersion field (which causes it to ’re-instrospect’ and ‘roll’). |
kubernetes/samples/scripts/create-weblogic-domain/model-in-image/utils/patch-enable-online-update.sh |
Utility script for updating a running domain spec.configuration.model.onlineUpdate field to enabled: true (which enables the online update feature). |
In addition, this sample makes use of the waitForDomain.sh sample lifecycle script
that is located in the operator source kubernetes/samples/scripts/domain-lifecycle directory.
This is a utility script that optionally waits for the pods in a domain
to reach their expected restartVersion, introspectVersion, Completed, image, and ready state.
Ensuring your Kubernetes cluster can access images
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:
- After you’ve created an image:
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.
- Before you deploy a Domain:
- Modify the Domain YAML file’s
image:value to match the image tag for the image in the repository. - If the repository requires a login, then also deploy a corresponding Kubernetes
docker secretto the same namespace that the Domain will use, and modify the Domain YAML file’simagePullSecrets:to reference this secret.
- Modify the Domain YAML file’s
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.
References
For references to the relevant user documentation, see:
- Model in Image user documentation
- WebLogic Deploy Tooling
- WebLogic Image Tool