Model in image

Contents

Introduction

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.

For more information on Model in Image, 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.

Model in Image domain types (WLS, JRF, and Restricted JRF)

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 WLS and JRF types.

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.

Use cases

This sample demonstrates five Model in Image use cases:

  • Initial: An initial WebLogic domain with the following characteristics:

    • Image model-in-image:WLS-v1 with:
      • A WebLogic installation
      • A WebLogic Deploy Tooling (WDT) installation
      • A WDT archive with version v1 of an exploded Java EE web application
      • A WDT model with:
        • A WebLogic Administration Server
        • A WebLogic cluster
        • A reference to the web application
    • Kubernetes Secrets:
      • WebLogic credentials
      • Required WDT runtime password
    • A Domain with:
      • metadata.name and weblogic.domainUID label set to sample-domain1
      • spec.domainHomeSourceType: FromModel
      • spec.image: model-in-image:WLS-v1
      • References to the secrets

  • 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.

    • Image model-in-image:WLS-v1:
      • Same image as Initial use case
    • 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
    • A Domain, same as Initial use case, plus:
      • spec.model.configMap referencing the ConfigMap
      • References to data source secrets

  • Update 2: Demonstrates deploying a second domain (similar to the Update 1 use case domain).

    • Image model-in-image:WLS-v1:
      • Same image as the Initial and Update 1 use cases
    • 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.name and weblogic.domainUid label become sample-domain2 instead of sample-domain1
      • Its secret/ConfigMap references are decorated with sample-domain2 instead of sample-domain1
      • Has a changed env variable that sets a new domain name

  • Update 3: Demonstrates deploying an updated image with an updated application to the Update 1 use case domain and then restarting (rolling) its domain to propagate the change.

    • Image model-in-image:WLS-v2, similar to model-in-image:WLS-v1 image with:
      • An updated web application v2 at the myapp-v2 directory path instead of myapp-v1
      • An updated model that points to the new web application path
    • Kubernetes Secrets and ConfigMap:
      • Same as the Update 1 use case
    • A Domain:
      • Same as the Update 1 use case, except spec.image is model-in-image:WLS-v2

  • Update 4: Demonstrates dynamically updating the running Update 1 or Update 3 WebLogic domain configuration without requiring a domain restart (roll).

    • Image model-in-image:WLS-v1 or model-in-image:WLS-v2:
      • Same image as Update 1 or Update 3 use cases
    • 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.onlineUpdate set to enabled: true

Sample directory structure

The sample contains the following files and directories:

Location Description
domain-resources JRF and WLS Domain YAML files.
archives Source code location for WebLogic Deploy Tooling application ZIP archives.
model-images 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.
model-configmaps/datasource Staging files for a model ConfigMap that configures a data source.
model-configmaps/workmanager Staging files for a model ConfigMap that configures the Work Manager threads constraints.
ingresses Ingress resources.
utils/wl-pod-wait.sh Utility script for watching the pods in a domain reach their expected restartVersion, introspectVersion, image name, and ready state.
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).
utils/patch-restart-version.sh Utility script for updating a running domain spec.restartVersion field (which causes it to ’re-instrospect’ and ‘roll’).
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).
utils/opss-wallet.sh Utility script for exporting or importing a JRF domain OPSS wallet file.

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 tag the image with a target image name (including the registry host name, port, repository name, and the tag, if needed).
    • docker push the 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 secret to 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.

References

For references to the relevant user documentation, see: